Insights / Operations
When automation makes noise instead of leverage.
Automating a process that is not yet reliable scales the unreliability and adds a layer nobody can see into. Four questions decide whether a workflow is ready, and none of them are about the tooling.
Automation is sold on hours saved, and hours saved is a real benefit. What the hours-saved framing leaves out is that automating a process also removes the person who was silently absorbing its exceptions. A human running a flawed process notices the odd case and handles it. The same process automated does not notice, and the exception propagates.
This is why a workflow can be automated successfully and leave the business worse off. The labor is gone, and so is the judgment that made the labor tolerable.
Four questions before anything is built
1. Is the process deterministic yet?
If two competent people follow it and reach different results, it is not a process, it is a practice. Automating a practice encodes whichever version the builder happened to observe, and everyone else's variation becomes a defect report later. Write it down first. If it cannot be written down, it is not ready.
2. Is failure detectable?
The dangerous failure is not the one that stops the workflow. It is the one where the workflow completes and the output is wrong. Before building, decide what evidence would demonstrate that a run was correct, and make the automation produce it. A workflow that can only report that it ran is a workflow you cannot trust.
3. Is it reversible?
Anything that sends externally, deletes, transacts or changes a record somebody else depends on should have a human checkpoint, not because machines are careless but because the cost of the rare wrong case is asymmetric. Being right ninety-nine times does not compensate for the hundredth if the hundredth was an email to the wrong list.
4. Is the input contract stable?
Automations are usually built against the shape of the data on the day they were built. Shapes change. A new field, a renamed column, a different date format, an upstream system that starts returning an empty value where it used to return nothing at all. If the input can change without anyone telling you, the automation needs to validate its input and refuse to proceed rather than improvise.
A process that is not reliable when a person runs it does not become reliable when a machine runs it. It becomes fast.
The noise failure
The second common outcome is not a wrong result but an unusable volume of signal. A workflow is set up to alert on anything unexpected. Unexpected turns out to be common. Within a month the alerts are a channel nobody reads, and the one alert that mattered arrives into a stream that has already been trained to be ignored.
Alerting has to be designed with the same discipline as the process. An alert that does not correspond to an action somebody will take is not an alert, it is decoration, and it actively degrades the alerts around it. The better default is to alert on very few conditions and to make each one genuinely actionable, with the action stated in the message.
For each notification a workflow produces, name the person who receives it and the specific thing they will do when they do. If either answer is vague, the notification should not exist. Applied honestly, this usually removes most of them.
What good automation looks like afterward
- It refuses bad input rather than processing it into a bad result.
- It produces evidence that a run was correct, not merely that it completed.
- It alerts rarely, and every alert names an action.
- It has a human checkpoint in front of anything irreversible.
- The team can explain it, operate it and switch it off without the firm that built it.
That last one matters more than it sounds. An automation nobody internally understands is a dependency, and dependencies that were sold as leverage have a way of becoming the reason a business cannot change a supplier.
When not to automate at all
Some work should stay manual on purpose. Low frequency work where the setup cost will never be recovered. Work whose value is in the attention it receives rather than in its completion. Anything safety, health, legal or compliance related. Anything where the process is genuinely still being figured out, where automating now would freeze a version you are about to outgrow.
The question is never whether a workflow can be automated. Almost anything can be. The question is whether it should be yet, and the honest answer is often not until the process is reliable without it.