AI ROI: how to estimate it before you build and check it after

Five numbers decide whether an AI project pays back. The arithmetic is simple and the inputs are where cases go wrong, so write each input down as an assumption with its source next to it. The post-launch check later on this page tests those assumptions one by one.

Two of the inputs need defining. Loaded hourly cost is what an hour of the team's time really costs you: salary plus employer taxes, pension and overheads, divided by the hours people actually work. Realisation rate is the share of freed time that turns into money. Both come up again further down, and they are where optimistic cases usually go wrong.

Every ROI figure compares the new way of working with the old one, so the baseline has to exist before the AI does. Measured afterwards, it becomes a reconstruction from memory, and the people who remember it best are the ones who want the project to have worked. I would not approve an AI business case with no measured baseline behind it.

The UK government's AI Playbook recommends early user research, with a business analyst looking for efficiencies in the current process, to establish a baseline of metrics that project outcomes can be measured against. HM Treasury's guidance on evaluating AI interventions goes further. Think about the baseline early, it says, and if the evaluation will compare the AI system with business as usual, document precisely what business as usual consists of before the system is introduced. It also warns that a baseline is harder to define when AI replaces complex or subjective work, which is an argument for starting early rather than for skipping it.

Measure the one workflow the project will change, in the units the ROI will be reported in. Four weeks of data is a sensible minimum for most volumes, because it is long enough to catch a month-end peak.

A saved hour is worth its loaded cost only if something changes because of it. If the same people are paid for the same hours and fill the freed time with other work, you have gained capacity rather than cash, and a business case that counts it as cash overstates the return.

So estimate a realisation rate: the share of freed time that will turn into money, and the route by which it will. The honest routes are a vacancy you no longer need to fill, overtime or agency cover you stop paying for, growth the team absorbs without hiring, errors that stop costing you refunds or penalties, and revenue from work that now gets done. Name the route for each part of the benefit and the person who will make it happen. A realisation rate with no owner tends to stay at zero.

HM Treasury's Green Book makes a related point about comparisons. Its business as usual option, the benchmark every proposal is compared against, does not mean doing nothing, because current arrangements carry their own costs, benefits and risks. For an AI case, compare with the process as it would otherwise run, including any hiring or growth you already planned.

Everyone sees the build cost. The lines below are the ones that get left out, and several of them come back every year. The AI Playbook warns that, depending on the tool, AI implementation can have considerable compute costs, and that ongoing investment is needed to maintain these systems, update them and keep their performance stable over time. When a buyer writes requirements for suppliers, the Playbook asks for guidance on budget that considers hidden costs.

Evaluation and monitoring are where the engineering that makes production AI systems safe to depend on shows up in a budget: regression tests, logs, failure handling and someone who reads them. Leave them out and the case looks better on paper while the system gets harder to trust in use. For work where a wrong answer costs money, the controls between the model and your systems belong in the cost line too. The pattern where the model proposes and a deterministic check decides is one way to build them.

Change management is the easy line to cut when a budget is squeezed, and it is the line that decides whether anyone uses the system. The AI Playbook asks organisations to plan for how AI will change the way people and processes work, including change management plans and training based on a learning needs analysis.

This example is invented to show the method. The business, the figures and the supplier quote are illustrative, and none of them is a 1AYM price, a client result or a benchmark. A mid-sized distributor's accounts payable team answers supplier invoice queries by email. The proposal is an AI step that reads each query, pulls the invoice and payment records, and drafts a reply for a person to check and send.

Assume a loaded hourly cost of £35 for the team and £50 for the process owner and manager. The coverage and handling-time figures come from a test on 300 past queries, which is the kind of evidence a case should rest on.

On these figures the project pays back inside three years, but only just, and the running costs eat almost half the realised benefit. Once the forgotten costs are in, expect that shape. It is a lot less exciting than the £65,100 a year of gross value a first slide would show. The next section tests whether the case survives worse assumptions.

