GuideStrategic Technology Consulting
How to write an AI business case that survives finance and board review
Finance teams reject AI business cases for predictable reasons: a single return figure nobody can check, no measured baseline, and running costs that appear only after launch. A case that survives review starts from today's measured performance, pairs every benefit with a way to measure it, counts the full cost of running and supervising the system, and asks for money one stage at a time, with criteria for stopping written in before the first stage starts.
On this page
- Why AI business cases fail review
- Building the case in seven moves
- Cost drivers a complete AI case includes
- Stage-gated funding from baseline to scale
- What each funding gate should decide
- A hypothetical bank's document-intake agent, stage by stage
- What the one-page board summary should contain
- Where a business case fits among other approval routes
- Questions and answers
- Sources
Why AI business cases fail review
Each of these is easy for a finance reviewer to spot and hard for a sponsor to defend once spotted.
A single return-on-investment figure
Early signalThe case rests on one number with no range, no scenarios and no stated assumptions.
MitigationPresent low, central and high scenarios and show which assumption moves the result most.
No measured baseline
Early signalBenefits are stated as improvements without saying what current cycle time, error rate or cost actually is.
MitigationMeasure the current process on real work before writing the case, even roughly.
Run costs left out
Early signalCosts stop at the build and the first year's licence; evaluation, inference and supervision are missing.
MitigationList every cost driver over the life of the system, including human review.
Benefits that need decisions nobody has taken
Early signalSavings assume fewer staff or a redesigned process, but no owner has agreed to make that change.
MitigationName the executive who will make the change and record their agreement in the case.
No way to stop
Early signalOne approval funds the whole programme and progress is reported as percentage complete.
MitigationSplit funding into stages, each with entry criteria and a recorded decision to continue or stop.
Building the case in seven moves
Start from the decision being asked for
State what the board or investment committee is approving now, what it is not approving yet and when the next decision will come back to it.
Measure today's baseline
Measure the process the system will change: volumes, cycle time, error or rework rates, cost per case and customer or staff experience. Use real samples, and say how the measurement was taken.
Write benefit hypotheses with measurement plans
Turn each expected benefit into a testable statement with a measure, a target range and a date. Pair a leading indicator, such as share of cases handled without rework, with a lagging one, such as cost per case.
Count every cost driver
List data preparation, integration, evaluation, inference, supervision, change management and governance effort across the expected life, not only the build. Estimate ranges where usage is uncertain.
State the risks being accepted
Name the risks the organisation is choosing to carry if it proceeds, who owns each and how each will be monitored, alongside the risks of doing nothing.
Design stage gates and stop criteria
Break funding into stages, each with entry criteria, the evidence expected at its end and the conditions under which the work stops.
Write the one-page summary last
Summarise the decision, the baseline, the range of outcomes, the accepted risks and the next gate on a single page the board can read before the meeting.
Cost drivers a complete AI case includes
The total cost of ownership view applies here; this table lists the AI-specific drivers sponsors most often leave out.
| Cost driver | What it covers | Why it is often missed |
|---|---|---|
| Data preparation | Extraction, cleaning, labelling, permissions and pipelines | Assumed to exist because the data exists somewhere |
| Integration | Connections to source systems, identity, logging and write-back | Vendor demos run without touching real systems |
| Evaluation | Building and maintaining test sets, scoring and re-testing after changes | Treated as a one-off acceptance test rather than ongoing work |
| Inference and hosting | Model usage, compute, storage and environments for testing | Estimated on pilot volumes that are far below production |
| Human supervision | Review of outputs, handling exceptions and escalations | The point of automation seems to be removing people |
| Change and training | Process redesign, training and communication for affected teams | Sits in a different budget from the technology |
| Governance and assurance | Risk assessments, documentation, audits and regulatory work | Arrives late, after the design is fixed |
Express each driver as a range with its main assumption, not a single figure.
Stage-gated funding from baseline to scale
- Baseline and design
Small funding to measure the current process, prepare data and agree the evaluation set.
- Bounded pilot
The system runs on real work with close supervision, judged against the agreed success measure.
- Limited production
One team or region uses it routinely while run costs and supervision effort are measured.
- Scale
Wider rollout funded on evidence from limited production, not on the original forecast.
- Benefits review
Results compared with the benefit register, feeding the next investment decision.
What each funding gate should decide
- If
The stage met its success measure within the expected cost range.
ThenRelease the next stage's funding and update the case with the measured results.
Each stage should make the next forecast more reliable than the last.
- If
Benefits appeared but were smaller than expected.
ThenNarrow the scope to the cases where the system performed and re-forecast before continuing.
Partial success often hides a strong result on a subset of the work.
- If
A cost driver came in well above its range.
ThenPause, find the cause and re-run the case on the new figure before any further spending.
Run costs scale with use, so an early overrun usually grows.
- If
A stop criterion was met.
ThenStop, record what was learned and close the budget line.
A stop agreed in advance is a sign of a working process, not a failure of the sponsor.
A hypothetical bank's document-intake agent, stage by stage
What the one-page board summary should contain
Where a business case fits among other approval routes
In the public sector, many bodies must follow a prescribed structure: UK central government business cases, for example, are expected to follow HM Treasury's Green Book guidance on appraisal and the five case model that accompanies it2. The principles above sit comfortably inside that structure.
ColdAI's consulting deliverables follow the same logic: an options paper comparing paths on cost drivers and risks, a sequenced roadmap with a decision point before each funding stage, and a short board summary stating the recommendation and the risks being accepted1. Feasibility questions, such as whether the data can support the use case at all, belong in an AI readiness assessment before the case is written.
Questions and answers
How can we estimate AI benefits before a pilot has run?
Estimate from the measured baseline and a small test on real cases, then present the result as a range. A few hundred representative cases run through a prototype, or reviewed by hand against what the system would do, give a far better basis than vendor benchmarks. The first funding stage exists partly to replace estimates with measurements.
Should the business case count headcount savings?
Only where an accountable executive has agreed to the change in staffing or process that produces them. Otherwise, express the benefit as capacity released and say what the capacity will be used for. Cases that assume headcount reductions nobody has committed to are the ones finance reviewers challenge first, and the savings rarely appear.
How detailed should run-cost estimates be at the first gate?
Detailed enough to show the drivers and their ranges, not precise to the last unit. At the first gate, list each driver, its main assumption and a plausible range. The pilot and limited-production stages exist to replace those ranges with measured figures before the large spending decisions arrive.
Who should sign off the measurement plan?
The process owner and finance, before the first stage starts. The process owner confirms the measures reflect the real work; finance confirms the benefits can be traced to figures it recognises. Agreeing this in advance prevents arguments about whether the pilot worked after the results are in.
Sources
- Strategic Technology Consulting: options paper, sequenced roadmap and board summary — ColdAI
- The Green Book: appraisal and evaluation in central government — HM Treasury · checked 10 October 2026