Processes You Should Never Automate

5 August 2026 · 3 min read

blog contents
  1. Work that has never been written down
  2. Judgement dressed up as a rule
  3. Cases too rare to learn from
  4. Anything expensive to reverse
  5. How to tell judgement from a rule
  6. What to do with the work that stays manual

read

Automation multiplies whatever it touches. Point it at a good process and you get leverage, point it at a broken one and you get the same breakage at speed and at scale. Four kinds of work should stay manual: anything nobody has written down, anything that is decided rather than executed, anything rare enough that the rule never stabilises, and anything where being wrong is expensive to reverse.

Work that has never been written down

If two people do the same task differently and both are right, there is no process yet, only a habit with variations. Automating it freezes one person's version and calls it policy.

Write it down first. Half the time the written version turns out not to need automating, because most of the delay was ambiguity rather than effort.

Judgement dressed up as a rule

Approving an unusual discount, deciding whether a complaint is a refund or an apology, choosing which client hears bad news first. These look like rules because experienced people apply them quickly.

What you can automate is the gathering: bring the facts together, put them in front of the person, record what they decided. That removes the tedious part without removing the judgement.

Cases too rare to learn from

A path taken twice a year will not have a stable rule, and the automation will be wrong in a way nobody notices until it matters.

Rare and important is the worst combination. Rare and trivial can stay manual forever at no real cost.

  • Happens a few times a year
  • Every instance is a little different
  • Getting it wrong is hard to unwind
  • Only one or two people have ever handled it

Anything expensive to reverse

Money leaving, messages going out, records being deleted. The value of a person here is not the work, it is the pause.

Where the volume genuinely demands automation, keep the pause and move it: let the system prepare everything and let a person release it.

How to tell judgement from a rule

The test is whether two experienced people, given the same facts, reach the same answer. If they do, it is a rule and it can be written down and then automated.

If they disagree and both can defend their answer, it is judgement. Automating it does not resolve the disagreement, it just picks a side permanently and stops anyone noticing.

What to do with the work that stays manual

Manual does not have to mean slow. Most of the time in a judgement task is spent gathering context, not deciding.

Put everything the person needs on one screen, in the order they need it, and record what they chose. The decision stays human and the surrounding work stops being tedious, which is where the actual time was.

questions

Is a checkpoint not just a bottleneck?

It is, and that is the point. The question is whether the bottleneck costs less than the mistakes it prevents. For money and outbound messages it usually does, by a wide margin.

How do we know a process is stable enough?

Two people can follow the written version and reach the same result without asking each other anything. If that is not yet true, the writing is the work, not the software.

What about automating just part of it?

That is usually the right answer. Automate the collecting, the formatting and the routing, and leave the decision. Most of the time saved was never in the deciding.

More on this track

  1. How to Automate Your Business Automate in this order: count where the hours actually go, fix the process before encoding it, integrate the systems that make people retype data, add AI only where the input is messy and the output gets checked, and stop when the next item costs more to automate than it saves. 29 August 2026 · 3 min read
  2. Find the Hours Worth Automating Most automation projects start with a tool somebody liked and work backwards to a problem. Start from the hours instead: for two weeks, record what the team actually repeats, how often, and how long it takes. The list that comes back is always shorter than the list people describe from memory, and the top item is almost never the one that gets complained about most. 21 July 2026 · 2 min read
  3. What Breaks When You Automate Automation rarely fails with an error. It fails by continuing to run after the world underneath it changed: a field renamed, a rate limit hit, a supplier altering a format without telling anyone. The work is not building it, the work is noticing when it drifts. Anything running unattended needs a way to say it is unwell and a written answer for what to do about it. 2 July 2026 · 2 min read