“Should I automate this?” often gets answered by gut feel. A better decision starts with a measured baseline, an explicit estimate and a test that can prove the estimate wrong.

Step 1: Measure the current process

Take one specific, repeating task. Not “admin”, but “chasing overdue invoices” or “writing quotes”. Then work out its real cost, which is more than the minutes on the clock.

Time. How long does one go take, and how often? Measure several real examples rather than relying on memory.

Your hourly cost. Not your take-home. Use the labour cost relevant to the person doing the task, and record how you arrived at it.

The hidden costs. This is where manual tasks quietly bleed you, and where most ROI sums go wrong by ignoring it:

  • Mistakes. A mispriced quote, a missed reminder, a double booking. What does one error cost when it happens, and how often does it?
  • Delay. Include a cost only where your own records show that delay changed an outcome. Otherwise leave it at zero.
  • The tax on your attention. The task you keep half-remembering to do drains focus even when you are not doing it.

Mark every estimate as an estimate. Unsupported precision is not evidence.

Step 2: Model the realistic change

Now the other side, and be just as honest here or the sum lies to you.

Time saved. Automation rarely takes a task to zero. Measure the automated run, review and correction together, then compare that total with the baseline.

Errors and delays changed. Add a value only after the trial shows a real change and you can explain the calculation. Until then, use zero.

Then subtract the costs of automating. Two of them, and people forget both:

  • Setup time. Record the real setup, testing and training time. Treat it as a one-off cost.
  • The running cost. The tool’s monthly fee, plus any occasional upkeep when something changes.

Step 3: Calculate net benefit and payback

Put the evidence together into a projected monthly net benefit and a payback estimate.

Projected monthly net benefit = (measured time change x hourly cost) + (evidenced outcome change) − (monthly tool cost)

Payback time = setup cost (your setup hours x hourly cost, plus any one-off fee) ÷ monthly saving

ROI over the review period = (total net benefit − total investment) ÷ total investment x 100

The second number is an estimate, not a promise. Usage, maintenance and tool costs change, so revisit it after the trial and at a fixed review date.

Step 4: Stress-test the decision

Run the calculation three times before you commit:

  • Conservative: lower time saving, more review and the highest plausible running cost.
  • Expected: the result your small test actually produced.
  • Optimistic: the best case you can explain without removing human review or pretending exceptions disappear.

Set the maximum setup cost, acceptable running cost and review date before the trial. Include data risk, adoption and failure handling alongside the financial estimate. Continue only when the measured result clears the threshold you set in advance, preferably in the conservative case too.

A worksheet you can audit later

Keep these inputs beside the decision, with the source and date for each one:

Input What to record
Current volume Runs per week or month
Current labour Minutes per run and loaded hourly cost
Current failures Rework, delay or error cost you can evidence
Future labour Automated run, review and correction time together
One-off investment Discovery, build, integration, testing and training
Ongoing investment Software, hosting, monitoring and maintenance
Review rule Minimum return, maximum payback and decision date

If an input has no evidence, put zero in the financial case and keep it as a note to measure. That makes the model more conservative and far easier to defend.

A hypothetical worked example

Suppose a recurring task takes 45 minutes, happens eight times a month and the responsible person’s time is valued at £30 an hour. The current labour cost is £180 a month. If a proposed workflow still needs ten minutes of review each time, the realistic saving is 35 minutes per run, not the full 45.

Now add the actual tool cost and the setup time. Those are inputs, not promises. Replace every number above with your own evidence before you decide.

How this guide was produced

AGMM uses this structure to separate a promising automation idea from a business case that can survive scrutiny. The equations are standard financial relationships; the discipline is in recording every input, counting the work that remains and revisiting the model with the measured result.

Where to take this

Pick one repeating task and run it through these four steps. The result is a testable estimate, not a guarantee to act.

If you would like to do this during the live session, bring your own task and baseline to The AI Bottleneck Blueprint live webinar. See the event page for current booking details.

To make the maths quick, use our automation time-savings calculator. Put in your own baseline, rate and costs, then treat the output as an estimate to verify. If the case survives the test and the process needs a purpose-built system, see how AGMM approaches business process automation.

Questions people ask before they start

How do you calculate ROI for process automation?

Compare the measured value of time and evidenced outcome changes with setup, software, maintenance and remaining human-review costs. Divide net benefit by total investment for ROI, and calculate payback separately so you know how long the initial cost takes to recover.

What costs should an automation business case include?

Include discovery, setup, integration, testing, training, software, maintenance, monitoring, human review and exception handling. Include error or delay savings only when your records show a real cost and the test shows it changed.

What is a good ROI for automation?

There is no universal percentage. Set the minimum return, maximum payback time, risk tolerance and review date before the test. A lower financial return may still be sensible for a safety-critical process, while a high projected return is not enough if the process or data is unstable.