Senthil Info

automating business processes, honestly

Volume, Variance, Exceptions

Three numbers determine whether a process is worth automating. Most organisations know the first, guess the second, and have never measured the third — which is the one that decides the outcome.

Volume

How many times a month does this run? For a product-side reference related to workforce operations, Monitask also covers employee attendance tracking software.

The only one people usually have. It is also the least discriminating, because volume alone justifies nothing: a thousand instances of a process with a 40% exception rate is a worse candidate than two hundred clean ones. For broader background and an independent point of comparison, see OECD Digital.

The rough threshold is where the annual hours saved exceed the build plus a year of maintenance. Below a few hundred instances a month, that arithmetic rarely works for anything custom — and maintenance is the line most first-year cases omit.

Variance

How many distinct paths does the process take?

An invoice arriving in one format from one supplier is one path. The same invoice from three hundred suppliers in eleven formats is not high volume — it is eleven processes wearing one name.

Count the paths before counting the instances. A process with four paths and 400 instances is four automations of 100 each, and the fixed cost applies to each.

This is where proposals quietly go wrong: the volume figure is real, and it is spread across a variance nobody counted.

The exception rate

What proportion of instances need a human decision?

The most predictive figure available and the one almost nobody can state. It decides the outcome for a structural reason:

Automation handles the standard path. The exceptions remain, and they are now concentrated.

Before automation, a clerk processing a hundred items handles ninety routine ones and ten awkward ones, and the routine work provides rhythm, context and pattern recognition that makes the awkward ones easier. Afterwards, the same person handles ten awkward items in a row, without the context, in a job that is now entirely exceptions.

That job is harder, slower per item, and worse to do. The saving is real and smaller than the arithmetic suggested, and the residual work has become less pleasant — which shows up later as turnover in a team nobody was watching.

The rough bands

Not thresholds, and useful as orientation.

Under 5% exceptions. Good candidate. The residual is manageable and the automation covers the bulk.

5–15%. Workable, and the exception handling must be designed as part of the project rather than left as what remains.

15–30%. Marginal. Frequently the honest answer is to standardise the inputs first and automate afterwards.

Over 30%. The process is mostly judgement with a clerical wrapper. Automating it produces a handoff and a worse job.

How to measure it without a project

You do not need a system. Take a hundred consecutive instances and mark each: straight through, or human decision required.

A tally sheet for two weeks gives you the number. If a hundred instances take longer than two weeks, that is your volume answer too.

Ask the people doing the work to mark why, in three words, when it is an exception. The reason list is more valuable than the rate: two or three causes usually account for most exceptions, and at least one is normally fixable upstream without any automation at all.

What the number changes

The business case, obviously — the saving applies to the clean proportion only.

The design. At 15% exceptions, exception routing is a first-class part of the build, not an afterthought.

And the decision itself. Fixing the input variance is frequently cheaper than automating around it, and it improves the manual process immediately rather than in nine months.

The short version