The return on an automation is the cost of the manual process minus the cost of running the automation, measured against what it costs to build. All three are knowable before you commit, and the first one is the one companies almost never measure — which is why automations get justified on instinct and then cannot be evaluated afterwards.
Measure the manual process first
Before designing anything, establish three numbers:
- Frequency. How many times does this run — per day, per week, per month? Count, do not estimate. Estimates on repetitive work are consistently wrong in both directions.
- Duration. How long does one run take, including the interruption cost of switching to it.
- Error rate and cost. How often does it go wrong, and what does a wrong one cost — a re-issued invoice, a lost order, an unbilled accessorial.
Frequency times duration times loaded hourly cost gives the labour figure. Error rate times error cost gives the second, which is usually the larger of the two and almost always the one omitted.
Then the running cost
An automation is not free to operate:
- Infrastructure, if it is a custom service
- Per-task pricing, if it runs on Zapier or Make — this is the one that surprises people at volume
- AI inference, if the work needs judgment, priced per use
- Human review, for the cases routed to a person
- Maintenance, because the systems it touches will change
That last one is real and gets left out. An automation connecting to a vendor portal will break when the vendor changes the portal.
Then the build cost
Get this from your supplier as a scoped figure, not a guess. It should account for the integrations involved and whether the systems have usable APIs, because a system without an API costs several times more to connect and stays more fragile.
The calculation
Annual saving = (labour cost + error cost) − annual running cost
Payback period = build cost ÷ (annual saving ÷ 12)
If the payback period is longer than the time you expect the process to survive unchanged, do not build it. Processes get replaced, vendors get switched, and an automation that pays back in three years against a process being reviewed next year is a loss.
What this method rules out
Used honestly, it rejects things. Common rejections:
- Low-frequency work. A process running forty times a month rarely justifies a custom build, whatever the per-run saving.
- Work about to change. If the process is under review, wait.
- Work that should be deleted. Some tasks exist because a system produces the wrong output and someone corrects it by hand. Fix the upstream system.
We would rather run this calculation and tell you not to build than take the work. An automation that does not repay its cost damages the case for the next one, which is usually the one that would have paid.
Ranking, not just approving
Once you have the numbers for several candidate processes, rank by payback rather than by enthusiasm. The order is frequently surprising: the process that irritates people most is often not the one costing most, and the one costing most is often invisible because it is spread thinly across many people.
Start where the return is clearest. The second automation is always cheaper than the first, because the connections and credentials are already in place.
- automation
- roi
- measurement
- process