The missing step in AI ROI: turning time saved into business value

An AI assistant reduces the time needed to handle a customer enquiry from eight minutes to six. Multiply those two minutes across thousands of enquiries, attach an hourly labour cost, and the business case looks persuasive.

There is still an unanswered question: what will the organisation do with the capacity it releases?

It might reduce overtime, absorb growth without recruiting, or improve service levels. It might simply create small gaps between tasks while payroll stays unchanged. Each outcome has a different economic value.

My view is that an AI investment case should explain how a technical improvement becomes an operational change, and how that change produces a measurable benefit. Data, integration and architecture belong inside that argument from the beginning.

Research provides context, not your forecast

The evidence illustrates why local measurement matters. Brynjolfsson, Li and Raymond’s Generative AI at Work study, in its revised November 2024 paper, reports a 15% average increase in issues resolved per hour among 5,172 customer-support agents. Benefits varied considerably across workers.1

METR’s July 2025 randomised study found that 16 experienced open-source developers took 19% longer on their tasks when allowed to use early-2025 AI tools.2 That result concerns a particular population, workflow and generation of tools. In February 2026, METR reported that selection effects made its follow-up estimates unreliable as a measure of current productivity impact.3

These are different settings and different outcome measures. They should not be combined into an average or treated as predictions for today’s deployment. They support a more useful discipline: test the actual workflow, with representative people and a credible baseline.

Define the outcome before selecting the tool

Start with a decision the business can act on. “Reduce the cost of resolving eligible enquiries while maintaining service quality” is specific enough to guide design. “Give everyone an AI assistant” describes an activity.

Record the starting point: enquiry volumes, handling time, repeat contacts, quality, escalation rates and the cost of successful resolution. Include the time people spend verifying outputs and fixing mistakes. A quicker first response can still create more work elsewhere.

Then name a benefit owner. If released capacity is supposed to reduce overtime, someone in operations must change the roster. If it enables more sales, there must be sufficient demand, and the case should count incremental contribution after fulfilment costs rather than headline revenue alone.

A worked example: 280 hours does not automatically mean £8,400 saved

Consider a hypothetical support team. These figures are illustrative assumptions, not a customer result or a market benchmark.

The calculation is 12,000 × 70% × 2 ÷ 60 = 280 hours. At £30 an hour, that is £8,400 of potential capacity value. Whether it becomes an economic benefit depends on how the team uses it.

Assume the team can translate half into actual avoided spending, such as reduced overtime or contractor hours, at the stated rate. Its monthly benefit is then £4,200. This 50% realisation rate is an explicit scenario assumption that needs evidence.

Suppose implementation costs £24,000 and ongoing operation costs £2,800 a month. Those budgets must cover integration and data preparation, evaluation, licences or inference, monitoring, support, training and process change without double counting.

Over a full year at steady-state performance:

• Realised benefit: £4,200 × 12 = £50,400.
• Total cost: £24,000 + (£2,800 × 12) = £57,600.
• Net benefit: −£7,200.
• First-year ROI: (benefit − cost) ÷ cost = −12.5%.

The team improved task speed, yet the assumed first-year financial return is negative. At 75% realisation, the same case produces £75,600 of benefit and 31.25% first-year ROI. First-year break-even requires approximately 57.1% realisation, holding every other input constant.

This simplified model excludes ramp-up, tax and discounting. Slower adoption would reduce the first-year return. Quality or risk improvements may justify investment, but quantify them separately when evidence permits. Do not count the same released hour as both a cost saving and revenue-generating capacity.

Architecture changes the economics

The commercial assumptions depend partly on the system design. An assistant that gives a useful answer but leaves staff copying information between applications can lose much of its benefit at the hand-off.

For this support example, I would consider four requirements:

Relevant, authorised data. The assistant needs current policy and customer context, subject to the user’s access rights. Conflicting records or stale guidance increase verification and correction work.

A reliable route to action. Where action is required, controlled APIs should connect the workflow to the system of record. Permissions, validation and duplicate protection belong in the action path. A timeout should not turn one approved refund into two.

An explicit exception path. Uncertain or policy-sensitive cases need an owner and a hand-off that preserves context. Escalation is part of the operating model and its cost should be measured.

Evidence of the final outcome. A successful model response is only one event. Track whether the enquiry was resolved, whether it reopened, and how much human effort the complete process required. NIST’s Generative AI Profile offers a broader reference for incorporating trustworthiness into system design and evaluation.4

Authorised CRM and policy context feeds AI assistance. A person reviews or escalates the draft, and a controlled API validates approved actions. Workflow events and final outcomes join through a shared case identifier so the business can measure cost, adoption, effort, resolution and repeat contacts.

Architecture should remain proportionate. A low-risk drafting assistant may need no action API. The purpose is to remove the specific failure modes that weaken the business case, with the simplest design that does the job.

Measure the whole workflow

Use a small scorecard that links operations to finance:

Where practical, compare similar cases with and without assistance, rather than relying solely on a before-and-after average. Changes in demand, staffing or case difficulty can otherwise distort the result. Set an observation window that captures repeat contacts and delayed failures.

A better question for the investment committee

Before expanding a pilot, ask: which benefit has an accountable owner, what evidence supports it, and what must change operationally to realise it?

Start with one workflow. Establish the baseline, test representative cases and measure both quality and total effort. Then revise the economic assumptions using observed adoption, exception rates and operating costs.

Scale when that evidence supports the decision. Redesign when a specific hand-off, data problem or operating constraint prevents value from materialising. Stop when the benefits do not justify the full cost.

That is the standard I would apply to AI ROI: a traceable connection between the technology, the way work changes and the outcome the business actually receives.

Sources

Sources checked 27 September 2026. All financial calculations are illustrative author calculations.