E-commerce
July 6, 2026
"Why is my package shipping from Lille when I live in Marseille?" "The website says in stock, why two separate packages?" "You have a warehouse in Lyon, why 5 days for delivery?" As soon as a brand distributes its inventory across multiple nodes, the customer sees a single promise, while behind the scenes, automatic routing, split shipment, and warehouse priorities are at play and never explained to them.
Shopify documents four default order routing rules: minimize split shipments, stay within the destination market, ship from the closest warehouse, and rank locations by priority (Shopify Help, order routing 2026). ShipBob points out that a well-routed multi-warehouse network can reduce last-mile costs and improve perceived delivery times (ShipBob, multi-warehouse 2026).
This guide #324 covers multi-warehouse inventory customer support: availability, lead times, split shipments, and routing disputes. Distinct from out of stock (#106), display errors (#319), and in-store vs online (#271): this focuses on multi-node logistics complexity from the customer's perspective.
Summary
Why does multi-warehouse generate tickets that single-site stock does not?
With a single warehouse, "in stock" means one thing. With three nodes, the same label hides an invisible distribution: 40 units in Paris, 0 in Bordeaux, 12 in transit to Lyon. The customer thinks in terms of global availability; your OMS thinks in terms of location, routing, and zone cost.
Four multi-warehouse customer friction points
Opaque shipment origin: package shipped from far away even though a warehouse seems "local"
Split shipment: two packages, two dates, a single order
Variable ETA by region: same SKU, different delivery times depending on the customer's zip code
Network phantom stock: total OK, but no single node covers the ordered quantity
Typical volume
For a DTC store with 2 to 5 active locations, expect 7% to 15% of stock/delivery tickets to be related to routing or multi-node availability once the second warehouse is opened. Goflow notes that without a centralized system, multi-warehouse management quickly becomes a logistical nightmare for both the team and the customer (Goflow, multiple warehouses 2026).
Principle #324
Pipeline MWSTOCK-LOOP: customer question → qualify MWSTOCK-INTENT → read location inventory → explain with MWSTOCK-POLICY → offer option (wait, split, partial cancel) → log for ops.
Convert over 2,000 customers on average per month with Qstomy.
The world’s 1st Shopify AI dedicated to customer conversion
Empowering 200+ e-commerce merchants
How does it differ from out of stock #106, stock errors #319, and bot #325?
Five stock contents, five levels of complexity.
General OOS (#106)
Out of stock (#106): alternatives, alerts, waiting for replenishment. #324: stock exists elsewhere in the network or routing creates delay without global stockout.
Display errors (#319)
Displayed stock (#319): overselling, sync lag. #324: correct display but misunderstood multi-node logistics behavior.
Store vs online (#271)
Cross-channel availability (#271): boutique vs web. #324: warehouses and 3PL, not walk-in POS.
Bot shipping
Shipping bot: ETA and shipping fees. #324: human customer service policy when the customer disputes the origin or the split.
Multi-warehouse bot (#325)
Multi-warehouse bot (#325): automated MW-BOT-FLOW execution of #324 policies. #324 sets up MWSTOCK-POLICY, macros, and split protocols that the bot executes.
Promise #324
MWSTOCK-INTENT, MWSTOCK-POLICY, MWSTOCK-DISPLAY, MWSTOCK-ROUTING, MWSTOCK-SPLIT, MWSTOCK-FALLBACK, macros, multi-node KPIs.
Which MWSTOCK-INTENT taxonomy should be used to route multi-warehouse tickets?
The MWSTOCK-INTENT taxonomy classifies inquiries before inventory lookup.
10 multi-warehouse intents
mw_avail_pdp: "is it available?" without specifying a locationmw_eta_by_region: lead time according to postal code or customer countrymw_split_shipment: why multiple packages / different datesmw_wrong_origin: package shipped from far away, local warehouse assumedmw_partial_node_oos: out of stock at one node, stock available elsewheremw_qty_network_block: network total insufficient for cart qtymw_routing_delay: order assigned to a slow warehousemw_market_hold: EU stock blocked, UK customer or vice versamw_transfer_pending: stock in transit between warehousesmw_compensation_routing: gesture after delay or unanticipated split
Customer Service Prioritization
P1: mw_partial_node_oos paid order not shipped. P2: mw_split_shipment post-purchase surprise. P3: mw_avail_pdp pre-purchase. Tag multi_warehouse separated from stockout_general (#106) for routing analytics.
What should the internal MWSTOCK-POLICY document contain?
The MWSTOCK-POLICY document aligns support, ops, and merchandising on what can be promised to the customer.
14 policy blocks
Location list: customer-facing name, city, role (web, retail, 3PL)
PDP stock display: aggregated qty vs binary "available"
Shopify order routing rules: order of the 4 active rules
Split shipment: allowed yes/no, max package count threshold
Split communication: auto-email D+0 or silence until shipping
ETA by zone: matrix of origin warehouse × customer zone
Node stockout fallback: adjacent warehouse, hold, partial cancellation
Safety stock buffer: hidden qty online by location
Separate markets: UK vs EU stock non-interchangeable
Agent SLA response: inventory lookup within 4 business hours
Routing compensation: gesture if delay > X days vs checkout promise
Agent restriction: promising origin warehouse without verifying fulfillment
Ops escalation: if recurring routing is contested on a SKU
Owner: support collects, ops validates routing change
Shopify routing reminder
Shopify recommends ranking "minimize split fulfillments" as high priority, and "ship from closest" often as a tie-breaker (Shopify, shipping routing 2026). Documenting this order in MWSTOCK-POLICY prevents support from promising a "close" warehouse that the algorithm will not choose.
How to explain availability with MWSTOCK-DISPLAY?
The MWSTOCK-DISPLAY protocol defines what the agent (or site) says based on the authorized level of detail.
Three display levels
Level 1 public: "In stock" / "Out of stock" network aggregated qty
Level 2 agent pre-purchase: "Available, shipping from our {region} warehouse, estimated delivery {date}"
Level 3 post-order auth: assigned fulfillment location + tracking per parcel
Intent mw_avail_pdp
Request SKU or product link + desired qty
Inventory lookup across all web-enabled locations
If aggregated qty >= demand: confirm available + customer zone ETA via section 4 matrix
If aggregated OK but no single node covers: warn of potential split before purchase if policy requires
If aggregated < demand: partial stockout, propose max qty or restocking alert (#106)
Intent mw_eta_by_region
Input: customer postal code + time + probable warehouse cutoff (closest warehouse with stock). Output: "Ordered before {cutoff} from {ville_entrepôt}: estimated receipt {date_concrète}." Avoid vague "3-5 business days". SafetyCulture recommends unified visibility to reduce blind spots between sites (SafetyCulture, multi-warehouse 2026).
Support prohibitions
Never say "we have 47 in stock in Paris" if the policy prohibits disclosing qty per location (competition, security). Say "available for fast shipping from our Île-de-France hub".
How to respond when the package does not leave the "logical" warehouse?
The MWSTOCK-ROUTING protocol translates order routing logic into customer language without OMS jargon.
Intent mw_wrong_origin
Auth order number
Read fulfillment location(s) assigned in Shopify admin
Cross-reference with active MWSTOCK-POLICY rules
Explain probable cause among: minimize split, market rule, out of stock at nearby warehouse, ranked location (priority 3PL)
Provide actual ETA from the effective warehouse, not the assumed warehouse
Agent template messages
Minimize split: "Your order includes 3 items. To ensure you receive them in a single package, we are shipping from {ville} where all three are available. A closer warehouse only had partial stock." Closest with partial stock: "Item A is shipping from {ville_A}, item B from {ville_B} to meet our deadlines. You will receive two separate tracking numbers."
When the customer insists on a local warehouse
If order is unshipped and policy allows: escalate to ops with routing_reassign_request. If already in transit: explain technical impossibility, offer a delivery gesture if delay > checkout promise. Shopify Smart Order Routing calculates address-to-warehouse distance automatically (Shopify, smart routing 2026): support does not "choose" the warehouse manually without ops.
Intent mw_market_hold
Stock reserved for destination market: "Your address is in {pays}. Our {autre_pays} stocks cannot be shipped to you due to customs/VAT compliance. Shipping from {hub_market}." Link to pre-purchase delivery FAQs if there are customs questions.
How to manage split shipments with MWSTOCK-SPLIT?
The MWSTOCK-SPLIT protocol structures communication when an order becomes N packages.
Intent mw_split_shipment
Order authorization
List fulfillments and tracking by line
Identify cause: multi-location stock, weight/volume, mixed preorder, partial backorder
Communicate package-by-package schedule with concrete dates
Offer cancellation of unshipped lines if customer refuses post-purchase split (according to policy)
Pre-purchase prevention
If MWSTOCK-POLICY requires transparency: checkout message "Your cart may be shipped in {n} packages depending on warehouse availability". Ecommerce Times recommends only allowing the split if the customer has explicitly accepted it, otherwise hold and proactive communication (Ecommerce Times, multi-node 2026).
Email and split macros
Macro MW-SPLIT-01: "Package 1/2 shipped on {date1}, tracking {track1}. Package 2/2 scheduled on {date2}. Reason: items stored in two hubs to minimize your total delivery time." Always include active tracking link per package.
Dispute "I wanted a single package"
If split not announced at checkout and routing compensation policy is active: delivery commercial gesture for package 2 or -X% code according to matrix #324 section 4. Log mw_compensation_routing for ops review: should the minimize split rule be adjusted?
What should be done when a warehouse is out of stock but the network still has inventory?
The MWSTOCK-FALLBACK protocol documents the hierarchy when the planned node is out of stock.
Intent mw_partial_node_oos
Detect unfulfillable line on assigned location
Verify qty of other locations (adjacent or network)
Apply fallback policy: reassign, split, hold customer, cancel line
Contact customer before they discover the delay themselves
Fallback type hierarchy
Reassign adjacent warehouse even if shipping zone +1 (cost absorbed by brand)
Split if customer accepted multi-package
Hold + restock ETA nearby warehouse if inter-node transfer < 48 h
Partial or full cancellation with compensation if wait > threshold
Intent mw_transfer_pending
Stock in transit between warehouses: "Your item will arrive at our {ville} hub on {date_transfert}. Customer shipping planned on {date_exp}. Total delay {jours} business days." Do not promise transfer date without WMS confirmation.
Stock errors link #319
If node stockout is due to sync lag and not actual distribution: tag stock_display_error and apply STOCK-DISP-RECOVER (#319), not a simple excuse routing. Critical ops distinction for post-mortem.
Proactivity Klaviyo / Gorgias
Ecommerce Times: automate SMS or email when fallback is triggered, with wait / cancel / split options (Ecommerce Times, stockout escalation 2026).
Which intents should you prioritize according to your multi-warehouse model?
The MWSTOCK segment matrix adapts the deployment policy and macros.
DTC 2 warehouses France
North + South. Dominant intents: mw_wrong_origin, mw_eta_by_region. Activate minimize split + closest tie-breaker. Macro MW-ORIGIN-01 ready.
DTC + 3PL ShipBob / similar
3PL locations are opaque to the customer. Do not name the 3PL unless there is a dispute. Say "our fulfillment center {region}". Intents: mw_split_shipment, mw_routing_delay. ShipBob estimates 13% bottom-line savings via routing algo (ShipBob, distributed inventory 2026).
Multi-market EU + UK
Prioritize mw_market_hold. Inventory is non-fungible post-Brexit. Separate checkout markets. Support never promises cross-market shipping.
Retail brand + web warehouse
Overlap #271: ship-from-store vs warehouse. If ranked locations put web warehouse before stores: explain that store stock is reserved for pickup. Link #271.
Large B2B multi-SKU carts
Frequent mw_qty_network_block intent: 200 units requested, 120 total
Which KPIs to measure for multi-warehouse support?
Measure perceived routing friction, not just overall stock volume.
Monthly MWSTOCK KPIs
mw_ticket_rate: MWSTOCK-INTENT tickets / multi-location orders
mw_split_surprise_rate: unanticipated split tickets checkout / split orders
mw_wrong_origin_rate: origin disputes / multi-node fulfillments
mw_fallback_contact_sla: % of clients proactively contacted before complaint
mw_first_contact_resolution: resolution without ops escalation
mw_compensation_routing_cost: routing-related gestures / affected revenue
mw_eta_accuracy: support-announced ETA vs actual delivery
Benchmarks
Objectif phase 1 (90 days post second warehouse): mw_split_surprise_rate < 8%, mw_first_contact_resolution > 70%. If mw_wrong_origin_rate rises on a SKU: review merchandising allocation, not just support macros. Ecommerce Times: formal review at Day+90 post-multi-node launch with WAZ (weighted average zone) and split rate (Ecommerce Times, KPI 2026).
Weekly Dashboard
Top 5 SKUs by mw_ticket_rate. Word cloud "
How does Qstomy qualify multi-warehouse stock questions?
Qstomy does not replace your Shopify order routing, but automates the MWSTOCK-INTENT qualification, zone ETA, and split explanation.
Capabilities
Route mw_* intents from natural messages
Aggregated inventory reading + order fulfillment locations
Calculated ETA from MWSTOCK-POLICY matrix and cutoff
Split explanation with post-auth tracking by package
Ops payload escalation (order, SKUs, locations, intent)
Compliance with stock qty disclosure prohibition per warehouse if policy requires
Calculated DTC Scenario
Sports brand, 2 FR warehouses + 1 EU 3PL. Before #324: 41 multi-node tickets/month, mw_first_contact_resolution 52%, mw_split_surprise_rate 19%, 2.1 ops escalations/ticket. After MWSTOCK-POLICY + Qstomy (10 weeks): 24 tickets/month, FCR 74%, split surprise 7%, mw_compensation_routing_cost −44%. Stock/delivery CSAT 4.3/5 vs 3.7 before the second hub.
Integration
Sync MWSTOCK-POLICY from knowledge base. See AI customer support, Shopify, demo. Integration grid: multi-warehouse bot (#325).
Which playbooks should be deployed to structure multi-warehouse support?
Playbook 1: 90-day stock ticket audit (3 h)
Export verbatims "warehouse", "parcel", "two shipments", "why so long". Classify MWSTOCK-INTENT. Measure multi-node vs. single-node share.
Playbook 2: MWSTOCK-POLICY + routing doc (1 d)
Write 14 blocks for section 4. Screenshot Shopify order routing rules. Share Notion with support + ops.
Playbook 3: MW macros + ETA matrix (4 h)
8 macros: MW-AVAIL, MW-ETA, MW-SPLIT-01, MW-ORIGIN-01, MW-FALLBACK, MW-MARKET, MW-TRANSFER, MW-COMP. Test 15 role-play scenarios.
Playbook 4: proactive fallback flow (1 week)
Trigger ops → Klaviyo SMS upon warehouse reassignment. Wait/cancel options template. Measure mw_fallback_contact_sla.
Playbook 5: Day+90 multi-node review (2 h)
KPI section 10 vs. baseline pre-second hub. Adjust SKU allocation or minimize split rule if mw_wrong_origin_rate is high.
Useful links
Enzo
July 6, 2026
