What the manual process was quietly protecting
Automation removes more than the work
When you automate a manual process, you write down the steps and hand them to a machine. The steps are the part you can see, so the steps are what gets transferred.
But a person doing that job by hand was doing something else at the same time — noticing. They saw the order that looked odd, the name that was obviously a test entry, the invoice that was a decimal place out. None of that was in the process document, because nobody thought of it as part of the job.
Automate the steps and you get the steps. The noticing does not come along, and nothing announces its absence.
How it shows up
The pattern is consistent enough to be worth naming:
- A lead form gets automated. Submissions rise. So does the share of junk, because the person who used to skim the list and bin the obvious garbage is no longer between the form and the CRM.
- Invoicing gets automated. It is faster and more accurate — and the first genuinely wrong invoice goes out unchallenged, because the previous system had a human who would have said "that cannot be right."
- Onboarding emails get automated. Every new customer now gets a consistent sequence, and the one who clearly signed up for the wrong plan gets it too.
In each case the automation did exactly what it was asked. The loss is a check that was never specified because it never had a name.
The question worth asking first
Before automating a process, ask the person who currently does it:
"When was the last time you caught something?"
Not what are the steps. They will tell you the steps happily, and the steps are the part you already have. Ask what they stopped, what looked wrong, what they escalated. That list is the real specification, and it is usually short — three or four things, each of which they will describe as obvious.
Those obvious things are the ones about to disappear.
What to do with the answer
You have three honest options, and picking one deliberately is the whole exercise:
- Encode the check. If they catch orders over a threshold, add the threshold. Cheap, and it works for anything with a rule behind it.
- Keep a human in the loop for that one case. Not for the whole process — for the exception. Automate the ninety percent and route the rest.
- Accept the loss, in writing. Sometimes the check is not worth the cost. That is a legitimate decision, and it is only legitimate if someone made it. Write the sentence: we no longer catch X, and we decided that.
The failure mode is a fourth option nobody chooses on purpose: the check quietly stops happening and everyone assumes it still does.
Why the accurate description is the dangerous one
There is a trap in doing this analysis well.
When you look closely at a manual process, you will often conclude that most of it was unnecessary — and you will usually be right. The steps genuinely were redundant. But the redundancy was buying margin: slack that absorbed mistakes nobody had catalogued.
An accurate account of the parts can support a wrong conclusion about the whole. "This step does nothing" can be entirely true, while "so we can drop it" is false, because what the step was doing was not in the step.
The short version
Automate the work. Before you do, spend twenty minutes asking what the work was catching — and decide, out loud, what happens to each of those catches.
The steps you can see are the easy part. The judgement riding along inside them is what you are actually replacing.