Guide
What to automate first: how to pick the right process
Most automation projects fail on selection, not execution. Here is a scoring method for ranking candidate processes, the four traps that make teams pick wrong, and what to do with the processes that score badly.
In short
The first process you automate decides whether there is a second one. Pick by score, not by volume of complaints. Frequency multiplied by time per run gives you the raw prize, while error cost, handoff count and rule stability tell you whether the automation will still be right in a year. A boring, frequent, rule-based process with a clear owner beats a painful but rare one every time. The most common mistake is automating the loudest complaint, which is usually a broken process that needs fixing before it needs automating.
The real bottleneck
Selection is where automation projects fail
Teams rarely fail because a workflow could not be built. They fail because the first thing they automated was chosen by whoever complained loudest, or by whichever process looked most impressive in a slide. Six weeks later the automation saves twenty minutes a month, and nobody asks for a second one.
A good first candidate is boring, frequent, rule-based, and owned by someone who will notice when it breaks. It does not have to be strategic. It has to be repetitive enough that the saved hours are visible within a month, and stable enough that the rules will not change under you halfway through the build.
The scoring method
Score every candidate on three factors
The first sets the prize. The other two decide whether you keep it.
Frequency times time per run
A ten-minute task done forty times a week is worth far more than a two-hour task done once a quarter. Multiply before you rank, because intuition consistently overweights how painful a task feels.
Error rate and what an error costs
Processes where a mistake means a wrong invoice, a missed delivery or a lost lead are worth more than the raw time suggests. Automation buys consistency, not only speed.
How stable the rules are
If the rules change every quarter because a person decides case by case, you are automating a moving target. Stable, written rules are the strongest single predictor that an automation survives its first year.
The method
How to run the selection in a week
Five steps. Most of the real work sits in the first two.
- 1
List the processes, not the pain
Write down every repetitive process by name, from the people who perform it. Not what annoys them. What they actually repeat.
- 2
Measure frequency and duration
One week of honest counting beats a month of estimating. People systematically underestimate frequent short tasks and overestimate rare painful ones.
- 3
Score and rank
Multiply frequency by duration for the prize, then adjust for error cost, handoff count and rule stability. Rank the list, then look only at the top three.
- 4
Check each candidate has an owner
Someone has to notice when the automation stops being right. A process nobody owns should not be the first project, no matter how well it scored.
- 5
Automate one, end to end
Ship the top candidate completely, including the failure cases and the notification when a human is needed. A half-automated process is often worse than the manual one.
Four traps
The four ways teams pick the wrong process
Each one is a project that quietly stops.
Automating the loudest complaint
The most painful process is often painful because it is broken, not because it is manual. Automating a broken process only makes the mistakes faster and harder to see.
Starting with the most impressive process
The process that demos well is rarely the one that returns real hours. An impressive first project creates expectations and no measurable result to meet them with.
Automating a process with no stable rules
If the person doing it decides case by case, the rules do not exist yet. Write them down first. Often the writing alone removes half the work before anything is built.
Ignoring the handoffs
A process that crosses three teams and two tools has three conversations to have and two integrations to build. That is fine work, but it is not a first project.
Side by side
A good first candidate vs a bad one
Both feel urgent. Only one of them compounds.
| Dimension | Bad first candidate | Good first candidate |
|---|---|---|
| Frequency | Runs a few times a quarter, painfully. | Runs many times a week, quietly. |
| Rules | Decided case by case by an experienced person. | Written down, or easy to write down in an afternoon. |
| Handoffs | Crosses several teams and tools before it finishes. | Lives mostly inside one team and one or two systems. |
| Visible result | Savings that only show up in an annual review. | Hours back within the first month, visible to the team. |
| Ownership | Everyone touches it, nobody owns it. | One person notices immediately when it goes wrong. |
Frequency
- Bad first candidate
- Runs a few times a quarter, painfully.
- Good first candidate
- Runs many times a week, quietly.
Rules
- Bad first candidate
- Decided case by case by an experienced person.
- Good first candidate
- Written down, or easy to write down in an afternoon.
Handoffs
- Bad first candidate
- Crosses several teams and tools before it finishes.
- Good first candidate
- Lives mostly inside one team and one or two systems.
Visible result
- Bad first candidate
- Savings that only show up in an annual review.
- Good first candidate
- Hours back within the first month, visible to the team.
Ownership
- Bad first candidate
- Everyone touches it, nobody owns it.
- Good first candidate
- One person notices immediately when it goes wrong.
Being honest about it
What to do with the processes that score badly
A low score is not a verdict of never. It usually means the process needs something before it needs automation: rules written down, an owner assigned, or the process itself simplified. Half the time that preparation removes so many steps that the remainder is not worth automating at all, which is a good outcome and a cheap one.
The other honest answer is that some processes should stay manual. Judgment-heavy work at low volume, anything where the exception is more common than the rule, and anything a person does twice a year all cost more to build and maintain than they will ever return. Saying so plainly is part of the job.
Questions we hear about choosing what to automate
Straight answers before the first project starts.
How many processes should we automate at once?
One, completely, before starting a second. A finished automation that handles its own failure cases changes how a team works. Three half-finished ones change nothing and consume the same effort.
How do we measure whether it worked?
Decide the number before you build: runs per week, minutes per run, error rate, or how long a case waits. Measure it for a week before, and the same way a month after. Without a before, every result becomes an opinion.
Can a process be too small to automate?
Yes. If it runs rarely and takes minutes, the build and the maintenance cost more than it returns. Frequency is what makes small tasks worth automating, not the difficulty of the task itself.
What if we already automated the wrong thing?
It is recoverable and very common. Keep it if it still saves something, and run the scoring properly for the next one. The failure mode to avoid is concluding that automation does not work for your business based on one badly chosen project.
Does this mean replacing people?
In the work we do, no. The processes that score well are the repetitive, rule-based parts of a role, not the role itself. The point is giving skilled people back the hours they currently spend re-entering data and chasing status updates.
How do we get started?
A short review of the repetitive processes you run, ranked by frequency, error cost and rule stability. You leave with a ranked shortlist and an honest note on which ones are not worth automating yet.
Not sure which process should go first?
Tell us what your team repeats every week. We will score the candidates with you and tell you which one earns the first project, including when the honest answer is none of them yet.