Exception queues: how to manage by exception instead of by inbox

The problem with the inbox

When problems are discovered through emails, calls and messages, the loudest issue wins attention, not the most important one. Nothing records who has seen it. Items disappear when someone is on leave. A review meeting becomes a search for what went wrong.

What an exception queue is

An exception queue is a list, generated from the operating record, of the items that fall outside what was expected. Each entry names the item, the rule it broke, the owner and the age. It stays on the list until someone resolves it with a recorded reason.

This idea runs through the Kramvyu working pattern: plan the work, execute and capture evidence, review by routing exceptions and approvals to named owners, settle against commercial records, then learn from the exception queues and management reports.

Exceptions worth listing

• Work done but not measured or certified.
• Documents required for closure that have not arrived.
• Approvals waiting beyond an agreed time.
• Items with no owner.
• Quantities that do not match between two records, such as issued and returned material.
• Balances or claims that have stayed open past their due date.
• Stock approaching expiry without a decision.

How to design the rules

Start with the problems that have already cost you money or time. Write each as a plain sentence: when this happens, show it to this person. Keep the first list short. A queue with a hundred rules becomes another inbox.

Give every exception an owner

An unowned exception is only a notice. Route each to a named person, with a deputy if they are away.

Set an expected response time

Decide how long each type may wait before it moves up to the next level of approval. Ageing becomes visible, which is often enough to change behaviour.

Require a reason to close

Closing an exception should record what was decided and why. The history then becomes a learning tool, showing which problems repeat.

Reading the queue in a review

A weekly review can start from the queue: how many items, how old, which owners hold the oldest ones, and which rules fire most often. A rule that fires constantly signals a process that needs fixing at its source, not another reminder.

A short example

Suppose approvals are meant to be completed within two working days. A queue that lists approvals older than that, grouped by approver, tells a manager at a glance where decisions are stuck. It also shows whether one person is overloaded or whether a rule is sending too many routine items upwards. The fix may be a revised limit rather than a reminder, and the queue makes that visible.

Used this way, exceptions are not blame lists. They are a map of where the process needs attention.

What the queue cannot do

A queue is only as good as the record behind it. If evidence is not captured when the work happens, the rules have nothing to test. That is why exception handling and clean records belong together.

Want to see how this applies to your industry? Browse the seven Kramvyu products or book a demo.