How to Define Which Business Processes Are Worth Automating

The 2x2 matrix — frequency by complexity

The most useful prioritisation tool we've found for helping SMEs decide what to automate is a simple 2x2. On one axis, frequency — how often the process runs. On the other, complexity — how many consistent rules govern it versus how much judgment it requires.

The quadrant you want to start in is high frequency, low complexity. These are the processes that run daily or weekly, follow the same rules every time, and don't require contextual judgment. Invoice intake. New employee account creation. Inventory threshold alerts. Status update emails. These automate cleanly and the ROI is fast.

Low frequency, low complexity processes can be automated but often aren't worth prioritising. The time saving is small because the process rarely runs. High frequency, high complexity processes are the trickiest — they look like automation candidates because they run often, but the complexity creates edge cases that are expensive to handle correctly. Approach these carefully. Low frequency, high complexity processes should almost never be automated first.

Knowing how to define business processes to automate for operational efficiency means being willing to say 'not this one yet' to processes that don't fit the right quadrant.

Processes you should never automate

This is the section that gets cut from most automation guides because it's commercially inconvenient. Some processes look automatable and aren't.

• Client relationship management. The part of account management that involves reading a client's mood, negotiating scope, or delivering bad news. Automating the administrative scaffolding around these conversations is fine. Automating the conversations themselves is not.
• Novel problem-solving. If a process produces a genuinely different output each time based on contextual factors that change, it isn't rule-based. It requires judgment. Trying to automate judgment leads to systems that are confidently wrong at exactly the worst moments.
• Broken processes. Automating a bad process just runs the bad process faster. Before you automate anything, make sure the process produces the right output when a human does it. If it doesn't, fix the process first.
• Low-volume one-offs. If a task happens twice a year and takes an hour each time, the automation cost will never pay back. Apply the hours to processes that run at volume.

Calculating ROI before committing to build

The ROI calculation for business process automation doesn't need to be complex. A simple version: multiply the average time spent on the process per month by the fully loaded cost per hour of the people doing it. That's your current monthly cost. Then add error correction time and any downstream costs of mistakes. Compare that to the build cost amortised over a reasonable lifetime (three years is a fair assumption for a well-built custom automation) plus an estimate of ongoing maintenance.

If the monthly savings exceed the amortised build and maintenance cost within twelve months, the project has a strong ROI case. If breakeven is beyond eighteen months, look harder at whether the process is the right target or whether the scope can be reduced.

One thing to include that most calculations miss: the value of the human time freed up. If automating a process allows a skilled team member to spend those hours on higher-value work, that opportunity gain belongs in the ROI. It's harder to quantify but it's often larger than the direct cost saving.

Red flags that a process isn't ready for automation

Even high-frequency, low-complexity processes can be bad automation candidates if the underlying conditions aren't right. Watch for these signals before committing to a build.

• No documented process exists. If the process only exists in one person's head and varies based on who's doing it, you don't have a process yet. Document it first, stabilise it, then automate it.
• The process is about to change. Building automation around a process that's being redesigned in the next quarter is wasteful. Automate stable processes, not transitional ones.
• The data inputs are unreliable. Automation is only as good as the data it processes. If the inputs come from inconsistent sources, manual entry with no validation, or external parties with no data discipline, the automation will produce garbage at high speed.
• No one owns the process. If there's no clear owner who understands what correct looks like and can make decisions about edge cases, the automation will have no one to escalate to when something unexpected happens. That leads to silent failures.

These aren't reasons to abandon automation. They're reasons to fix the foundations first. Skipping this step is the most common reason business process automation solutions underdeliver on their expected return.

The AEKIOS take

The businesses that get the most from automation are the ones that approach it with some discipline. They don't automate everything — they automate the right things, in the right order, with a clear sense of what success looks like. We run a process audit as the first step of every engagement, because identifying the right targets is half the work. The build is the easier part.