Business & Money
How to Build an Honest AI ROI Case Your CFO Will Believe
By Jim Vernon, Editor, AI Intelligence International · Published 9 January 2026 · Reviewed against our editorial standards · About the author
The typical AI business case multiplies a number of employees by minutes saved per day by an hourly rate, and arrives at a figure large enough to embarrass everyone in the room. Finance teams have learned to discount these instantly, because saved minutes that do not change a cost line are not savings.
An honest case is smaller, slower, and far more likely to get funded twice. It separates cash savings from capacity gains, prices the work of adoption, and states what has to be true for the number to hold.
Key takeaways
- The saved-minutes fallacy: Saving each of forty people twenty minutes a day sounds like three full-time roles.
- Counting the costs people forget: Licences are the visible cost and usually the smallest.
- Modelling the transition, not the steady state: Benefits arrive on a curve.
- Risk-adjusting the benefit: Attach a probability to the benefit and state the assumptions behind it.
The saved-minutes fallacy
Saving each of forty people twenty minutes a day sounds like three full-time roles. In practice it is forty people with slightly less pressure, which is valuable but does not appear in any budget line.
Time converts to money only through three mechanisms: you reduce headcount, you avoid a hire you would otherwise make, or you increase revenue-generating output with the same team. If your case does not run through one of those, call it a quality or morale benefit and stop attaching a currency symbol to it.
This is not pedantry. Cases that overstate savings get audited after two quarters, and the finding poisons the next three proposals.
Counting the costs people forget
Licences are the visible cost and usually the smallest. The real costs are integration engineering, the review time that replaces production time, prompt and process maintenance, security and legal review, training, and the productivity dip during transition.
Add an ongoing evaluation cost. Model behaviour changes when vendors update, so someone has to re-test periodically. Budget it explicitly or it will be absorbed silently by whoever is least able to refuse.
As a planning heuristic, non-licence costs in year one commonly run two to four times the licence cost for anything touching a core workflow.
Modelling the transition, not the steady state
Benefits arrive on a curve. A realistic model has a three-month ramp at near zero net benefit, a middle period where quality issues surface and consume review time, and a steady state that starts somewhere in months six to nine.
Straight-line annual savings figures are the single most common reason a case fails post-implementation review, because the first two quarters always underperform the average.
Model monthly. It forces honesty about the ramp, and it gives you an early-warning tripwire: if month four looks nothing like the model, you can correct before the annual review.
Risk-adjusting the benefit
Attach a probability to the benefit and state the assumptions behind it. A pilot that already ran with real users might justify eighty percent confidence; a vendor demo justifies far less.
Then add the cost of being wrong: an error that reaches a customer, a compliance finding, rework. In regulated contexts this can dominate the model, and pretending otherwise means the risk team blocks the project at the last gate.
A case that shows a smaller, risk-adjusted number with an explicit downside scenario is consistently more fundable than an optimistic one, because it tells the approver you have thought about their exposure as well as your own.
Choosing the right first project
The best first project is high volume, low variance, easy to evaluate, and owned by one team. High volume so the effect is measurable, low variance so the model performs consistently, easy to evaluate so quality is not a debate, and single-owner so nobody can veto it late.
Avoid anything requiring data you do not already have permission to use. Data access negotiations are where enthusiastic projects go to die quietly over nine months.
Write the success criteria before the pilot and get them signed. A pilot with retrospective criteria always succeeds and therefore teaches nothing.
Presenting the number
Lead with the decision you want, not the technology. One slide: the problem, the cost of the status quo, the intervention, the risk-adjusted benefit, the assumptions that would break it, and what you need.
Run the ROI model with conservative inputs first and show the optimistic case second. Approvers trust people who show them the pessimistic case unprompted, and that trust is worth more across a programme than any single approval.
Count the costs people leave out
Most ROI cases include licence fees and stop. The costs that actually decide whether a project pays are the review time on every output, the engineering days spent integrating and maintaining, the training and change-management effort, and the cost of the failures that reach a customer.
Review time is the largest hidden cost in text-heavy work. If a draft takes two minutes to produce and eight minutes to verify, the saving against a twenty-minute manual draft is real but half of what the headline suggests.
Include a contingency for rework in year one. Every deployment gets at least one prompt rewrite and one model change, and both consume time nobody budgeted.
A worked example that survives scrutiny
Baseline: forty support replies a day at eleven minutes each, roughly seven and a third hours. After deployment: forty replies at four minutes of review each, roughly two and two-thirds hours, plus about one hour a week of prompt and quality maintenance.
That is a saving of around four and a half hours a day, less the maintenance hour, against a licence and usage cost you can read off an invoice. Expressed as hours rather than pounds, the number survives a finance review because every input is checkable.
Then state what the freed hours are for. 'Absorb the twenty per cent volume growth forecast for next quarter without hiring' is a claim that can be verified in six months. 'Increased productivity' cannot, and finance has heard it before.
Frequently asked questions
What payback period is realistic?
For a well-chosen workflow project, twelve to eighteen months including integration. Anything promising under six months is usually counting saved minutes as cash.
Should the savings be given back to finance?
Decide before the pilot. Teams that discover the answer afterwards stop cooperating with the next project, whatever the official policy says.
How do I value quality improvements?
Through avoided cost: rework hours, credit notes, escalations, churn. If you cannot find a cost line it affects, present it as a non-financial benefit rather than inventing a figure.
Is it worth building rather than buying?
Rarely at first. Build only after a bought solution has proven the workflow and the constraint is genuinely something no vendor addresses.
What payback period is reasonable?
For off-the-shelf tools, under six months. Anything longer usually means the task was a poor fit or the integration cost is doing the damage.
How do we value quality improvements?
Tie them to an existing metric — fewer escalations, lower rework rate, faster response — rather than asserting a monetary value nobody can trace.