A four-part filter for picking your first automation win — and the gut-check that confirms it.
Start with a task that is important, repetitive, boring, and simple enough to run on autopilot — high-volume, well-characterised work you already trust by hand. The everyday "ugh, not this again" reaction is a reliable signal you've found one. Judgement-heavy tasks can be automated too, but they need far more custom development, so they're rarely the right first project.
A good first automation target clears all four bars at once. Miss one and the project gets harder fast:
| Criterion | Why it matters |
|---|---|
| Important | High-volume or on the critical path — so the time you free up actually counts. |
| Repetitive | Run often enough that automation pays back quickly. |
| Boring | Low-judgement steps a machine can follow without interpretation. |
| Simple | Well-characterised and stable, so you're automating a known-good process. |
If a task makes your team groan — "ugh, not this again" — that reflex is a reliable signal. Boring, repetitive, low-judgement work is exactly what should run on autopilot.
The tasks people dread are usually the ones with the clearest rules and the least need for scientific judgement — which is precisely what makes them automatable.
Automation amplifies a good process; it can't rescue a bad one. If a protocol isn't reproducible by a trained person, automating it just produces failures faster. And the stakes of leaving repetitive manual work in place are real:
Stabilise the protocol by hand first, then automate the version that already works. More on why projects fail →
Tasks that need real scientific judgement — interpreting an ambiguous result, deciding the next step — can be automated, but they usually demand significant custom development and a tight feedback loop. They're a great second or third project, once you've banked a reliable win on something boring and simple.
