From Prediction to Action
A prediction is not itself a business decision. A score that estimates the probability of a claim containing an overpayment does not review the claim, and a forecast of incoming service requests does not schedule staff. To be useful, a prediction must connect to an action that a decision-maker can actually take. That connection should be specified before a model is built: otherwise, a model may produce outputs that are difficult to interpret operationally or impossible to use.
The earlier material on translating business questions into predictive tasks and identifying the decision-maker and decision provides the context for this step. Here the focus is the bridge between the prediction and the action: which output leads to which response, what makes that response worthwhile, and whether the organization has the resources and authority to carry it out. Examples below use hypothetical insurance and service settings.
Actions can be individual or aggregate. An individual probability might determine whether a claim is referred for review; a forecast of total demand might inform a staffing plan. In either case, the action must be described in operational terms: “refer the claim to the review queue” or “schedule an additional hour of staff coverage” is more useful than “use the score.”
Specify the Action and Its Feasibility
A practical action rule starts by listing the responses the organization can take. For example, a claim team might be able to review, defer, or take no further action on a claim. The rule should then state what prediction information triggers each response and what capacity is available. A threshold rule may be suitable when each case can be considered independently and there is enough capacity to act on every case that qualifies. If capacity is limited, the rule may instead rank qualifying cases and select the highest priorities.
State what staff can actually do, such as review, contact, refer, or schedule additional coverage.
Specify which probability, score, or forecast informs the action and how the response is selected.
Compare the expected consequences of acting with the consequences of not acting, using the assumptions relevant to the decision.
Confirm capacity, staff time, eligibility, timing, and a workable process for cases that cannot be acted on as planned.
A prediction can support prioritization without determining an action automatically. A high estimated probability does not by itself establish that a particular intervention will change an outcome. The action’s costs, benefits, and operational requirements must also be considered. In practice, these may be supplied by business rules or separate evidence about the action; they are not established merely by a predictive score.
A Simple Decision Threshold
A basic threshold can be derived when there are two choices: take an action or do not take it. Suppose an event has predicted probability \(p\). Assume, for this calculation, that taking the action costs \(C\) regardless of whether the event occurs, and produces a benefit \(B\) if the event occurs. Assume no additional benefit or cost in other circumstances, and compare expected net benefit with zero. These simplifying assumptions must match the decision; the threshold does not apply unchanged if the action has different consequences, uncertain effectiveness, or important non-financial effects.
The action has positive expected net benefit when \(pB-C>0\). Since \(B>0\), adding \(C\) to both sides and dividing by \(B\) gives the threshold:
This derivation explains why the ratio \(C/B\) is a threshold: the expected benefit, \(pB\), must exceed the action’s cost, \(C\). If \(p=C/B\), the expected net benefit is zero under the stated assumptions. The threshold says nothing by itself about whether the action can be performed for every qualifying case.
Worked Example: A Review Threshold With One Available Slot
A hypothetical insurer is considering a review of claims flagged by a predictive model. For this decision, assume the model supplies a calibrated probability \(p\) that a claim has an eligible overpayment. A review costs $100 per claim and, if the event is present, recovers $400. Assume the recovery is certain when the event is present, there is no recovery otherwise, and the review cost is incurred in either case. Two claims have probabilities 0.35 and 0.27, but the team can review only one today. Determine the threshold and the claim to review.
Method and assumptions. Use the expected-net-benefit rule above. Here \(C=\$100\) and \(B=\$400\), and the assumptions in the problem match the simple threshold model.
Threshold. Divide the review cost by the benefit if the event is present:
A claim qualifies when its probability is greater than 0.25. For the claim with \(p=0.35\), expected recovery is \(0.35\times \$400=\$140\), so expected net benefit is \(\$140-\$100=\$40\). For the claim with \(p=0.27\), expected recovery is \(0.27\times \$400=\$108\), so expected net benefit is \(\$108-\$100=\$8\).
Decision with capacity. Both claims exceed 0.25 and have positive expected net benefit. Because only one claim can be selected, review the claim with \(p=0.35\), which has the higher expected net benefit. The capacity constraint prevents reviewing both; it does not make the \(p=0.27\) claim fail the threshold.
Check. The selected claim has expected net benefit \(\$40\), compared with \(\$8\) for the other claim. The decision is consistent with both the threshold and the one-slot limit. The common mistake is to say that only the \(p=0.35\) claim qualifies; the correct distinction is that both qualify, but only the higher-priority one can be selected.
Prioritize When Capacity Is Limited
A threshold and a capacity rule answer different questions. A threshold identifies cases whose expected value meets a specified criterion under the assumptions used. A capacity rule determines which cases to act on when the organization cannot handle all of them. If every selected action uses the same amount of capacity, ranking cases by expected net benefit is a natural approach. If actions require different amounts of time or have different constraints, a simple ranking may not produce the best allocation; the operational rule must account for those differences.
Worked Example: Selecting Two Claims for Investigation
A hypothetical investigation unit can handle two claims in its current work period. Each investigation costs $50. For each claim, the model provides the probability of an eligible overpayment, and the claim file provides the amount recoverable if that event is present. Assume the stated amount is fully recovered when the event is present, no amount is recovered otherwise, and each investigation consumes the same unit of capacity. Select two claims from the following:
| Claim | Probability | Recoverable amount if event is present |
|---|---|---|
| A | 0.20 | $3,000 |
| B | 0.40 | $1,000 |
| C | 0.15 | $5,000 |
Method. For each claim, multiply the probability by the recoverable amount to obtain expected recovery, then subtract the $50 investigation cost. Because all investigations use equal capacity, select the two claims with the largest positive expected net benefits.
For claim A, expected recovery is \(0.20\times \$3{,}000=\$600\), so expected net benefit is \(\$600-\$50=\$550\). For claim B, expected recovery is \(0.40\times \$1{,}000=\$400\), so expected net benefit is \(\$400-\$50=\$350\). For claim C, expected recovery is \(0.15\times \$5{,}000=\$750\), so expected net benefit is \(\$750-\$50=\$700\).
The ranking is C (\$700), A (\$550), then B (\$350). The unit should investigate C and A. Their combined expected net benefit is \(\$700+\$550=\$1{,}250\). The selection uses exactly two investigation slots.
Check. Claim B has the highest probability, but not the highest expected net benefit. Ranking by probability alone would select B and C, with combined expected net benefit \(\$350+\$700=\$1{,}050\), which is \(\$200\) less than selecting C and A. The calculation uses the assumption that the amount shown is recoverable if the event is present; if that assumption is not appropriate, the expected-value comparison must be revised.
Convert Forecasts Into Feasible Plans
Not every action rule uses individual probabilities. A numerical forecast can be converted to an operational quantity, such as workload or staff time. This conversion requires explicit planning assumptions: for example, average handling time and available productive minutes. A point forecast should not be treated as a guarantee that the actual workload will equal the forecast. A workable plan should acknowledge that uncertainty and specify what happens if demand exceeds planned capacity.
Worked Example: Turning a Workload Forecast Into Coverage
A hypothetical service team receives a forecast of 42 requests for the next shift. For a basic staffing calculation, assume each request requires 15 minutes of handling time. Eight scheduled agents each have 75 productive minutes available during that shift. A flex agent can be called in for a minimum block of 60 productive minutes. Determine whether the scheduled team can cover the forecast workload and whether one flex block is sufficient.
Forecast workload. Multiply the number of forecast requests by the assumed handling time: \(42\times 15=630\) agent-minutes.
Scheduled capacity. The scheduled agents provide \(8\times 75=600\) agent-minutes. The forecast workload exceeds this capacity by \(630-600=30\) agent-minutes, so the scheduled team alone does not cover the forecast.
Action and capacity check. Calling in one flex block adds 60 productive agent-minutes, bringing total capacity to \(600+60=660\) agent-minutes. The plan then has \(660-630=30\) minutes of capacity beyond the forecast workload. Under the assumptions given, one flex block is sufficient for the point forecast.
Check and limitation. The proposed action is feasible because its 60-minute block covers the 30-minute shortfall and fits the stated staffing option. This calculation does not guarantee coverage if actual demand exceeds 42 requests or handling time exceeds 15 minutes. A complete operating procedure should say who monitors incoming work and what escalation is available if the forecast is exceeded. A common mistake is to compare 42 requests directly with “eight agents” without converting both demand and capacity to the same unit of time.
Common Implementation Traps
- Treating a prediction as an action. A probability or forecast describes expected information; it does not specify who will respond, what they will do, or by when.
- Confusing a threshold with a capacity limit. A case can qualify under a threshold even when it cannot be selected because all available slots are already assigned.
- Ranking by the wrong quantity. When potential consequences differ by case, the largest probability need not correspond to the greatest expected value of action.
- Ignoring resource units. Compare workload and capacity in compatible units, such as agent-minutes, rather than comparing a count of requests with a count of agents.
- Assuming the action works because the prediction is high. Predicting an event and changing its likelihood are different claims. Do not infer that contact, review, or another intervention will prevent an outcome solely from a predictive association.
- Leaving exceptions undefined. If a case is ineligible, capacity is exhausted, or demand exceeds the forecast, staff need a clear alternative such as a queue, escalation, or later review.
These checks matter because even a technically sound prediction can fail to improve a process if it leads to an infeasible or poorly specified response. Before implementation, the decision-maker should be able to describe the action rule, its operating limits, and the fallback for cases the plan cannot handle. The aim is not to make every prediction trigger an action; it is to make the intended use explicit and workable.
Check Your Understanding
For each problem, identify the action rule or feasibility check and verify the arithmetic.
- A hypothetical review costs $90 and produces a $600 recovery if an eligible event is present. Under the assumptions of the simple threshold model, find the probability threshold and the expected net benefit when \(p=0.18\). (Answer: Threshold \(p>0.1500\); expected net benefit is \(0.18\times \$600-\$90=\$18\), so the review has positive expected net benefit.)
- A team can review one case. Each review costs $100 and recovers $500 if the event is present. Two cases have probabilities 0.22 and 0.19. Which cases meet the threshold, and which should be selected? (Answer: The threshold is \(p>0.2000\); only the case with \(p=0.22\) qualifies, so select it.)
- A hypothetical unit can investigate one of two cases. Both investigations cost $100. Case A has probability 0.30 and recoverable amount $1,200; case B has probability 0.20 and recoverable amount $2,000. Assuming full recovery when the event is present, which case has the larger expected net benefit? (Answer: A: \(0.30\times \$1{,}200-\$100=\$260\); B: \(0.20\times \$2{,}000-\$100=\$300\); select B.)
- A forecast indicates 36 requests, each requiring an assumed 20 minutes. Six agents each have 100 productive minutes available. How many additional agent-minutes are needed to cover the forecast? (Answer: Workload is \(36\times20=720\) minutes; scheduled capacity is \(6\times100=600\) minutes; the shortfall is 120 agent-minutes.)
- A forecast of 30 service cases implies 12 minutes per case. The team has 360 productive agent-minutes, and the available flex option adds a minimum of 60 minutes. Is the flex option needed for the point forecast, and what operational uncertainty remains? (Answer: Forecast workload is \(30\times12=360\) minutes, exactly equal to scheduled capacity, so no flex time is needed for the point forecast; actual workload or handling time could exceed the assumptions, so a monitoring and escalation plan is still needed.)