The first ten automations decide the reputation of the whole programme. Pick well and the sponsor sees bots running, exceptions shrinking and people reclaiming hours within a quarter. Pick badly and the programme is remembered as the thing that took six months to automate a process nobody cared about. The selection method matters more than the platform.
This is the scoring approach we use in discovery sprints. It is deliberately simple. The aim is a ranked list that finance, operations and IT all recognise as fair, built in two to three weeks, not a perfect model.
Start wider than you think.
Most teams arrive with three or four candidates already in mind. Those usually come from whoever complained loudest. Before scoring anything, build a longer list. Walk the process landscape of two or three functions, talk to team leads and the people doing the work, and where the volume justifies it, run task mining on a sample of desktops for a fortnight. Forty to sixty candidates is a normal result for a mid-sized operation.
The long list is where the surprises live. The process that takes the most hours is often one nobody mentioned, because it is spread across many people in small daily doses.
Score on five dimensions.
| Dimension | What you are asking | Score high when |
|---|---|---|
| Volume | How many transactions a month, and how many minutes each | Thousands of transactions, or hundreds of hours |
| Stability | How often the rules, screens or inputs change | Rules unchanged for a year, systems not about to be replaced |
| Data quality | Is the input structured and complete | Fields arrive in a system or a template, not free text |
| System access | Can a bot reach every system in the flow | APIs or stable UIs, credentials available, no hard MFA |
| Business pain | What goes wrong when it is done manually | Errors, delays or compliance findings with a named owner |
Score each from one to five. Weight them if you must, but the unweighted sum works well enough and is easier to defend in a steering meeting. Then add two gates that override the score.
- Process health gate. If the process itself is broken, with rework loops, unclear ownership or steps that exist only because of a past incident, fix it before automating it. A bad process automated is a faster bad process.
- Change gate. If the underlying system is being replaced within twelve months, defer. Building a bot on a screen that is about to disappear is money spent twice.
Why the obvious candidate is often wrong.
The process everyone names first tends to be the most painful one. Painful usually means complex: many exceptions, many systems, judgement in the middle. That makes it a poor first automation. It will take longest to build, surface the most surprises and be hardest to stabilise. By the time it goes live the programme has lost momentum.
The better first candidates are the dull ones. High volume, few exceptions, two or three systems, a clear pass or fail. They go live in weeks, they run every night, and they give the team the operating muscle it needs before tackling the painful process as number six or seven.
Balance the ten.
A good first ten is a portfolio rather than a top-ten list. Aim for a mix that proves different things to different stakeholders.
- Three or four quick wins that can be live in the first six to eight weeks.
- Two or three with a clear financial case, so finance sees payback in the first year.
- One or two that remove a compliance or audit pain, so risk and control functions become allies.
- One that touches a customer-facing outcome, such as turnaround time, so the business sees it as more than back-office efficiency.
- At most one that is hard, chosen because it will teach the team the most.
Write the business case per process, not per programme.
A programme-level number is easy to produce and easy to doubt. A per-process case is harder and far more credible. For each of the ten, record the current effort in hours per month, the share you expect to automate, the build and run cost, and the payback period. Keep the assumptions visible. When one process disappoints, the others stand on their own numbers.
Record the non-financial outcomes too: errors avoided, cycle time, hours released during month-end, audit findings closed. Many sponsors care more about those than about the headcount arithmetic.
The best first automation is the one that is running, unremarkably, every night, three months from now.
A discovery sprint produces exactly this: a scored long list, a balanced first ten, a design sketch for each, and a business case the finance team has already seen. If your programme has a list but no method behind it, that is the place to start.