Which Business Processes Are Suitable for Automation?

Picture two processes. Both run every day, both repeat, both look rule-based. Automate one and the team is relieved; automate the other and six months later everyone has gone back to their old method.

The difference is usually not where it is assumed to be. The most common criterion for picking automation candidates is repetition: this job happens often, so let's automate it. Repetition is a necessary condition, and on its own it guarantees nothing.

What decides the outcome isn't how often a process runs, but how often it steps outside its own definition.

Automation automates one path

An automation speeds up a single defined path. Every case that falls outside it creates a second path: one where somebody has to notice, pull the case out of the system, finish it by hand, and write the result back.

The critical part is that once the second path opens, the cost isn't the sum of the two. It's more. Every case now needs a decision about which path it belongs to, and that decision is a burden separate from the work itself.

This is why the exception rate sets the economics of an automation directly.

In a process producing two percent exceptions, the system genuinely takes the work over; the team never sees ninety-eight of the cases and concentrates on the remaining two. In a process producing thirty percent, nobody can trust the system — every output has to be checked, because the only way to tell which case was handled wrongly is to look. At that point the automation hasn't reduced the work; it has added a layer of supervision on top of it.

The conclusion runs against intuition: a process that runs a thousand times a month with a third of its cases exceptional is a worse candidate than one that runs two hundred times and almost never deviates.

Two thirds of exceptions aren't exceptions

When the exception rate comes out high, the reflex is to conclude the process isn't suitable for automation. That is usually premature, because exceptions are not all of one kind.

Genuine variety. The cases really do differ by the nature of the work: every customer's contract carries different terms, every request needs its own assessment. These exceptions cannot be reduced.

Undefined rules. A rule does exist, but it was never written down. An experienced employee knows what to do; nobody ever asked, so it is recorded nowhere. These stop being exceptions the moment they are written.

Missing data. The case is actually standard, but the information needed to decide isn't in the system, so somebody goes and finds it by hand. Here the problem sits on the input side rather than in the process.

Making that distinction changes the decision. If twenty points of a thirty percent exception rate come from undefined rules, the work to do is not abandoning automation but writing the rules down. This is the concrete form of the simplification step in digital transformation being more than buying software: here, simplifying doesn't mean shortening the process but making an existing decision visible.

Don't estimate the rate — count it

Asked in a meeting, the exception rate always comes back optimistic. Whoever runs the process counts exceptions mentally as part of the job, so they don't register as a separate item.

There is a cheap way to measure it: take the last fifty cases and mark whether each one went down the defined path. That is a few hours of work and produces two things — the real rate, and a list of the exceptions. The second output is usually worth more than the first, because the deviations cluster into a handful of headings and it becomes obvious that some of them can be turned into rules.

Fifty cases are not statistical proof. They are a considerably better basis than "I think it's rare."

It matters that the count is done with whoever actually runs the process. An outsider misses some of the deviations, because the corrections that leave no trace in the records are invisible: missing information settled with a phone call, an amount fixed by hand, a step skipped. Those are precisely where an automation will stumble.

The second axis: where does the time go?

The exception rate tells you whether a process suits automation. Whether the automation will be worth anything is answered by a different measurement: where the time is spent.

The life of a request divides in two. Handling time is the time somebody is actually working on it. Waiting time is the time it sits on a desk, in a queue, or in an approval line.

In most enterprise processes the gap between them is large: eleven minutes of handling, three days of waiting. Automation projects almost always target the first figure, because it is the visible and measurable one. But cutting eleven minutes to four does nothing to the three days.

What shortens waiting is usually not faster handling but the removal of handoffs: something that tells the next step the previous one finished, work in the queue being visible, and cases that need no approval never entering the approval line at all. These are technically simpler and larger in effect.

Automations age

One question almost never gets asked while choosing a candidate: how often do this process's rules change?

An automation freezes the rule as it stood when it was written. When a price band, an approval threshold, a tax rate, a discount policy or the definition of a customer segment changes, the system doesn't learn that by itself. The rule moves on and the automation goes on applying last year's version.

The dangerous part is that this is silent. The system raises no error; it simply performs a now-incorrect job flawlessly. And because nobody has checked it in a long time, the divergence usually surfaces through a customer complaint or an end-of-period reconciliation — which is to say, in the most expensive place.

Two practical consequences follow. First, in a process whose rules change often, the value of an automation depends on those rules not being buried in code: thresholds and rates should sit somewhere they can be updated without a development cycle. Second, every automation needs an owner — if it isn't defined whose job it is to update the system when a rule changes, it is nobody's job.

Partial automation is usually the right answer

The discussion is generally framed as a binary: do we automate this process or not? In practice the third arrangement produces the best results.

The system handles cases on the defined path end to end. It doesn't attempt the ones that don't fit the definition — it recognises them, sets them aside, and routes them to a person. The team hands over seventy percent instead of a hundred, and genuinely looks at the remaining thirty.

For this to work the system has to be able to say "I can't process this case." That capability is the most frequently skipped part of an automation: a system that produces an output for every case produces the wrong output with the same confidence, and noticing takes months.

Partial automation has a second benefit: measurement. The set-aside cases accumulate into a list, and that list shows which rule to define next. Automation then stops being a one-off project and becomes a system whose scope widens in stages.

In closing

The process suited to automation is not the one that repeats most often. It is the one that deviates least.

That distinction explains much of why automation projects produce such different outcomes from similar investment: in a low-exception process the system takes the work over, and in a high-exception one it adds a control burden on top of the work that was already there.

Which makes the selection stage more decisive than the build stage — and a few hours of counting can change a decision worth months of development. In our enterprise software and automation work, the first step isn't designing the process but looking at how the last fifty cases actually went.