Name the kinds, because they need different treatment
"Exception" as a single bucket is what produces the unsorted queue. There are four kinds and they go to different places.
- Missing information
- The input genuinely lacks what is needed. Nobody can decide it. Goes back to the sender, and this should be automatic.
- Ambiguous
- Two readings are defensible. Needs judgement, so it goes to a person with the authority to set a precedent.
- Out of policy
- Clear enough, but exceeds a limit. Needs an approver, not an expert, and often a different one.
- Novel
- A shape never seen. Needs an expert, and it is the queue worth reading weekly, because it is where the next automation lives.
Get this classification right and most of the tail routes itself. Missing information in particular is usually the largest group and needs no human at all.
Route with the context attached
An exception arriving as a reference number costs the recipient ten minutes of reconstruction. Most of the cost of exception handling is that reconstruction, not the decision.
- Say why it is here, specifically. "Vendor tax number does not match any account" not "requires review".
- Include what the system already worked out. Partial extraction is still useful.
- Include the nearest matches it rejected, with the reason. This is often the whole decision.
- Include the history: has this vendor, this shape, this sender been an exception before, and what happened last time.
- State what will happen if nothing is done, and by when.
Keep the queue from rotting
- Every queue has a named owner. Not a team, a person, per shift.
- Alert on age, not on depth. Ten items sitting for three days is worse than two hundred cleared daily.
- Set an explicit policy for what happens at the deadline: auto-reject, auto-escalate, or hold. Decide it; do not let it be whatever happens.
- Report the exception rate weekly by category to the business owner. A rate that climbs quietly is the normal way an automation programme dies.
The single most useful meeting we set up on these engagements is a half hour every week reading the novel queue. It is where the next thing to automate is always visible, and it keeps the operators bought in because their input drives the roadmap.
Close the loop back into the system
An exception that is resolved and forgotten will recur. The resolution has to become part of the system, and this is where most programmes stop short.
- Capture the resolution in a structured form, not a free-text note in a ticket.
- Add it to the eval set. It is by definition a hard case with a known answer.
- Ask whether it is a class or a one-off. Three of the same shape in a month is a class and deserves a rule or a prompt change.
- Feed the fix through the normal gate, with the eval delta, like any other change.
Want us to run this with you?
The Audit is this method pointed at your systems, with a costed build plan at the end of it.
Schedule call