How to calculate AI ROI without fooling yourself

Most AI return-on-investment figures fail for one of two reasons. Either the benefit is a percentage pulled from a vendor slide, or the cost stops at the build. Neither survives contact with a finance team, and neither should. Here is the method we use.

Start with a baseline, not a benefit

You cannot claim to have saved thirty per cent of anything unless you know what one hundred per cent looks like today. Before estimating benefit, measure the current process: volumes, cycle time, handling time, error and rework rates, labour cost per unit, and where relevant the customer or revenue impact of delay. If the organisation does not have these numbers, gathering them is the first task, and it often reveals more than the AI analysis does.

Express every benefit as a mechanism

A benefit is a mechanism, not a percentage. 'Reduce average handling time from eleven minutes to seven for the four routine enquiry categories, which make up sixty per cent of volume' is a mechanism. It can be tested in a prototype, tracked after launch and challenged by the people who do the work. 'Improve productivity by thirty per cent' is a slogan.

Model each mechanism with three scenarios: conservative, expected and optimistic. The conservative case should be one you would be comfortable defending if everything that could go wrong went wrong. Present all three. Decision-makers trust ranges more than points.

Cost the whole lifecycle

Build cost is usually the smallest line over three years. Include:

• Model and platform usage at production volume, including retries, context growth and evaluation runs
• Data preparation and ongoing pipeline maintenance
• Integration with source systems and identity
• Evaluation, monitoring and the people who respond to alerts
• Governance, privacy and security review
• Change, training and support during adoption
• Periodic re-testing as models and prices change

Inference cost deserves particular care. It scales with usage, which is exactly what you are hoping will grow. A prototype that costs a few dollars a day can cost a great deal more at enterprise volume, and the model that gives the best demo is rarely the cheapest that meets the quality bar.

Run the sensitivity

Change each major assumption by a plausible amount and watch what happens to the return. If the case only works when adoption reaches ninety per cent in month two, you do not have a business case; you have a hope. Sensitivity analysis tells you which assumptions to test in a prototype before committing.

Decide how you will measure after launch

The business case should define the metrics, the data source and the reporting cadence for post-launch measurement. If you cannot describe how you would know it worked, you are not ready to fund it. This also keeps everyone honest later: the same numbers used to justify the investment are the ones reported back.

A note on soft benefits

Employee experience, decision quality and risk reduction are real but harder to quantify. Include them, label them clearly as unquantified, and do not let them carry the case. A business case that stands on hard mechanisms and is improved by soft benefits is credible. One that depends on soft benefits is not.

If you cannot describe how you would know it worked, you are not ready to fund it.