The first automation project: how to pick one that will succeed
The first project decides whether there is a second. Seven criteria for choosing it, and the candidates that look attractive and fail.
The short answer
The first automation project in a business decides whether there is a second. A visible win, however modest, builds the appetite, the trust and the skills for larger ones; a visible failure closes the subject for a year. So the first project is chosen for probability of success, not size of prize. Seven criteria pick it: the task is frequent, mostly rule-based, works from clean data, touches one system, carries low stakes, has a clear owner, and can be measured against a baseline. Two or three candidates will fit. The attractive ones that fail are customer-facing, money-adjacent, multi-system or built on messy data.
The seven criteria
| Criterion | Why it matters | Test |
|---|---|---|
| Frequent | Daily volume produces evidence fast and value that adds up | Happens many times a week |
| Rule-heavy | Most cases follow patterns; AI handles the remainder | A person can describe how they decide |
| Clean data | The inputs are consistent and the reference documents current | Someone can show you the source of truth |
| One system | Integration is the expensive part | Inputs and outputs live in one place |
| Low stakes | Mistakes are reversible and internal | Nothing customer-facing with money |
| Clear owner | Someone wants it and will review exceptions | A named person, not a department |
| Measurable | A baseline exists or can be taken in two weeks | You can state today’s time, volume and error rate |
Candidates that usually fit
- Incoming email triage: routing, summarising and drafting first replies for a shared inbox, with a person sending.
- Data extraction from standard documents: invoices, orders, forms, into a system, with mismatches to a person.
- Internal knowledge search on one clean document set: policies, product information.
- Meeting and call summaries into the CRM, reviewed by the attendee.
- Routine report assembly from data that already exists, delivered on a schedule.
Running it so it succeeds
Baseline for two weeks. Scope to the smallest useful version. Build with an evaluation set labelled by the people who do the work. Pilot with a person reviewing most cases and a simple screen to approve or correct. Widen the straight-through lane from the log. Measure at six weeks against the baseline. Tell the story internally with the numbers, and let the team that benefited propose the second project.
What this means for you
Pick the first project to win, not to impress. Frequent, rule-heavy, clean data, one system, low stakes, an owner, a baseline. Run it small and measured, with a person at the gate. The win buys you the second project, and the second project is where the larger returns live.
Frequently asked questions
Should we start with the process that costs us the most?
Usually not. The most expensive process is expensive because it is complicated, and complicated is where first projects die. Start with something frequent and boring that clearly works, learn the pattern with your own data and people, then take the lessons to the expensive one. The second project is faster because of the first.
How long should a first project take?
Weeks, not months: a couple of weeks to baseline and scope, a few weeks to build with evaluation, a few weeks of pilot with a person reviewing. If the plan says six months, the scope is too large for a first project. Cut it until it fits.
What if the first project does not work?
Then you learned about your data, your systems and your people at low cost, which is the point of choosing a small one. Write down why, fix what can be fixed, and choose the next candidate with the seven criteria applied more strictly. A failed first project that cost a few weeks is a good outcome compared with a failed large one.