How to Calculate AI Automation ROI Before You Spend a Dollar

The four numbers you need

Pick one workflow — not a department, not a strategy, one workflow with a start and an end. Invoice intake. Support ticket triage. Contract review. Then collect:

1. 1Volume: how many times that workflow runs per month.
2. 2Handling time: how many minutes a person spends on one run, start to finish, including the waiting and the re-checking.
3. 3Loaded hourly cost: the salary of whoever does it, plus payroll tax and benefits. A rough multiplier of 1.25–1.4x base salary is the usual planning figure — use your actual number if finance has one.
4. 4Automation rate: the share of runs the system can finish without a human. This is the number people get wrong, so treat it conservatively below.

Be pessimistic about the automation rate

This is where business cases quietly break. A pilot handles 95% of the cases you tested it on, so 95% goes in the spreadsheet. In production it sees the messy tail — the scanned fax, the supplier who changed their invoice layout, the customer asking two questions at once — and the real rate lands lower.

Worse, partial automation can cost more than none. If a human has to review all of the output anyway, you have added a review step to a task they could have just done. The system has to be trusted enough to let most cases through untouched, or the saving is imaginary.

Two things make the estimate honest. First, calculate at a rate meaningfully below what your pilot showed and see if the case still holds. Second, insist that the pilot runs on real historical data — a sample of the actual last few hundred cases, including the ugly ones — not a curated demo set.

The costs almost everyone forgets

Inference is usually the smallest line in the budget, which surprises people. The costs that actually accumulate are these:

The saving has to be a real saving

There is a difference between freeing eight hours a week and saving eight hours a week. If those hours go back into work that generates revenue or removes a hire you were about to make, that is money. If they get absorbed, it is a nicer working day — genuinely worth something, but it is not the number you should be putting in front of an owner.

Be explicit about which one you are buying. Both are legitimate reasons to do a project. Only one of them shows up in the accounts, and confusing them is how AI projects lose their sponsor at renewal time.

Workflows that tend to pay for themselves

• High volume, low variance — the same shape of task hundreds of times a month.
• Text in, structured data out — invoices, forms, applications, intake documents.
• Answers that already exist in writing but are hard to find, which is the classic case for a retrieval-based assistant over your own documents.
• Triage and routing, where the decision is quick but has to happen constantly.
• First-draft generation, where a human edits rather than writes from nothing.

Workflows that usually do not

• Low volume, high stakes — if it runs eleven times a year and a mistake is expensive, the arithmetic never gets there.
• Anything requiring a judgement call somebody is legally accountable for.
• Processes that change every quarter, because you will rebuild faster than you recoup.
• Work that is only painful because an upstream system is broken. Fix the upstream system; it is cheaper.

What a defensible pilot looks like

Before committing to a production build, a pilot should answer one question: on our real data, what share of cases does this finish correctly without a human? Everything else is secondary.

That means agreeing what 'correctly' means before you start, scoring against a held-back set of real historical cases, and reporting the failures as prominently as the successes. A pilot that produces a demo instead of a score has not told you anything you can spend money on.