What Makes a Process Automatable

Most automation failures are decided before any tool is chosen. The wrong process was picked, and no platform recovers from that.

Five properties determine whether a process is a candidate. They are checkable in about twenty minutes, and they are worth checking before a vendor is in the room rather than after. For a product-side reference related to workforce operations, Monitask also covers remote workforce management software.

Reviewed August 9, 2026. For broader background and an independent point of comparison, see BCG AI.

The five

One. The rules are written, or can be. Not "the team knows how to handle it." If nobody can write down what happens in each case, the rules do not exist yet — they live in someone's judgement, and judgement is what automation is worst at.

Two. The inputs arrive in a consistent form. Same fields, same place, same format. A process that begins with "whatever the customer sent" begins with a human classification step, and that step is the process.

Three. The exception rate is low and the exceptions are recognisable. This is the property that decides most projects and the one least often measured. A process with 5% exceptions automates well. One with 30% automates the 70% and leaves a worse job behind.

Four. The volume justifies the build. Automation has a fixed cost that does not scale down. Twelve instances a month rarely repays it, whatever the hourly saving looks like.

Five. The underlying systems are stable. If the screen, the form or the API changes quarterly, you are buying a maintenance obligation rather than a saving.

The test

Take a candidate process and answer, in writing:

How many times a month does it run?

What proportion of instances go straight through with no human decision?

Can you write the rule for the remaining ones on one page?

How often did the systems involved change in the last two years?

And who owns this process today?

If you cannot answer the second question with a number, that is the finding. Most organisations do not know their own exception rate, and it is the single most predictive figure available.

What looks automatable and is not

Four patterns, all common in proposals. The full set is six.

Processes that are mostly judgement with a clerical wrapper. Credit decisions, exception approvals, anything where the visible work is data entry and the actual work is deciding. Automating the wrapper leaves the judgement and adds a handoff.

Processes with high variance in the input. Invoice processing across three hundred suppliers with different formats. Possible, and the cost is in the classification layer rather than in the automation.

Processes that exist because a system is bad. Automating around a broken system entrenches it and makes the eventual replacement harder.

And processes nobody owns. If three departments touch it and none is accountable, the automation project will inherit that ambiguity and stall on decisions nobody can make.

The uncomfortable first question

Should this process exist at all?

A meaningful share of candidate processes are reconciliations, re-keying, and checks that exist because two systems do not talk to each other, or because a control was added after an incident nobody remembers.

Automating those makes them permanent. Eliminating a process beats automating it, always, and it is cheaper — which is why the mapping step matters more than the tool selection.

The test: if this process disappeared tomorrow, what would break? If the honest answer is "nothing, we would notice in three months," you have found something better than an automation candidate.

Where the vendor's interest diverges

Not an accusation — a structural point worth holding.

A vendor is selling a build. A vendor cannot recommend elimination, cannot recommend fixing the upstream system, and cannot easily recommend doing nothing — those are the three answers that produce no engagement.

So the first three questions on this page are ones you have to ask yourself. Nobody in the sales conversation is positioned to ask them for you, and that is worth knowing before you read a proposal's numbers.

The short version

• Five properties: written rules, consistent inputs, low and recognisable exceptions, sufficient volume, stable systems
• The exception rate is the most predictive figure and the one most organisations cannot state
• Judgement work with a clerical wrapper is the commonest false candidate
• Automating around a bad system entrenches it and makes replacement harder
• Ask first whether the process should exist — elimination beats automation and is cheaper
• A vendor cannot recommend elimination, fixing upstream, or doing nothing, so those questions are yours