What AI ROI Needs Before You Can Calculate It

Search this and you get two things. A formula, which is benefits minus costs divided by costs, and a table of benchmark returns by use case. The formula is correct and the table is somebody's marketing, and neither of them is the reason you cannot answer the question.

The arithmetic was never the obstacle. The obstacle is that the numerator does not exist yet, and in most of the projects that ask this question it was never going to, because the thing that makes a return measurable has to happen before the system is built and the question is being asked afterwards.

So this is a page about the measurement rather than the number. What to record, what unit to record it in, where a saving gets counted twice, and what to do in the common case where the model does its job and the return is still zero.

A return you did not instrument is not a return

The benchmark tables are unusable for a reason that has nothing to do with whether their figures are honest. A return is a ratio, and the denominator is your old process. Two organisations running what they describe as the same workflow can differ by a wide multiple in how long it takes, how often it has to be redone, and how many people touch it. A published ratio built on someone else's denominator tells you nothing about yours.

Which means the useful work happens before anything ships. For the one process you are about to change, record four things while it is still being done the old way:

Time per instance. Not the time the process takes in principle. The time it takes, measured on real instances, including the ones that go wrong.

Volume. How many instances per week, over a long enough stretch to catch the quiet weeks and the busy ones.

Rework rate. How often an instance comes back and has to be done again. This is the line that most often carries the real cost, and it is almost never recorded.

Who touches it. The number of distinct people an instance passes through, because each handoff is a wait and the waits are usually larger than the work.

If the system has already shipped and none of that was captured, you have two honest options and one dishonest one. You can sample the old process where it still runs somewhere, on another team or another document type, and use that as a retroactive baseline. You can run a split, where one team keeps the old process and one uses the new one, which is the most rigorous thing available and is often politically impossible. The dishonest option is to ask the people using the system how much time it saves them and treat the answer as data. Self-reported time savings are reliably generous, and the whole point of a baseline is that it was recorded by somebody who did not yet know what answer would be convenient.

Per-instance time is the only honest unit at small scale

The temptation is to express the return in money straight away, because money is what the approval needs. Resist it for one more step.

Converting to money early forces you to pick a rate, and the rate you pick decides the answer. Worse, it invites the two conversions that make a return unfalsifiable: revenue attributed to a system that touched one step of a long sale, and headcount that was never going to be hired anyway. Both are defensible in a large organisation with a finance function that can arbitrate them. Neither is defensible at the scale most of these projects actually run at.

Time per instance, multiplied by volume, is reproducible. Somebody who disagrees with your conclusion can check it, and that property is worth more than a larger number. Convert to money once, at the end, using a loaded hourly rate you are prepared to defend out loud, and show the unconverted figure next to it.

The two places a saving gets counted twice

The avoided hire. A saving in task time and an avoided headcount are frequently the same saving, written down in two places. If the hours freed up are the justification, then the hire those hours would have required is not a separate benefit. Pick one. The usual honest version is the hours, because the hire was a projection and the hours are a measurement.

The review step. This is the common one and it is easy to miss, because the review feels like diligence rather than cost. If a person still reads every output before it is used, the cost of an instance is the model's run plus that reading, and the reading is often most of what the old process was. To put it as arithmetic rather than as a finding: if an instance took forty minutes of writing and now takes five minutes of generation plus thirty minutes of checking, the saving is five minutes and not thirty-five. Measure the whole instance end to end, from the trigger to the point where the work is actually used, or the saving you report will be the saving on one step of it.

There is a third, less common but worth naming: a saving in a queue that was not the bottleneck. Making a fast step faster changes nothing downstream. If the constraint is the approval that happens two steps later, the time you freed is sitting in the same queue it was in before.

The cost side is the half you can get exactly

This is the pleasant part of the exercise. Your costs are knowable to a close approximation before you commit, which is unusual in any kind of forecast.

Take one realistic instance, write out what goes into the request and what you expect back, and put it through our LLM cost calculator at the volume from your baseline. If any part of the design runs on infrastructure you own, the AWS cost calculator gives you that line in the same session. Then add the one nobody budgets: somebody noticing when the answers get worse, and fixing it. We have a longer piece on what decides AI development cost, and the recurring half of it is the half that decides whether a project is alive in its second year.

Put your own cost figure against your own time saving and you have a ratio that belongs to you. It will not match any published benchmark, and that is the point.

When the model works and the return is still zero

This is the most common disappointing outcome, and it is routinely misdiagnosed as a model problem.

The pattern looks like this. Accuracy is acceptable in testing. The system goes live. Nothing measurable changes. The instinct is to go back to the prompt, and the prompt is usually not where the problem is.

What has typically happened is that the workflow around the model is unchanged. The output lands in a place nobody looks at as part of their actual job. The handoff that used to follow the manual step still follows it. The person who used to do the task now reads the output with the same care they used to write it, because nobody told them they could stop, and nobody gave them a rule for when to trust it. The step got faster and the process did not.

The diagnostic is the same measurement as before: end-to-end cycle time per instance, not the latency of the model's step. If the model's step is fast and the cycle time has not moved, the model is not the subject of the investigation. What is missing is usually a stated rule for when a human has to look, which is a decision somebody has to own rather than a parameter to tune, and it depends on having an evaluation set good enough to say how often the system is wrong and in which direction.

What to write down before you ship

Four lines, on one page, agreed by the person who will judge the result rather than by the people building it. The baseline, in time per instance and volume. The metric you will re-measure, which should be the same one. The date you will re-measure it on. And what number would count as a failure, decided in advance, because a pilot that is declared neither successful nor failed is a worse outcome than one that fails, and most of them end that way.

If you are not sure the organisation is ready to hold those four lines, our free AI readiness assessment asks six questions that each predict a deployment not surviving its first year, and the answer it gives you is more useful before the build than after.

A return measured this way is smaller than the one in the benchmark tables, and it is yours, and it survives being questioned. For more on building these systems, see the rest of our writing.