What is most often missing?

The definition of failure. A case that describes only what success looks like has committed to nothing checkable, while one naming the result that would mean dropping the tool is both more persuasive at approval and more useful afterwards, because somebody can tell which happened.

How should the soft benefits be handled?

Named and left unpriced. Putting an invented figure on better decisions or reduced frustration damages the credibility of the numbers that were real, whereas stating them plainly as things that matter and cannot be counted is honest and usually persuasive.

Is it worth revisiting after the purchase?

It is the only way the next one gets better. The comparison between what the case predicted and what happened is where the organisation's estimating actually improves, and skipping it means the same optimistic assumptions survive into every case that follows.

Glossary

Business case

The written argument for spending the money, which is read by two audiences wanting opposite things from it.

In plain terms

The document that gets the money released. It says what will change, what it costs and how anybody will know afterwards whether it worked, and that last part is the one most likely to be missing because it is the only part that can later be checked.

Why it matters

Because AI purchases sit awkwardly in most approval processes. The costs are legible and the benefits are diffuse, arriving as time saved across many people rather than as a line somebody can point at, so the case has to do more work than it would for a purchase with an obvious return.

How it works

Two audiences read it and want opposite things. Whoever approves the spend wants a number and a comparison; whoever has to live with the tool wants to know what changes about their week. A document written entirely for the first gets signed and then ignored, which is a familiar way for a rollout to stall after purchase.

The costs are the easy half and are still usually understated. Licences are visible and the rest is not: time spent configuring, the person who becomes the informal expert, the work of connecting it to systems that were not expecting it, and the training that gets skipped and then happens anyway in slower form.

The benefit side is where honesty is hardest, because time saved is real and does not become money unless something is done with it. Twenty minutes returned to forty people is genuine and it is not a headcount reduction, and a case that quietly implies otherwise is making a promise the tool cannot keep.

The strongest cases name what would count as failure. A document that only describes success has not committed to anything, and one that says what result would mean the tool should be dropped is far more persuasive, because it demonstrates that the person writing it has considered the possibility.

It is written once and rarely reread, which is the practical failure rather than any flaw in the arithmetic. The comparison that matters is the one between what the case predicted and what happened, and almost nobody makes it, so the same optimistic assumptions survive into the next case.

Two readers, one document

The reason this is worth drawing out is that the second column is usually treated as a rollout concern to be handled after funding, and by then the case has already shaped what the purchase is understood to be. An approval built entirely on a saving commits the organisation to a story about efficiency, and the people expected to change their working habits meet that story for the first time as an instruction. What makes the difference is not a longer document but a short section aimed squarely at the right-hand column, written before approval rather than after, because it changes what is being bought: not a licence with an expected return, but a change in how a particular team works, with a licence attached. That framing also survives contact with reality better. When the tool turns out to be useful in a way nobody predicted, which happens often in this category, a case built on the right-hand column can absorb that as a success, while one built on a single projected number has to explain why the number did not arrive.

Seen in the wild

A case for an assistant that counts licences and omits the time somebody spends becoming the internal expert.
ChatGPT
Justifying a search deployment on time saved, without saying what the saved time is for.
Glean
An automation case naming the volume threshold below which the tool would not be worth keeping.
Make

Common misconceptions

People assume

It is mainly a financial exercise.

In fact

The arithmetic is the easy part and rarely the reason a case fails. What decides is whether the change it describes is one people will actually make, which is a question about the organisation rather than about the numbers.

People assume

Time saved converts to money.

In fact

Only if something is done with it. Time returned in small amounts across many people is a real benefit and does not appear in a budget, and a case that implies it will is promising something the tool cannot deliver on its own.

Questions

What is most often missing?: The definition of failure. A case that describes only what success looks like has committed to nothing checkable, while one naming the result that would mean dropping the tool is both more persuasive at approval and more useful afterwards, because somebody can tell which happened.
How should the soft benefits be handled?: Named and left unpriced. Putting an invented figure on better decisions or reduced frustration damages the credibility of the numbers that were real, whereas stating them plainly as things that matter and cannot be counted is honest and usually persuasive.
Is it worth revisiting after the purchase?: It is the only way the next one gets better. The comparison between what the case predicted and what happened is where the organisation's estimating actually improves, and skipping it means the same optimistic assumptions survive into every case that follows.