What to automate first when everything looks automatable
Frequency times time times cost of error, plus the factor nobody puts on the list: who notices when it breaks. What usually wins, what to postpone, and what to fix first.
When a company decides to automate, the list of candidates appears quickly and it is long. Everything looks automatable, everything looks urgent, and the project stalls before it starts because there is no obvious way to order the list.
This is the criterion we use to order it. It is not a named methodology: it is four questions you can answer in one meeting.
The question that leads nowhere
“What can we automate?” is useless, because the honest answer is “almost everything”, and that prioritises nothing. The question that does sort the list is different: what is costing me more to do by hand than it would cost to fix?
The shift matters because it removes tasks that are annoying but cheap, and brings in the ones that are invisible and expensive. The one that hurts most is rarely the one that costs most.
Frequency x time x cost of error
| Factor | The question | Where it gets underestimated |
|---|---|---|
| Frequency | How many times a week it happens | Daily beats monthly, even when monthly hurts more |
| Time per run | How long it takes by hand | Count the interruption, not just the task |
| Cost of error | What happens if it goes wrong once | An error reaching the customer costs far more than an internal one |
| Detection | Who notices if it stops working | If the answer is nobody, the risk multiplies |
Frequency. The most underestimated factor, because monthly work feels heavier. A three-minute task happening fifteen times a day consumes far more than a four-hour monthly close — and it breaks somebody’s day fifteen times as well.
Time per run. Count the whole interruption, not the task. Copying a value from one system to another takes two minutes; getting back to what you were doing takes considerably longer.
Cost of error. Two different worlds separate here. An internal error gets corrected. An error that reaches the customer — a wrong quote, a duplicated booking, an email to the wrong recipient — costs trust, and an apology does not buy that back.
The fourth factor: who notices when it breaks
Nobody puts this on the list, and it causes the most trouble later. Every automation falls over eventually: an API changes, a token expires, somebody renames a column.
The question is not whether it will fail, it is how long before someone finds out. And there is one particularly cruel failure mode: the silent one. An automation that stops running does not produce a visible error — it produces nothing. And “nothing” looks exactly like “it did not happen this week”.
What usually wins, and what usually should not
Candidates that almost always score high:
- Moving a lead from the form to wherever somebody will see it. Frequent, easy to get wrong, and the cost of error is a lost customer nobody knows about.
- Alerting when something has gone too long without a response. Cheap to build, and it attacks the most expensive problem in service businesses.
- Consolidating data that is currently copied into a spreadsheet by hand. High frequency and guaranteed silent errors.
- Reminders and confirmations. High volume, zero judgement, direct impact on no-shows.
And the ones worth leaving for later, however tempting:
- Processes with many exceptions. If every case has an “unless”, you will be programming the “unless” forever.
- Anything that changes every month. Automating something unstable is building on sand.
- Judgement calls dressed up as rules. If the real rule is “depends how the customer comes across”, that is not a rule.
- Whatever happens three times a year. Even if each time is a headache.
A note on AI: almost nothing in the first list needs it. Moving, alerting, validating and scheduling are solved by classic automation, which is cheaper and more predictable. AI earns its place when the input is unstructured language — and there it brings its own rules, which are in what goes wrong with an agent talking to customers.
What to fix before automating anything
Automating a bad process makes it faster, not better. Before building, rule out three things:
- That the process is written down. If nobody can describe it in five steps, it is not ready to be automated: it is ready to be defined.
- That the data it needs exists and is reliable. An automation reading a field that is empty half the time inherits that problem and spreads it.
- That it has an owner. Someone who receives the alert and decides what to do. Without that, the automation has an expiry date.
The first rules out more projects than you would expect, and always for the better: writing the process down usually reveals that the problem was not the lack of automation.
FAQ
- Should I automate the biggest process first? Usually not. Big processes have the most exceptions, and exceptions are what break automations. Starting with something small and frequent gets you a working system and a team that trusts it — which is what makes the next one possible.
- Is it better to buy a tool or build it? Buy when the process is standard and the tool already does it. Build when the process is what makes you different. The expensive mistake is buying a tool and then bending your business to fit it.
- Do I need AI for this? Most of what is worth automating first needs no AI at all: moving data between systems, notifying, validating, scheduling. AI earns its place where the input is unstructured language. Reaching for it first adds cost and uncertainty to a solved problem.
- How do I know it is working? Decide the failure signal before you build. If nobody would notice the automation stopping, you have not built a system — you have built something that will fail silently.