"We want to automate." It is a sentence that arrives every week, and almost always with a process already in mind — usually the one that makes the most noise, not the one with the highest return. The expensive mistake is rarely automating badly: it is automating the wrong thing. This is the honest guide to choosing which processes to automate in a company, which criteria to use to prioritise and, above all, what to leave alone.
Automating is not the goal
It is worth starting with the uncomfortable part: automating is not a goal, it is a tool. The goal is to free up hours, reduce errors or speed up a flow that is holding the business back. If a process does none of those three things measurably, automating it is buying technology to show off, not to win.
That is why the first question is never "can we automate this?" — almost everything can be. The question is "is it worth automating this before that?". And that answer does not come from intuition or from whichever process irritates you most on a Monday: it comes from crossing a handful of concrete criteria.
The six criteria that decide what to automate first
When we diagnose an operation, every candidate process goes through these six filters. None of them rules alone; it is the combination that orders the list.
1. Volume
How many times a day, a week or a month does it happen? Automating something that happens three times a year almost never pays: the cost of building and maintaining far exceeds what you save. Volume is the multiplier for everything else. A saving of two minutes per operation is nothing if it happens ten times a month, but it is a lot of hours if it happens five hundred.
2. Repetitiveness
Is it always the same flow, or is every case its own world? Automation shines on the repetitive and predictable. If every time the process runs it needs different human judgement, contextual reasoning or a new exception, you are not looking at a clean candidate — you are looking at something that, at most, can be assisted, not fully automated.
3. Clear rules
Can you describe the process as a sequence of "if this happens, do that"? If the logic fits in a diagram and the people who run it agree on how it is done, there are clear rules. If every colleague does it differently and nobody can explain why, you first have to tidy up the process, not automate the chaos. Automating a confused process only produces faster confusion.
4. Cost of an error
What happens if the process fails? Sending an internal email wrongly is not the same as miscalculating an invoice or a figure that goes to the tax authority. The cost of an error defines how much robustness, validation and oversight the automation needs, and therefore how much it costs to do it properly. Processes with a low cost of error are ideal to start with: getting it wrong is cheap and you learn fast.
5. Data quality
An automation is only as good as the data feeding it. If the information lives clean and structured in an accessible system, the path is short. If it is spread across PDFs, loose spreadsheets, emails and one person’s head, the real work is not automating: it is tidying up and connecting the data first. It is the number one cause of automation projects that get stuck.
6. Return
The criterion that closes it all. Add up what it costs to build and maintain the automation and compare it with what it saves or generates: hours freed, errors avoided, shorter response times, opportunities no longer lost. If the return does not appear reasonably within a horizon of months, it is not a priority, however beautiful it is technically. We automate only where there is a real return.
The prioritisation matrix: effort against return
With the six criteria on the table, every process boils down to two axes: how much it costs to automate it (effort: technical complexity, data quality, integrations, cost of an error) and how much it gives back (return: volume, hours, errors avoided). Crossing them gives four quadrants that order the investment without boardroom arguments.
| Quadrant | Effort / Return | What to do |
|---|---|---|
| Quick wins | Low effort · High return | Start here. They build confidence, free up hours early and pay for what comes next. |
| Strategic projects | High effort · High return | Plan them in phases. They are worth it, but they need a serious diagnosis and are not improvised. |
| Filler | Low effort · Low return | Do them only if they fall in your lap. Do not move the roadmap for them. |
| Traps | High effort · Low return | Avoid them. They are the ones that excite most in a demo and give back least in production. |
The practical rule is simple: start with the quick wins, use the return they generate to justify and pay for the strategic projects, leave the filler for the gaps and stay away from the traps however flashy they are. Almost all the value of the first few months comes from the top-left quadrant.
What NOT to automate (and why)
A good automation plan is recognised as much by what it discards as by what it executes. These processes are best left out, at least for now:
- Processes you do not yet understand well. If nobody can explain how it works end to end, automating it is freezing the confusion into code. First you map it, then you decide.
- Processes about to change. If the flow is going to be redesigned, the regulation is changing or the tool is being replaced in six months, automating now is building on sand.
- Very low-volume processes. Three times a year does not justify an automation you have to maintain, document and watch over forever.
- Decisions that require human judgement. Negotiating, handling a delicate exception, weighing up an edge case. Well-applied AI assists these decisions; replacing them entirely usually costs dearly in trust and in errors.
- Processes with dirty data and no plan to clean it. Automating on bad data only industrialises the error. Tidying the data is prior work, not optional.
Saying "do not automate this yet" is not a lack of ambition: it is what separates a project that gives money back from one that buries it.
The step almost everyone skips: the diagnosis
Here is the real starting point, and it is the most ignored. Before touching a single tool, you need a real map of how the operation works today: which processes exist, how often they run, who does them, how many hours they consume, where they fail and what data they handle.
Without that map, prioritisation is opinion. With it, the list orders itself almost on its own: the criteria and the matrix stop being theory and fill up with concrete numbers from your business. The diagnosis is what turns "we want to automate" into "we automate this, in this order, for these reasons".
And it has a valuable side effect: often, while mapping, it turns out the problem was not automation at all, but a badly designed process or disordered data. Solving that first usually gives a bigger return than any robot. We diagnose before proposing precisely so as not to sell you an automation you do not need.
Systems you can understand, measure and maintain
There is one last filter we apply to everything that gets automated, and it appears in no matrix: that the result is a system you can understand, measure and maintain. No black box, no shortcuts only the supplier knows how to touch, no vendor lock-in. An automation that saves hours but ties your hands is not an asset: it is a mortgage.
Choosing well what to automate is, in the end, an engineering decision: clear criteria, numbers on the table and honesty about what genuinely pays. If you want to order that list for your operation, starting with a diagnosis that tells you where there is a real return and where there is not, that is exactly what we do in process automation. Tell us how you work today and let us talk about your operation: we will tell you frankly what makes sense to automate and what does not.