How to measure AI ROI: a worked process example

Measure AI ROI on one defined process: establish the baseline, include human review in the new workflow, calculate usable capacity, identify how that capacity becomes a financial benefit, and subtract the full cost. Saved time is an operational result. A return requires a credible decision about how that time is used.

Softblues helps UK and Irish firms become AI-native. This guide gives operations and finance leaders a practical way to assess one process before committing to a wider rollout. The example below is synthetic arithmetic, not a client result or a calculator output.

Key facts

• The example uses 200 document packs a month, with 20 minutes of human work before AI and 8 minutes afterwards, including review and corrections.
• The difference is 40 hours a month of capacity. It is not automatically a reduction in payroll or an increase in profit.
• A financial benefit needs an owner, a specific operational decision and evidence that it happened.
• Costs include implementation, licences, usage, training, oversight and ongoing maintenance. Count each cost once.
• Payback depends on when benefits and costs occur. This method makes no promise of a typical payback period.

What should you define before measuring AI ROI?

Choose a process with a clear beginning and an accepted output. For a document-pack check, that might run from receiving the complete pack to a reviewer accepting the check result. Keep that boundary the same before and after the change.

Write down who does the work, where the volume count comes from and what counts as a completed case. A pack returned for correction is not equivalent to an accepted pack. If the team still has to find missing material, fix extraction errors or rewrite the result, include that effort.

Agree the quality standard with the process owner. A faster check that misses an important discrepancy has not delivered the same service. Track the type and severity of errors alongside time, rather than compressing everything into one speed figure. In a regulated workflow, ask the compliance lead to confirm the required review and sign-off.

Step 1: what does the current process actually take?

Record volume and human handling time together. Count active work, including corrections, chasing and repeat checks within your chosen boundary. Record elapsed waiting time separately: reducing a queue is useful, but it does not necessarily remove an equivalent number of paid working hours.

Start with a representative working week, then extend the measurement if month-end work, renewals or unusual cases change the mix. Do not assume that a quiet week describes the whole year. Note where a colleague's estimate substitutes for a timed observation so that the estimate can be replaced later.

Our illustrative process handles 200 packs a month at 20 minutes of human work per pack. That is 4,000 minutes, or about 66.7 hours a month. These are invented inputs to make the calculation visible. Your baseline should come from your own records and observations.

Step 2: how many human minutes remain after AI?

Test the proposed workflow on a representative sample, including difficult and incomplete packs. Count preparation, checking the AI output, correcting errors and dealing with exceptions. Include a failed attempt even if the person eventually completes the case manually.

For the illustration, human effort falls to 8 minutes per pack. Those 8 minutes already include checking and correcting the result. Across 200 packs, the new workflow uses 1,600 minutes, or about 26.7 hours a month.

Measure comparable work. If the original sample includes difficult cases and the AI sample contains only tidy files, the comparison is misleading. Separate routine and difficult cases if necessary, then weight the result by the real workload mix. Record whether output quality meets the agreed standard before treating the time difference as usable.

Keep the evidence modest and inspectable: case category, minutes before, minutes after, correction required and final acceptance. Use approved identifiers and storage; the measurement sheet does not need copies of sensitive documents.

Step 3: how much capacity can the team use?

The arithmetic for the example is straightforward:

(20 − 8) × 200 ÷ 60 = 40 hours a month.

Illustrative example only. Rounded hours are shown for readability; the 40-hour difference comes from the unrounded calculation.

Now check whether the time can be used. Ten minutes spread across many people and interrupted tasks may be harder to redeploy than a predictable block in one team's schedule. The work removed may also sit with a different role from the one facing the bottleneck.

Ask the team lead which work will move into that time, when, and whether another constraint will prevent it. Keep the measured time difference and the usable portion separate if they differ. Do not quietly assume every minute becomes productive capacity immediately.

A reduced backlog or a more manageable working day can be a worthwhile operational outcome. Report it directly. It does not need an invented cash value to justify discussing it.

Step 4: which decision turns capacity into financial benefit?

Name the mechanism before multiplying hours by a salary rate. A loaded hourly rate can describe the value of capacity, but the business still pays a salaried employee unless a cost or output decision changes.

In the 40-hour illustration, no hiring, overtime or sales decision has been specified. The defensible conclusion is therefore 40 hours of capacity and an unquantified financial benefit. The example does not establish cash payback.

Do not allocate all 40 hours to both avoided hiring and additional revenue. If different portions support different decisions, show the split. Check that the team has sufficient demand and the right skills to deliver additional work. Count contribution after its costs, not the whole invoice value.

