The business case for AI,
calculated honestly

What belongs in the business case for AI that still holds up a year later?

An AI business case only counts hours saved as a saving once the costs actually fall, and it includes the full cost side: consumption, upkeep, integration, change and governance. The outcome is stated as a range, with the assumptions about adoption, volume and converting time saved into money made visible at the top.

Does extra time for valuable work count as a saving in an AI business case?

No. More time for valuable work is real value, but not a financial saving. In the business case for AI, that item belongs under qualitative benefits, not in the sum.

Source: article by Dave Willemstein. Updated: October 2026.

Where AI business cases fail

Not at approval, because that's usually where they do fine. They fail a year later, at the question of whether the promised result was actually achieved. At that point, the promise turns out not to be measurable, the cost side incomplete, and the saving nowhere to be found in any budget.

That's a shame, because it damages trust in the next business case too, even if that one is better.

The benefit side: three kinds of value, three ways of counting

1. Cost reduction (hard, provided you follow it through)

The classic: we save hours, so we save money. That's only true if those hours actually disappear from the cost base. Three ways that happens:

• Less outside hire or temporary staff: directly visible in the figures, so hard.
• Absorbing growth without an extra hire: real, but only if the growth is actually there. Record what the baseline scenario was.
• Fewer of your own FTEs: hard, but requires a decision that goes beyond an AI project. Only include this if leadership genuinely intends to make that decision.

What doesn't count: "our people have more time for valuable work." That's real value, but not a financial saving. Put it under qualitative benefits in the business case, not in the sum. Otherwise it gets held against you a year later.

2. Revenue effect (softer, but often bigger)

Faster quotes, higher conversion, less customer churn, more capacity for billable work. This is often where the biggest value sits, and at the same time the hardest to attribute.

An approach that holds up: pick one measurable intermediate step instead of the end revenue figure. For example, not "more revenue" but "turnaround time from quote request to sending, from 4 days to 1 day." Then show historically what the relationship is between that turnaround time and conversion. That makes the reasoning traceable, even for someone sceptical.

3. Risk reduction (hard to quantify, but can be substantiated)

Fewer errors, better compliance, less rework. Here, work with the costs of past incidents: how many files had to be redone last year, what did that cost in hours, fines or claims? That's a defensible basis. A percentage from a research report isn't.

The cost side: where it usually goes wrong

The benefit side gets the attention, the cost side gets underestimated. Five items that are almost always too low or missing entirely.

Consumption costs that scale with use

This is fundamentally different from classic software. Where a licence is a fixed amount per user, with AI you often pay per document processed, per conversation or per volume of text processed. In a pilot with fifty users, that's negligible. At five hundred users and ten times the volume, it's a serious item.

Do this: in the pilot, measure the cost per transaction and multiply by the expected volume at full rollout. Also run a scenario at double that volume, because successful applications get used more intensively than planned.

Upkeep and monitoring

Budget for ongoing hours for quality monitoring, keeping test sets current, model updates and incident handling. For a medium-sized application, half a day to a full day a month is realistic, more for high-risk applications with formal review requirements.

Integration and connections

Usually the biggest surprise. The application itself is ready in weeks; connecting it to the source system, the permissions model and logging takes months. Ask explicitly for every business case: which systems need to open up for this, and who manages them?

Change and training

Instruction, guidance, temporary double work during the transition, and the productivity dip in the first few weeks. That dip is real and usually lasts four to eight weeks. Include it: it makes your case more credible, not weaker.

Governance and compliance

For medium- and high-risk applications: documentation, assessment, periodic review, possibly external validation. For regulated processes, this is not a marginal item.

Work with ranges, not point estimates

A case that says "€412,000 saving in year two" is less credible than a case that says "€250,000 to €500,000, depending on whether we get adoption above 60%." The second shows you know where the uncertainty sits.

Make explicit which assumptions most strongly determine the outcome. In most AI business cases, there are three: the adoption rate, the volume, and whether the time saved converts into something that generates money. Put those three at the top, with the value you've assumed and its source.

Agree what you'll measure in a year

The part that's most often missing, and that makes the biggest difference. At approval, record:

• Which three figures you'll report on after twelve months, and where they come from.
• What the baseline measurement is, taken before the start, not reconstructed afterwards.
• At what outcome you'll adjust course, and at what outcome you'll stop.

That last point turns a business case into an agreement rather than a pitch. It also lowers the bar for approval: a CFO says yes more easily to a proposal with an explicit stop point than to one that can only succeed.

One final test

Have someone with no stake in the project read the case, with one instruction: find the assumption the whole outcome rests on. If they find it within five minutes, your case is transparent. If they can't find it, it's buried too deep. And that will surface a year later anyway, at a less convenient moment.