How to measure AI ROI without lying to your board.

Three kinds of numbers show up in most AI ROI presentations, and none of them hold up to a direct question about cash.

• Survey-based productivity claims. "73% of employees report feeling more productive with AI tools." This measures sentiment, not output. It has no denominator, no baseline, and no connection to a cost or revenue line.
• Best-case demo timing. A task that took an analyst forty minutes now takes the AI system four minutes, measured once, under conditions chosen to showcase the tool. Production performance, with real edge cases and real review overhead, is a different number.
• Vendor-supplied benchmark ROI. A number produced by the company selling you the tool, based on their customers' averages, not your workflow, your labor cost, or your error tolerance.

A CFO asking "what did this actually save us last quarter, in dollars" can't get an answer from any of these three. That question is coming eventually. The method below is built to answer it before it's asked.

We run the same four-step method on every ROI engagement, regardless of the workflow being measured:

1. Pick one workflow. Not "customer support" broadly, but "tier-one billing ticket resolution" specifically. ROI measured across a whole department is unfalsifiable. ROI measured on one workflow is checkable.
2. Establish the pre-AI baseline, in cash terms. Before writing a line of the new system, measure the current cost of the workflow: labor hours times loaded hourly cost, error rate times cost per error, cycle time if it affects revenue. Write this number down and date it. It doesn't count if it's an estimate made after the AI system already exists.
3. Measure the same workflow, the same way, after launch. Same units, same time window length, same definition of "resolved" or "complete." If the baseline measured resolution time including rework, the post-launch measurement has to as well.
4. Report the cost line next to the benefit line, every month. Token spend, engineering maintenance time, human review time, and the cost of errors that reached a customer, subtracted from the benefit, reported as one net number.

This is slower and less flattering than a single demo-driven percentage. It's also the only version of the number that survives an audit eighteen months later.

The most common way ROI numbers get inflated isn't overstating the benefit. It's undercounting the cost. Four line items we see missing from nearly every ROI deck we review:

• Engineering maintenance time. Prompt updates, tool fixes, model version migrations. This is ongoing, not a one-time build cost, and it belongs in the monthly number, not amortized away.
• Human review time. If a person checks the AI system's output before it goes out, that person's time is a real cost of running the system, not a footnote.
• Cost of errors that reach a customer. A wrong answer that damages trust or triggers a support escalation has a cost, even if it's harder to quantify than token spend. Estimate it conservatively and include it rather than omit it.
• Infrastructure and observability. Logging, dashboards, and eval infrastructure cost money to run and maintain. They're part of running the system responsibly, and part of its true cost.

Our production readiness guide covers the operational side of this in more detail, since most of these missing cost items are also the same gaps that cause production incidents.

Here's a simplified version of a real engagement, with the numbers rounded for clarity.

Workflow: first-pass triage of inbound support tickets.

Baseline (30 days, pre-AI): 4,000 tickets, average 6 minutes of analyst time per ticket at a $35/hour loaded cost, roughly $14,000 in labor. Error rate on category assignment: 9%, each miscategorized ticket costing about 12 extra minutes downstream, adding roughly $2,500.

Post-launch (30 days, month one): Average analyst time per ticket dropped to 2 minutes for review of the AI's suggested triage, cutting labor to about $4,700. Error rate on category assignment dropped to 4%, cutting downstream cost to roughly $1,100. Token spend for the month: $1,900. Engineering maintenance time: 8 hours at $85/hour, about $680.

Net: Baseline cost was $16,500. Post-launch cost was $8,380. Net monthly benefit: roughly $8,100, reported with both lines visible, not just the headline savings figure.

That's a real, defensible number a CFO can check against actual invoices and time logs. It's smaller and less exciting than "AI cut support costs by 90%," and it's the number that survives the second and third time someone asks about it.

The common advice this year is to build an "AI ROI dashboard" that tracks adoption metrics, usage counts, and sentiment scores alongside financial figures, on the theory that a fuller picture builds a stronger case. In practice this usually does the opposite. Blending soft metrics with cash metrics on the same dashboard gives every stakeholder a way to cherry-pick the number that supports their existing opinion, and it lets a genuinely weak cash number hide behind a strong adoption number.

The stronger version keeps them separate. One section, clearly labeled, for cash-visible ROI, calculated with the baseline method above. A second section, clearly labeled as qualitative, for adoption and sentiment data. Never let the second section's numbers get averaged into or presented alongside the first. Boards that have been burned by AI ROI claims before will trust a modest, well-separated number far more than an impressive blended one.

A method is only as good as its cadence. We recommend:

• Report monthly, starting week one, even before the number looks good. An honest negative number in month one, trending toward positive by month three, is more credible than a single strong number that appears with no history behind it.
• One named owner for the ROI number, the same way there should be one named owner for the project itself. If ROI reporting is nobody's specific job, it quietly stops happening once the initial excitement fades.
• Same definitions, every month. If the definition of "resolved ticket" or "successful task" changes partway through, restate the prior months under the new definition rather than letting the comparison silently break.

This is the same rigor we bring into pilot-to-production engagements, where the ROI case is often the deciding factor in whether a pilot gets the budget to keep going.

AI ROI doesn't need to be impressive to be useful. It needs to be real, checkable, and reported consistently, with the cost line sitting right next to the benefit line every time. Baseline before you build, measure the same workflow the same way after launch, count the costs that are easy to forget, and keep the soft metrics in their own section. That's the version of the number that survives the second year, not just the first board meeting.