Create an exception queue for work that cannot proceed through its normal process and needs a decision, missing information, or a special recovery step. Keep each exception attached to the underlying job. Assign one person to pursue its next action and specify when it will be reviewed again.
An exception queue is most useful when problems are currently scattered across messages, sticky notes, and individual memory. It should make the unresolved condition visible without creating a second, competing system for every ordinary task.
Define what belongs in the queue
Write a short intake rule. For a workshop, exceptions might include missing customer specifications, damaged supplied materials, or an unavailable specialist approval. A routine task that is merely waiting its normal turn does not require an exception record unless its expected wait has become a problem.
Atlassian’s Jira Service Management documentation describes queues as filtered views that help people triage and assign requests. That is a useful organizing principle even when a business uses a shared list. The Kanban Guide’s attention to work-item age also helps distinguish a recently blocked item from one that has been unresolved for days.
Keep a direct link to the original order or work record. If several messages describe the same missing material for the same job, combine them into one exception with supporting references. Count unique exceptions, not the number of people asking about them.
Capture enough to enable the next decision
| Field | Specific content |
|---|---|
| Blocked outcome | What cannot proceed and which job it affects. |
| Observed condition | The known problem, separated from an unconfirmed explanation. |
| Impact and deadline | Who is affected and the next commitment at risk. |
| Owner and next action | Who will do what to advance resolution. |
| Opened and next review | When the exception began and when someone will check it. |
| Closure test | The evidence required before normal work can resume. |
“Supplier issue” is too vague. “Order 218 cannot be assembled because two supplied brackets do not match drawing revision C” gives the next person a concrete condition to investigate. Include a photograph or reference number where appropriate, while keeping unnecessary personal information out of the shared view.
Worked example: mismatched brackets
Imagine a hypothetical commercial shelving workshop. A Thursday installation requires brackets that have arrived with a different hole spacing from the approved drawing. The assembly lead records exception E-031 at 10 a.m. Tuesday. The record names the purchasing coordinator as the owner of the next step.
The next action is “confirm by 2 p.m. whether the supplier can deliver matching brackets Wednesday.” The closure test is that the correct parts are physically checked against the approved drawing and released to assembly. A supplier’s promise is progress, but it does not satisfy that closure test.
At 2 p.m., the supplier has confirmed replacement availability but cannot confirm transport. The coordinator updates the record to waiting on delivery confirmation and sets a 4 p.m. review. The installation manager now has enough context to decide whether to prepare an alternative schedule. No one has to reconstruct the issue from four separate chat threads.
Use priority rules tied to consequences
Separate the impact from the urgency. A problem affecting several jobs may have broad impact but a later deadline. A single missing item may need immediate attention because a crew departs shortly. Describe both dimensions before choosing the next exception to work.
For ordinary coordination, use a few understandable priority classes: committed work at immediate risk, near-term work blocked, and investigation needed without a current delivery risk. Safety emergencies and other specialist incidents should follow their established response procedures; a routine queue must not delay those routes.
Choose an escalation point in advance. In the shelving example, lack of transport confirmation by 4 p.m. may require an installation-manager decision. Escalation means a named person must choose among options. Copying more people into the record without a question does not resolve the uncertainty.
Make waiting and closure visible
Review new exceptions, items due for a follow-up, and the oldest unresolved records at a regular operating check. A waiting status needs an external party, an expected response, and a next review time. Otherwise it becomes a parking place for work nobody owns.
Close the record when the defined condition is met and the underlying job is updated. Record any remaining corrective action separately. The correct brackets may release the job today, while a supplier drawing-control improvement takes another week.
Review recurring exception types after enough examples accumulate. A repeated missing-input problem may warrant an intake checklist change. Keep the recovery queue small enough to run daily, then use its history to decide which process defect deserves a permanent fix.
