Modelling the Benefit Honestly

The four multipliers

Almost every AI benefit reduces to the same chain. Each term is a discount on the one before, and the honest number is much smaller than the headline.

Benefit = Volume × Coverage × Adoption × Unit value

Volume. How many times the task happens. Get this from a system, not from an estimate — people are unreliable about frequency in both directions.

Coverage. The proportion the system actually handles. This is the straightforward pile from your hundred-case sample, not 100%. If 78 of 100 cases were straightforward, coverage is 0.78 at best.

Adoption. The proportion of eligible cases where a person actually uses the output. This is the term everyone omits and the one the MIT NANDA finding is entirely about. A tool nobody opens has an adoption of zero, and the benefit is zero regardless of the other three terms.

Unit value. What one handled case is worth — minutes saved, error avoided, day of settlement removed.

Worked through: 40,000 invoices a year, 78% straightforward, 85% adoption in year one, 6 minutes saved each.

40,000 × 0.78 × 0.85 = 26,520 invoices, at 6 minutes = 2,652 hours.

The headline version — 40,000 × 6 minutes — would have claimed 4,000 hours. The honest model is a third smaller before anyone challenges it, which is exactly why you should build it that way: you want the discounting to happen in your own spreadsheet, not in the approval meeting.

Then the hard question

2,652 hours is not money. Module 1 flagged this; here is how to resolve it.

Saved time becomes financial benefit through exactly one of three routes, and you must name which:

📅 Timeline

Headcount reductionRoles genuinely removed or not backfilled. The cleanest financially and the hardest organisationally. Only claim it if the decision is real and someone senior has agreed to it.

Absorbed growthVolume rises without adding people. Very commonly the true benefit and rarely claimed, because it is invisible — the cost that never appeared. Requires a credible growth forecast.

Redeployed outputThe freed hours produce something you would otherwise have bought or gone without. Weakest claim unless you can name the specific work and someone commits to it.

If none of the three applies, say so and claim the benefit somewhere else — quality, speed or new capability. A case that claims cost savings an organisation will not realise is worse than one claiming a smaller benefit honestly, because it will be measured on the saving and found to have failed.

Benefits other than time

Time is the default and often not the strongest argument.

Error reduction. Current error rate × volume × cost per error. Requires knowing your error rate, which frequently nobody has written down — establishing it is useful independent of the project.

Cycle time. Only counts when it changes a rate: deals won on responsiveness, working capital released, churn avoided. Evidence the rate change; do not assert it.

Capacity for the previously impossible. Reviewing 100% instead of 5%. Value it by what the additional coverage finds — if reviewing 5% of claims surfaces a certain rate of error, reviewing everything surfaces proportionally more.

Risk reduction. Fewer compliance breaches, better audit position. Hard to quantify, genuinely valuable, and best expressed as exposure reduced rather than money saved.

State the assumptions

Every number in a benefit model rests on an assumption. Write them where the reader can see them:

Volume from which system, over which period.
Coverage from the hundred-case sample of what size, taken when.
Adoption assumed at what level, based on what.
Unit value measured how — timed, estimated, or asserted.

This does three things. It makes the case honest. It lets a challenger argue with an assumption rather than with you. And it means that in twelve months you can check which assumption was wrong, which is the only way anybody gets better at this.

Run the same invoice case at three adoption levels and nothing else changes:

| Adoption | Invoices handled | Hours saved | |---|---|---| | 95% | 29,640 | 2,964 | | 60% | 18,720 | 1,872 | | 20% | 6,240 | 624 |

Adoption alone swings the benefit by a factor of nearly five. No modelling improvement available to any technical team moves the number that much — going from 78% to 90% coverage adds far less than going from 60% to 95% adoption.

This is the arithmetic behind the MIT NANDA finding, and it has a direct managerial consequence: once a system is technically adequate, your effort is better spent on adoption than on accuracy. Yet almost every project review is dominated by accuracy, because accuracy is the technical team's metric and they are the ones presenting.

Low adoption has recognisable causes, all of them fixable and none of them technical:

The output arrives somewhere people do not work — a separate dashboard, a daily email.
People do not trust it, because they saw it fail early and nobody explained the failure or what changed.
It is optional and slower than the old habit for the confident cases.
The person using it is not the person who benefits, so the effort and the reward sit in different places.
Nobody told them what happens if they follow it and it turns out wrong.

Ask about these before launch, not after. And put your adoption assumption in the business case explicitly, because it is the number most likely to be wrong and the one you can most directly influence.

❓ Knowledge Check

A case claims 4,000 hours saved from 40,000 invoices at 6 minutes each. The hundred-case sample showed 78 straightforward, and realistic adoption is 85%. What is the defensible figure, and why build it this way?

📚 Flashcards1 / 6

Term

The benefit chain

Click to flip

Definition

Benefit equals volume times coverage times adoption times unit value. Each term discounts the one before, and the honest figure is much smaller than the headline.

Click to flip back

💡Key Takeaway

Model benefit as volume times coverage times adoption times unit value, and do the discounting yourself so it happens in your spreadsheet rather than the approval meeting. Saved time only becomes money through headcount reduction, absorbed growth or redeployed output — name which, or claim the benefit as quality, speed or new capability instead. And treat adoption as the decisive term: once a system is technically adequate, it moves the number far more than any further accuracy will.