Earlier version · Where enterprise AI value actually lands
Where does enterprise AI value go?
A successful automated case can be cheap. The business case still depends on how many people use the system, how often exceptions occur, and how much work those exceptions create.
Prior version — preserved text. Read the current version.
The work that a cheap answer leaves behind
The cost of a successful AI task is a weak guide to the value of an AI programme. Exception work and adoption can decide the outcome even when inference is cheap. In financial operations, the useful operating question is who does the work left behind: resolving ambiguity, correcting a field and accepting responsibility for the next step.
Public evidence also argues against using one productivity uplift everywhere. Brynjolfsson, Li and Raymond’s 2023 NBER working paper studies a conversational assistant in customer support and reports uneven gains across workers. That supports asking who benefits and on which work. It does not calibrate review rates, labour costs or adoption for this calculator.
The model below makes the decision inspectable. All its inputs and slider bounds are synthetic. They are stress-test choices, not observed industry ranges or a claim about a customer deployment.
Try the operating model
All values are illustrative. Currency is USD; change the costs to fit your own model.
| Fully manual baseline | $20,000 |
|---|---|
| Unadopted cases: labour | $8,000 |
| Exception review: labour | $4,500 |
| AI usage | $600 |
| Fixed operating cost | $2,000 |
| Total with AI | $15,100 |
Three scenarios, and what changes the sign
At 1,000 cases a month, 20 manual minutes per case, $60 per hour and $2,000 fixed operating cost, the manual baseline is $20,000. With 60% adoption, 25% review, 30 minutes per exception and $1 AI usage per adopted case, modelled net benefit is $4,900; 125 hours are released. The labour difference is capacity, not automatically cash savings.
Hold those common assumptions fixed. At 85% adoption, 10% review and 20 review minutes, net benefit becomes $12,450. At 75% adoption, 60% review and 50 review minutes, it becomes a $10,250 loss and adds 125 hours of work. These are arithmetic comparisons of synthetic scenarios, not measured ROI.
For planning, test adoption at 20%, 60% and 85%; review at 5%, 25% and 60%; and review duration at 15, 30 and 120 minutes. These are illustrative sensitivity points. Replace them with eligible-case uptake, actual intervention frequency and resolution times from the specific process before making an investment decision.
The exception rate can improve while the economics worsen
Expected review cost per adopted case is review probability × review minutes × hourly cost ÷ 60. At $60 per hour, 25% review and 30 minutes, that is $7.50 against $1 of AI usage. Review dominates usage in this scenario; it need not dominate when review is brief or inference is expensive.
A smaller exception rate can hide a more expensive remaining workload. Five percent needing two hours costs $6 per adopted case; twenty percent needing fifteen minutes costs $3. A system can handle more routine work while concentrating difficult cases in a smaller queue. Measure the distribution of review effort, not just its average or frequency.
More adoption scales whatever per-case economics you have. It spreads fixed cost only if adopted work has positive value after expected intervention and usage cost. If that value is negative, greater adoption compounds the loss. A backlog of specialist review can also increase waiting time, which this linear calculator does not model.
Follow the exception work
The starting scenario appears attractive. Yet a higher review rate or a longer review process can absorb the time saved by successful automation. An evaluation should measure recovery cost alongside answer quality.
Adoption matters for a different reason. Fixed operating costs are paid even when few cases use the system. A technically sound product can therefore have weak economics until enough suitable work passes through it.
Released capacity is an operating option. Turning it into financial value requires a separate plan: more throughput, shorter turnaround, less overtime, or other measurable work. A modelled labour difference alone does not establish realised savings.
When a simpler business case is enough
A useful counterargument is that a repetitive, stable workflow may need little exception handling. In that case, a simple cost-per-case comparison can be enough. The risk comes from applying that result to a different workflow, where review consumes specialist attention or adoption stays low. Measure those conditions before carrying the estimate across.
Model and assumptions
Manual baseline hours = cases × manual minutes ÷ 60. Adopted cases = cases × adoption. Remaining manual hours = unadopted cases × manual minutes ÷ 60. Review hours = adopted cases × exception rate × review minutes ÷ 60.
Net benefit = baseline labour cost − remaining manual labour − review labour − AI usage − fixed operating cost. Where per-case value is positive, break-even adoption = fixed cost ÷ (monthly cases × value per adopted case). Per-case value is avoided manual labour minus expected review labour and AI cost.
With zero fixed cost and negative per-case value, only zero adoption breaks even; additional adoption reduces benefit. With zero fixed cost and zero per-case value, every adoption level breaks even. “Not reachable” means no adoption level between zero and 100% breaks even.
Adopted cases without exceptions are assumed to need no additional human handling. The model assumes constant volume, average labour rates and linear costs. Include residual handling in expected review time or extend the model if needed. Up-front implementation, quality failures outside review, transition effort and demand changes are excluded. No customer outcomes or deployed product performance are represented.
What to measure next
Measure adoption on eligible work, the share of cases needing intervention, and the minutes required to resolve them. Then test whether released capacity creates an outcome anyone values. Those observations give a stronger business case than multiplying a successful demonstration by the size of a team.
This is an illustrative operating model, not observed ROI. Its assumptions are synthetic. Your scenario stays in this page and is not uploaded.
Sources and attribution
This is an original, self-published piece. Sources support the referenced frameworks. Observed incidents, design principles and illustrative examples are identified separately in the text.