When to Turn It Off
Automations rarely get switched off. They get left running, half-trusted, maintained reluctantly by someone who inherited them, long after they stopped being worth the effort.
Turning one off is a legitimate outcome and it needs the same deliberation as building one. A product-side example of how workforce software approaches this topic is available in this overview.
Five signals
One. Maintenance exceeds the saving. Measurable, if you have been logging both. If upkeep runs eight hours a month against a six-hour saving, the arithmetic has inverted and nobody noticed because the two numbers live in different places. For broader background and an independent point of comparison, see Ars Technica IT.
Two. The exception rate has climbed past usefulness. Upstream drift, new input types, a business that changed. At 40% exceptions the automation is routing more work to people than it completes.
Three. The process changed and the automation handles the old one. Sometimes it is quietly processing a case that no longer matters, and the real work happens elsewhere.
Four. Nobody trusts the output. People check it manually anyway, or maintain a shadow spreadsheet. This is the clearest signal and the least often acted on — the automation is running and the organisation has already stopped relying on it.
Five. The underlying system is being replaced. A bridge whose far end has arrived. Decommissioning should be in the replacement plan and rarely is.
Why they stay running
Sunk cost. Somebody approved it, somebody built it, turning it off feels like admitting the project failed. It may not have — a five-year-old automation that paid for itself and is now obsolete was a success.
Nobody owns the decision. The builder has gone, the sponsor has moved, and the person maintaining it does not have the authority to stop it.
Fear of the manual path. Nobody remembers how the process worked before, which is a documentation failure and is why the manual path should be kept documented.
And it is invisible. A working automation makes no noise. Nobody reviews things that are not complaining.
Decommissioning properly
Check the manual path exists and someone can run it. In writing, tested, before switching anything off. This is where most decommissioning goes wrong.
Run manual in parallel for a period, the reverse of the implementation parallel run, and for the same reason.
Find the downstream dependents. Something may be consuming the output — a report, a feed, another automation. This is what the dependency documentation is for, and its absence is why people leave things running.
Archive rather than delete. The logic, the documentation, the rules. If it needs rebuilding in two years, that record is worth having.
And write down why. One paragraph: what it did, why it was turned off, what replaced it. The next person will ask.
The review that prevents zombies
An annual list of every automation, with two numbers each: hours saved and hours spent.
Half a day for most organisations. It surfaces the ones that inverted, the ones nobody trusts, and the ones whose process changed — all of which are invisible individually and obvious in a list.
Most organisations have never made this list, and the first time it is made it usually contains at least one automation nobody could account for.
The one to keep despite the numbers
Being fair, because this page is one-directional.
An automation whose value is consistency rather than hours. Something that never forgets, never gets it wrong on a Friday, never varies between people. The hours may not justify it and the reliability might.
Say that explicitly when reviewing, rather than letting it pass under an hours calculation it fails.
The short version
- Five signals: maintenance exceeds the saving, exceptions climbed past usefulness, the process changed, nobody trusts the output, or the underlying system is being replaced
- Distrust is the clearest signal and the least acted on — the automation runs while the organisation has already stopped relying on it
- They stay running from sunk cost, absent decision ownership, fear of a forgotten manual path, and invisibility
- Decommission properly: verify the manual path, run parallel, find downstream dependents, archive rather than delete, and write down why
- An annual list of every automation with hours saved and hours spent takes half a day and surfaces every zombie at once
- Keep the ones whose value is consistency rather than hours, and say so explicitly