When a company decides it should “do more automation,” the list of candidates is usually longer than the capacity to deliver them. Invoice approvals, ticket routing, onboarding, reporting, CRM updates and a dozen local workarounds all have a claim. Choosing the wrong first project does more damage than choosing slowly: it consumes the people who could have delivered a useful change, and it teaches the organization that automation is expensive and inconclusive.
A first project should be important enough to matter and small enough to finish. This framework is a way to rank candidates against that standard, using evidence rather than enthusiasm.
Four questions for every candidate
For each process on the list, answer four questions with numbers where you can and honest ranges where you cannot. The point is not a perfect score. It is to make the comparison visible.
- Frequency: how often does this run in a normal month?
- Effort: how much hands-on time does each instance take, across everyone involved?
- Error cost: what happens when it goes wrong, and how often does that occur?
- Dependency: what else must be true before this can be automated cleanly?
Frequency times effort gives you a rough time cost. Error cost captures the cases that are expensive even when they are rare: a missed payroll change, a ticket that reaches the wrong team for three days, an invoice paid to the wrong entity. Dependency captures hidden work. A process that looks simple often depends on clean master data, a stable approval matrix or an integration that does not yet exist.
Prefer high frequency and low dependency
The strongest first candidates sit in the high-frequency, low-dependency corner. Ticket routing rules, invoice exception queues and standard employee access requests often fit. They happen often enough that improvement is felt quickly, and they can usually be designed without rebuilding the company’s entire system landscape.
Low-frequency, high-dependency work is a poor first project even when the eventual value is large. A full CRM-to-ERP synchronization may be the right third or fourth piece of work. As a first project it tends to expand, because every data mismatch becomes a debate about definitions, ownership and history. Save that debate until the organization has seen a smaller automation succeed.
The first automation should teach the organization how to finish. The later ones can teach it how to be ambitious.
Watch for processes held together by one person
Some work looks small until you notice that only one person can do it. A monthly reconciliation, a customer onboarding checklist or a regulatory extract that lives in someone’s head is a risk as well as a cost. These are good early candidates if the process can be written down. They are poor candidates if the real work is undocumented judgment that nobody has yet described.
The test is simple. Ask that person to walk through the last three cases. If the steps are repeatable and the decisions follow rules, the process can be designed. If every case is a special case, you do not yet have a process. You have a role. Automating a role without first extracting the rules usually produces a brittle workflow that the same person then has to supervise.
Score value against effort, then apply a finish test
A value-versus-effort matrix is useful if both axes are defined. Value is the combination of time recovered, error cost avoided and operational visibility gained. Effort is design time, integration work, data cleanup and the ongoing ownership the process will need. Plot the candidates. The top-left group is the shortlist.
Then apply a finish test to that shortlist. Can this be in use, with real volume, in six to eight weeks? If the honest answer is no, it is not a first project. It may still be the right second project once a narrower slice has been delivered. Ticket routing for one channel is a first project. Rebuilding the entire support model is not.
- A named business owner who will use the result, not only sponsor it.
- A baseline you can measure before and after.
- A scope that can shrink without losing the point of the work.
- No dependency on a system replacement that has not started.
Sequence the rest once the first one is live
After the first automation is running, the ranking should change. You now know more about data quality, about how people handle exceptions and about which integrations are harder than they looked. Re-score the remaining list. Processes that depended on the first piece of work, such as reporting that needs reliable ticket categories, will often move up.
This is also the moment to resist the urge to automate everything that looks similar. A successful invoice exception queue does not automatically mean every finance process should be treated the same way. Use the same four questions. Some work will stay manual because it is infrequent, because the judgment is the product, or because the organization is not ready to own it.
Where to start
Write down no more than eight candidate processes. For each one, estimate monthly volume, minutes of hands-on time, error frequency and the main dependency. Plot them. Choose the highest-value item that can be finished in a short cycle with a named owner and a baseline. Design that one. Leave the rest on the list. A short, finished project does more for the next conversation than a comprehensive programme that is still being scoped.