From a Business Concern to a Predictive Task
Business questions often begin as broad concerns: “Can we improve renewals?”, “Why are claims taking longer?”, or “Where should we focus our analysis?” These are useful starting points, but they do not yet say what a predictive model should estimate. Different interpretations of the same concern can lead to different outcomes, different prediction units, and different uses. A model cannot be sensibly developed until the question has been translated into a task with those choices made explicit.
The goal at this stage is not to choose a model or decide exactly what operational action should follow a prediction. It is to state, in plain language, what is to be predicted, for whom or what, when the prediction is made, and how the prediction is intended to be used. This framing gives the later analysis a clear direction without assuming that a particular algorithm or data source has already been selected.
A business concern may support several valid predictive tasks. For example, “reduce claim handling delays” could lead to predicting which newly reported claims will need extended handling, estimating the number of claims likely to arrive next month, or forecasting the time until a particular claim is closed. These are not interchangeable: they predict different outcomes, for different units, at potentially different times. A task statement makes the chosen interpretation visible.
A Four-Part Specification
Use four questions to translate a broad concern. Each answer should be specific enough that another analyst could describe the intended prediction without guessing.
Name the event, amount, count, or other result that the prediction concerns. Avoid placeholders such as “risk,” “performance,” or “success” unless they are defined in the task.
State the population or objects covered and the unit to which one prediction refers, such as a policy, claim, customer, or geographic area.
Specify the point in the process at which the prediction is intended to be available. “Before renewal” or “when a claim is first reported” is more informative than “in advance.”
Describe the broad purpose, such as planning workload, supporting budgeting, or prioritizing review. Keep this at the level needed to explain why the prediction matters.
A compact statement can be written as follows:
Here, \(Y\) names the outcome, \(\mathcal{U}\) is the stated population of prediction units, \(t_0\) is the prediction time, and \(A\) is the intended use. This is a planning template, not a statistical model. It does not specify which data to collect, which algorithm to fit, or how to turn a prediction into a particular action.
Why the Four Parts Belong Together
The specification is useful because a prediction is meaningful only relative to a defined outcome, unit, and time. Consider a statement such as “predict high risk.” It does not identify what result counts as risk, whether the prediction is for a customer or a claim, or when the result must be available. Even a technically accurate score would be difficult to interpret or evaluate against that statement.
The logic can be expressed as a simple dependency. A prediction record needs a defined unit and a defined prediction time; the outcome must then refer to that unit in a way that makes sense for the stated task. If any component is left open, the task can be interpreted in multiple ways.
This is a justification for specifying the task before proceeding: the model’s output has no stable interpretation until each part is fixed. For instance, “the number of claims” could refer to a count per policy, per territory, or per month. The count and the unit together determine what one predicted value represents. Similarly, a forecast made at policy inception is a different product from one made shortly before renewal, even if both concern the same eventual outcome.
The intended use completes the statement by explaining why the prediction is being requested. It helps distinguish a useful prediction from an outcome that is merely available in a data file. At this stage, a broad use such as “support quarterly staffing plans” is enough; detailed choices about decision-makers, thresholds, or actions can be specified separately.
Worked Example: Framing a Renewal Concern
A hypothetical insurer asks, “How can we improve policy renewals?” The phrase “improve renewals” is broad. Translate it into one predictive task for planning renewal operations. The insurer wants a prediction available 45 days before each policy’s scheduled renewal date. For this exercise, define a nonrenewal as a policy that has not renewed by its scheduled renewal date.
Step 1: Identify the outcome. The outcome is whether the policy renews by its scheduled renewal date. This turns the vague word “improve” into an observable result. It does not claim that the model will explain why a policy does not renew.
Step 2: Identify the prediction unit and population. One prediction is for one policy approaching its scheduled renewal. The population is the insurer’s policies with a renewal date for which the prediction is requested. It would be ambiguous to say simply “customers,” because one customer could hold more than one policy.
Step 3: State the prediction time. The prediction is made 45 days before the scheduled renewal date. The statement now identifies when the result is needed, rather than leaving “in advance” open to interpretation.
Step 4: State the intended use. The prediction is intended to support planning the volume and timing of renewal operations. This describes a purpose without prescribing a particular contact, intervention, or threshold.
Task statement. Predict, for each policy approaching its scheduled renewal, whether it will have renewed by that date, using a prediction made 45 days beforehand, to support planning renewal operations.
Method and mistake avoided. The four-part decomposition converts the business phrase into a task with a defined outcome, unit, time, and use. A common mistake would be to write “predict which customers will leave,” which changes the unit from policy to customer and leaves “leave” undefined.
Worked Example: Defining a Claim-Handling Prediction
A hypothetical insurer’s claims team reports that some newly reported property claims require substantial follow-up. It asks, “Can we identify complex claims?” For a planning exercise, the team wants a prediction at the initial claim report. Define a claim as requiring extended handling if it remains open 60 days after that report. State a predictive task that could help estimate the workload requiring follow-up.
Step 1: Replace the vague outcome. “Complex” has no stated operational definition. The task will instead predict whether a claim remains open 60 days after its initial report. This is the outcome specified for this exercise; it should not be described as a universal definition of claim complexity.
Step 2: Identify the prediction unit. Each prediction concerns one newly reported property claim. The unit is not the policyholder or the entire claims team, because the requested result concerns the handling outcome for an individual claim.
Step 3: Fix when the prediction is made. The prediction is made at the initial report. That timing is part of the task, not an incidental implementation detail: a prediction requested at the initial report is not the same task as one requested after several weeks of handling.
Step 4: State the purpose. The intended use is to estimate and plan the volume of claims requiring follow-up workload. The task does not yet specify which claims should be assigned to a particular adjuster.
Task statement. At the initial report of each property claim, predict whether the claim will still be open 60 days later, for the purpose of planning claims follow-up workload.
Method and mistake avoided. The four-part decomposition replaces a subjective label with the stated outcome and makes the prediction unit and time explicit. A common mistake would be to define the outcome as “claims that need more attention.” That wording is not precise enough to identify which recorded result should count as the outcome.
Worked Example: Turning a Budgeting Question Into a Forecast Task
A hypothetical benefits administrator asks, “How much should we budget for reimbursements next quarter?” The administrator wants a forecast prepared at the end of the current quarter, covering the next calendar quarter, to support budget preparation. Frame a predictive task. State what one prediction represents and do not substitute a per-person prediction for the requested total.
Step 1: Identify the outcome. The outcome is the total dollar amount of reimbursements paid during the next calendar quarter. “How much should we budget?” is a business question; the forecast target is the specified amount paid over the period.
Step 2: Identify the unit and population. One prediction is a total for the administrator’s covered plan population, not a separate reimbursement forecast for each member. The task therefore concerns an aggregate amount for the covered population.
Step 3: State the prediction time. The forecast is prepared at the end of the current quarter. The target period is the next calendar quarter. These are different pieces of the specification: one says when the forecast is issued, and the other says which period’s outcome is forecast.
Step 4: State the use. The forecast is intended to support preparation of the next quarter’s budget. It is not itself a statement of the budget decision or of how the funds will be allocated.
Task statement. At the end of each quarter, forecast the total dollars of reimbursements paid for the covered plan population in the following calendar quarter, to support preparation of that quarter’s budget.
Method and mistake avoided. The same four questions distinguish an aggregate forecast from individual-level predictions. A common mistake would be to forecast reimbursement per member and call that the requested answer without stating how it relates to the total. This task asks directly for the aggregate dollar amount.
Reviewing a Draft Task Statement
Before accepting a task statement, read it as if you had not heard the original business discussion. Ask whether you could answer each of these questions without making an assumption:
- What exact result is being predicted?
- What people or objects receive predictions, and what does one prediction refer to?
- At what point must the prediction be available?
- What broad purpose makes the prediction useful?
If one answer is missing, revise the statement rather than silently filling in the gap. A clear statement does not guarantee that the proposed task is feasible or that suitable data exist. It does, however, make those questions possible to investigate. It also helps prevent analysts from building a model for a convenient recorded outcome that does not address the stated concern.
The intended use should be concrete enough to explain the business relevance but not overloaded with decisions that have not yet been defined. “Support workload planning” is more informative than “help the business.” Conversely, writing a complete operational policy at this stage can obscure the predictive question. Keep the task focused on what the prediction represents and why it is wanted.
Check Your Understanding
For each situation, identify the main ambiguity and write or select a more precise task statement.
- A hypothetical insurer says, “Predict claim risk.” It wants a result for each newly reported liability claim when the claim is first recorded, for use in planning claim workload. State an outcome that would make the task specific, and then write the task statement. (Answer: One valid choice is to predict whether each newly reported liability claim will remain open 90 days after first report, with predictions made at first report to support workload planning; “risk” alone is undefined.)
- A transit agency asks for a forecast of late arrivals. Specify a task for the agency’s next-day operations meeting, where the requested prediction is the total number of buses arriving more than 10 minutes after their scheduled time during the following day. (Answer: At the next-day operations meeting, forecast the total number of buses arriving more than 10 minutes late during the following day, to support operations planning.)
- A hypothetical insurer wants to “identify customers likely to have costly losses.” Explain one ambiguity in this statement and revise it for predictions made at the start of each policy year, with the intended use of annual portfolio budgeting. (Answer: “Costly” and the prediction unit are ambiguous. One valid revision is: at the start of each policy year, predict the total dollars of paid losses during that year for each policy, to support annual portfolio budgeting.)
- A health plan asks, “Which members will use services?” It wants a prediction for each enrolled member at the start of the calendar year to estimate the plan’s total number of members with at least one covered outpatient visit that year. State a task that matches the stated aggregate use. (Answer: At the start of the calendar year, predict the number of enrolled members who will have at least one covered outpatient visit during that year, to support estimating the plan’s total number of such members.)
- A property manager requests “a forecast of maintenance problems” for the next month. Rewrite the request so that the outcome, unit, prediction time, and use are all stated, using this scenario: predict whether each building will have at least one emergency repair during the next calendar month; issue predictions on the final day of the current month; use them for monthly staffing plans. (Answer: On the final day of each month, predict for each building whether it will have at least one emergency repair during the next calendar month, to support monthly staffing plans.)