A fulfillment exception queue is a separate worklist for orders that have stopped following the normal fulfillment path. Instead of asking support staff to scan every open order, the system flags only the orders that are aging, missing a first carrier scan, partially fulfilled, repeatedly delayed, or outside the supplier’s promised SLA. The goal is to make operational risk visible before the customer has to report it.
The queue should not be another generic “open orders” page. It needs a clear reason for every exception, an age, an owner, a next action and an escalation deadline.
Which orders belong in an exception queue?
| Exception | Trigger example | First question |
|---|---|---|
| Aging order | supplier has not fulfilled within agreed dispatch window | did the supplier accept and reserve the order? |
| No first scan | tracking exists but carrier has not physically scanned the parcel | is the label only pre-advice or was pickup missed? |
| Partial fulfillment | one line or parcel shipped, another remains open | what is still missing and what promise was made to the customer? |
| Supplier SLA breach | dispatch milestone is past due | is this isolated or supplier-wide? |
| Tracking conflict | duplicate, replaced or invalid tracking event | which identifier is authoritative? |
| Carrier exception | parcel is delayed, held, returned or damaged | who owns the carrier account and claim process? |
Separate order age from exception age
An order placed three days ago is not automatically worse than one placed yesterday. A supplier may have a three-business-day dispatch promise for one product and same-day handling for another. The useful clock is therefore the time since the relevant SLA milestone was due.
Store at least four timestamps: customer order time, supplier acceptance time, label creation time and first carrier scan. These let you distinguish a slow supplier from a slow carrier. Without that separation, every late delivery looks like the same problem.
Use reason codes that lead to actions
A reason code should tell the operator what to do next. “Delayed” is too broad. “SUPPLIER_NOT_ACCEPTED”, “LABEL_NO_SCAN”, “LINE_ITEM_BACKORDERED” and “CARRIER_RETURN_TO_SENDER” are much more useful because each can have a different playbook.
- SUPPLIER_NOT_ACCEPTED: verify API/email receipt and supplier stock;
- LABEL_NO_SCAN: ask whether the parcel physically left the warehouse;
- PARTIAL_OPEN: identify missing SKU and promised ship date;
- SLA_BREACH: escalate according to supplier contract;
- TRACKING_CONFLICT: stop customer notifications until the correct number is confirmed;
- CARRIER_EXCEPTION: decide whether supplier, store or customer must act.
Prioritize by customer impact, not just oldest first
An exception queue becomes unmanageable if every record has the same urgency. A useful priority score can consider promised delivery date, order value, customer tier, replacement difficulty, number of days outside SLA and whether the customer has already contacted support.
For example, a $20 accessory that is six hours late may rank below a high-value gift order that has missed a promised delivery date. The scoring model does not need machine learning. A transparent set of weighted rules is easier to audit and tune.
No first scan is not the same as missing tracking
A supplier can create a label while the parcel remains on a warehouse bench. That means a store should avoid using “tracking number received” as the only definition of shipped. First physical carrier scan is a stronger milestone. If numbers themselves are suspect, the controls discussed in the guide to reliable supplier and tracking checks become relevant.
Partial fulfillment needs line-level visibility
Order-level status alone hides partial shipments. If three items were ordered and only two left the supplier, the queue should show the missing SKU, quantity, supplier promise and whether the customer was told. The operator should not have to open a second system to discover which line is still waiting.
The same order may legitimately have several tracking numbers. Treat each package as a separate shipment object linked back to order lines. This avoids replacing the first tracking number when the second parcel finally ships.
Build a supplier SLA score from the queue
- percentage of orders accepted within target;
- percentage dispatched within target;
- median and 95th-percentile time to first carrier scan;
- percentage of orders entering exception status;
- median time to resolve an exception;
- repeat rate for the same exception reason.
These numbers turn supplier conversations from anecdotes into evidence. “We had several late packages” is weak. “8.4% of your orders missed the 24-hour dispatch SLA last month, and 70% of those were label-without-scan cases” is actionable.
When should the customer be contacted?
Not every internal exception requires an alarm email. Contact is most useful when the customer promise has changed, a choice is required, or support can give a meaningful revised plan. A pre-advice label that is six hours old may resolve normally. A parcel still without a scan after the supplier’s dispatch promise has passed should usually trigger investigation before the estimated delivery date becomes misleading.
Carrier claims belong to a different workflow
Once a parcel has entered the carrier network, ownership of a claim may depend on who purchased the shipping label. In many dropshipping setups, the supplier controls the carrier account and must file the claim. The article on dropshipping shipping insurance and carrier claims explains why the store still needs customer-facing responsibility even when it cannot directly open the carrier case.
A practical status model
- Open: rule triggered and no one has reviewed it.
- Investigating: supplier or carrier check in progress.
- Waiting on supplier: next action belongs to supplier; deadline recorded.
- Waiting on customer: substitution, address or other decision required.
- Resolved: order returned to normal flow, refunded, reshipped or closed.
- Root-cause tagged: final reason saved for supplier reporting.
FAQ
Should every late order enter the queue?
Only after a defined milestone is missed. Use supplier- and service-specific SLAs rather than a single universal age.
Can the queue be fully automated?
Detection can be highly automated. Resolution often needs judgment, especially when substitution, refund, customer communication or supplier escalation is involved.
What is the most important field in the queue?
The exception reason plus the next-action deadline. Without those, the queue becomes a static report rather than an operational tool.
admin
Author of practical guides to dropshipping, ecommerce, automation, and growing an online business.