How to Measure the ROI of an Automation Project (Before and After)

Every automation project gets pitched with a promise of time saved. Few get measured properly afterward. That's a problem in both directions: good projects don't get credit, and weak ones never get questioned. If you want to know whether automation is worth doing, and whether it actually paid off, you need a simple, repeatable way to measure automation ROI.

This guide gives you that method. It works for any kind of automation, from a simple Zapier flow to a custom AI document-processing system. At the end there's a worked example. Every number in it is invented for illustration, so treat it as a template rather than a benchmark.

The basic formula

ROI itself is simple:

ROI = (total benefits − total costs) ÷ total costs, measured over a defined period, usually 12 or 24 months.

Alongside it, track the payback period: how many months until cumulative net benefits cover the upfront cost. For most business owners, payback is the more intuitive number.

The hard part isn't the formula. It's getting honest inputs. That's what the rest of this guide is about.

Step 1: Draw a boundary around the process

Define exactly what you're measuring. "Order processing" is too vague. "From the moment a purchase order email arrives to the moment a sales order exists in NetSuite with correct lines and prices" is measurable. Be clear about the start, the end and who's involved. If you can't describe the boundary, you can't measure the change.

Step 2: Measure the baseline before you build

This is the step most teams skip, and it's the one you can't go back and do later. Before anything changes, collect:

• Volume: how many items per day, week or month (orders, invoices, tickets, leads). Note seasonal swings.
• Handling time per item: time it, don't guess. Have the people doing the work log a sample of a few dozen items, including awkward ones.
• Error rate: how often something goes wrong, and how you know (credit notes, customer complaints, corrections in the system).
• Cost per error: time to fix, plus any direct cost such as reshipping, discounts or write-offs.
• Delay: how long items wait before being handled, if speed matters commercially.
• Labor cost: a fully loaded hourly cost for the people involved (salary plus benefits and overhead). Your finance team can give you a reasonable figure.

Two weeks of careful sampling is usually enough. Write the numbers down and get the process owner to agree they're fair.

Step 3: Count all the costs

Automation costs are more than the build. Include:

• Upfront: discovery, build, testing, data cleanup, training, and your own team's time during the project.
• Running: software subscriptions, hosting, and model usage if AI is involved (usually billed per token, so it scales with volume).
• Maintenance: fixes, updates when connected systems change, prompt tuning, monitoring.
• Human review: time spent checking exceptions or uncertain results. This is a real, ongoing cost and it's often left out.

Step 4: Estimate the benefits, conservatively

Benefits fall into a few categories. Be realistic about each.

Time saved

The new handling time per item, including review of exceptions, compared with the baseline. Don't assume 100% automation. Estimate what share of items will go straight through and what share will need a person.

Errors avoided

The reduction in error rate multiplied by the cost per error. Be careful here: automation can introduce new kinds of errors, so plan to measure the new rate rather than assume it's zero.

Speed

Faster quotes, faster replies to leads, faster invoicing. These can matter a lot commercially but are harder to value. If you include them, state the assumption clearly, such as "faster invoicing brings cash in a week earlier," and keep them separate from hard savings.

Capacity

Handling more volume without hiring. This is often the most valuable benefit for a growing company, but only count it if growth is genuinely expected.

The trap of "hours saved"

Hours saved are only worth money if they turn into something: less overtime, fewer temporary staff, a hire you didn't need to make, or time that goes to work that brings in revenue. If the saved hours just dissolve into the day, the financial ROI is close to zero, even though people are less stressed. Be honest about which case applies. It's fine to report "this freed 80 hours a month, which we used for X." It's not fine to multiply 80 hours by a wage and call it profit if nothing changed.

Step 5: Measure again after launch

After the system has settled, usually after a month or two once early tuning is done, repeat the baseline measurements in exactly the same way: same boundary, same sampling method, same definitions of an error. Compare like with like. Good reporting automation helps here, because the system can log volumes, straight-through rates and exceptions automatically instead of relying on manual timing.

Also check for costs you didn't anticipate, such as more review time than expected, higher model usage on long documents, or extra support from IT.

A hypothetical worked example

To make this concrete, here's an example with entirely invented numbers. It's a template for your own calculation, not an indication of typical results or of what any project costs.

