Hours saved are not a benefit. It is an input to a benefit, and the step in between is where most AI business cases fall apart.
Here is a claim that appears in many AI business cases. We saved 400 hours per quarter. It is often true, sometimes carefully measured, and rarely persuasive to a finance director.
The reason is simple and slightly brutal. Four hundred hours across ninety people is about four hours each, which is not enough to change anyone’s role, reduce headcount, or increase output in any way that appears in a ledger. Finance has seen this claim before, from process improvement, from RPA, from the last three transformation programmes.
The chain, and where it breaks
Steps one and two are measurement problems, and they are tractable. Time the task before, time it after, multiply by volume and by a loaded cost per hour. Reasonable people can agree on those numbers.
Step three is not a measurement problem. It is a management decision that someone with authority over the team must make about how the team spends its time. Either the freed capacity gets pointed at something specific, or it dissipates. There is no third outcome, and dissipation is the default.
This is why AI business cases fail in front of finance, even when the underlying improvement is entirely real. The improvement happened. Nobody decided what to do with it.
Capacity that is not redeployed is not saved. It is absorbed, usually within about three weeks, and nobody can tell you where it went.
Netting off the costs honestly
The other habit that damages credibility is presenting gross savings. Every claim gets discounted by the reader anyway, so you may as well do the discounting yourself and be believed.
The line people forget is rework and checking. AI output gets reviewed, and review takes time. If drafting a document went from ninety minutes to fifteen but now requires a twenty-minute check that did not exist before, the saving is fifty-five minutes and not seventy-five. Presenting the seventy-five and being caught costs more than the twenty minutes ever would.
Run and monitor is the other underestimate. Agents need evaluation runs, occasional retuning, and someone watching cost. It is not large, but it is not zero, and it recurs annually while the build cost does not.
Benefits that are not hours
Time is the easiest thing to measure, which is why everyone measures it, yet it is often not where the value lies. Three categories are often larger and are worth arguing for.
Cycle time. Not how long the work takes, but how long the customer waits. A quote that goes out in two hours instead of two days wins business that a faster internal process does not. This one converts directly into revenue and finance understands it immediately.
Quality and error rate. Fewer missed clauses in contract review, fewer misrouted cases, fewer claims paid that should have been queried. When you have a historical error rate and a cost per error, this is a stronger metric than hours because it is already denominated in money.
Capacity at peak. The value is not the average; it is what happens in the week when volume triples. If AI handling means you do not hire contractors for the seasonal spike, that is an avoided cost with an invoice history to back it up.
For the practitioners
- Agree the loaded cost per hour with finance in writing before you build. If they choose the number, they cannot dispute it later, and they will almost always choose a lower one than you would.
- Baseline with a sample, not with a survey. Asking people how long something takes produces an estimate. Timing ten instances yields a measurement, and the results differ more than you would expect.
- Instrument for cost from the start. Agent cost varies with context size, reasoning depth, and step count, so an assumed per-interaction figure will be wrong.
- Report against the same metric every period, even when it looks bad. Changing the measure mid programme is the fastest way to lose the room.
- The widely quoted figure that surviving agent pilots return over 170%applies only to survivorship. Presenting a survivorship number as an expected value is the fastest way to lose a finance audience that has already seen the failure statistics.
The conversation to have first
The highest-return activity in an AI programme takes about an hour and involves no technology. Please sit with whoever will eventually judge the programme and agree, in advance, on four things: what we are measuring. Who takes the baseline. What cost per hour will we use? And what specifically counts as capacity redeployed.
Doing this afterwards is how good projects lose arguments they should have won. The improvement is real, the numbers are defensible, and none of it matters because the terms of the debate were set by somebody sceptical after the fact.
There is a secondary benefit too. Having that conversation early tends to reveal, quite quickly, whether the use case was ever going to produce a number worth having. Better to find that out before the build than after it.
A worked example
Abstract principles about measurement are easy to agree with and hard to apply, so here is the arithmetic on a case that comes up often. A bid team of twelve people produces first drafts of tender responses. The numbers below are illustrative, but the structure is the part to copy.
| Line | Working | Value |
|---|---|---|
| Baseline drafting time | Timed across 20 real bids, not estimated | 6.5 hours per bid |
| Time after | Same measurement, same team, four weeks later | 2.5 hours per bid |
| New review time | Checking AI output, which did not exist before | 0.75 hours per bid |
| Net time per bid | 6.5 less 2.5 less 0.75 | 3.25 hours |
| Volume | Bids submitted per year | 180 |
| Gross annual saving | 3.25 by 180 by an agreed loaded rate of 45 pounds | 26,325 pounds |
| Less licences | 12 users, agreed internal rate | Deduct |
| Less build and change | Amortised over three years | Deduct |
| Less run and monitor | Evaluation runs, retuning, cost monitoring | Deduct |
Now the part that decides whether any of it counts. Three and a quarter hours per bid across 180 bids is roughly 585 hours, or a third of a full-time role. Nobody is being made redundant, so the benefit is not a cost reduction. It has to be something else, and it has to be named.
In this case, the credible claim is bid volume. The team declines qualified opportunities because of capacity, and 585 hours is somewhere between twenty and thirty additional bids. If the win rate is a quarter and the average contract value is known, the revenue number follows, and it is considerably larger than the cost savings would have been. That is a benefit finance will engage with, and it came from asking about capacity rather than stopping at hours.
When the honest answer is that there is no number
Sometimes you do the analysis and the benefit is real but not bankable. The team is genuinely faster, the work is genuinely better, and the freed time is spread so thinly that nothing changes at the system level.
It is worth saying this out loud rather than manufacturing a number. Presenting a soft benefit as a hard one damages your credibility on the next case, and the next case might be the one with a real return. There are legitimate reasons to proceed anyway, including quality, risk reduction and the fact that people prefer working somewhere that does not waste their time. Those arguments are perfectly respectable when made in their own terms and badly weakened when disguised as arithmetic.
What to take away
- Hours saved is an input. The benefit is what the freed capacity gets used for, and that requires a decision.
- Net off review time, licences, build and run costs before presenting. Do the discounting yourself.
- Argue for cycle time, error rate and peak capacity where you can. They are often larger and already denominated in money.
- Agree on the measurement rules with finance in advance, in writing.
- Report the same metric every period, including when it is unflattering.
