How to calculate AI automation ROI

Most automation business cases fail in one of two directions. Either nobody builds one and the project is justified on vibes, or someone builds one with a heroic time-saved estimate and no running cost, producing a number no finance team believes.

The method below is deliberately conservative. If an automation clears it, build it. If it doesn't, that's useful — cheaper to find out on a spreadsheet than after a six-week build.

Step 1: Fully-loaded hourly cost

Getting this wrong invalidates everything downstream. Salary divided by 2,080 hours is not what an hour costs you.

Add employer-side benefits. According to the Bureau of Labor Statistics' Employer Costs for Employee Compensation series, benefits made up 31.4% of total compensation costs for civilian workers in the most recent published quarter. Your own figure will differ, but salary alone is roughly two-thirds of compensation cost, not all of it.

Then decide whether to add overhead: software, equipment, workspace, management time. Including it is more accurate and harder to defend in a meeting. Using compensation cost only, and noting the exclusion, keeps the figure conservative — which is where you want it.

Finally, use the cost of the person who actually does the task. Automating a junior coordinator's work does not save an executive's hourly rate.

Step 2: Hours recovered, honestly

Measure the current process rather than estimating it. Have the person doing it log actual time for two weeks, including the exception handling that never appears in the process description. Manager estimates are consistently low, because managers remember the happy path.

Then subtract the time the automated process still requires. Almost nothing goes to zero — someone reviews exceptions, checks output, or handles what the automation punts on. If a model does classification or extraction, budget for a review step. A workflow with no human checkpoint is one whose error rate you don't know.

Then apply the hardest test: do the recovered hours convert into anything?

• Hours that avoid or delay a hire are worth full value.
• Hours that let someone do revenue-generating work instead are worth full value only if that work exists and is currently constrained by their time.
• Hours scattered in ten-minute fragments across several people are worth substantially less — fragmented time mostly refills with other work.
• Hours recovered from someone not at capacity are worth close to nothing financially, though they may still be worth recovering for retention or accuracy.

Discount fragmented savings deliberately. Halving them is a defensible convention.

Step 3: Error cost reduction

This is where most of the real money is, and the line most business cases omit because it's harder to source internally.

Find the failure rate of the current manual process. Not the perceived rate — count. Pull three months of relevant records and count how many needed correction. Then price a single failure end to end: time to detect, time to fix, downstream cost (a re-issued invoice, a shipping credit, a service call, a lost customer), and anyone pulled in to help.

Annual error cost equals volume times failure rate times cost per failure. The automation's contribution is whatever fraction it prevents — not all of them. Automations introduce their own failure modes, particularly where a model makes a judgment. Assume you remove some errors and add different ones.

Step 4: Revenue recovered from faster response

Only include this where you can observe a real relationship in your own data, not because faster is intuitively better.

• Inbound lead response. Segment your historical leads by time-to-first-contact. If there's a conversion difference, it's a real input. Use your data, not a statistic from a blog post.
• Quote turnaround. If same-day quotes close at a higher rate than week-old quotes, and you can see it in your CRM, count it.
• Invoice timing. Same-day invoices get paid earlier. That's a working capital effect, not new revenue — value it at your cost of capital.

If you can't see the relationship in your own numbers, set this line to zero. An unsupported revenue assumption is what makes a business case fall apart in review.

Step 5: Costs

Build cost. Internal time at fully-loaded cost, or the agency invoice. Include discovery and testing — usually half the effort — plus the time staff spend explaining the process, which is real and usually invisible in the estimate.

Running cost, annually. Platform subscription or per-execution fees. Model API usage at your expected volume — the line people forget, and it scales with success. Maintenance: several hours a month, more if the automation touches APIs that change often. Monitoring, plus whatever it costs when the automation fails silently for a week.

A worked example

A distributor receives purchase orders as PDF email attachments. A coordinator retypes each one into the ERP.

Note what the example shows: error reduction is worth more than time savings, and the honest answer is marginal. A twelve-month payback sits right at the boundary — worth doing if PO volume is growing, worth deferring if the ERP is being replaced next year.

That's the point of the arithmetic. The intuitive case — "we're retyping 400 orders a month, obviously automate it" — looked much stronger than the numbers.

Payback period and what to do with it

• Under 3 months. Build now. Even if estimates are optimistic by half, it clears.
• 3 to 12 months. Build if the process is stable and volume is steady or growing. Check no system in the chain is scheduled for replacement.
• 12 to 24 months. Probably not yet. Software changes fast enough that a two-year payback often never arrives.
• Over 24 months. No. Something in the model is wrong, or the problem isn't expensive.

What makes an automation not worth building

Low volume. A task performed a few times a month rarely justifies a build, a subscription and a maintenance relationship — however irritating it is.

High exception rates. If 40% of cases need human judgment, the automation handles 60% and you still staff the exceptions. You've added a system without removing a role.

Unstable processes. If it changed twice this year, it'll change again during the build.

Undocumented processes. If two people describe the workflow differently, you don't have a process — you have two. Simplify before you automate.

Systems scheduled for replacement. Integrations against software you're migrating off are pure waste.

Savings that can't convert. If recovered hours won't avoid a hire or produce revenue, be honest that you're buying accuracy and morale, not ROI. Both are legitimate reasons to build — just don't attach a fake financial number to them.

If an agency runs this calculation and every process clears comfortably, be suspicious. That's worth testing during selection.

Frequently asked questions

What is a good ROI for workflow automation?

Payback period is more useful than an ROI percentage, because automations have ongoing costs a simple ratio hides. Under three months, build it — the estimate can be wrong by half and still clear. Three to twelve months is a build if the process is stable and volume is steady or growing. Twelve to twenty-four months usually means wait, because processes and the software underneath them change fast enough that a long payback often never arrives. Beyond twenty-four months, either the model has an error or the problem isn't expensive enough to solve.

How do I calculate the fully-loaded cost of an employee hour?

Start with salary, then add employer-side benefit costs — Bureau of Labor Statistics data shows benefits making up roughly a third of total compensation for civilian workers, so salary alone understates the real figure meaningfully. Divide by actual working hours rather than 2,080 if you want precision about holidays and leave. Whether to add overhead — software, equipment, workspace, management time — is a judgment call. Excluding it produces a more conservative and more defensible number, which is generally what you want in a business case.

What ongoing costs should I include in an automation ROI model?

Four, all annual. Platform subscription or per-execution fees, which scale with volume. Model API usage if the workflow calls an AI model — the most frequently omitted line, and it grows as the automation succeeds. Maintenance time, since connectors break when the software underneath them changes; several hours a month is a reasonable starting assumption. And monitoring, including the cost of an automation failing quietly for days before anyone notices. Excluding running cost is what turns a marginal project into an apparently obvious one.

When is an automation not worth building?

When volume is low, when the exception rate is high enough that you still staff for the exceptions, when the process changed recently and will change again, when two people describe the workflow differently — meaning it isn't one process yet — or when a system in the chain is scheduled for replacement. Also when the recovered hours genuinely can't convert into avoided cost or new revenue. That last case can still justify a build for accuracy or morale reasons, but it should be argued on those terms rather than dressed up with a financial number that won't survive scrutiny.