How to Measure AI ROI (Four Numbers and One Break-Even)
To measure AI ROI, stop measuring AI and measure one job. Pick a task the system runs over and over, then collect four numbers: how many times it runs, how many human minutes it saves per run after review, what a loaded human minute costs you, and what a single run costs to produce. Net gain is the first three multiplied together, minus the fourth. Everything past that is commentary.
TL;DR
- The unit of measurement is a job, not a tool. "What is our ROI on AI" has no answer. "What is our ROI on ticket triage" has one.
- Four numbers: volume, minutes saved per run, loaded cost per minute, cost per run. Three of them are cheap to measure. The second one is the one everyone guesses.
- The measurement gap is the whole story. PwC's 29th Global CEO Survey found 56 percent of 4,454 CEOs saw neither revenue gains nor cost reductions from AI in the last year. McKinsey's State of AI 2026 found only 39 percent could attribute any EBIT impact at all.
- Model cost is almost never the constraint. In the worked example below, tokens run about 10 dollars a month against roughly 5,900 dollars of recovered time.
- Six haircuts turn a pilot number into a real one: eligibility rate, rework rate, priced review time, amortized build, monthly upkeep, and the reallocation question.
- Saved minutes are capacity, not cash. They become money only if you skip a hire or move the hours onto work that earns.
Why most AI ROI numbers are fiction
The gap between how much AI gets used and how much of it shows up in the accounts is now well documented. McKinsey's State of AI 2026 survey found 39 percent of respondents could attribute any level of EBIT impact to AI, and most of those said it was under 5 percent of EBIT. PwC's January 2026 CEO survey found 56 percent of chief executives reported neither increased revenue nor decreased cost over the prior twelve months, while 12 percent reported both.
Read those two findings together and the diagnosis is not "AI does not work." Plenty of the same respondents report strong individual productivity gains. The diagnosis is that almost nobody built the measurement rig. If you never timed the task before, you cannot compute what changed. If review time is uncounted, you booked a saving that did not happen. If the pilot ran on the easy 40 percent of cases, you extrapolated from a sample that does not represent the work.
None of that requires a data team to fix. It requires four numbers and the discipline to collect them before you build.
Measure one job, not "AI"
The first move is scoping. A job is a task with a defined trigger, a defined output, and a countable volume. "Support agents draft first replies to inbound tickets" is a job. "Marketing uses AI" is not.
Pick the job with the highest product of volume and current human minutes. High volume with small savings usually beats low volume with big savings, because the small saving is measurable and the big one is anecdotal. Text in, text out, with a human who checks the output, is the shape that measures cleanest. If you want the pattern for turning a repeated task into something that runs without you, that is what WRITE LOOPS NOT PROMPTS covers.
The four numbers, defined precisely
Volume. Runs per month, taken from the system of record, not from an estimate. Tickets closed, invoices processed, transcripts filed. Use a real month, not an average of good months.
Minutes saved per run. The before figure comes from timing the task by hand across at least thirty real instances, including the ugly ones. The after figure is the human time still required once the system is live, and that includes reading the output, editing it, and deciding to send it. Review is not free. It is usually the single largest cost in the after column.
Loaded cost per minute. Salary times about 1.3 for payroll taxes and benefits, divided by 2,080 hours, divided by 60. A 60,000 dollar role runs roughly 0.63 dollars per minute. Use the loaded number or you will understate the gain by a quarter.
Cost per run. Tokens, plus tooling, plus the build amortized over the period you expect the job to stay stable, plus monthly upkeep. On Anthropic's published rates, Claude Haiku 4.5 bills 1 dollar per million input tokens and 5 dollars per million output. A 1,500 input, 400 output run costs about a third of a cent. Prompt caching bills cache hits at a tenth of the input rate, and the Batch API takes 50 percent off both sides for anything that can wait an hour.
The break-even, worked all the way through
Take support ticket triage and first-draft replies. 200 tickets a day, 22 working days, so 4,400 runs a month. Timed by hand, the before figure is 6 minutes per ticket to read, categorize, and draft. After launch, an agent spends 2 minutes reviewing and sending the draft. Loaded cost is 0.625 dollars per minute.
The pilot report writes itself: 4,400 runs times 4 minutes saved times 0.625 equals 11,000 dollars a month, against 15 dollars of tokens. That is the number that gets put on a slide, and it is wrong in four places.
Now apply the haircuts.
Eligibility. Only 62 percent of tickets fit the pattern. The rest are billing disputes and edge cases that route to a human immediately. Eligible volume drops to 2,728 runs.
Rework. 9 percent of drafts get discarded and written from scratch. Those 246 runs do not save 4 minutes, they cost an extra 2 minutes of wasted review. The remaining 2,482 runs save 4 minutes each.
Net minutes: (2,482 x 4) minus (246 x 2) equals 9,436 minutes, or about 157 hours a month. At 0.625 dollars per minute that is 5,898 dollars a month of recovered time.
Costs. Tokens on the eligible volume run about 10 dollars. The build took 60 engineering hours at 85 dollars loaded, so 5,100 dollars, amortized over 12 months at 425 dollars a month. Upkeep, prompt fixes, and eval runs take 4 hours a month, so 340 dollars. Monitoring tokens add 50. Total monthly cost: 825 dollars.
Net monthly gain: 5,073 dollars. ROI: about 615 percent on run-rate cost. Payback on the 5,100 dollar build: just over one month.
That is still an excellent result. It is also less than half the pilot number, and it is the one that survives a quarter of scrutiny.
The six haircuts that separate a pilot from a P&L
- Eligibility rate. What fraction of real volume the system can actually take. Pilots select for the cases that work. Production does not.
- Rework rate. How often output gets discarded. Track it as a first-class metric, because it is the number that moves most after launch and the one that quietly reverses a positive result.
- Priced review. Every minute a human spends checking output belongs in the after column. If review takes longer than the original task, you have not automated anything, you have added a step.
- Amortized build. Engineering hours at a loaded rate, spread over the period you expect the job to hold still. Twelve months is a fair default. Six is fairer if the surrounding process changes often.
- Monthly upkeep. Prompts drift, upstream formats change, models get deprecated. Budget four to eight hours a month per production job and put it in the denominator.
- The reallocation question. Where did the 157 hours go. This is the only haircut that is not arithmetic, and it is the one that decides whether your number is a cost saving or a capacity gain.
That last one deserves its own sentence. Saved minutes are capacity, not cash. They convert into money in exactly two ways: you do not make a hire you would otherwise have made, or you move those hours onto work that produces revenue you can point at. If neither happened, say so. "The job now takes 157 fewer hours a month and the team absorbed it into faster response times" is a real result, honestly stated, and it will hold up better than a dollar figure nobody can trace.
The measurement rig, in one week
You do not need a platform. You need five things, and four of them are logging.
Baseline first, always. Before any build, time thirty real instances of the task by hand. This is the only number you cannot reconstruct later, and skipping it is why so many teams end up arguing about whether anything improved.
Hold out 10 to 20 percent. Route a slice of eligible work down the old path after launch. A live control beats a remembered baseline, and it catches the volume changes and seasonality that would otherwise get credited to your system.
Log every run. Input id, timestamp, input and output token counts, latency, whether a human edited the output, whether it was discarded, and the reviewer's time on task. That is one row per run and it is the whole dataset. Cost per run and rework rate both fall straight out of it.
Grade a sample weekly. Pull 30 outputs, score them against a rubric you wrote before launch, and log the pass rate. Quality regressions show up here before they show up in rework, which gives you a week of warning.
Report one number monthly and one quarterly. Monthly: net hours recovered, with the haircuts applied. Quarterly: whether those hours turned into avoided cost or new revenue, stated plainly either way. Two numbers, no dashboard.
If you want the versions of this that show up in the field, with the templates and the failure modes, that is what goes out in the newsletter.
The bottom line
AI ROI is not hard to measure. It is hard to measure honestly, which is a different problem and a solvable one. Scope to a single repeated job. Time the before by hand. Price the review. Apply the eligibility and rework haircuts. Amortize the build and budget the upkeep. Then answer the reallocation question out loud instead of hoping nobody asks.
Do that and you get a number in the 600 percent range that holds up, instead of a number in the 1,100 percent range that collapses the first time finance looks at it. The second number wins the meeting. The first one wins the budget next year.
How do you actually calculate AI ROI?
Pick one repeated job, not your AI program, and collect four numbers. Volume is how many times that job runs per month. Minutes saved per run is the human time it took before minus the human time it takes now, with review time included in the after. Loaded cost per minute is salary times roughly 1.3 for payroll and benefits, divided by 2,080 working hours, divided by 60. Cost per run is model tokens plus the amortized build plus monthly upkeep. Monthly gain is volume times minutes saved times loaded cost per minute. Monthly cost is volume times token cost plus the amortized build plus upkeep. ROI is gain minus cost, divided by cost. If any of those four numbers is a guess rather than a measurement, your ROI number is a guess too.
Why do most companies report no measurable ROI from AI?
Because they measure adoption instead of outcomes, and because the gains stop at the individual. PwC's 29th Global CEO Survey, released in January 2026 and covering 4,454 chief executives across 95 countries, found 56 percent reported neither increased revenue nor decreased costs from AI in the previous twelve months, with only 12 percent reporting both. McKinsey's State of AI 2026 survey found 39 percent of respondents could attribute any level of EBIT impact to AI, and most of those put it below 5 percent of EBIT. The pattern underneath both numbers is the same. Individual productivity gains are real and widely reported, but hours saved only become money when they are either not backfilled with headcount or redeployed onto work that earns. Nobody measures that second step.
Should I count time saved as money?
Only with a stated assumption, and only if you can name where the time went. Saved minutes are capacity, not cash. Capacity converts to cash in exactly two ways: you avoid a hire you would otherwise have made, or you move those hours onto revenue-generating work and can point at the revenue. If neither happened, the honest report says the job now takes 157 fewer hours a month and the team absorbed it, which is a real result but not a line on the P&L. Writing it that way costs you nothing and buys you credibility the next time you ask for budget.
How long should I measure before I trust the number?
Two weeks of baseline before you build anything, then a full month of production traffic with a holdout. The baseline is the part everyone skips and the part you cannot reconstruct later. Time the task by hand across at least thirty real instances, including the messy ones, before a single line of code exists. After launch, route 10 to 20 percent of eligible work through the old path so you have a live control group rather than a memory of how long things used to take. One month of production data catches the volume seasonality and the rework rate that a one-week pilot always misses.
What is a realistic payback period for an internal AI build?
For a narrow, high-volume, text-shaped job, one to three months is common because the build is small and the token cost is close to noise. In the worked example below, a 60-hour build costing about 5,100 dollars pays back in roughly one month at 5,070 dollars of net monthly gain. Payback stretches past six months when the job is low volume, when the output needs an expert reviewer whose time is expensive, or when the integration work dwarfs the model work. If your estimate lands past twelve months, the problem is usually the job selection, not the model.
OpusJake is Jake Schincariol's operating system for building with AI: agents, workflows, prompts, and the free resources behind them. Get the next move every week.