The hardest part of automation usually isn't building it — it's choosing what to build first. Pick the wrong process and you'll spend weeks for little payoff. Pick the right one and you fund the entire programme with the time it saves.
Here's the framework we use on every first engagement.
Step 1: List the work, not the wishes
Ask each team a single question: “What do you do every week that feels repetitive, manual, and low-judgement?” You're hunting for tasks that are frequent and rule-based — copying data between systems, sorting inboxes, formatting reports, chasing approvals.
Step 2: Score each task on three axes
- Impact — how many hours per week, across how many people, and is there a cost or revenue tie-in?
- Effort — how stable are the rules, how clean is the data, how many systems does it touch?
- Risk — what happens if it's wrong? A misfiled email is low-risk; a wrong invoice posting is not.
Your first project should be high impact, low effort, low risk. Save the high-risk, high-complexity ideas for after you've built trust.
Step 3: Sanity-check the data
Automation lives or dies on the inputs. Before committing, confirm the data the task relies on is accessible, consistent, and reasonably clean. A “simple” automation on top of messy data is not simple.
Step 4: Write the one-line value statement
If you can finish this sentence with real numbers, you've found your first project:
“Automating ___ will save about ___ hours a week and remove ___, with low risk if it fails.”
A quick example
A testing lab we worked with was re-keying instrument readings into reports by hand — hours every day, error-prone, and the same every time. High impact, stable rules, contained risk. It was the obvious first move, and it paid for itself quickly.
Start there. The first win buys you the credibility and the budget for everything after it.