Automation is a deeply seductive subject. There is a reason “automate it” gets thrown around as a default suggestion in any operational meeting — automation feels like leverage, like compounding, like a clever solution. Most of the time, it is none of those things.
Most automation projects die for one of three reasons. They automate something that did not happen often enough to matter. They automate something whose business rules change so often that the automation is constantly being rewritten. Or they automate the easy part and leave the hard part for a human anyway.
The frequency-by-stability matrix.
Two questions, asked of any candidate workflow.
How frequently does this happen? Daily? Weekly? Monthly? Once a year?
How stable are the rules? Will they look the same in six months? Twelve months? Two years?
Automation is worth it when frequency is high and stability is high. It is a waste of time when frequency is low or stability is low. The matrix is unsexy because most of the workflows people want to automate fall in the wrong quadrants — high-frequency-but-unstable, or stable-but-rare.
- →High frequency + high stability: automate. This is where compounding lives.
- →High frequency + low stability: do not automate yet — pin the rules first.
- →Low frequency + high stability: usually not worth the build cost. Document instead.
- →Low frequency + low stability: definitely do not automate. A checklist is enough.
“Automation is worth it when frequency is high and stability is high. Most candidate workflows fail one or both tests.”
The hidden cost is maintenance, not build.
The build cost of an automation is what people quote. The maintenance cost is what kills it. Every time the upstream system changes, every time the business rules shift, every time a new edge case shows up, somebody has to dive back into the automation and fix it.
The automations that survive are the ones with low maintenance cost. That usually means stable underlying systems, clear ownership, good observability so failures get caught early, and a small surface area so changes are easy.
The automations that die are the ones written for a workflow that is still being figured out. The rules change every fortnight, the automation breaks every fortnight, and after three rounds the team quietly goes back to the manual process. The automation gets archived.
Three automations I have seen pay off, repeatedly.
Email notifications and digests. They run constantly, the rules barely change once you have got them right, and the leverage is enormous. Daily overdue alerts to the role that can act on them. Weekly digests to directors. Approval emails on submission. These pay back forever.
Data reconciliation between two systems that need to agree. Payroll reconciling attendance against leave and expenses. Inventory reconciling between an ops platform and an accounting tool. Stable rules, high frequency, and a clear deterministic right answer. Perfect automation territory.
Scheduled reports. Monthly summaries, quarterly dashboards, end-of-week ops reports. The cron job that produces them is fifty lines of code, runs forever, and saves a person hours every month. Almost free.
Three automations I would not build for clients.
Anything that depends on screen-scraping a SaaS UI. SaaS UIs change. Your automation breaks every quarter. The maintenance cost will exceed the build cost inside a year. If the SaaS does not have a real API, the automation is not viable.
Anything where the “automation” just moves work to a human. If the automation generates a draft that someone has to review carefully every time, you have not removed the human bottleneck — you have added a step before it. Sometimes that is fine, but the ROI conversation needs to be honest about it.
Anything for a business process that the team has been running for less than three months. The team does not know yet how the process should run. Automating prematurely freezes a bad version into code, which is harder to change than a bad spreadsheet.
“The automation that survives is rarely the one people get excited about. It is the boring email digest that has been running for two years.”
The honest order of operations.
Before automating, document the workflow as a checklist. Run it manually, with the checklist, for a couple of months. Find out what actually happens, what the edge cases are, where the rules are ambiguous. Stabilise the process.
Then, and only then, automate the parts that are stable and high-frequency. Leave the unstable parts manual. Revisit annually. The instinct to automate first is almost always wrong.