HM Treasury's Green Book, the UK government's guidance on appraisal, says appraisals should be explicitly adjusted for optimism bias, the proven tendency to be over-optimistic about key assumptions. It describes the pattern as costs that are typically higher, benefits that are typically lower and delivery that typically takes longer than first anticipated. It expects the size of the adjustment to come from an organisation's own record of past forecasts against what actually happened, so if you keep that record, use it.

The Green Book also asks for sensitivity analysis, which changes key assumptions to see how the result moves, and switching values, the value an assumption would have to reach for an option to stop being value for money. Both are cheap to run on a spreadsheet, and either one tells a sponsor more than a single ROI figure does.

Apply that to the fictional example. Cut the benefit by 20% and raise every cost by 20%, and the three-year result turns from a 15% return into a 23% loss. The switching value for the realisation rate is about 43%: below that, the project loses money over three years, whatever else goes right. The 20% figures are our illustration, not a Green Book value.

That tells the sponsor what the pilot is for. The test on past queries has already measured the model. The open question is whether half the freed time really becomes money, so that is what the pilot should measure, and the approval should depend on the answer.

Four figures turn up in AI business cases and progress reports, and each says less than it appears to. Keep reporting them, but never let one of them stand in for the return.

The check after launch reuses the worksheet. Measure what the baseline measured, the same way, and put the actual figure next to each assumption: volume, coverage, time per case, rework, realisation and each running cost from the invoices. The gaps show you which assumption was wrong, and that is worth more than a single yes or no.

Run it at about 90 days, once the new way of working has settled, and again at a year. HM Treasury's guidance on evaluating AI interventions recommends rapid evaluation in the early stages of a roll-out and regular evaluation after full roll-out, because AI systems keep changing after launch. Repeat the check after any large change of model or scope.

Where you can, compare against a group that has not got the system yet. The same guidance points out that because AI is delivered digitally, you can control who uses it and when, for example by giving one team access before another. Measuring both groups before and after, a method it names difference-in-differences, separates the system's effect from a quiet month or a change in the work itself. If the whole team switched over on the same day, all you have is a before-and-after comparison, and the report should say so.

End the check with a decision: continue, fix the assumption that failed, or stop. A project that misses its case and is stopped early still leaves the evidence for the next case.

UK central government has a set method for this. The AI Playbook for the UK Government says any investment approaching £10 million will typically need a five-part business case, for which the Green Book must be used. Below that threshold, it says teams should strongly consider the Government Digital Service's guidance on agile business cases. It also says digital and technology spend above £100,000 for anything public facing, and above £1 million for anything else, must be assured through your assurance boards, following your organisation's own process.

The Green Book discounts future costs and benefits at the social time preference rate, set at 3.5% in real terms for years 1 to 30, and asks practitioners to keep monitoring and evaluation in mind throughout appraisal, with value for money evaluation among the types it names. HM Treasury's AI evaluation guidance adds that many AI interventions will need more substantial evaluation than similarly sized business as usual work, because they are untested and carry distinct risks.

This section summarises published guidance. It is not legal or financial advice, and your finance and commercial teams set the rules you follow. Our public sector page explains how UK public bodies can work with 1AYM, and what G-Cloud covers.

Fill this in before approval, keep it with the business case, and complete the actual column at 90 days and at a year. Any line you cannot fill in before approval is a question for the pilot to answer.

Building this case is what 1AYM's AI Opportunity & Feasibility Sprint is for. It is fixed scope and typically takes two to four weeks: we look at how the work is done today and what state your data and systems are in, score candidate use cases on value, feasibility and risk, settle build versus buy, and write the roadmap, the investment case and the governance conditions. Whoever writes the case, make sure its assumptions are written down, because they are what make a post-launch check possible.

If a case needs evidence before full approval, a pilot built to measure coverage and realisation can be scoped on its own, because 1AYM takes small fixed-scope statements of work as well as larger builds. For a quick read of where you stand first, the free AI readiness assessment covers ownership, data, systems and controls in 13 questions. And if you already have a case and want a second opinion on its assumptions, book the call below.