When should a business automate a process?
A practical test for which processes are worth automating, which to fix first, and what to do about the exceptions.
Automation pays off when a process is repetitive, rule-based and frequent. It goes wrong when a broken process is automated as-is, because all you get is a faster version of the same mess.
A four-question test
- 01Does it happen often enough to matter? A task done twice a year rarely justifies the build.
- 02Is it rule-based? If you can write the decision as 'if this, then that', a computer can make it. If it needs judgement, automate the steps around the judgement and leave the decision to a person.
- 03Is the input consistent? Structured data automates cleanly. Free-text email and handwritten forms need an extraction step first.
- 04Does a mistake cost something? Processes where errors cause refunds, penalties or lost customers benefit most from validation.
Fix the process before you automate it
Map the current process end to end and you will usually find steps that exist only because of an old constraint — an approval nobody reads, a report nobody opens, a form field nobody uses. Remove those first. Automating a step is worth less than deleting it.
Start where the work is copied, not created
The highest-return automations are almost never glamorous. They are the moments where a human acts as a bridge between two systems: copying an order into accounting, re-typing a form into a CRM, assembling a report from three exports. That work is pure overhead and it automates reliably.
Plan for the exceptions
Every real process has cases that do not fit the rules. A good automation handles the common path and routes the rest to a person with enough context to decide, rather than failing silently or forcing the exception through the wrong branch.