Most ROI-from-AI-automation numbers you see are fiction. Someone multiplies "hours saved" by a loaded hourly rate, writes a big number on a slide, and calls it a business case. Nobody checks it six months later. Nobody subtracts what the thing costs to run.
We measure it differently, because we have to. Here is the honest formula, the costs nobody quotes, and a worked example with real numbers.
The Honest Formula for ROI From AI Automation
ROI from AI automation is not "hours saved times wage." It is a subtraction problem. Write both sides.
Value = time saved (at a real, not aspirational, rate) + error cost avoided + revenue enabled.
Cost = build cost + run cost + oversight cost.
ROI = (Value − Cost) / Cost.
That is it. The discipline is in refusing to leave anything off the cost side. Most business cases are just the value column with the cost column deleted. A workflow that saves $80k a year and costs $70k a year to build and run is a 14% return, not a miracle. You need to know which one you have before you sign off.
Why "Hours Saved" Lies
"Hours saved" is the most abused metric in this field, for three reasons.
First, saved hours are not recovered dollars unless someone does something else billable with them. If you automate 6 hours a week of a salaried analyst's work and they fill those 6 hours with Slack, you saved nothing. You bought slack. Saved time only converts to money when you reassign the person, cut headcount, avoid a hire, or take on more volume with the same team. Name which one, or don't count it.
Second, people overstate the baseline. Ask someone how long a task takes and they'll say two hours. Time it and it's forty minutes, twice a week. The gap between remembered time and measured time is where fake ROI lives.
Third, hours saved ignores quality. If the automation is faster but wrong 5% of the time, the review and rework can eat the entire saving. Speed without accuracy is not a saving. It's a liability with a shorter cycle time.
The Run Costs Nobody Quotes
Build cost is the number everyone fixates on. Run cost is the one that kills the return, quietly, month after month. Four things go here.
Tokens and inference. Every run costs money at the model. It's usually small per call and enormous at volume. Ten thousand documents a month through a multi-step LLM pipeline is a real line item. Estimate it before you build, not after the first invoice.
Monitoring and infrastructure. Hosting, orchestration, logging, alerting, the queue that retries failures. This doesn't run for free just because the code is written.
Human review. This is the big one people delete. Most AI automation worth deploying keeps a human checking some fraction of outputs, especially early. If a human reviews 20% of outputs at two minutes each, that time is a permanent operating cost. Count it. It usually shrinks as trust grows, but it rarely hits zero.
Maintenance. Models change. Upstream formats change. Edge cases surface. Someone owns this system and spends real hours on it. A safe first-year estimate is 15–25% of the build cost, recurring.
Add these up before you commit. A workflow that looks like a 5x return on hours saved often lands at 1.5x once run cost is honest. Still worth doing. Just not the number on the slide.
Baseline Before You Build, or You Prove Nothing
Here is the rule people skip and then regret. If you don't measure the "before," you can never prove the "after." You'll ship the automation, everyone will feel busier and vaguely more productive, and you'll have zero defensible numbers.
Before you build, capture four things: how long the task takes today (measured, not guessed), how often it runs, the current error rate, and the fully loaded cost of the people doing it. It takes a day or two of tracking. That day is the difference between a real ROI number and a story you tell yourself.
Then split your metrics into leading and lagging. Leading indicators move in week one: cycle time per task, percentage of runs needing human correction, volume processed. Lagging indicators take a quarter: headcount avoided, revenue from faster turnaround, error-driven cost reduction. Leading indicators tell you it's working. Lagging indicators tell you it paid. Don't confuse the first for the second, and don't wait a quarter to notice it's broken.
When the ROI Is Real vs Vanity
Real ROI has a named beneficiary of the saved time and a dollar figure that shows up in a budget line: a hire not made, a contract renewed, overtime cut, a queue cleared that was costing you customers. You can point at the change in the P&L.
Vanity ROI is "we saved 400 hours a year" with no follow-up question about what happened to those hours. It's efficiency that never becomes cash. It might still be worth it for morale or capacity headroom, but call it what it is and don't book it as savings.
A Worked Example
A mid-size insurer automates first-pass claims triage.
Value. Two analysts spent 6 hours a day each on triage; the automation removes 60%, and both are reassigned to complex-claims review that clears a backlog costing about $90k a year in delayed settlements. Error cost avoided: manual mis-routing ran ~4% and drove $40k in annual rework; the automation cuts that to 1.5%, saving ~$25k. Value ≈ $115k/year.
Cost. Build: $60k, one time. Run: tokens ~$9k/year, infrastructure ~$6k/year, human review of 15% of cases ~$18k/year, maintenance ~$12k/year. Run total ≈ $45k/year.
Year one ROI = (115 − 60 − 45) / (60 + 45) = 10 / 105 ≈ 10%. Thin.
Year two, with build cost gone and review down to 8%: value ~$115k, cost ~$38k. ROI = (115 − 38) / 38 ≈ 200%.
That shape is normal and it's the whole point. Judge AI automation on year two, but only if you can name where the year-one money went and you baselined well enough to prove it.
If you want the honest version of this math for your own workflows, our AI Readiness Assessment includes an ROI estimate — build cost, run cost, and expected return — before you spend a cent building.