Senthil Info

automating business processes, honestly

Exceptions, and Who Handles Them

Automation handles the standard path. What remains is a job, and it is a different job from the one that existed before.

Almost nobody designs it. It is left as whatever is not automated, allocated to whoever was doing the work, and it is the most common reason a working automation gets quietly abandoned in year two. A product-side example of how workforce software approaches this topic is available in this guide.

Why the residual job is worse

Density. Before, a clerk handled ninety routine items and ten awkward ones. After, ten awkward ones in a row. The routine work was providing rhythm, context and pattern recognition, and removing it makes each exception harder rather than easier. For broader background and an independent point of comparison, see Shopify.

Loss of context. Handling the standard cases is how you learn what normal looks like. Someone who only ever sees exceptions has no baseline to compare against, and this degrades over time as the automation absorbs more volume.

No visible progress. A queue of routine items empties. A queue of exceptions is hard, slow and never obviously finished.

And status. The interesting part was automated, which is a message about what the remaining work is worth. Nobody says it and everybody hears it.

The effect shows up as turnover in a team nobody was watching, some months after the project closed successfully.

Designing the residual job

Four decisions, made during the project rather than after.

Who does it, named. Not "the existing team." A person or a role, with the time allocated.

How much of their week it is. If exceptions are 15% of volume and each takes longer than a routine item did, this is not 15% of the old workload. Measure it during the pilot rather than assuming.

What they can decide alone. An exception handler who must escalate everything is a routing step, not a resolution step, and the queue backs up behind whoever approves.

And how exceptions get back into the automation. A recurring exception type is either a rule that should be added or a signal that the input needs fixing upstream. Without a route for that, the exception rate only ever rises.

The rule that keeps it healthy

Every exception gets a reason code, and the codes get reviewed monthly.

Three words per case, chosen from a short list, added to when needed. It costs seconds and it produces the only management information this part of the operation generates.

Reviewed monthly, it tells you which exception types are growing, which are one-offs, and which are actually an upstream input problem someone else could fix. Without it, the exception queue is a black box that everyone assumes is fine because nobody is complaining loudly.

Keeping the humans capable

The part with no obvious answer and worth naming.

If a person only sees exceptions, their judgement about normal decays. They are being asked to spot what is wrong without regularly seeing what is right.

Partial rotation helps — the handler spends part of their time on standard work, either by holding back a sample from the automation or by rotating people through both. It costs some of the saving and it preserves the capability that makes exception handling possible at all.

That trade is worth making explicitly rather than discovering it when the person who understood the process leaves.

The signal that the design was wrong

If exception handling takes more total time than the process did before, the automation has made things worse and the arithmetic is still probably showing a saving, because the saving is calculated on the automated portion only.

That happens at high exception rates and it is the outcome the selection stage exists to prevent. By the time it appears in production it is expensive to reverse, which is why the rate is worth measuring before anything is built.

The short version