How to identify which business processes are worth automating

The most common automation mistake is automating the wrong thing. The second most common is automating the right thing badly, because nobody mapped the process properly before writing a line of code.

Here is the framework we use before recommending any automation engagement.

The four questions

Before automating anything, answer these four questions honestly.

1. How often does it happen?

A process that runs once a month is rarely worth automating. A process that runs fifty times a day almost always is. Frequency is the multiplier on every other factor.

2. How consistent is it?

Automation handles consistency well and exceptions badly. If a process requires human judgement on 30% of cases, automating the other 70% may create more work than it saves — someone still has to monitor the automation and handle the exceptions it cannot.

3. Where do errors occur?

Manual processes have error patterns. The same step fails in the same way, for the same reason, repeatedly. If the errors are in the data rather than the process, automating the process will automate the errors too.

4. What happens when it breaks?

Every automation breaks eventually. The question is what happens when it does. A broken automation that fails silently is worse than a manual process — at least a human notices when something goes wrong.

The processes worth automating first

Based on these questions, the highest-value automation candidates share a few characteristics:

• High frequency — runs daily or more
• Low exception rate — fewer than 10% of cases require human judgement
• Clean input data — the data feeding the process is reliable and consistent
• Visible failure — errors surface immediately rather than accumulating silently

Data transfer between systems is the most common example. Order processing, invoice generation, inventory updates, report distribution — these are repetitive, consistent and well-defined. They are also the processes where errors are most costly, because they happen at volume.

What to automate last

Processes that involve customer communication, complex decision-making or regulatory compliance should be automated carefully and late, if at all. The cost of an automated error in these areas is disproportionate to the time saved.

The audit before the build

We spend the first week of every automation engagement mapping the process manually — walking through it step by step, measuring time, counting exceptions and identifying where errors occur. The automation design follows from that map, not from assumptions about how the process works.

The map almost always reveals something the client did not know: a step that exists because of a problem that was fixed two years ago, a workaround that became standard practice, a dependency on a system that is being replaced next quarter.

Automating without the map is how you build something that works perfectly for a process that should not exist.