Business process automation ROI: how to work out what to automate first

Most automation business cases undercount, because they only count the obvious labour. There are four costs to measure.

Direct time: how many hours per week the task consumes across everyone who touches it. Count the interruptions and the context switching, not just the task itself. Error cost: how often mistakes happen and what fixing one costs, including downstream consequences like an incorrect invoice reaching a customer. Delay cost: what the lag itself costs — an invoice raised three days late is three days of working capital, every time. Opportunity cost: what the people doing this work would otherwise be doing.

The last two are usually the largest and are almost always omitted. In a logistics engagement we ran, the direct labour case alone was marginal; adding the delay cost of late dispatch and the working-capital impact of late invoicing made the decision obvious.

List every candidate process and score each on annual cost from the four factors above, then estimate build and first-year running cost. Divide to get a payback period. Sort by payback.

This ordering is often uncomfortable, because the process that annoys leadership most is rarely the one with the best return. The unglamorous, high-volume, invisible task — invoice matching, order transcription, report assembly — usually wins on the numbers.

Our working rule: anything paying back inside six months is worth doing now; six to twelve months belongs in the plan; beyond twelve months is usually better solved by simplifying the process than by automating it.

Avoid automating processes that are still changing shape. If the process was redesigned twice in the last year, automation will encode a version that is about to be wrong, and changing software costs more than changing a habit.

Avoid low-volume, high-judgement work. A task done twice a month by an experienced person who weighs context each time is a poor candidate — the build cost is real and the saving is negligible.

Be careful with processes whose exceptions outnumber the standard path. If 60% of cases are exceptions, you are not automating a process, you are attempting to encode expert judgement, which is a different and much larger project.

Finally, do not automate a broken process. Automation makes a bad process faster and harder to change. Simplify first, then automate what remains.

The safest pattern is: the system proposes, a person confirms. It captures most of the time saving immediately, while keeping a check that surfaces errors before they reach customers.

It also builds trust, which is the real constraint on adoption. Teams that have been burned by a bad rollout do not trust the next one, and an automation nobody trusts gets worked around.

Once the confirmation step has approved a few thousand cases with a low correction rate, you have earned the data to let the highest-confidence cases run unsupervised, keeping human review for the rest.

Every process has exceptions, and they are where automation projects fail. The instinct is to hide them; the correct move is to surface them prominently, because that is where human attention is genuinely valuable.

Build an exception queue with enough context to resolve each case, and track the exception rate over time. A rising rate is a signal the process has changed and the automation needs revisiting — the difference between a system that degrades quietly and one that tells you it needs attention.

For EU operations, automated processing of personal data brings GDPR obligations, and any automated decision-making that materially affects individuals needs a human review path by design.

Cost structures shift the maths by market. In high-labour-cost markets like Germany, the Netherlands, the US, and Australia, automation payback is faster because the hours saved are more expensive. In South Africa, where labour costs are lower, the stronger case is usually delay and error cost rather than headcount, particularly where processes gate cash collection.

Companies operating across several of these markets often find their best first candidate is a process duplicated in each region, since one build removes the same manual work several times over.