How to measure whether AI is paying off

Most businesses cannot tell you whether their AI spend is working, and the surveys say so plainly. PwC's latest survey of 4,454 chief executives found 56% had seen neither revenue growth nor cost savings from AI in the past year. McKinsey's 2026 research found only 29% of executi

Most businesses cannot tell you whether their AI spend is working, and the surveys say so plainly. PwC’s latest survey of 4,454 chief executives found 56% had seen neither revenue growth nor cost savings from AI in the past year. McKinsey’s 2026 research found only 29% of executives could reliably measure the return on their AI investment at all. The fix is unglamorous. Decide what you are measuring before you start, measure it against a baseline, and count the full cost.

Here is how to do that in a business without a data team, with a worked example and the three ways the numbers lie.

Why most firms cannot answer the question

Three reasons, and they compound.

Nobody set a measure before the tool went in, so there is nothing to compare. The tool arrived, people used it, and six months later the question ‘is it working’ has no number attached.

Nobody took a baseline, so even where there is a measure, there is no before. ‘It feels faster’ is the usual answer, and it is worthless.

Nobody counted the full cost. The licence is in the budget. The three hours a week someone spends checking the output is not. Neither is the training, the set-up, or the afternoon lost when it produced a confident wrong answer.

Fix those three and the question becomes answerable. Leave any one of them and you are guessing with a spreadsheet.

Pick one outcome per use case

‘Productivity’ is not a measurement. Hours saved on a named task is. Invoices chased without a person touching them is. First-reply time on customer email is. Each AI use case needs one outcome you can count, agreed before the tool goes in. If you cannot name it, you are not ready to measure it, and probably not ready to buy it.

Good measures are boring and specific. Hours per weekly report. Proposals produced per salesperson per week. Days from invoice to payment. Tickets resolved without escalation. Pick the one that the use case is actually supposed to move, and ignore the rest.

Take the baseline first

The number that proves a return is the one from before. How long did the task take, how many did you process, how many errors. Measure it for a few weeks before you change anything. Businesses that skip this end up arguing about whether things got better, because nobody wrote down how bad they were.

The baseline does not need to be sophisticated. Ask the three people who do the task to log their hours on it for a fortnight. Count the output. Note the errors. Write it down and date it. That is enough to compare against.

Count the whole cost

Licences are the small part. Add the time to set it up, the time people spend checking the output, the training, and the hours lost when it goes wrong. An honest cost line is often double the subscription. If the saving still clears it, you have a result. If it only clears the subscription, you have a hobby.

The checking time is the one everyone forgets, and it is usually the largest hidden cost. If an agent drafts 30 emails and a person spends 40 minutes reviewing them, those 40 minutes are part of the cost of the agent. Count them.

A worked example

A 40-person firm puts an AI agent on invoice chasing. Before the change, the finance assistant logs their time for two weeks. Chasing takes about 6 hours a week, and roughly 1 in 5 reminders goes out with a mistake that needs a follow-up.

The agent goes in. Licence, £80 a month. Set-up, two days of a consultant’s time, £2,400, spread over a year as £200 a month. Training, half a day for the assistant. Checking, the assistant reviews the drafted reminders, about 45 minutes a week.

After a month, chasing takes about 1 hour a week including the checking. Errors have dropped to almost none, because the agent does not mistype a figure. The saving is about 5 hours a week, roughly 20 hours a month. At the assistant’s loaded cost, say £25 an hour, that is £500 a month saved against about £280 a month in full cost. A real return, modest, and provable.

Now the honest part. Those 20 hours only count if they went somewhere. In this case the assistant took on the supplier reconciliation that had been slipping, so they did. If they had simply been absorbed into a slightly less busy week, the £500 would have been imaginary.

Review it on a cadence, with a person accountable

Quarterly is about right. Did the measured outcome move, by how much, against what cost. Keep, expand or stop. The leaders who see returns are, in McKinsey’s words, twice as likely to have a defined process for measuring impact. The process matters more than the metric.

One page per use case, every quarter. The measure, the baseline, the current number, the full cost, the decision. Signed by the person who owns it. That is the whole system, and it is more than most firms have.

Watch for the three fake returns

Time saved that nobody reclaims. If the hours freed up do not become sales calls, faster delivery or fewer overtime bills, you have not saved anything, you have moved it. Decide in advance where the hours go.

Output that looks finished but needs rework. Count the checking time, or the saving is an illusion. A tool that produces a draft in two minutes that takes 20 minutes to fix has saved you nothing against a human who took 20 minutes.

Pilots that never scale. A result in one team that stays in one team is a nice story, not a return. Decide early what ‘rolled out’ means and measure against that.

The common mistakes

Measuring usage. Logins and prompts tell you people are using the tool. They tell you nothing about whether the work got better or cheaper.

Letting the vendor measure. A supplier’s dashboard measures what flatters the supplier. Use your own numbers.

Starting with the hardest use case. Measure something simple and repetitive first, prove the method works, then take it to the complex ones.

Never stopping anything. A measurement system that only ever says ‘keep’ is not a measurement system. Stopping a use case cleanly on the evidence is a good result.

The honest trade-off

Measuring properly slows the start. You spend weeks on a baseline while competitors appear to race ahead. The trade is worth it. The firms racing ahead are, on the evidence, mostly spending money they cannot account for. An AI opportunity review sets the measures and the baseline up front, so the question ‘is this working’ has an answer rather than an argument, and our piece on AI agents in the back office shows the kind of use cases that measure cleanly.

Frequently asked questions

What is a realistic return on AI for a small business?
Measured in hours saved on specific tasks and errors avoided, rather than headline revenue. Most firms that measure properly find real but modest gains on a few processes, not a transformation.

Why can’t most companies measure AI ROI?
Because they never set a baseline or a single outcome per use case. McKinsey found only 29% of executives could reliably measure AI return, almost always for that reason.

What should I measure first?
One countable outcome per use case, such as hours per task or items processed without human touch, recorded before the tool goes in and reviewed quarterly against the full cost.

How do I count the cost of checking AI output?
Ask the person reviewing it to log the time for a fortnight. It is usually the largest hidden cost, and it belongs on the cost side of the calculation.

What if the time saved just disappears?
Then nothing was saved. Decide before the tool goes in where the freed hours will go, a named task or a named person, and check that they went there.

When should we stop an AI project?
When a quarterly review shows the measured outcome has not moved enough to clear the full cost, including checking and rework time. Stopping cleanly is a good result. Drifting on is the expensive one.

Sources