A planned hire that can wait is a different claim from reducing current payroll. Show the timing and the approved counterfactual: what would otherwise have been spent, and why. Finance should own or validate that assumption.

Step 5: what is the full cost, and when is payback reached?

Build a dated cost record rather than treating the licence as the whole investment. Separate one-off implementation from recurring costs so that the reader can see both the first-year position and ongoing economics.

Include process mapping, data preparation, configuration or development, integrations, testing and rollout. Add recurring licences, usage, monitoring, maintenance and governance. Include training and the time staff spend supporting the new process, even when that effort does not appear as a supplier invoice.

Be consistent about human review. In our example, review is already included in the 8 minutes. When valuing the reduction in human effort, do not subtract the same review time again as an extra running cost. Separately count additional governance work outside the measured case boundary.

For an agreed measurement period:

ROI = (realised financial benefit − total incremental cost) ÷ total incremental cost.

State the period and accounting basis. If cost is zero, that ratio is undefined; do not report an infinite return. If benefits remain only as capacity, show them separately from the financial ROI calculation.

For cash payback, track incremental cash inflows and cash outflows month by month. The payback month is the first month cumulative attributable cash benefits cover cumulative incremental cash costs. Internal staff effort can belong in a wider economic assessment even when it does not create a new cash payment; label that basis separately.

A simple setup-cost divided by monthly net-benefit formula only works as an approximation when the monthly benefit and running cost are stable. It can mislead during a staged rollout. If recurring costs exceed realised benefits, the model does not establish payback. There is no universal number of months that fixes this.

How should you test the result before scaling?

Keep a comparison set containing ordinary work, exceptions and deliberately difficult cases. Use the same acceptance criteria for both workflows. Record failed outputs and time spent resolving them, not just the successful demonstrations.

Have the process owner review quality and the finance owner review the route to financial benefit. Agree in advance what would justify continuing, changing the scope or stopping. A pilot can supply better inputs; it cannot by itself prove a year of benefits.

Repeat the measurement after the workflow settles, and again when the model, policy, source documents or process changes materially. Record changes in demand or staffing that could explain the difference without AI. Preserve the earlier baseline so that a new comparison does not erase the original evidence.

Our financial-advice compliance file-review example illustrates a proposed workflow with human sign-off. It is at the proposal and pre-discovery stage. It is not evidence of a delivered saving or measured ROI.

Which calculator answers your question?

Use the process automation ROI calculator when the decision concerns one recurring workflow. Use the whole-firm AI ROI calculator when you are making a first estimate across the organisation. Their assumptions are starting points to replace with your own evidence, not a supplier quote or a guarantee.

The insurance-broker business-case example explores the whole-firm decision. This article keeps the focus on measuring a single process, so the two estimates should not be added together without checking for overlapping benefits.

If you have not chosen an implementation route, the general AI adoption guide explains the alternatives. A ready-made assistant may be enough for a person-led task. Recurring workflows with integrations, exceptions and write actions need a wider assessment of controls and cost.

Frequently asked questions

What counts as AI ROI?

Financial ROI compares attributable realised financial benefit with the full incremental cost over a stated period. Time released, improved quality and shorter queues are useful operational measures, but they should be reported separately unless a defensible mechanism turns them into financial benefit.

Should time saved count as money?

Report saved time as capacity first. Count a financial benefit when there is evidence of a relevant change, such as less paid overtime, a justified hiring deferral or additional contribution. Multiplying hours by a salary rate alone does not show that cash has been saved.

How long should we measure before deciding?

Measure long enough to represent the process, including its exceptions and busy periods. A working week can be a starting sample, not a universal decision rule. Extend it where volumes vary, and distinguish pilot estimates from benefits observed after rollout.

What costs do firms forget?

Common omissions include data preparation, testing, staff training, human checking, exception handling, monitoring and ongoing maintenance. Include the work required to keep sources and permissions current. Avoid counting review effort twice when it is already included in the measured post-AI handling time.

Can the 40-hour example prove a payback date?

No. It establishes a capacity difference from synthetic inputs. A payback date also needs evidenced financial benefits, full costs and their timing. Without those, the honest result is an operational estimate with an unresolved business case.

What is the next practical step?

Choose one process, name its owner and collect a baseline. Test the whole workflow against the same quality standard, including difficult cases. Then ask finance to validate the decision that would convert capacity into benefit before committing to a larger investment.

For help defining that scope, book a discovery call. A paid discovery can establish the process, evidence and proposed implementation; timelines and commercial terms belong in the subsequent proposal.