Automation is easy. Choosing what to automate is not.
Most automation projects don't fail in the build. They fail in the choice of what to build.
A team picks the task that's most visible, or most annoying, or most fun to demo — and automates that. Six months later the automation is switched off, because the task didn't happen often enough to matter, or the rules changed every quarter, or one rare edge case caused enough damage that nobody trusts it anymore.
The technology worked. The decision was wrong.
Before we build anything, we run every candidate process through the same four questions. They decide not just whether to automate, but how much.
Question 1: How often does it happen?
Automation has a fixed cost to build and an ongoing cost to maintain. That cost is only worth paying if the task happens often enough to earn it back.
A report compiled every weekday morning is a strong candidate — the time saved compounds five times a week, every week. A process that runs twice a year usually isn't. The effort to automate it reliably, and to keep it working between runs, costs more than just doing it by hand.
Frequency is the first filter because it's the most ruthless. High-frequency, low-value tasks are where automation quietly returns the most — far more than the rare, dramatic ones that get all the attention.
Question 2: How clear are the rules?
Some work follows rules you can write down: if the invoice matches the purchase order, approve it; if not, flag it. That kind of work automates cleanly, because the logic is explicit and testable.
Other work depends on judgement that nobody can fully articulate — reading a situation, weighing trade-offs, knowing when the rule shouldn't apply. You can support that work with good information and a clean interface, but trying to fully automate it usually produces something confidently wrong.
The honest test: can someone write down the rules completely enough that a new hire could follow them without asking questions? If yes, it's a candidate for automation. If it always "depends," it's a candidate for assistance — surfacing the right data so a person decides faster, not removing the person.
Question 3: What happens when it's wrong?
Every automated process will eventually do the wrong thing. The question is what that costs.
A misfiled internal note is cheap to catch and fix. A payment sent to the wrong account, an email to a client, a compliance submission — those are expensive, sometimes irreversible. The stakes don't disqualify a task from automation, but they decide how much human oversight stays in the loop.
We use a simple ladder:
- Low stakes → automate and notify. The system acts; a person can review after the fact.
- Medium stakes → automate behind an approval gate. The system proposes; a person confirms before anything happens.
- High stakes → assist only. The system prepares everything, but a person makes and owns the decision.
The goal is never maximum autonomy. It's appropriate autonomy for what's at risk.
Question 4: How stable is the process?
A process that changes every few weeks is a moving target. Automate it and you'll spend more time rewriting the automation than you ever saved.
Some of that instability is real — a young process still finding its shape should stay manual until it settles. But often the instability is a symptom: the process keeps changing because it was never designed, just accumulated. In that case the right move isn't to automate the mess. It's to fix the process first, then automate the version that works.
Stability is the question that tells you whether you're ready to build yet, or whether there's design work to do first.
The map: automate, assist, or leave alone
Run those four questions and every process lands in one of three places:
Automate — frequent, rule-based, recoverable, stable. These are the quiet wins: the reconciliations, the status updates, the routine reports. Unglamorous, and exactly where the time goes back.
Assist — valuable but judgement-heavy, or high-stakes. Don't remove the person; make them faster and better-informed. Pull the right data into one view, draft the first version, flag what needs attention.
Leave alone — rare, unstable, or low-value. Automating these costs more than it returns. The discipline to not build here is what keeps a system maintainable.
Why the discipline matters
It's tempting to automate everything that technically can be. But every automation is something to maintain, monitor, and trust. A system stuffed with marginal automations is fragile and expensive to keep alive.
The systems that last are selective. They automate the high-frequency, clear-cut, recoverable work completely. They make people sharper everywhere judgement matters. And they leave the rest alone, on purpose.
The bottom line
The hard part of automation was never the building. It's the choosing.
Ask how often it happens, how clear the rules are, what a mistake costs, and how stable the process is. Let those answers decide what to automate, what to assist, and what to leave in human hands. Build the right things completely — and have the discipline to skip the rest.