Order-routing rules help an online retailer send purchased items to the correct fulfilment location, warehouse queue or supplier. They may consider product identity, available stock, destination, delivery promise and handling requirements. But when an exception occurs, a staff member may manually move the order without explaining why the automated route failed. This can help one customer today while concealing the same configuration or data problem that will affect tomorrow's orders. A useful exception review protects the current order, traces the decision made at the time and identifies whether the lasting correction belongs in source data, routing configuration or an integration.
Identify the intended route for the actual order
Start with the stable order ID and relevant item or variant IDs. Establish the order's delivery address, chosen service, customer promise and approved handling restrictions. Review the routing policy and configuration that applied when the order entered the system, not simply the settings visible at the time of investigation. A rule may have changed after the exception, and applying the current rule retrospectively could create a false diagnosis. Capture the evaluation time and time zone along with the decision or correlation reference where available.
Ask which fulfilment path the business intended and why. Some products can be shipped from several facilities; others must use a specialist site. A split shipment may be legitimate for a mixed basket, while the same split could violate a particular customer promise. Do not infer that the manually selected location was correct merely because somebody used it as a workaround. Confirm intended routing from the authorised commercial and operations rules.
Check the inputs the routing engine actually used
Routing decisions commonly depend on product identifiers, inventory availability, warehouse eligibility, carrier restrictions, fulfilment cut-offs and capacity. Validate the fields in the decision record and identify each authoritative source. A routing engine can apply its rules correctly to wrong or stale stock data. Changing the rule to compensate for inaccurate inventory can then send other orders to unsuitable locations. Separate bad input from defective logic before deciding on a correction.
Inventory terminology matters. Physical on-hand stock, reserved quantity, sellable stock and available-to-promise can differ. A warehouse with units on a shelf may already have promised them to earlier purchases. A fulfilment location may be open but unable to handle a hazardous or oversized item. Document the real eligibility constraints and whether they existed when the decision was made. Avoid inventing arbitrary stock quantities to force a route to accept the order.
Preserve the timeline across asynchronous systems
An order may be accepted by the storefront, queued for routing, submitted to a warehouse and acknowledged later. If the warehouse response is delayed, one screen may show a pending route even while staff at the original location have started picking. Before redirecting, check the authoritative status at the first destination and identify whether any reservation or pick instruction has already been created. A timeout is not proof that the request failed.
Use event identifiers, queue references, timestamps and safe logs to establish the last known state. A normal processing delay should be distinguished from a lost, rejected or duplicate message. Where a supplier owns the destination, confirm the approved support route and what evidence it can provide. Do not repeatedly submit the same fulfilment instruction using new transaction IDs simply to clear the exception banner. The resulting duplicate work can be harder to correct than the original delay.
Categorise exceptions by observable cause
Use categories that help route investigation: unavailable sellable stock, unsupported shipping service, missing product mapping, restricted warehouse capacity, address eligibility, stale location status or integration rejection. Keep an explicit unknown category so staff are not compelled to guess. A broad label such as routing issue does not identify the owner or the safe next check. Record the exact observation and the evidence needed to distinguish competing explanations.
Review patterns by product family, warehouse, carrier, rule version and event window. Several similar orders may reveal one mapping problem, but similarity alone does not prove a shared cause. If incidents increased after a configuration change, preserve that correlation and test whether the same error occurs for unaffected products or locations. Technical analysis should support a controlled decision rather than creating a convenient narrative that blames the last release without proof.
Make manual rerouting an accountable business action
When staff must move an order manually, use the approved operational tool and record the original route, destination, reason, authorised operator, action time and downstream confirmation. Avoid changing raw database fields that bypass reservation or fulfilment controls. Confirm whether the original location still has a pick, label or allocation in progress. Where duplicate processing cannot be ruled out, hold the intervention for qualified reconciliation rather than issuing another instruction immediately.
The routing decision may affect delivery costs, timing, split shipments and customer communications. These are business choices as well as technical operations. Ensure the authorised fulfilment or customer-service owner decides whether the proposed alternative meets the customer's promise. A technician diagnosing the route should not independently commit the retailer to a more expensive shipping service or an unapproved delivery date. Record any temporary override so normal automation does not later undo it or duplicate work.
Keep customer orders and financial state distinct
Payment status, fulfilment reservation and shipment progress are related but separate dimensions. An order marked paid does not mean stock was picked, and a shipping label generated does not necessarily mean a carrier received the parcel. When rerouting, check which events have genuinely occurred. If a customer cancels before an exception is repaired, an old automatic replay should not force fulfilment against the current authorised business decision.
Protect personal and payment information in support records. Use stable internal identifiers and approved diagnostic references rather than copying full customer details across team chats. Refunds, cancellations and adjustments should follow the retailer's authorised process. A routing review can identify the need for a commercial decision but should not silently make it. Where several order lines route differently, preserve each line's identity and the final agreed delivery outcome.
Assign rule changes to the correct owners
Operations owns the commercial routing intent, inventory teams own stock truth, developers or platform administrators own software behaviour, and suppliers may control external warehouses or carrier integrations. Name the relevant owners and the approval path. An exception that repeats frequently may justify changing rules, but the change should be assessed against other products, locations and customers before deployment.
Test representative normal and edge cases. Include a stocked single-item order, an unavailable location, a mixed basket, an unsupported delivery option and a delayed external acknowledgement where applicable. Do not generate live customer transactions or supplier dispatch instructions merely to test routing. Use approved test environments or controlled production checks with appropriate authority. Record which scenarios passed and what remains unverified. A new rule that reduces the exception queue but increases wrong-location dispatches is not an improvement.
Verify the complete downstream outcome
After an approved correction, confirm that the order reached exactly the intended fulfilment path and that reservations or tasks from the previous route were properly handled. Check the receiving warehouse's accepted state rather than assuming that the routing engine's success code proves fulfilment. Reconcile stock implications and ensure customers receive accurate delivery updates. A central integration may recover while individual orders still require manual attention.
For a wider incident, establish the affected time window and review the whole population of orders that might have followed the wrong route. Look for duplicates, stalled allocations, unnecessary split shipments and customer promises requiring correction. Keep these exceptions assigned even after the technical change is closed. The final record should distinguish route restored from order fulfilled; the former is a technical milestone, and the latter is part of the customer outcome.
Measure whether the underlying problem improved
Compare similar order populations before and after the intervention. Assess repeat exception rate, wrong-location picks, manual overrides, unresolved orders and customer impact. A lower queue count is not sufficient if exceptions have simply moved into informal spreadsheets. Consider campaign volume and changing stock conditions when interpreting results. Where an automated rule correctly rejects a genuinely unusual order, retaining a visible exception is preferable to forcing every order through a default path.
Use what the review reveals to improve upstream product setup, inventory synchronisation or supplier mappings. A small, verified correction at the source may be more durable than a large rule change. Keep a record of why an exception was classified, the authorised action and how closure was established. That makes future investigations faster without encouraging operators to apply a copied workaround to a different case.
Develop a sustainable exception-review rhythm
Review meaningful patterns regularly and provide an immediate route for urgent customer-impacting failures. Make the case record concise: actual order, intended route, last confirmed state, evidence, owner, next safe action and downstream outcome. Train staff to recognise uncertain acknowledgements and to stop before duplicating a shipment. Document the supplier support route and approved reconciliation process. The purpose is a reliable workflow that handles legitimate edge cases while revealing avoidable routing failures before they become the normal way of working.
Source A: Shopify developer guidance on webhook delivery verification and duplicates, an example of why a notification requires independent state checks. Source B: Stripe's documented idempotent requests, illustrating provider-specific replay safeguards. Neither source defines an individual retailer's fulfilment rules; the operational comparisons are editorial interpretation.
Order-routing exceptions: correct the record, the rule or the shipment?
The same warning badge may describe stale inventory, an ineligible carrier, a failed mapping or a warehouse acknowledgement that arrived late. These different situations must not all trigger an immediate manual reroute: a warehouse may already have reserved or picked the order. First preserve the order and event identifiers and establish the state at the relevant source.
| Observed exception | What may be wrong | What the responsible team should verify |
|---|---|---|
| Preferred warehouse has no sellable stock | Stock input, reservations or allocation timing. | Authoritative inventory, existing reservations and approved alternative-location policy. |
| Chosen carrier cannot serve the order | Handling constraints, region or chosen delivery promise. | Actual eligibility and business approval before changing carrier or quoted delivery. |
| Variant rejected by destination | Source SKU or transformation mapping. | Stable variant identity and where authoritative product data is corrected. |
| Warehouse acknowledgement timed out | Reply lost after work was accepted. | Destination order state and event references before any replay or reroute. |
| Same override repeatedly required | Underlying data, rule or integration fault. | Pattern by rule version, location and affected orders, followed by controlled test. |
Practical decision: Distinguish an incorrect routing decision from a correctly rejected ineligible route. For an ambiguous response, request downstream confirmation before starting another pick or delivery. A commercial owner must approve changes that affect costs or customer promises. After a fix, check the affected orders for reservations, duplicate instructions and accurate customer updates; a smaller exception queue by itself is not evidence of correct fulfilment.
Source A: Shopify Dev, Ignore duplicate webhooks explains deduplication of incoming delivery events in a specific commerce system. Source B: Stripe, Idempotent requests addresses repeated supported outbound financial API requests, not warehouse-routing rules. They establish the caution around duplicate processing, while routing eligibility is a retailer-specific operational decision. Related image source: the article's Founders Cube workstations photo is attributed under CC BY-SA 4.0; it depicts operational teamwork, not a warehouse or real order. For a more directly technical reference use the linked Shopify webhook documentation without copying its proprietary screenshots.
Frequently asked questions
Should staff manually reroute an order as soon as the first attempt appears delayed?
No. First confirm whether the original warehouse accepted, reserved or began the work. An acknowledgement can be delayed even when processing succeeded.
How can the team distinguish bad routing logic from stale stock data?
Compare the actual rule version and inputs used at decision time with authoritative stock and eligibility records. Correct the source of the error rather than changing unrelated rules.
Which identifiers belong in a routing exception record?
Use the stable order ID, relevant item or variant, original route, decision time, integration event references and downstream confirmation, with customer data limited to approved systems.
Who may approve a more expensive or slower alternative route?
The responsible business or fulfilment owner under the retailer's policy. Technical staff should not promise a revised delivery commitment without authorisation.
What evidence closes a routing exception?
Confirm one intended fulfilment path, correct stock and reservation state, appropriate customer communication and assignment of any remaining order-level exceptions.