“Saves the team two hours a week” is not ROI – it is a hope with a number next to it. Here is the model that separates value you can book from value that quietly evaporates the moment a CFO asks a second question.

Most enterprise AI business cases die in the same meeting. Somebody presents a slide claiming the new tool saves 200 hours a month, multiplies that by a fully loaded hourly rate and arrives at a confident annual saving. The CFO asks a single question – “so which costs go down, and by how much?” – and the number collapses. Because saved minutes that change neither headcount nor contractor spend nor output are not money. They are slack.

This is not finance being obstructive. Finance is simply right. We have built business cases that survived that meeting and ones that did not – and the difference is always the same: the survivors measured value that shows up in a line of the accounts.

The real problem: productivity is not the same as profit

AI creates value in three ways, and only two of them are realisable on their own:

• Cost reduction – you spend less: fewer contractors, deferred hires, lower error and rework costs, less infrastructure. Directly realisable.
• Revenue growth – you earn more: higher conversion, faster sales cycles, retained customers. Realisable, but harder to attribute.
• Capacity gain – the team achieves more with the same people. Only realisable if you actually fill the freed-up capacity with revenue-relevant work or absorb growth without new hires. Otherwise it is comfort, not money.

The two-hours-a-week claim is almost always a capacity gain dressed up as cost reduction. It becomes real only when you can name the hire you did not make or the growth you absorbed. Until then, the honest ROI of “everybody is slightly less busy” is zero.

The four-factor model

Every defensible AI business case we build reduces to four numbers:

Annual net value = (realised value × adoption) − running costs − change costs

• Realised value – realisable effects only, named and mapped to a budget line. No theoretical hours.
• Adoption – the share of the eligible user population that actually uses the tool. Value scales with usage; a tool that 30% of the team uses delivers 30% of the business case.
• Running costs – model and API spend, infrastructure, plus the human-in-the-loop and maintenance time the system genuinely needs. The part most business cases forget.
• Change costs – rollout, training, process redesign and the productivity dip while people learn. Real, one-off and routinely left out.

Two of those four – adoption and running costs – are exactly the ones optimistic business cases ignore, and they are usually the two that decide whether a project is actually positive.

A worked example: AI-assisted draft replies in support

A support organisation handling 9,000 tickets a month wanted AI to produce draft replies that agents would edit and send. The first business case claimed 3 minutes saved per ticket × 9,000 × CHF 1.10/minute = roughly CHF 356k/year. Here is what survived contact with finance.

Realised value: the 3 minutes saved were real, but applied only to the roughly 60% of tickets the AI handled well – and the freed-up time turned into money only because the team was about to hire two additional agents to cope with 15% volume growth year on year. Those two deferred hires – around CHF 180k/year fully loaded – were the realisable value. Not CHF 356k. CHF 180k.

Adoption: after a clean rollout, 80% of agents used the drafts routinely. 180k × 0.80 = CHF 144k realised.

Running costs: inference at roughly CHF 0.018 per draft × 9,000 × 12 ≈ CHF 1.9k, plus infrastructure and around 0.2 FTE for ongoing prompt and eval maintenance (~CHF 28k). ≈ CHF 31k/year.

Change costs: rollout, training, building the evals and a four-week productivity dip ≈ CHF 45k, one-off.

Year-one net: 144k − 31k − 45k = CHF 68k. Year-two net (without change costs): CHF 113k.

CHF 68k is a smaller, slower headline than CHF 356k – and it was precisely that number which got approved, because every factor traced back to a line finance could audit. Only the framing around deferred hires made the value realisable; without the growth that absorbed the freed-up capacity, the honest year-one value would have been close to zero – and we would have said so.

Measure before you celebrate

The model is only as good as its baseline. Capture the as-is state before go-live: cost per ticket, current rework rate, current turnaround time, current contractor spend. Without a baseline you end up negotiating over anecdotes after the fact. With a baseline, “rework fell by 22%” is a number you can book rather than a feeling. The most common reason a genuine success cannot be proven: nobody measured the “before”.

Portfolio ROI beats project ROI

There is a structural reason why individual AI business cases feel unsatisfying: many of the most valuable effects are diffuse and shared, and forcing every project to justify itself in isolation systematically undervalues them. The evaluation harness built for one feature accelerates the next five. The data clean-up for one use case makes three more possible. The model abstraction layer that protected one feature from a forced migration protects the whole landscape. Charge the full cost of those shared assets to the first project and it looks marginal; recognise them as portfolio infrastructure and the economics change completely.

That is why mature AI organisations stop running every initiative as a standalone P&L and start steering an AI portfolio in which the costs of shared infrastructure are reported separately from feature-level value. The first use case in a domain carries a heavy “platform tax” – data work, evals, integration, governance scaffolding – that makes its isolated ROI look weak. The second and third use cases reuse that platform and show strong returns. Judge the first project alone and you kill the programme before compounding sets in; judge the portfolio and you see the real curve. The CFO model above applies per feature; the portfolio view is what justifies the platform investments that make every feature cheaper.

The practical step is to separate two budgets explicitly: a platform budget (evals, data pipelines, model abstraction, governance gate), justified by its leverage across many features, and feature budgets, justified by realisable value under the four-factor model. Mix the two and you get the worst of both worlds – platform work that never gets funded because no single feature can justify it, and bloated feature cases expected to shoulder platform costs they honestly cannot carry. Keep them separate and each is assessed on the right basis: features on realisable value, the platform on how many features it accelerates.

Pitfalls

• Counting saved time as saved money. That only holds if it reduces spend or absorbs growth. Otherwise it is slack.
• Assuming 100% adoption. Model the realistic curve; a brilliant tool at 25% adoption is a quarter of a business case.
• Leaving out the human-in-the-loop cost. If a person reviews every output, that time belongs in running costs and it changes the economics.
• Getting the model cost trend the wrong way round. Inference is getting cheaper, which helps – but volume usually grows faster. So model your costs at forecast scale, not at today’s pilot volume.
• One big number, no sensitivity. Show the business case at 50%, 80% and 100% adoption. Finance trusts a range it can stress-test more than a single confident number.

Decision checklist

1. Which specific budget line does this value reduce or increase? Name it.
2. If the value is freed-up capacity: which hire is deferred, or which growth is absorbed?
3. What does our realistic adoption curve look like, and how does the business case stand at the low end?
4. What are the full running costs, including human review and maintenance?
5. What are the one-off change costs, including the dip during the learning curve?
6. Did we capture a baseline before go-live, so that success is provable?
7. What does the model say at forecast scale, not at pilot scale?

The gridz view

The fastest way to burn the credibility of your entire AI programme is to over-promise on the first business case and miss the target. We would rather present CHF 68k that materialises than CHF 356k that evaporates – because the latter poisons the well for every project after it. Build the business case on realisable value, model adoption honestly, count running and change costs, and capture the baseline before you start. We help organisations build AI aimed at realisable outcomes, and evidence the result in numbers finance signs off without debate – talk to us.

If you are looking for a single starting point: take your most hyped AI initiative right now and force every claimed benefit onto a budget line – which cost falls, which revenue rises, or which specific hire is deferred. The claims that survive that test are your real business case; the ones that dissolve were always productivity theatre – and it is far cheaper to find that out now than in the post-mortem. Do this exercise before the next steering committee and you walk in with a number that holds.