Which Process Should You Automate First?

Most automation programs do not stop for technical reasons. Usually the first project fails to make the expected impact, the budget for the second never materializes, and the subject drops off the agenda. That makes the choice of the first process more decisive than the choice of platform.

Why the first project matters this much

The first automation does two jobs. It does the work it was asked to do. And, more importantly, it forms the organization's opinion about automation. When management considers the second project, what they hold is not a technical report but an impression: "that worked", or "we put in the effort and not much changed".

So the question to ask when choosing the first project is not "which is our biggest problem" but "which one can we finish quickly and beyond dispute".

Poor candidates for a first project

The organization's biggest headache. The most complained-about process is usually the most complex one. It involves several departments, carries many exceptions, and often has an organizational problem underneath it. It may well need automating, just not first.

A process with no clear owner. If it is unclear who decides, every question that comes up during development requires a meeting, and the project timeline becomes a function of the meeting calendar.

A process that is about to change. If an ERP migration, a regulatory change or a system replacement is being discussed, automating that process creates work that will be rewritten within months.

A process that runs a few times a year. The return comes from repetition. A process that runs four times a year, however tedious, will not cover its development and maintenance cost.

What a good candidate looks like

• High repetition: work that runs daily or weekly
• Rule-based decisions: conditions that can be written down, not "it depends"
• Digital input: data from a system, an email or a structured file
• A named owner: one person who answers when asked
• A measurable output: transaction count, duration or error rate known in advance
• Limited exceptions: a small number of scenarios covering most of the flow

Few processes meet all six. But a candidate that fails four of them is not the right first project.

The phrase "it depends"

This is the most common and most misleading phrase in process interviews. If a step is described as "it depends", that step is not yet ready for automation. The work here comes before automation: clarifying the process itself.

In practice one of two things turns out to be true. Either the rule exists but has never been written down, which is good news. Or the rule genuinely varies from person to person, in which case agreement has to come before automation.

Choosing the process: workshops or data?

There are two methods, and they are not alternatives to one another.

In a workshop you sit down with process owners, draw the flow on a board and estimate volumes. It is quick and sufficient for a small number of processes. Its weakness is that the process described may not be the process lived. People tend to describe a process in its ideal form rather than with its exceptions.

Process mining derives the process from system records instead. It shows how long each step takes, where work waits and how many variations occur. The exception dismissed in the workshop as "rare" often turns out here to cover a substantial share of the work. Its precondition is that the process leaves traces in systems; it is not suitable for a process that runs entirely on email and spreadsheets.

The approach that works well in practice is to start with mining where data exists, then validate the findings with process owners in a workshop.

Set up measurement before you start

The most common mistake on a first project is trying to calculate the benefit after go-live. If the situation before automation was never recorded, there is no number to compare against afterwards, and the discussion runs on impressions.

Three things are worth noting before go-live: how long one transaction takes, the monthly transaction count, and the current error rate. Those three numbers are the strongest argument in the meeting where you ask for the second project's budget.

The short answer

Start with a process that is tedious, repetitive, clearly owned and measurable. The first project's job is not to impress the organization but to demonstrate that automation works. Impressive projects can wait for the second.

If you would like to work out which of your processes fits that description, it is exactly where we start in RPA consulting.