How to write an AI business case that finance will approve.

Finance sends the AI proposal back with three questions. What does it cost to run, not just to build? Compared with what? And what happens if it doesn’t work?

A proposal built on a vendor’s headline and a price per token can’t answer any of them. A case finance will approve prices the whole workflow against a measured baseline, writes down the assumptions so they can be checked, and names the point at which you stop. It fits on one page.

What does finance need to see?

• A baseline, measured. Volume, time per case, error rate and cost per case as the work runs now, not as someone remembers it.
• The whole cost. Building, running and reviewing, not only licenses or tokens.
• Benefits in their terms. Which budget line moves, and which benefits are capacity rather than cash.
• Assumptions they can check. Every number traced to a source, or labeled as an estimate.
• The downside. What you will have spent by the time you know it doesn’t work, and who decides to stop.

Which costs belong in the case?

Cost to build is the one-off part: discovery, the pilot, integration with the systems the workflow touches, security and data-protection review, training and the evaluation set. Count internal time, especially the experts who write the reference answers; it is the line most often missing. What drives build costs is a subject of its own.

Cost to run recurs every month: model usage, infrastructure, monitoring, support, and upkeep such as maintaining prompts and re-testing after model updates. It also includes the minutes people spend reviewing each case, often the largest line of all.

Cost of change is easy to forget: running old and new side by side during the pilot, training new starters and retiring the old path. Ask finance how they want one-off and recurring costs presented, and follow their format.

How do you estimate benefits without inventing numbers?

Start from measurements of the current process. Volume comes from your systems. Time per case comes from a short time study: sit with the team for a morning and time real cases. Error rates come from rework logs, credit notes and complaints.

Estimate the change as a range, and test it early. Running a candidate design on a few dozen past cases before the pilot gives you a range from your own work instead of a vendor’s average.

Then separate capacity from cash. Hours freed become money only when a budget line moves, such as overtime, temporary staff or a hire you no longer need; otherwise say what the time is for and count it as capacity. Measuring ROI after launch covers that distinction in depth. List benefits nobody prices, such as consistency across teams, in words rather than numbers.

How do you show risk and the cost of errors?

Price each kind of error with the workflow owner and finance: rework, direct loss, customer impact, compliance exposure. Rough ranges are enough, and the note on the cost of a token vs. the cost of a mistake shows the arithmetic.

Show the expected cost of errors on both sides, because the current process is not error-free. Name the errors that are unacceptable at any rate, and the control that prevents each one, usually an approval point, instead of pricing them. And state the downside plainly: the fixed cost of a pilot that fails its criteria.

Price the option of doing nothing too. The backlog that grows, the overtime at every peak and the growth the team can’t absorb are real costs, and leaving them out makes every alternative look expensive.

A business case without stop criteria is a request for money, not a plan.

Which assumptions must be written down?

At least these: volume, time per case now, review time with the system, error rates before and after, cost per error, running cost per task, the share of cases that will actually go through the system, build cost and ramp-up time. Give each a source (measured, estimated or vendor-quoted) and the pilot measurement that will confirm it. One line might read: “Review time with the system: 4 minutes a claim. Source: 30 past claims run through a prototype. Confirmed by: timing live claims during the pilot.”

Then move one assumption at a time and watch the result. Usually one dominates. That is the assumption the pilot should measure first, and the one the stop criteria are written around.

What does a one-page business case look like?

Take an illustrative warranty-claims desk. The numbers are invented to show the arithmetic, in made-up units; they are not prices or benchmarks. A minute of staff time costs 1 unit, and a wrong decision costs 60 units to put right.

At 1,000 claims a month the difference is 8,200 units, so a build cost of 60,000 units pays back in a little over seven months. Staff time counts as money here only because the owner has committed the freed time to absorbing growth that would otherwise need temporary staff.

Now test the sensitivity. If running costs double, payback stretches to a little over eight months; if errors don’t fall at all, to about eight and a half. If review takes 9 minutes instead of 4, it stretches to almost nineteen. Finance wants payback within twelve months, which holds only while review stays under about seven minutes a claim. Review time decides this case.

When should the case be revisited?

At every gate: after discovery, when estimates become a measured baseline; after the pilot, when assumptions become measurements; and after the first quarter live. Revisit it also when an input moves, such as volume, prices, error costs or the model underneath.

The stop and continue criteria go into the case before the pilot starts. In the claims example they might read:

• Continue if review time is at or below seven minutes, no unacceptable error appears on the evaluation set, and running cost stays under 1.5 units a claim.
• Stop if review time stays above nine minutes after two rounds of changes.
• Pause if data access isn’t in place by the end of the second week.

A pilot stopped by its own criteria is not a failure. It is the cost of learning, capped in advance. Keep the approved version of the case, too: comparing it with what was measured is how finance learns to trust the next one.

Baseline before benefits

Fill in the baseline row first; if you can’t, that is your first piece of work. A Discovery Sprint of about two weeks measures the baseline and writes the pilot plan and acceptance criteria this page needs. The first steps, from an Executive Build Day to a pilot, have a fixed scope and price (see the ways in), so the cost of learning is known before it starts.