Which processes should you automate first? A matrix for deciding where to start

First: identifying automatable processes is not the same as prioritising them

A business may identify ten, twenty or fifty tasks that could be automated. That does not mean every one of them should become a project.

The guide about which tasks a business can automate answers the question of what possibilities exist.

This guide answers a different question: if I already have several candidates, how do I decide which one deserves to come first?

That distinction matters because a poor choice can produce a technically correct automation that barely saves time, requires constant maintenance or solves a problem that was not a priority.

Before automating: check whether the process is defined well enough

Automating a disorganised process does not automatically make it a good process. In many cases it simply makes the mistakes happen faster.

Before scoring a candidate, you should be able to answer:

• What starts the process? A form, email, date, order, status change or another event.
• What information does it need? The minimum data required to execute it correctly.
• Which steps repeat? Actions that follow a recognisable pattern.
• Where do exceptions appear? Cases that cannot be resolved through the normal workflow.
• Who is responsible? A person should remain accountable for the result.
• How do we know it finished correctly? The result needs a verifiable condition.

If we cannot even describe the process, it is probably too early to automate it.

Automation prioritisation matrix: 6 criteria I would compare

A practical way to avoid decisions based only on intuition is to score every candidate using exactly the same criteria.

1. Impact

How much time, delay, cost or manual work can it reduce? A process that consumes ten hours a week has a different potential impact from one that takes twenty minutes a month.

2. Frequency and volume

How often does it happen? A small task can become a priority if it repeats hundreds of times.

3. Process stability

Are the steps clear and relatively stable? The more stable the workflow, the easier it is to automate without rebuilding it every few weeks.

4. Technical complexity

How many tools need to be connected? Are APIs available? Is the data accessible? Do we need to develop a custom application? Complexity affects cost, delivery time and maintenance.

5. Risk if something fails

Making a mistake when creating an internal task is not the same as automatically sending an incorrect contractual document to a customer. The cost of an error determines how much supervision is needed.

6. Ease of measuring the result

The first automation should allow a before-and-after comparison: time spent, errors, response speed, pending tasks or any other relevant metric.

How to score each process without turning it into an endless analysis

You do not need a complex financial model for an initial comparison. A simple 1-to-3 scale is enough.

With six criteria, the maximum score would be 18. I would not use the total as an automatic decision formula, but as a way to compare candidates using the same framework.

A process scoring 16 may be an excellent place to start. Another scoring 14 may have greater strategic value. The score helps make differences visible; it does not replace business judgement.

Example: three processes that could be automated, but do not have the same priority

Imagine a service business with these three candidates:

This example shows why the easiest process is not always the best y the most painful one does not necessarily need to be first. We are looking for a good combination of value and feasibility.

Impact vs complexity: four types of candidates

High impact + low or medium complexity

This is where I would look for the first opportunities. These are often called “quick wins”, provided the process is stable and the risk is controlled.

High impact + high complexity

It may be an excellent project, but not necessarily the first one. I would try to break it down and find a subprocess with a more controlled scope.

Low impact + low complexity

It can be automated if it requires almost no effort, but it should not displace projects that solve more important problems.

Low impact + high complexity

I would normally leave it out. The technical and maintenance cost is difficult to justify.

Processes I would not prioritise yet

Even when they could technically be automated, I would postpone processes that show several of these signs:

• they change constantly;
• each person carries them out differently;
• they depend on information that is not digitised;
• they have too many exceptions that are difficult to define;
• they require sensitive human decisions in almost every case;
• they involve systems with no technical access or no reasonable integration route;
• they happen so rarely that the saving is minimal;
• there is no clear way to measure whether automation improved anything.

In those cases, it may be better to organise, document or digitise the process before automating it.

What a good first automation should look like

For a business that has not yet worked with automation, I would look for a first implementation with these characteristics:

• a clear trigger;
• few systems involved;
• rules that are easy to explain;
• reversible errors;
• a visible result;
• enough impact for the team to notice the difference;
• the ability to keep supervision during the first few weeks.

A very simple example would be: a form arrives → the contact is registered → a confirmation is sent → a task is created → the responsible person is notified.

It is not the most spectacular automation. That is exactly why it can be a good first test: the process is understandable, measurable and makes it easy to see quickly where it fails.

What to do after automating the first process

Automation does not end when the workflow is switched on. First you need to see what happens in real use.

During the first few weeks, I would review:

• how many times it ran;
• how many runs needed correction;
• which exceptions appeared;
• how much time was actually removed;
• whether the team uses the new workflow correctly;
• whether the result justifies keeping, expanding or modifying the automation.

Only then would I look for the next process. This way, each new automation builds on what was learned from the previous one instead of creating several systems at the same time without knowing which one adds value.

If the objective is to calculate the financial impact of those improvements, the relevant guide is how much a business can save with automation .