Most automation programmes do not fail on technology. They stall after the first project, because the first project was chosen badly.
The four questions, in order
How often does it run? Frequency is the whole economic argument. A process that runs fifty times a day repays a week of work almost immediately. One that runs quarterly will not repay it this year, however irritating it is.
How much judgement does it need? Little judgement means conventional automation — cheap, fast, predictable. Substantial judgement means an AI step, which is more capable and less certain. For a first project, prefer less judgement. You are proving the approach, not its ceiling.
Who owns it? A process with an owner has someone who can say what "correct" looks like and confirm it is working. A process owned by everyone has nobody to sign it off, and it will drift for weeks in review.
What does it cost when it goes wrong? Low is better for a first project. Not because errors are acceptable, but because a first project should not be the one where the organisation discovers its tolerance for failure.
What people choose instead, and why it goes wrong
The most annoying process. Usually annoying precisely because it is complicated and full of exceptions — the worst possible first build.
The most impressive-sounding one. Long, visible, and by the time it ships everyone has stopped paying attention.
The one the enthusiastic person wants. Sometimes right. Worth checking against the four questions rather than against their enthusiasm.
The shape of a good first project
- Runs many times a day
- Currently done by a person moving data between two systems
- Has an owner who can define "correct" in a sentence
- Is visible enough that people notice when it stops being done manually
- Can be built and proven in days
That last point matters more than it looks. A first project measured in months loses the attention it needs to be adopted.
Map it before you build it
Sit with the person who does the process and watch them do it. Not a description of it — the actual thing.
This step reliably produces two findings. First, the process is not what the documentation says. Second, some steps exist because of a system that was replaced years ago and can simply be deleted.
Deleting a step is the cheapest automation available, and it is free. Do that before writing anything.
How to tell whether it worked
Decide the measure before you start, and make it something you were already tracking. Time from enquiry to first response. Number of records re-keyed by hand. Hours a week on a specific task.
A pilot that ends in "it feels faster" has not proved anything, and the second project will be as hard to get agreed as the first one was.
Questions
- How long should a first automation take?
- Days, not months. If the shortest useful version of the first project is measured in months, the scope is wrong — find the narrower piece inside it that can stand alone.
- What if the process is done differently by different people?
- That is a finding, not an obstacle, and a common one. Automating forces the question of which way is correct — which is frequently worth more than the automation itself.
- Should we automate a broken process or fix it first?
- Fix it, or at least simplify it. Automation applied to a broken process gives you a broken process running faster, and it makes the underlying problem harder to see.
Want this working on your numbers rather than in an article? We scope it on one call.
Book a Consultation Call