Skip to content
← Back to blog
AI Strategy·Updated October 22, 2026·5 min read

How to measure AI ROI when the reports say most can’t

Only 39% of firms see any EBIT impact from AI, and just 4 of the 50 largest banks reported realised ROI. Measuring return is the skill that separates winners.

If most organisations can't show a bottom-line return on AI (only 39% of respondents to McKinsey's 2025 survey report any EBIT impact, and just 4 of the 50 largest banks Evident tracks reported realised ROI across all their AI use cases as of October 2025) then measuring ROI is itself the competitive skill. That's a subtle but important reframe. The bottleneck isn't always whether AI creates value; it's whether you can prove it created value, in numbers a finance team will accept. A useful pilot can still die in a budget review if nobody can show it worked.

Why AI ROI is hard to see

  • Benefits are often diffuse, a few minutes saved per task spread across hundreds of people, and small, scattered savings are notoriously hard to roll up into a number on a report.
  • The full cost is rarely tracked against the benefit. Teams remember the headline API bill but forget the monitoring, the prompt upkeep, the integration work and the human review time that keep the feature honest.
  • Perception misleads. In METR's randomised trial of 16 experienced open-source developers using early-2025 AI tools, the developers estimated afterwards that AI had cut their task time by 20%, when it had added 19%. If the people doing the work can't reliably sense the effect, then "it feels like it's helping" is worthless as evidence. Vibes aren't ROI.

Why this matters

This connects directly to why so many AI pilots fail: a pilot with no baseline and no measured target can't be defended when budgets tighten. The team that can walk into a review and say "this workflow cost X before, costs Y now, here's the running cost, here's the net" survives the cut. The team waving a demo and a good feeling does not. Measurement isn't bureaucracy here; it's the thing that keeps a working feature alive.

A practical approach

  1. 1.Pick one workflow with a baseline. Measure its current cost, time and quality before AI touches it. If you skip this step, you've lost the comparison forever, because you can't reconstruct a baseline after the fact.
  2. 2.Instrument the AI version. Track its true running cost (inference, monitoring, review) and its measured output, not its perceived output.
  3. 3.Compare like for like, including the maintenance tail. The launch is the cheap part; prompts drift, models change, and someone has to keep it working. Count that, the same discipline behind the AI cost curve.
  4. 4.Tie it to a P&L line: revenue, cost or risk. If you can't connect the feature to a number that shows up in the accounts, be honest that it's a bet, not a return. Banking teams face this acutely; see AI in banking: the ROI gap.
If you can't draw a straight line from the AI feature to a number that matters, you don't have ROI. You have a hope.

A worked example (made-up numbers)

Suppose a support team of ten agents adds an AI assistant that drafts replies. The numbers below are invented to show the arithmetic. They aren't from a client or a study, and they count agent hours instead of money, so the method works with any rate card.

Before the rollout, the team measures one month: 6,000 tickets closed in 1,600 agent hours, which is 16 minutes a ticket. It also records its reopen rate, because speed that costs quality isn't a saving.

After the rollout, the same team closes 7,200 tickets in the same 1,600 hours, and the reopen rate holds steady. The assistant has a running cost too. Converted to hours at the team's loaded rate, it comes to 200 hours a month: 50 for inference, 75 of engineer time on monitoring and prompt upkeep, and 75 of human review.

The 1,200 extra tickets would have taken 320 hours at the old 16 minutes each. Subtract the 200-hour running cost and the net gain is 120 hours a month, a 60% return on what the assistant costs to run (120 on 200). Spread the full cost across every ticket and the time per ticket falls from 16 minutes to 15 (1,800 hours over 7,200 tickets).

Now count only the inference line. The same pilot looks like a 540% return (270 on 50). Same tool, same month, and only one of those numbers survives a finance review. One caveat belongs next to the result: the extra tickets are savings only if they would otherwise have cost something, such as a hire you didn't make or overtime you didn't pay. If the queue was already empty, the benefit is zero, and only a baseline would have told you. Contrast the team that reports "agents love it" with no numbers: identical tool, completely different fate when finance asks the hard question.

The forward-looking takeaway is that measurement compounds. The first workflow you instrument is painful; by the third, you have a repeatable method for deciding what to scale and what to kill. In a landscape where most can't show a return, that discipline is the edge. If you want help measuring what an AI investment actually returns, get in touch.

Sources

Written by Zain Ali

Frequently asked questions.

Three reasons compound. Benefits are diffuse, often a few minutes saved per task across hundreds of people, which is hard to roll up into a reportable number. The full cost is rarely tracked against the benefit, because teams remember the API bill but forget monitoring, prompt upkeep, integration and human review. And perception misleads: a randomised trial found developers who felt faster while actually being slower.

Measuring the workflow before AI touches it. Record its current cost, time and quality first, because a baseline cannot be reconstructed after the fact. Skip that step and you have lost the comparison permanently, which is why so many working features cannot be defended when budgets tighten.

The AI version's true running cost, meaning inference plus monitoring plus review time, against its measured output rather than its perceived output. Then compare like for like including the maintenance tail: prompts drift, models change, and someone has to keep it working. The launch is the cheap part.

Tie it to a P&L line: revenue, cost or risk. If you cannot draw a straight line from the feature to a number that appears in the accounts, the honest description is a bet rather than a return, and saying so is better than defending a figure finance will not accept.

It is the thing that keeps a working pilot alive. A team that can say a workflow cost X before and costs Y now, with the running cost stated, survives a budget review. A team showing a demo and a good feeling does not, regardless of whether the feature actually worked.