What to automate first, and what to leave alone
Most automation projects start with the most impressive-sounding process. That is almost always the wrong place to begin, and it is why so many of them stall.
There is a predictable failure pattern in business automation. A company decides to automate, picks the process that sounds most impressive in a meeting, spends months on it, discovers the process has forty exceptions nobody mentioned, and quietly abandons the project. The conclusion drawn is usually "automation doesn't work for us", when the real conclusion should have been "we picked the wrong thing".
Here is a more reliable way to choose.
The three-question test
A process is a good automation candidate if the answer to all three is yes.
- Does it happen often? Something done twice a year is rarely worth automating, however tedious. Daily or hourly tasks compound.
- Does it follow the same rules every time? If the answer depends on judgement, context or who is doing it, you're looking at decision support rather than automation.
- Does getting it wrong cost something? Money, a customer, a compliance obligation, a wasted hour. If nothing happens when it goes wrong, the process may not need to exist at all.
Two out of three is usually not enough. Frequent and rule-based but consequence-free is often a process worth deleting rather than automating.
Start with intake, not the interesting part
In most businesses the highest-return automation is the least interesting one: what happens when something arrives. Enquiries land by form, email and phone. Someone reads them, works out what they are, decides where they go, and acknowledges them. It happens constantly, it follows rules, and doing it slowly costs you work.
It also has a property that makes it an ideal first project: it is at the edge of your process. If it goes wrong, you find out immediately and nothing downstream has been corrupted. Compare that with automating something in the middle of your operation, where an error propagates silently into three other systems before anyone notices.
Automate at the edges first. Intake and output are where mistakes are visible and recoverable. The middle is where they hide.
The things worth automating, roughly in order
| Process | Why it is a good first candidate | Typical effort |
|---|---|---|
| Enquiry intake and routing | High volume, rule-based, errors visible immediately | Low |
| Confirmations and reminders | Pure rules, removes chasing, customers notice instantly | Low |
| Document generation | Data already exists, output is checkable before sending | Low-medium |
| Data sync between systems | Removes re-keying, which is where errors come from | Medium |
| Scheduled reports | Recurring manual work with a predictable shape | Low |
| Invoice chasing | Nobody enjoys it, so it slips - and it is pure rules | Low-medium |
| Verification and checks | High value where stakes are real, but needs care | High |
What to leave alone
Anything you haven't written down
If nobody can describe the process precisely, automating it means automating one person's version of it - and discovering the other versions later, in production. Write it down first. That exercise alone frequently improves the process enough that automation becomes less urgent.
Processes you're about to change
Automating something you plan to restructure in six months means paying twice. If a process is genuinely in flux, wait for it to settle.
Judgement calls dressed as rules
Plenty of processes look rule-based until you examine them and find an experienced person applying judgement in a way nobody has articulated. Pricing is the classic example: there is a price list, and there is also what the person on the desk does when a good customer asks for a discount on a Friday afternoon.
You can automate the rules and route the judgement to a person. What you cannot do is pretend the judgement wasn't happening.
Anything irreversible, without a human gate
Money leaving the business, records being deleted, communications going to customers for the first time. Automate the preparation, let a person approve the action. The time saved by removing that click is never worth the day you spend explaining an automated mistake to a customer.
Design for the exception before you build the rule
This is the single biggest difference between automation that survives and automation that gets switched off. Every real process has cases that don't fit, and a system that only works when every input is perfect will fail in week two and lose the team's confidence permanently.
Before building anything, answer these:
- What happens when the input is malformed or incomplete?
- What happens when an external system is down or slow?
- Who finds out when something fails, and how quickly?
- Can a person see what the automation did, after the fact?
- Can a person override it, and is that override recorded?
If those answers don't exist, the automation is not ready to build regardless of how well-understood the happy path is.
Where AI fits into this
Almost everything above is deterministic rules, and rules should be code - testable, predictable and auditable. Language models are the wrong tool for anything that must be right every time.
Where they earn their place is the step that currently requires a person to read something and understand it: working out what a free-text enquiry is actually about, summarising a long history, pulling fields out of a document that arrived in whatever format the sender chose. Use a model for the reading, and rules for the deciding.