What to Automate First, and Why It Is Not the Worst Job
The instinct is to start with the process everyone hates. Blast radius is the better criterion, and it usually points somewhere else entirely.
The instinct is wrong in a predictable way
Ask a team which process to automate first and they will name the one they hate.
That job is usually fiddly, high-stakes and infrequent. Contract preparation. The month-end reconciliation. The thing that has to be right and takes an afternoon and only happens twice a month.
It is close to the worst possible first candidate, and for reasons that have nothing to do with whether it deserves to be automated eventually.
Blast radius is the criterion
The question that orders the list is what happens when the system gets it wrong, because on a first project it will.
| Process | If it fails | Blast radius |
|---|---|---|
| Inquiry routing | One reply goes to the wrong person | 1 conversation, recoverable in minutes |
| Availability check | A booking is refused that could have been taken | 1 booking, recoverable same day |
| Document assembly | A contract goes out with wrong terms | A customer, and possibly a legal problem |
| Pricing or commitment | The company is bound to something | A customer, and the commitment stands |
The first two are places to learn. The last two are places to be careful, and they are almost always where the complaints come from.
Frequency is what turns a build into evidence
The second criterion is how often it runs, and it decides how long you wait to know anything.
A process that happens forty times a week gives you a usable answer in a fortnight. The same build on a process that happens twice a month tells you nothing for a quarter, and by then the team has stopped paying attention and the vendor has moved on.
This is also the practical reason a first project should fit into two to four weeks. A long first project is a bet placed before any of the information has arrived, committing you to a supplier and a design at the moment you know the least.
Which one it usually is
Of the four processes we deploy most often, inbound inquiry handling is usually first.
It runs constantly. A mistake is one misrouted reply. It touches few systems, so the integration work does not eat the schedule. And it produces a number quickly: in one brokerage deployment, response time went from 6 hours to 8 minutes, and the deal cycle from 14 days to 5.
That second number is the one that funds the next project, and it is worth noticing where it came from. Faster replies did not save anyone's afternoon in a measurable way. They shortened the cycle, and shorter cycles convert better because fewer buyers cool off in the gap.
When the obvious candidate touches money
Split it rather than skipping it, because the part that touches money is rarely the part where the time goes.
In an order flow, the availability check, the document assembly and the dispatch scheduling can all be automated while the commitment, the price and the terms stay with a person. You get the frequency and the saving without putting a three-week-old system in a position to bind the company.
That is not a compromise for beginners. It is the design the finished system has anyway, for the reasons set out in our rules for keeping a person in the loop, and the rental order flow is a worked example of exactly this split.
What the first project is really for
It is the cheapest chance you will get to learn three things no proposal can tell you.
How your team reacts to a system making decisions, which is rarely how anybody predicts. How many exceptions the process actually produces once somebody is counting, which is almost always more than the estimate. And whether the vendor tells you about problems before you find them, which is the one that should decide whether there is a second project.
Those answers change the shape of what comes next. Choosing a first project that cannot deliver them within a month is the expensive part of getting this wrong, and it is why the order matters more than the list.
Before any of this
None of the above helps if the process fails the readiness test in the first place, and the five conditions in when not to automate yet are worth running before choosing an order at all.
Pick the volume from your own systems. Name the owner. Then take the frequent, recoverable one first, even though it is not the one anybody complains about.
01Why not start with the process the team complains about most?+
Because complaint tracks unpleasantness, and unpleasantness does not track either value or safety. The job everyone hates is usually the one that is fiddly, high-stakes and infrequent, which is close to the worst possible combination for a first automation. Infrequent means you wait months for enough runs to know whether it works. High-stakes means the first mistake is visible to a customer rather than to a colleague. Fiddly means it is full of exceptions, which is precisely the material that makes a build long and a result disappointing. There is a place for that process, and the place is second or third, after the team has learned how the system behaves and after somebody has watched an exception queue for a few weeks. Starting there is the most common way a first project sours an organization on the whole idea.
02What makes a good first candidate, concretely?+
Four properties, and the first two matter far more than the others. It has to run often, because frequency is what turns a build into evidence: a process that happens forty times a week tells you whether it works within a fortnight, while one that happens twice a month takes a quarter to say anything. It has to fail recoverably, meaning a person can undo the mistake before a customer is affected. It needs a named owner who will actually watch it. And it should touch few enough systems that the integration work does not dominate the schedule. Inbound inquiry routing satisfies all four in most small companies, which is why it so often goes first, and it also produces the kind of number that makes the second project easy to fund.
03Is the first project mostly about the automation or about learning?+
Both, and treating it as only the first is the mistake. The first project is the cheapest opportunity you will get to find out three things that no proposal can tell you: how your team reacts to a system making decisions, how many exceptions your process really produces once someone is counting, and whether the vendor tells you about problems before you find them. Those answers change what the second project should be, and sometimes they change whether there is a second project. This is also why we keep the first one small enough to finish in two to four weeks. A six-month first project is a bet placed before any of the information arrives, and it commits you to a supplier and a design at exactly the moment you know the least.
04What if the obvious first candidate touches money?+
Then split it rather than skipping it, because the part that touches money is rarely the part where the time goes. In an order flow, availability checking, document assembly and dispatch scheduling can be automated while the commitment itself, the price and the terms stay with a person. That gives you the frequency and the time saving without putting an early system in a position to bind the company to something. It is the same rule we apply permanently rather than only at the start: anything binding goes to a human, exceptions route with full context, and every automated decision is logged. Starting with the non-binding portion is not a compromise; it is the design the finished system will have anyway.
Free AI Diagnostic
Fifteen minutes, no email required. It maps where your work actually goes and ranks what is worth automating first.
Start the free diagnosticStarts immediately in the browser.
- Fee
- Free
- Length
- 15 minutes
You keep the ranked list of candidates either way.
