Most AI business cases we are shown measure one thing: labor hours removed. It is the easiest number to produce and the least likely to survive a finance review, because it assumes the hours convert to cost savings and they usually do not.
Five dimensions worth measuring
- Cycle time — elapsed time from request to resolution, not hands-on time
- Throughput per person — output at constant headcount, which is what usually happens
- Error and rework rate — often the largest hidden cost in the current process
- Coverage — work that was previously not done at all because nobody had capacity
- Variance — consistency of outcome, which matters enormously in regulated settings
Cycle time is the one we push hardest on. It is measurable before and after with no modeling assumptions, and in most businesses it maps directly onto revenue recognition or customer satisfaction.
Three traps
The first is counting hours saved as dollars saved. Unless you are actually reducing headcount — and you probably are not — those hours get reallocated. The honest framing is capacity gained, and the business case should say what you intend to do with it.
The second is ignoring the maintenance tail. Models drift, sources change, and someone owns the eval suite. Budget 15–25% of build cost annually and put a name against it, or the system quietly decays until it is switched off.
The third is measuring against an idealized baseline. Compare against what the process actually does today, including its error rate and its backlog — not against the documented process that nobody follows.
If your business case cannot survive being wrong by 40% in either direction, it is not a business case — it is a hope with a spreadsheet attached.
The question we ask every client
Before scoping anything, we ask: if this works exactly as specified, what decision changes? If the honest answer is that a report gets produced faster but nobody acts differently, the ROI is zero regardless of how good the model is. That question has killed more of our own proposals than any technical constraint.
