Operations
How to measure the ROI of AI automation, running costs included
The short version
To calculate the ROI of AI automation, measure the baseline before you build, then compare 12 months of benefit with the one-time cost plus 12 months of running costs. Count hard savings, freed capacity and new revenue as separate lines. Include model usage, platform fees, monitoring and human review time. Report payback in months next to the percentage, and always show the cash-only figure as well.
- Published
- Updated
- Reading time
- 10 minutes
- Written by
- The Method Crew
Key takeaways
First-year ROI = (B − R − I) ÷ (I + R), where B is 12 months of benefit, R is 12 months of running cost and I is the one-time cost. Payback in months = I ÷ (monthly benefit − monthly running cost).
Measure 4 numbers for 2 weeks before building: monthly volume, handling minutes per item, error rate and cycle time. Without them, any ROI claim afterward is a guess.
Freed hours are a saving only when they move to named work. Report them on their own line, separate from cash savings.
In our hypothetical invoice example, the build loses money on cash savings alone and pays back in about 8 months only if 93 freed hours a month go somewhere specific.
What is the formula for AI automation ROI?
AI automation ROI compares what an automation returns over a period with everything it costs over the same period. For a first-year figure, use First-year ROI = (B − R − I) ÷ (I + R), where B is 12 months of benefit, R is 12 months of running cost and I is the one-time cost.
Next to it, report payback in months: I ÷ (monthly benefit − monthly running cost). A COO can sanity-check "9 months" faster than "31%", and payback exposes a weak case that a high year-two percentage can hide.
| Term | What goes in it | Where the number comes from |
|---|---|---|
| B, benefit | Hard savings, the value of hours that moved to other work, and incremental gross profit | Baseline and after measurements, the general ledger |
| R, running cost | Model usage, platform plans, hosting, per-page or per-minute fees, monitoring or a care plan, change requests | Vendor invoices and usage dashboards |
| I, one-time cost | Build fee, internal staff time, training, data cleanup | The signed proposal plus timesheets |
Two rules keep the formula honest. Compute year two separately, because it carries no build cost and will always look better. And count human review time once: either subtract it from the hours freed, or list it as a running cost. We subtract it from hours freed, as in the example below.
How do you measure the baseline before you build?
Measure 4 numbers for 2 weeks before any build starts: volume per month, handling minutes per item, error or rework rate, and cycle time from arrival to done. Use system timestamps where they exist and a timed sample where they don't.
| Metric | How to measure it | Common mistake |
|---|---|---|
| Volume per month | Count from the system of record over 2 to 4 weeks, then scale | Using the busiest month of the year |
| Handling minutes per item | Time 30 to 50 real items end to end, including lookups and interruptions | Asking people to estimate instead of timing them |
| Error or rework rate | Count items reopened, corrected or sent back | Counting only the errors customers notice |
| Cycle time | Timestamp in to timestamp done | Confusing it with handling time |
| Loaded hourly cost | Base wage times a loading factor agreed with finance | Using the base wage alone |
For the loading factor, start from public data. The US Bureau of Labor Statistics Employer Costs for Employee Compensation release (opens in a new tab) for June 2026 puts wages and salaries at 70.0% of compensation costs for private industry workers, with benefits at 30.0%. Dividing a base wage by 0.70, or multiplying by about 1.43, gives total compensation per hour. Finance may add overhead for space, equipment and management. Agree the factor once and use it in every business case so projects can be compared.
The baseline is a gate in our AI readiness checklist for a reason. If you start building first, the "before" number gets reconstructed from memory after launch, and memory flatters whatever you just paid for.
Should hard savings, freed capacity and revenue be counted together?
No. Count them as 3 separate lines, because they differ in how certain they are. Hard savings show up in the ledger. Freed capacity becomes money only when the hours move to other work. Revenue effects need a comparison group before anyone should believe them.
| Line | Examples | Becomes cash when | How to prove it |
|---|---|---|---|
| Hard savings | Agency or temp hours stopped, overtime cut, software canceled, late fees avoided, early-payment discounts captured | Immediately | Ledger lines before and after |
| Freed capacity | Hours no longer spent keying, sorting, chasing or copying between systems | The hours move to named work, or a planned hire is not made | The backlog the hours went to, or the requisition that was closed |
| Revenue | Faster lead response, fewer missed calls, more follow-ups sent | Conversion changes against a comparison | A holdout group, or before and after with the same lead sources |
We put 3 ROI figures in front of a leadership team: cash savings only, cash plus redeployed hours, and both plus measured revenue. If a project only works on the third figure, say so in the first sentence of the business case and fund it as an experiment, with a smaller budget and an earlier stop date.
Which running costs should you include?
Every cost that recurs while the automation is live: model and API usage, platform subscriptions, hosting, per-unit vendor fees, monitoring or a care plan, change requests, and the human time spent reviewing outputs. Many ROI calculators stop at the build fee, which is why their numbers look so good.
| Cost | What drives it | How to handle it |
|---|---|---|
| Model usage (OpenAI and Anthropic APIs) | Items per month, tokens per item, price per token | Billed at cost, with a monthly cap and an alert |
| Automation platform (n8n, Make, Zapier) | Plan tier and executions or operations per month | Check the plan limit against peak volume, not average |
| Hosting and databases | A self-hosted n8n server, a vector database for a knowledge assistant | Usually small for a single workflow |
| Per-unit vendor fees | Per page for document processing, per minute for voice and telephony such as Twilio | Passed through at cost and modeled at peak volume |
| Monitoring and maintenance | Failed runs, vendor API changes, model updates, prompt tuning | A care plan from $1,500 a month, or named in-house hours |
| Change requests | New fields, new suppliers, process changes | $175 an hour with us, or internal developer time |
| Human review | Minutes per item checked, times items, times the loaded rate | Counted once, here or as fewer hours freed |
Rule-based steps cost close to nothing per run. Model calls cost money every time. So we use a model only for the steps that need language understanding, such as reading an unstructured invoice or classifying an inbound email, and keep routing, validation and arithmetic in plain workflow logic. If a rule-based automation does the whole job, we build that instead. Our guide to AI agents, automation and chatbots covers where that line sits.
Budget for model changes as well. Providers retire model versions, and each retirement means re-running your test set and adjusting prompts. We plan 4 to 8 hours a quarter for it on a typical single workflow.
Worked example: invoice intake at a hypothetical distributor
This example is hypothetical. The company, volumes, wages and vendor fees are invented to show the method; they are not results from a client project. The Method Crew prices in it are real: the build fee sits inside our published document processing band, and the care plan is our entry tier.
A 120-person distributor receives 1,800 supplier invoices a month. Two weeks of timing put handling at 6 minutes per invoice, or 180 hours a month. At month end an agency temp covers 30 of those hours at $42 an hour. Late payment fees average $350 a month. The accounts payable clerks earn $26 an hour, which is $37 an hour loaded at a factor of 1.43.
The build is an intelligent document processing pipeline, close to our invoice processing blueprint: it extracts fields, matches each invoice to its purchase order and posts it to the accounting system. A clerk checks every invoice for 1 minute before posting, which is human-in-the-loop review. 15% of invoices fall out as exceptions and take 6 minutes each.
| Monthly line | Amount | How it is calculated |
|---|---|---|
| Hours before | 180 | 1,800 invoices at 6 minutes |
| Hours after | 57 | 30 hours of review plus 27 hours of exceptions |
| Temp cover stopped (hard saving) | $1,260 | 30 hours at $42 |
| Late fees avoided (hard saving) | $250 | $350 down to $100 |
| Staff hours freed | 93 | 123 hours freed, minus the 30 temp hours |
| Value of freed hours, if redeployed | $3,441 | 93 hours at $37 |
| Document processing fees | $250 | Per-page vendor pricing |
| Model usage | $60 | Billed at cost |
| Automation platform | $100 | One paid plan |
| Care plan | $1,500 | Our entry tier |
| Total running cost | $1,910 | Sum of the 4 lines above |
The one-time cost is a $22,000 build, inside our $12,000 to $40,000 band for document processing, plus 60 hours of internal time at $45 loaded, or $2,700. I = $24,700.
| View | Net per month | Payback | First-year ROI | Year-two ROI |
|---|---|---|---|---|
| Cash savings only | −$400 | Never | −62% | −21% |
| Cash plus redeployed hours | $3,041 | About 8 months | 25% | 159% |
On cash alone this build loses $400 a month before it has paid back a cent. It pays off only if the 93 freed hours go somewhere specific: clearing a supplier reconciliation backlog, or absorbing growth without the next accounts payable hire. If nobody can name where those hours go, the honest advice is a smaller build. Without the care plan the cash-only view turns positive at $1,100 a month, but payback stretches to about 22 months and someone in-house has to fix every failed run.
The exception rate moves the result more than any other input, which is why we measure it on real invoices during a pilot before quoting the full build.
| Exception rate | Hours after | Staff hours freed | Net per month, with redeployed hours | Payback |
|---|---|---|---|---|
| 10% | 48 | 102 | $3,374 | 7.3 months |
| 15% | 57 | 93 | $3,041 | 8.1 months |
| 30% | 84 | 66 | $2,042 | 12.1 months |
Why does pilot ROI look better than production ROI?
Pilots run on tidy samples, with the builder fixing odd cases by hand and no running costs on the books. Production meets every unusual format, every supplier who changes their invoice template, and a monthly bill. Set the business case on production numbers, and expect the production exception rate to be higher than the pilot's.
The gap usually comes from 5 places:
- Sample selection. Pilot samples lean toward typical items, because those are the ones people think to export.
- Hidden labor. During a pilot, the builder handles edge cases personally, and those hours never reach the ROI sheet.
- Missing costs. Model usage at pilot volume is trivial, and nobody has priced monitoring yet.
- Review behavior. Reviewers check carefully in week 1 and differently by month 3. Measure review time in month 3.
- Drift. Vendors change APIs and document formats, and models get updated.
Large companies see the same gap. MIT's Project NANDA, in its 2025 report The GenAI Divide, said 95% of organizations in its research were seeing no business return (opens in a new tab) from generative AI. The sample was modest (52 interviews, 153 survey responses and a review of more than 300 public initiatives), and the reasons it gave included brittle workflows, weak contextual learning and misalignment with day-to-day operations. A baseline and a production measurement plan won't fix a bad choice of workflow. They will tell you within 3 months that you made one.
What should a monthly ROI report contain?
One page, in the same format every month: volume, straight-through rate, review hours, where freed hours went, hard savings, itemized running costs, net benefit, and the cumulative position against the one-time cost. If a number can't be pulled from a system, write down how it was estimated.
| Metric | Source | Why it is there |
|---|---|---|
| Items processed | Workflow run log | Volume drives both benefit and cost |
| Straight-through rate | Run log: items posted with no human edit | The input that moves ROI the most |
| Review and exception hours | Review tool timestamps or a timed sample | The cost pilots underestimate |
| Errors found after posting | Corrections in the system of record | Catches silent failures |
| Hard savings | Ledger lines against the baseline month | Cash |
| Freed hours and where they went | One line from the team manager | Proves redeployment |
| Running costs, itemized | Vendor invoices and usage dashboards | Shows creep in model and platform spend |
| Net monthly benefit | Calculated | The headline |
| Cumulative position against I | Calculated | Shows how far along payback is |
Our automation care plans and AI ops monitoring include a version of this report each month, alongside the LLMOps work of watching runs, failures and cost. If you run it yourself, our weekly ops report blueprint automates most of the data pull. Pair it with a fixed test set and LLM evaluation runs, so a drop in straight-through rate can be traced to a model change, a prompt change or a change in the inputs.
When is ROI the wrong way to judge an automation?
When the value is avoided risk, when the volume is too small to measure, or when no baseline exists. In those cases, say so and judge the project on a different test.
Risk and compliance work rarely shows a return in a normal month. Logging every AI-assisted decision for an audit trail costs money and saves nothing until the day a regulator or a client asks. Judge it by the cost of the failure it prevents.
Small volumes drown in measurement noise. Below roughly 20 hours a month of work, we would build something small and cheap, or nothing, and skip the ROI model entirely.
Response-time projects need a holdout. Answering leads in 2 minutes instead of 4 hours may matter a great deal, but pricing it means routing a share of leads, say 1 in 5, to the old process for 4 to 6 weeks and comparing. If you won't run the holdout, call it a service-level decision and stop there.
And if the work was never measured before the build, don't invent a "before" number afterward. Report the operating metrics honestly and measure the next process properly. Our AI automation engagements start with that measurement in the Map stage, and a pilot that misses the agreed bar stops there. For what the builds themselves cost, see our breakdown of AI consulting costs.