A fictional wholesale distributor receives purchase orders as PDF attachments by email. Staff read each one and key the lines into the ERP. They consider AI document processing to extract the order lines and create draft sales orders automatically, with a person checking anything uncertain.

Baseline (measured over two weeks)

• Volume: 60 POs per working day, about 1,260 per month (21 working days).
• Handling time: 6 minutes per PO on average, about 126 hours per month.
• Errors: 2% of orders have a keying mistake, about 25 per month.
• Cost per error: estimated at $40 (time to fix, credit notes, occasional reshipping).
• Loaded labor cost: $35 per hour.

After (measured after two months live)

• 80% of POs go straight through with a quick 1-minute check: about 16.8 hours per month.
• 20% are flagged as exceptions and take the full 6 minutes: about 25.2 hours per month.
• Total handling time: about 42 hours per month, down from 126.
• Error rate falls to 0.5%, about 6 errors per month.

Item (hypothetical)	Before	After	Monthly difference
Handling hours	126	42	84 hours, worth $2,940
Errors per month	about 25	about 6	about 19 fewer, worth $756
Running costs (models, hosting)	$0	$300	−$300
Maintenance allowance	$0	$400	−$400
Net monthly benefit			$2,996

Suppose the upfront cost, including the team's own time, was $30,000 in this example. Then:

• Payback period: $30,000 ÷ $2,996 ≈ 10 months.
• 12-month ROI: (12 × $2,996 − $30,000) ÷ $30,000 ≈ 20%.
• 24-month ROI: (24 × $2,996 − $30,000) ÷ $30,000 ≈ 140%.

Now apply the honesty check. The 84 saved hours are only worth $2,940 if they're used. In this example, say the distributor was planning to hire another order-entry clerk for its busy season and no longer needs to, so the saving is real. If instead the hours simply spread across the team with no change, the hard ROI would rest almost entirely on fewer errors, and payback would take far longer. Same project, very different answer, which is exactly why this check matters.

Sensitivity: test your assumptions

Before committing, rerun the numbers with less optimistic inputs. What if only 60% of items go straight through? What if volume drops by a quarter? What if model costs double? If the project only makes sense under the best-case assumptions, it's a risky project. If it still pays back under cautious ones, you can proceed with confidence. A short prototype on real data is the cheapest way to replace guesses with measurements for the riskiest assumptions.

Projects that aren't mainly about time

Not every automation pays off through saved hours. Some of the most valuable ones change speed or quality, and need different measures:

• Lead response automation: measure time to first response and conversion rate by response time, before and after. Revenue impact is real but noisy, so look at it over a longer window.
• Support automation: measure resolution time, reopen rate and customer satisfaction alongside handling time. A faster answer that's wrong is not a saving.
• Finance automation: measure days to close the month, days sales outstanding, and the number of manual adjustments.
• Compliance or audit work: measure the issues found and the time to produce evidence when asked. Here the benefit is often reduced risk, which is hard to price, so describe it rather than forcing a number.

For these projects, report a small set of operational measures next to the financial ROI, and explain how you connected them. Decision makers generally trust a clearly reasoned estimate with stated assumptions far more than a single precise-looking figure.

Who should own the numbers

Ideally, the person who owns the process (not the person who built the automation) signs off on both the baseline and the after measurement. It keeps everyone honest, and it means the result belongs to the business rather than to the project.

Common mistakes

• No baseline. Without "before" numbers, every "after" claim is a guess.
• Ignoring exceptions. The cases automation can't handle often take longer than average, not shorter.
• Leaving out running costs. Especially model usage and maintenance.
• Counting soft benefits as cash. Report them, but separately.
• Measuring too early. The first weeks include tuning and learning. Measure once things have settled.

Putting it into practice

Pick one process, measure it for two weeks, and run the numbers before talking to any vendor. You'll have a much clearer brief, and you'll know what success looks like. For teams in finance, the same method works well on invoice processing, reconciliations and month-end reporting; we cover more of those on our finance and accounting page. For an overview of the kinds of projects this applies to, see our AI business automation services.

We build the baseline and success measures into the start of every project. If you're curious how that works in practice, our process page walks through it.