How to calculate automation ROI
You're weighing up whether to automate something, and everyone agrees it'll "save heaps of time." It probably will, but how much, and by when? Six months later there's no way to tell whether it paid off, because nobody wrote down what it was supposed to save in the first place.
Automation ROI fixes that by putting an actual number on the comparison: what the manual version costs each year, against what the automation costs to set up and keep running. It's a simple calculation, and doing it before committing to anything is what turns "this feels like it'll help" into an actual decision.
Working out the cost of manual work
Before any ROI number means anything, the manual cost needs to be real, not a guess. A simple version:
(minutes per instance ÷ 60) × instances per year × hourly labour cost = annual manual cost
If the manual process also causes errors that are expensive to fix, a client having to be re-invoiced, a shipment sent to the wrong address, add a rough estimate of that cost too. It doesn't need to be precise. It needs to be honest enough to compare fairly against what the automation will cost.
Payback period: how long until it pays for itself
For a small business, payback period is usually the more useful number, more intuitive than a percentage:
setup cost ÷ monthly savings = months to payback
That ratio tells you directly how many months of savings it takes to recover what you spent setting the automation up. Everything saved after that point is the actual return. As a rough rule of thumb, payback under twelve months tends to be easier to justify; multi-year payback is worth more scrutiny, especially for a process that might get redesigned or replaced before the automation earns itself back.
One extra line item if AI is involved
A rule-based automation is usually cheap to maintain once it's built, because the rules don't drift on their own. A step that uses AI to interpret messy input is different: budget some ongoing time to spot-check its output and correct course if the input it's seeing changes, at least until you trust it on your own work. That's a real cost, not a hypothetical one, and it belongs in the automation's running cost, not left out of the calculation.
Building a simple automation business case
A business case doesn't need to be a formal document to be useful. At minimum, it should state:
- The annual cost of the manual version, with the maths shown, not just a final number
- The full cost of the automation, including realistic ongoing maintenance, not just the setup fee
- The resulting payback period
- Any soft benefits (faster turnaround, less stress), listed separately from the hard numbers above, not folded into them
That's usually enough for an owner to make a confident decision, and enough to check back against once the automation is live to see whether the real numbers matched the estimate.
Sanity-checking the estimate
Every number in this calculation is a forecast, not a fact, so it's worth testing how wrong it can be before it stops being worth doing:
- Run it again at half the volume you expect. If the payback period still looks reasonable at half the instances per year, the case is solid. If it only works at the optimistic number, the real risk isn't the automation, it's the estimate.
- Check when the clock actually starts. Payback periods usually assume full efficiency from day one, but most automations take a few weeks to settle in while exceptions get found and fixed. Add that ramp-up time rather than counting it as lost.
- Compare against what you'd actually do instead, not against doing nothing. If the real alternative to automating a task is hiring someone or outsourcing it, compare the automation's cost and payback against that option specifically. See automate, outsource, or hire for that comparison.