Every fulfillment operation runs two workflows: the one on the process diagram, and the one for orders that refuse to follow it. Exceptions are not rare events — addresses fail, stock counts drift, carriers miss pickups and customs holds appear at their own rates. What separates disciplined operations is not zero exceptions; it is a queue with named owners, defined response times and a memory that prevents repeats. This article shows you how to build that queue.
What counts as an exception
An exception is any order that cannot complete the standard loop — inbound, storage, order sync, pick, QC, pack, dispatch, tracking — without a human decision. The definition matters because unmanaged operations treat exceptions as ambient chaos: something is "stuck," somebody messages the warehouse, and resolution depends on who is having the calmest day. A managed operation instead sorts exceptions into categories, because categories are what allow owners, priorities and eventually prevention. The working taxonomy:
| Category | Typical examples | Natural owner |
|---|---|---|
| Data exceptions | Invalid or incomplete address, duplicate order, suspected fraud hold, unmergeable customer edits | Operations or support |
| Inventory exceptions | Oversell against drifted stock, negative balance on a bestseller, ungraded returns blocking resell | Inventory control |
| Fulfillment exceptions | Mis-pick caught at QC, item damaged in storage, kitting component shortage, pack material stockout | Warehouse lead |
| Carrier exceptions | Missed pickup, stalled tracking event, damaged or lost parcel, wrong delivery scan | Logistics |
| Customs and regulatory | Holds for documentation, missing or disputed HS classification, duties unpaid since the de minimis suspension | Compliance or logistics |
| Customer-initiated | Cancel-after-dispatch, address change mid-transit, chargeback with a shipment in flight | Support |
The owners listed are roles, not heroic individuals — the test of a real queue is that an exception assigned to a role is still worked when that person is on holiday.
Designing the queue
A queue is a process, not a shared inbox where good intentions go to drown. Build it in this sequence:
- Detect automatically. Rules catch the predictable classes: address validation failures, orders pending past a time threshold, stock conflicts at sync, tracking events with no movement for a defined number of days. Detection by customer complaint is the most expensive detection that exists.
- Triage on entry. Priority follows promise date, order value and customer impact — an at-risk gift order four days before a deadline outranks a wholesale pallet with a week of slack.
- Assign a named owner. Every open exception has one person accountable for the next action. "The team is looking into it" is not an owner; it is a status that ages.
- Apply two SLAs, not one. First response — a human has acknowledged and is acting — and resolution — the order has an outcome — are different clocks, and conflating them is how queues look responsive while orders rot.
- Resolve from a documented action set. Reship, refund, reroute, contact the customer, correct the data — with the conditions for each pre-agreed, so resolution speed does not depend on improvisation.
- Log the cause code. The closure record names why the exception happened, not just what was done about it.
- Review weekly. Cause codes aggregate into the defect list for the operation, and each recurring cause gets a countermeasure upstream — where the next section takes this.
SLA design that survives busy weeks
SLAs fail in two familiar ways: they are set so generously that nobody respects them, or so absolutely that the first peak week breaks them and their authority dies. Design for the busy week specifically. Set first-response targets in hours and resolution targets by exception class, because an address fix and a lost-parcel claim do not resolve on the same clock. Define an escalation path that triggers on breach automatically — an aged exception moves up to a supervisor without anyone having to notice it first. Make the queue visible in a daily standup during peak: open count, oldest item, what breached yesterday. And kill the phrase "checking with the warehouse" as a status — it means no owner has been assigned, and the queue exists precisely so that sentence never needs saying.
One structural note: the queue belongs to the operation, not to a person. Brands that run fulfillment through a partner still need their own view of the queue — the partner may own warehouse and carrier categories, while the brand owns customer communication and refund decisions. Write the split down. Every unassigned category becomes a ping-pong zone precisely when speed matters most, which is why the split is part of any serious fulfillment setup rather than an afterthought.
The customs exception nobody planned for
Since the $800 de minimis exemption was suspended for all countries effective August 29, 2025 — followed by the CBP rule of June 24, 2026 that moved the suspension onto an indefinite statutory footing and introduced a new entry process for postal shipments effective July 24, 2026 — cross-border parcels generate customs exceptions that used to clear silently. Documentation gaps, disputed classifications and duty-related holds now surface as stalled orders, and a queue with no customs category will misfile them as "stuck tracking" and answer customers wrongly. If any part of your volume ships internationally, the queue needs a customs class with a defined document set, an owner who knows a broker, and customer messaging that does not promise what the clearance process cannot. The policy background is covered in our shipping cluster.
Exceptions as data: the part everyone skips
The queue's output is not just resolved orders — it is the defect list of your operation, and it is the only honest one. A weekly review of cause codes reliably produces the same upstream fixes: address validation turned on at checkout to kill a class of data exceptions; a pack standard rewritten because QC keeps catching the same damage; a carrier program changed because stalled events cluster on one lane; a supplier conversation opened because a defect class repeats across batches. Run this discipline for a quarter and the exception volume itself starts falling — which is the only direction that scales. Brands that skip the review run the same twelve exceptions forever and staff for them permanently. The wider practice of building service levels and feedback loops with a supply chain partner is covered in our growth cluster.
Frequently asked questions
What response time is realistic for order exceptions?+
Realistic means class-specific: first response within hours on business days for at-risk and customer-facing classes, resolution targets set per class — same day for data fixes, days for carrier claims, longer for customs. As a baseline for partner communication, we respond to project inquiries within 24 hours, Monday to Saturday, and operational SLAs are agreed per program in the service agreement rather than left to goodwill.
Who should own exceptions — the brand or the 3PL?+
Split by category rather than by effort: warehouse, inventory and carrier classes sit naturally with the fulfillment partner; customer communication, refunds and policy decisions sit with the brand; customs needs whoever holds the broker relationship. The split must be written down with handoff points, because unwritten splits resolve themselves only slowly and at customer expense.
How do we stop "where is my order" tickets from flooding support?+
Most WISMO volume is a visibility gap rather than a service failure: tracking events not synced to the store, or shipments stuck without anyone chasing them. Fix the sync so customers self-serve, arm support with the same event view, and let the exception queue chase stalled parcels proactively — the tickets that remain are the ones that genuinely need a human.
What should happen when an exception breaches its SLA?+
An automatic escalation with a new owner and a deadline — not a report generated afterwards. Breach data belongs in the weekly review alongside cause codes, because a class that breaches every week is telling you the SLA, the staffing or the upstream process is wrong, and the queue's job is to surface that argument while it is still cheap.
