How to Calculate the ROI of an AI Use Case Before Launch, Not After

Here's how a typical AI use case business case gets built: an employee spends two hours on a task, the tool does it in twenty minutes, the saved time is a hundred minutes, multiply by the number of tasks and by the hourly rate. The number that comes out looks impressive — and it is almost always wrong.

It isn't wrong because the arithmetic is off. It's wrong because of the unit of measurement. A saved hour is not a freed-up resource sitting on a shelf: it gets refilled with other work, part of it goes into checking and correcting the output, and sometimes it simply evaporates into higher throughput expectations nobody billed for. What belongs in a business case is whatever doesn't grow back — eliminated operations and eliminated failures.

Why a Saved Hour Isn't a Financial Benefit

This claim rests on two independent reasons, and you can verify both inside your own company with a week of observation — no vendor pilot required.

The hour goes back into the process. Freed-up time doesn't turn into a cost reduction on its own — it gets absorbed by tasks that used to sit in the backlog. That can genuinely be a good outcome: people get to items they never had time for. But it is not a line on the P&L, and no one should promise the board it will become one.

Part of the hour goes into verification. An output produced quickly still has to be read, checked against the source, and often rewritten. That work is new: it didn't exist before, because the person producing the output was also the one who checked it as they went. It's invisible in a vendor demo, and it shows up precisely in week two of actual use, once someone has to sign their name to the result.

I'll flag the limitation myself: the study was commissioned by an enterprise software vendor that sells its own embedded AI features and has an obvious interest in making "generic" tools look worse by comparison. The full methodology sits behind a lead-gen form, not in the open. I use the number as an order-of-magnitude discount factor, not as a benchmark to plug into a spreadsheet unquestioned.

This is self-reported time, not a stopwatch measurement, and causality is explicitly not established — the authors say so themselves. What matters for a business case is the shape of the distribution: there's a visible negative tail, and if you build your numbers around the vendor's average promise, that tail never makes it into the calculation.

The Three Numbers a Real Business Case Is Built On

Everything a genuinely honest business case needs can be pulled from the process itself in a day or two, without a pilot and without a vendor in the room.

The number of operations that disappear. Not "this will get faster" — "this step will no longer exist." An operation disappears when its output can be computed by a rule, populated automatically, or stops being required at all. Every eliminated operation buys you two things at once: time, and one less point where the process can fail.

The current failure rate. A failure isn't a typo — it's an event where the work didn't make it to the next stage: a document went out incomplete, a request never reached the person who should have acted on it, a payment went to the wrong account. You get this number by manually pulling the last twenty to fifty outputs and counting.

The cost of a single failure. This is the cost of the fix plus the probability of a downstream loss. The second part is uncomfortable, because it requires an estimate rather than a receipt — but it's usually the part that makes up most of the cost.

Look closely at that last row. Verification work is a new cost line that didn't exist in the process before the AI tool arrived, and it is almost never built into the initial calculation. It's exactly what turns a promised percentage into a disappointing month three.

What Companies That Already Measure This Are Finding

The caveat came from the authors themselves, and that's rare enough to call out: they ask readers to treat their own numbers "with a degree of skepticism" because the data isn't verified against company financials. The practical takeaway from this study isn't the percentage — it's that close to a third of companies aren't tracking returns at all, which means they also have no baseline for costing their next use case.

When the Right Call Is to Wait

The standard rule — "net present value is positive, so we launch" — breaks down in projects with high uncertainty. This has been worked out in the academic literature on IT investment, and the conclusion is counterintuitive.

The paper is over a quarter century old, and the underlying case — banking infrastructure from the late 1980s — is a limitation I'll name outright rather than gloss over. What does carry over exactly is the methodological frame: when the cost of a tool is falling fast and uncertainty is high, the right to wait has a measurable deferral value of its own. That's especially true for AI use cases, because compute pricing and model capability are moving faster than most integrations take to pay for themselves.

The Order the Calculation Follows

Node five holds the option most people never consider: solving the problem with rules instead of a model. If the breakdown shows the eliminated operations are deterministic and computable, you don't need a language model at all — I cover that choice separately. Run the calculation this way and it points to that conclusion more often than the person requesting the budget expects.

Four Questions to Ask Before Approving the Budget

Frequently Asked Questions