The number that ends the discussion
There is a figure most AI business cases cannot produce, and its absence is usually the reason a proposal is politely declined. It is the current cost of the problem: what the business spends today on the thing the proposal would change. Not the perceived waste, and not the number of people who complain about it. The measured number.
Without it, every benefit is a forecast and every forecast is negotiable, so the argument moves to whether the model is good enough, which is a much harder conversation to have honestly. With it, the argument becomes arithmetic, and arithmetic can be reviewed by someone who does not believe in the technology.
Establish the baseline before anything else
A usable baseline has four components, and they are gathered from operational records rather than from interviews, because interviews produce recollection and records produce counts.
- Volume. How many transactions the process handles per period, and what the distribution looks like across sizes and types. A process with a wide distribution has a long tail, and the tail is usually where the cost and the risk live.
- Cycle time. How long the process takes from trigger to completion, and where the waiting happens. Waiting, rather than working, is the usual finding.
- Error and intervention rate. How many transactions need correction, and who corrects them. This is normally the most useful single number, because it converts directly into rework hours.
- Rework hours. The actual time spent correcting, chasing, re-entering and re-communicating. A correction rate multiplied by the minutes it takes to correct is a defensible quantity.
These four are cheap to collect if the organisation already runs the process in a system of record. Where it does not, a fortnight of structured observation will produce an order-of-magnitude estimate that is good enough to proceed and honest enough to publish. The discipline that matters is labelling it an estimate and recording the assumption, rather than presenting a rounded figure as measured fact.
Count the whole cost, including the parts that do not appear on a slide
Enterprise AI proposals are usually costed on the visible items: licences, integration, and the engineers who build it. Those are the smallest part of the true cost, and the omission is what causes the gap between projected and realised value.
- Data preparation. Cleaning, reconciling, defining and maintaining the context the system works on. This is frequently larger than the build itself, and it recurs because business definitions drift.
- Integration. The work of connecting to systems of record, and the reconnection work that follows every change in them.
- Evaluation and testing. Building the test cases, and the continuing cost of re-testing when a rule, a source or a model changes. This is a permanent cost, not a project cost, and it is usually omitted because it appears after launch.
- Adoption. Training, the productivity dip while people learn a new way of working, the support load, and the continued operation of the old way because removing it is nobody's explicit responsibility.
- Governance. Review, audit, exception handling and the effort of keeping the system within its permitted boundaries.
The adoption line is the one that most often breaks a case, and it is the one least examined. A system that reduces handling time by a meaningful amount, deployed into a process where three people each work differently, frequently produces no improvement at all in the first two quarters — because the old process kept running alongside it. Counting the coexistence period is not pessimism. It is what happens.
Claim only what the evidence supports
A defensible case contains three kinds of statement, and they should be visually and verbally distinct from one another.
| Claim type | What it says | How it is supported |
|---|---|---|
| Measured | A quantity observed in the business today. | A count from a system of record, with the period and the population stated. |
| Assumed | A quantity that will change in a stated way. | A named assumption with its basis, and the person who believes it. |
| Illustrative | An example of what the arithmetic could produce. | Clearly labelled, with every input visible so a reader can substitute their own. |
The discipline that keeps a case honest is refusing the third column where the second would do. An illustrative figure presented in a board paper becomes a commitment in the reader's memory, and the organisation then finds itself measured against a number nobody authorised. This is the same failure mode described in the business case for fixing small operational errors: small errors are tolerable as incidents and corrosive as an aggregate, and the only honest way to discuss the aggregate is with stated assumptions attached.
Payback, expressed in a way finance will accept
Payback is still the most useful framing for an uncertain benefit, because it converts an unbounded forecast into a bounded question: how long until this stops consuming attention and money?
Three refinements make the number defensible. First, express the benefit in the units the business already manages — handling hours, error rates, cycle time — and let the reader convert to money with their own rate. Second, apply a discount to the benefit for the adoption ramp rather than assuming day-one performance. Third, and most importantly, state the point at which the project should be stopped if it has not reached its baseline, and be willing to stop it. A case that cannot be failed cannot be evaluated.
The most common honest conclusion
For many processes the arithmetic does not support an AI project, and that is a genuinely useful result. Sometimes the error rate is low enough that rework is immaterial; sometimes the volume is too small to carry a platform; sometimes the value is real but concentrated in one region or one customer segment that a dedicated tool does not justify. Establishing that quickly protects the credibility of the projects that should proceed, and it protects the attention of the people who will have to run them.
The review point is worth naming in advance: a fixed date on which the baseline, the first delivery and the adoption data are all on the table, and the decision to continue, reshape or stop is made against numbers rather than against enthusiasm. The selection method for which projects survive that review is set out in finding your first ten high-value AI opportunities.