Almost every article about automation assumes you have already decided to automate and is helping you choose a tool. That skips the decision that matters most.
The highest-value automation work is often deciding not to automate — because the wrong candidate does not merely fail to help. It entrenches a bad process, adds a maintenance burden, and removes the human judgement the process quietly depended on.
The four conditions
A process is a good automation candidate when all four hold. Missing one is a warning; missing two usually means no.
| Condition | The test | If missing |
|---|---|---|
| Stable | Have the rules been unchanged for six months? | You will maintain it more than you run it |
| High volume | Does it run often enough for the saving to matter? | Build cost exceeds lifetime saving |
| Rule-based | Can someone write down every decision, including edge cases? | The automation will handle the easy 80% and escalate the rest |
| Well-designed | Would you keep this process if you were starting today? | You are making a bad process permanent |
The last is the one people skip, and it is the one that causes the most damage.
Automating a bad process makes it worse
This is the central argument, and it is worth stating without hedging.
A manual bad process is annoying, and its friction is a signal. People complain, work around it, and eventually someone fixes it. Automation removes the friction while keeping the badness. The complaints stop. The process is now fast, invisible, and much harder to change — because changing it means changing software rather than telling people to do something differently.
The pattern is consistent: a form collects fields nobody uses, an approval step exists because of an incident years ago, data is re-entered between systems that could be connected. Automating any of these makes a redundant step permanent, and the automation becomes the reason nobody revisits it.
Ask the question directly: if we were designing this today, would it exist? If not, the work is process redesign — and automation may then be unnecessary, because the step you were automating turns out not to be needed.
This is why the first phase of any serious automation engagement is
mapping the process before automating it.The saving is usually smaller than the estimate
The standard calculation is frequency × duration. It is optimistic because it counts only the part that gets automated.
The honest calculation subtracts:
- Exception handling that remains. An automation covering 85% of cases leaves 15% needing a human — and those are the complicated ones. The time saved is not 85% of the total; it is 85% of the easy cases, which took less time each anyway
- Monitoring nobody currently does. A manual process fails visibly. An automated one fails silently, so someone must now watch it. That is new work created by the automation
- Maintenance when something upstream changes. APIs change, forms change, the business changes. Each requires someone to understand the automation before modifying it
- The cost of understanding it later. In a year, the person maintaining it will not be the person who built it
This is why automations that "save ten hours a week" reliably free up about three. Three hours a week is still worth having — but it is a different business case, and it changes which processes are worth the build.
When to leave it alone
Five situations where the answer is no, and the discipline is saying so:
The process changes frequently. Maintenance cost scales with rate of change. A process changing monthly needs an automation updated monthly, and each update is harder than the original build because someone must first reverse-engineer what exists.
Nobody can write the rules down completely. If the answer to "what happens if the customer has two accounts" is "it depends, ask Sarah", then Sarah is applying judgement, not following rules. Automating around Sarah produces a system that handles the easy cases and escalates everything real — and Sarah's job is now worse, because she only sees the hard ones with no context.
Volume is low and stakes are low. Annoying is not the same as expensive. A process run twice a month is rarely worth a build plus permanent maintenance, however irritating it is. Irritation is a poor proxy for cost.
The process is a symptom. Manually reconciling two systems is a symptom of the systems not being connected. Automating the reconciliation makes the disconnection permanent and removes the pressure to fix it properly.
Human contact is the point. Some processes carry a relationship. Automating the personal follow-up after a large purchase saves minutes and costs something that does not appear in the calculation until it is gone.
The strongest counter-argument
The best objection to everything above is this: automation forces clarity.
It is true. Software cannot proceed on unstated assumptions, so building an automation surfaces every ambiguity, undocumented exception and disagreement about how the process actually works. Many teams genuinely understand their own process for the first time while automating it.
That is a real benefit and I do not want to dismiss it.
But you can get it without building anything. Mapping the process — writing down the trigger, every decision, every exception, every handoff — produces the same clarity for a fraction of the cost. It takes days rather than weeks, needs no platform decision, and leaves nothing to maintain if the conclusion is that automation is not warranted.
Map first, then decide. If clarity is the benefit you are after, buy the clarity directly rather than as a side effect of a build you may not need.
The decision, in order
- Would you design this process today? No → redesign first. The automation question may disappear
- Can someone write down every rule, including exceptions? No → the process depends on judgement. Automate the rule-based parts only, or nothing
- Have the rules been stable for six months? No → wait, or accept ongoing maintenance explicitly
- Frequency × duration, minus exceptions, monitoring and maintenance — is it still worth it? No → leave it
- Does anything here depend on human contact? Yes → automate around it, not through it
Processes clearing all five are genuinely worth automating, and they tend to be unglamorous: data moving between systems, notifications on a defined trigger, recurring reports, routing based on stated criteria. Boring, stable, high-volume, rule-based. The boring ones are the ones that work.
Keep reading
This argument connects to a few other things worth reading before you make a decision.