Seven questions to ask about how exceptions are routed

An automated process that clears ninety-five percent of items sounds excellent. The other five percent holds all the risk. Those items are the unusual, the ambiguous, and the ones where somebody must decide.

So the quality of an automation shows in how it routes and reviews exceptions. Here are seven questions we would ask, whether you are buying a system or building one.

Why exceptions deserve the scrutiny

The clean path is cheap in any design. A person could do it, a rule could do it, and an agent could do it. The designs differ only on the messy items: who sees them, how fast, with what evidence, and what record is left.

A weak design hides exceptions in a queue nobody owns. A strong design makes each one visible, assigned and timed.

The seven questions

1. How does the system decide that something is an exception?

Ask for the criteria. Some are hard rules, such as a mismatch beyond a stated tolerance. Others are a model's confidence score. If confidence drives the decision, ask who sets the threshold and whether you can change it.

2. Does it say why?

"Needs review" is not a reason. "Invoice price differs from PO by more than your tolerance" is. The reviewer's time depends on how fast they see the cause.

3. Who receives it, and how is that decided?

Exceptions should go to the person who can resolve them, not to a shared inbox. A price variance goes to the buyer. A bank detail change goes to finance. Ask how routing rules are set, and who can edit them.

4. What does the reviewer see?

The reviewer needs the item, the evidence, the proposed action and the history in one view. If they must open three systems to decide, the exception costs more than it should, and some will be approved unread.

5. What happens if nobody acts?

Ask about timers and escalation. An exception that waits for nine days is a close risk. Good designs remind the owner, then escalate to a manager, and report aging to finance.

6. How are decisions recorded?

Each resolution should log who decided, when, on what evidence, and what the outcome was. This is the record that your auditors will want. For a general view of how internal control frameworks think about this, see COSO.

7. Does the system learn from the resolution, and how is that controlled?

If reviewers keep approving the same kind of variance, the system may propose a new rule. That is useful, but a rule change is a control change. Ask who approves it, and whether it is logged like any other policy edit.

What good answers sound like

Good answers are specific and testable. "We route by exception type and cost center, you edit the table, and every edit is logged" can be checked in a demo. "Our AI intelligently routes items" cannot.

Ask the vendor to show you one exception from detection to resolution on your own sample. Watch for steps where someone has to leave the system.

Metrics that tell you it works

• Exception rate: the share of items needing a person.
• Time to first action: how long an exception waits before someone opens it.
• Time to resolution: total age from detection to closure.
• Reversal rate: how often a resolved item is later corrected.
• Reroute rate: how often an exception goes to the wrong owner first.

A falling exception rate with a rising reversal rate means the system is clearing items it should have held. Watch both together.

Where we have seen routing go wrong

The patterns repeat. Routing to a group inbox where each member assumes someone else has it. Routing by amount alone, so a small but strange item sails through. Routing to a person who has left the company, because the table was never updated.

Each has a cheap fix. Name an individual owner and a backup, include conditions beyond amount, and review the table when staff change.

Your next step

Take last month's exceptions and trace five of them from detection to resolution. Note every handoff and every wait. If you cannot trace them, you have already found your first problem.