How to calculate automation ROI without fantasy math

Automation business cases fail for the same reason weight-loss plans fail. The number on the front page is aspirational, the assumptions behind it are unexamined, and nobody in the room wants to be the person who slows down the enthusiasm. Then reality shows up in quarter two and the finance team gets the blame for a shortfall that was baked in on day one.

The pattern is predictable. Someone counts the hours a task takes today, multiplies by the hourly rate of the person doing it, then presents an annualised saving that assumes perfect automation, zero adoption friction, no ongoing maintenance, and no cannibalisation of the work the freed-up person was already doing. The saving is real in a spreadsheet and imaginary in a P&L.

What follows is the framework we walk clients through when the room is small and the honesty is high. It is deliberately conservative because conservative business cases survive the board meeting.

Most business cases begin by multiplying an hourly wage by the hours saved. That is the wrong first number, because it hides whether the task happens often enough to matter.

Instead, start with frequency. How many times per week does this workflow run today? If the answer is fewer than five, the automation almost never pays back inside a year, no matter how expensive the labour looks on paper. Rare work is best solved with a checklist, not a system, because the fixed cost of building, maintaining, and monitoring the system exceeds the variable cost of doing it by hand.

Frequency above twenty runs per week is where automation starts to compound. That is because the second-order savings, faster cycle times, fewer errors, and better handoffs, only show up when the workflow runs constantly. A slow workflow that runs once a day just moves cost around. A fast workflow that runs a hundred times a day changes the shape of the business.

The other reason frequency matters is data. Every run of an automated workflow produces evaluation data, and that data is what lets you tune, improve, and defend the system over time. Low-frequency workflows do not generate enough data to know whether they are getting better or worse.

Ownership cost. Someone has to run the system after go-live. Budget five to ten percent of the build cost per quarter for care and feeding: monitoring alerts, threshold tweaks, small integration changes when an upstream API adds a field. If nobody owns it, it dies quietly. The most expensive AI systems are the ones the champion left the company without documenting.

Model drift cost. Foundation models change. Providers deprecate endpoints, silently shift response formats, and update their safety layers in ways that break edge cases you tested six months ago. Expect to spend one engineer-week per quarter recalibrating prompts, evals, and thresholds. This is normal and cheap if you plan for it, and expensive if you do not.

Adoption cost. The operators who used to do the work manually need training, a runbook, and a channel to report failures. Skipping this is why so many pilots never reach production even when the technology is fine. Budget one week of change management per shipped workflow, and give the operators the language they need to explain what changed to their peers.

None of these costs are dramatic on their own. Add them up across three workflows and they will consume roughly twenty percent of the headline savings. A serious business case names them upfront so the payback number survives audit.

Annualised savings equal frequency per week, times fifty working weeks, times the fully loaded cost per run, minus the ownership, drift, and adoption costs above.

Fully loaded cost per run includes the hourly wage, but also the switching cost when an operator changes tools, the error rate on manual runs, and the delay cost when the workflow blocks other work downstream. In our experience, these hidden costs are usually two to three times the direct labour cost. If a proposal takes an operator ninety minutes at fifty dollars an hour, the direct cost is seventy-five dollars, but the fully loaded cost is closer to two hundred once you count the context switch, the review cycle, and the fact that the sales rep was waiting for it.

Divide the build cost by annualised savings to get months to payback. Under six months is excellent and rare. Six to twelve is worth doing and typical. Twelve to eighteen is defensible if the workflow is strategically important, for example an audit trail requirement that unlocks a new market segment. Beyond eighteen means you are automating the wrong workflow, or you are paying too much for the build.

Every one of these numbers should have a source attached. A payback graph without sourced assumptions is a wish list. A payback graph with sourced assumptions is a plan.

The first workflow costs more than it should, because you are also paying for the platform, the integrations, the observability, and the operating discipline your team will reuse forever. Amortising all of that against a single workflow makes the first payback look mediocre, which then makes leadership nervous about the second.

The second workflow rides that infrastructure. Payback times routinely drop by forty to sixty percent once the foundation is in place, because the marginal cost of adding a new agent to an existing platform is a fraction of the cost of standing one up from scratch.

This is why we push clients to scope the first build against a workflow that will be followed by a second and third from the same operations pod. It compounds the leverage of the platform investment and turns a mediocre first payback into a spectacular blended payback across the trio. If your finance team is only willing to look at the first workflow in isolation, you are being asked to make a losing bet on purpose.

The corollary is that automating one-off workflows for one-off teams is almost always a bad investment. Not because the workflow is not painful, but because the platform cost never gets amortised across a portfolio.

A services firm automated their proposal drafting workflow. Frequency was thirty-two per week, fully loaded cost per proposal was one hundred and eighty dollars, and the build cost was fifty-two thousand dollars. Payback landed at four point four months. The second workflow, contract redlines, ran on the same platform and paid back in seven weeks. The blended payback across the two workflows was under three months, which is the number that got the third workflow greenlit.

A logistics operator wanted to automate a monthly board pack. Frequency was one run per month. Even at two thousand four hundred dollars per run in fully loaded cost, the maths did not work: an annualised saving of twenty-eight thousand dollars against a build cost of forty-five thousand meant payback outside two years, before drift and adoption costs. We recommended a templated SOP in Notion instead, took a smaller invoice for the design, and pointed them at a customer-facing workflow that ran two hundred times a week. That workflow paid back in ten weeks.

That is what an honest partner sounds like. Not every workflow deserves an AI system, and the fastest way to lose credibility with a client is to build one that should not exist. If you want to see the numbers on your own workflow, our ROI calculator uses the same formula and takes about ten minutes.

What if the model gets better and cheaper? Great. Bake the current pricing into the case, and treat any future cost reduction as upside. Never rely on projected price drops to make a payback work.

What if the team we automate around leaves? Even better, because the system holds the process knowledge. But budget for a two-week reload if the process owner moves on, because the tacit knowledge of what a good output looks like still needs a human anchor.

What if a competitor releases a tool that does this off the shelf? Then you switch and you keep the workflow you designed, because the design is the real asset. This is why we insist that clients own the process artefacts even when a vendor owns the runtime.

How do we know it is working? A weekly system health report that a non-technical operator can read in five minutes. If it needs an engineer to interpret, adoption stalls.

When can we stop paying you? On day one, contractually. In practice, most clients keep us on a light retainer through year two because the marginal cost of change requests is lower than staffing them internally. Beyond that, an internal team makes more sense, and we help hire them.