Order Routing Optimizer

Fulfillment planners decide where each online order ships from: a regional warehouse, a nearby store, or a dropship partner. The wrong node burns margin through premium shipping, late promises, or store labor that should have stayed on the floor. The right node protects the customer promise while keeping landed cost and labor load in balance.

An order routing optimizer scores eligible nodes for every order (or order line set) and recommends a fulfillment source. It is an optimization layer on top of inventory and promise data, not a replacement for the order management system (OMS) or warehouse management system (WMS).

The model recommends a node. Operations still reviews and confirms exceptions: split-ship conflicts, capacity overrides, partner blackouts, and any case where business rules and the score disagree. Routine, high-confidence routes can flow with light oversight; ambiguous or high-cost recommendations stay in a planner queue.

Routing quality collapses when core inputs are missing or stale. Treat these as hard prerequisites, not nice-to-haves.

Inventory position. On-hand and reserved units by SKU at each candidate node, plus known inbound if your policy allows promising against receipt. Soft-available counts that ignore open pick waves or store holds produce false eligibility.

Delivery promise. The customer-facing window (or SLA band) already shown at checkout or held on the order. Route scoring must respect that constraint; a cheaper node that cannot meet the promise is not eligible.

Labor and capacity signals. Store pick capacity, warehouse wave load, and cutoff times. A store with stock but no pick hours is not a free node.

Margin and shipping cost. Item margin after known promotions, plus outbound shipping cost (carrier rate cards or lane estimates) by origin–destination. Without cost, the model cannot trade promise against margin.

Node and partner constraints. Store ship-from-store eligibility, hazmat or oversized rules, dropship lead times, and partner fill-rate history if you use it as a soft penalty.

When inventory position or cost inputs are missing for an order, the model returns empty output for that order (no recommended node). Planners then fall back to the OMS default path or hold the order for manual assignment. Do not invent a route from partial data.

For each order, the system builds a candidate set: nodes with sufficient inventory that can meet the delivery promise under current cutoffs and capacity. Nodes that fail hard constraints drop out before scoring.

Eligible nodes receive a composite score that typically balances:

1. Promise risk — probability or proxy that the node will miss the stated window (distance, cutoff proximity, backlog).
2. Landed cost — shipping cost plus any known handling or transfer cost.
3. Margin impact — contribution after estimated fulfillment cost; prefer nodes that keep contribution above a floor when the promise allows choice.
4. Labor load — soft penalty for stores or DCs already near capacity so the network does not overload one node.
5. Split-ship preference — prefer single-node fulfillment when inventory allows; apply a penalty when a split is required to clear the cart.

Weights are policy choices owned by merchandising and operations. A same-day metro promise will weight promise risk higher; a standard ground order can weight landed cost more heavily. Document the weight set and change it through a controlled release, not ad hoc per planner.

The top-scoring eligible node becomes the recommendation. Secondary candidates stay visible so a planner can override with context the model does not see (local weather, partner dispute, VIP handling).

Automation should clear clean, single-node routes. Humans own the gray area.

Confirm exceptions before commit. When the recommended node differs from the OMS default, when the score gap between first and second is thin, when the order would split across nodes, or when estimated cost exceeds a threshold, send the recommendation to a planner queue. The planner confirms or selects an alternate; the OMS then issues the fulfillment request.

Empty output is a signal. Missing inventory or cost inputs produce no recommendation. Treat that as a data incident for that order, not as “route to nearest warehouse.” Logging empty outputs by SKU and node surfaces feed gaps faster than silent wrong routes.

Override with reason codes. Capture why a planner rejected the model (capacity, customer service request, inventory distrust). Feed those codes into weekly review so weight and constraint bugs get fixed instead of permanently overridden.

Tie to exception handling downstream. Once a node is confirmed, pick failures, carrier misses, and partner short-ships belong to fulfillment exception workflows, not a second routing pass unless the order is reopened.

Start with a shadow period: score every order, log the recommendation next to the actual ship-from node, and do not auto-commit. Compare promise attainment, shipping cost per order, split-ship rate, and store labor hours against the baseline OMS rules.

When agreement is high on routine orders and planners trust the exception queue, enable auto-commit for low-risk segments (for example, single-line in-stock warehouse orders with wide promise windows). Keep store ship-from-store, dropship, and multi-line splits on confirm-first until override rates stabilize.

Refresh rate cards, capacity calendars, and inventory feeds on a schedule that matches your order velocity. A model with yesterday’s inventory will confidently recommend empty shelves. Align pick-path and wave planning at the chosen node so a “cheap” route does not create chaotic store or DC work.

• Delivery Promise Accuracy Model — improves the promise window this router must honor.
• Fulfillment Exception Agent — handles post-commit failures after a node is chosen.
• Pick Path Optimization — reduces labor cost inside the selected store or warehouse once the order arrives.