E-commerce
6 juillet 2026
« Pourquoi mon colis part de Lille alors que j'habite Marseille ? » « Le site dit disponible, pourquoi deux colis séparés ? » « Vous avez un entrepôt à Lyon, pourquoi 5 jours de livraison ? » Dès qu'une marque répartit son inventaire sur plusieurs nœuds, le client voit une promesse unique alors que derrière courent routing automatique, split shipment et priorités entrepôt que personne ne lui explique.
Shopify documente quatre règles de order routing par défaut : minimiser les expéditions fractionnées, rester dans le marché destination, expédier depuis l'entrepôt le plus proche, classer les locations par priorité (Shopify Help, order routing 2026). ShipBob rappelle qu'un réseau multi-entrepôts bien routé peut réduire les coûts last-mile et améliorer les délais perçus (ShipBob, multi-warehouse 2026).
Ce guide #324 traite le support client stock multi-entrepôts : disponibilité, délais, split shipment, litiges routing. Distinct de rupture (#106), erreurs affichage (#319) et magasin vs online (#271) : ici la complexité logistique multi-nœuds côté client.
Summary
Pourquoi le multi-entrepôt génère-t-il des tickets que le stock mono-site n'a pas ?
Avec un seul entrepôt, « en stock » veut dire une chose. Avec trois nœuds, la même étiquette cache une répartition invisible : 40 unités à Paris, 0 à Bordeaux, 12 en transit vers Lyon. Le client raisonne en disponibilité globale ; votre OMS raisonne en location, routing et coût zone.
Quatre frictions client multi-entrepôt
Origine expédition opaque : colis parti loin alors qu'un entrepôt semble « local »
Split shipment : deux colis, deux dates, une seule commande
ETA variable par région : même SKU, délai différent selon CP client
Stock fantôme réseau : total OK, aucun nœud seul ne couvre la qty commandée
Volume typique
Sur une boutique DTC avec 2 à 5 locations actives, comptez 7 à 15 % des tickets stock/livraison liés au routing ou à la disponibilité multi-nœuds une fois le second entrepôt ouvert. Goflow note que sans système centralisé, la gestion multi-warehouse devient rapidement un cauchemar logistique pour l'équipe comme pour le client (Goflow, multiple warehouses 2026).
Principe #324
Pipeline MWSTOCK-LOOP : question client → qualifier MWSTOCK-INTENT → lire inventaire locations → expliquer avec MWSTOCK-POLICY → proposer option (attendre, split, annuler partiel) → logger pour ops.
En quoi diffère-t-il de la rupture #106, des erreurs stock #319 et du bot #325 ?
Cinq contenus stock, cinq niveaux de complexité.
Rupture générale (#106)
Rupture (#106) : alternatives, alertes, attente réassort. Le #324 : stock existe ailleurs dans le réseau ou routing crée délai sans rupture globale.
Erreurs affichage (#319)
Stock affiché (#319) : survente, décalage sync. Le #324 : affichage correct mais comportement logistique multi-nœuds mal compris.
Magasin vs online (#271)
Disponibilité cross-canal (#271) : boutique vs web. Le #324 : entrepôts et 3PL, pas POS walk-in.
Bot shipping
Bot livraison : ETA et frais port. Le #324 : policy SAV humaine quand le client conteste l'origine ou le split.
Bot multi-entrepôt (#325)
Bot multi-entrepôt (#325) : exécution automatisée MW-BOT-FLOW des policies #324. Le #324 pose MWSTOCK-POLICY, macros et protocoles split que le bot exécute.
Promesse #324
MWSTOCK-INTENT, MWSTOCK-POLICY, MWSTOCK-DISPLAY, MWSTOCK-ROUTING, MWSTOCK-SPLIT, MWSTOCK-FALLBACK, macros, KPI multi-nœuds.
Quelle taxonomie MWSTOCK-INTENT pour router les tickets multi-entrepôt ?
La taxonomie MWSTOCK-INTENT classe les demandes avant lookup inventaire.
10 intents multi-entrepôt
mw_avail_pdp: « est-ce disponible ? » sans précision lieumw_eta_by_region: délai selon CP ou pays clientmw_split_shipment: pourquoi plusieurs colis / dates différentesmw_wrong_origin: colis expédié loin, entrepôt local supposémw_partial_node_oos: rupture sur un nœud, stock ailleursmw_qty_network_block: total réseau insuffisant pour qty paniermw_routing_delay: commande assignée entrepôt lentmw_market_hold: stock UE bloqué, client UK ou inversemw_transfer_pending: stock en transit inter-entrepôtmw_compensation_routing: geste après délai ou split non anticipé
Priorisation SAV
P1 : mw_partial_node_oos commande payée non expédiée. P2 : mw_split_shipment surprise post-achat. P3 : mw_avail_pdp pré-achat. Tag multi_warehouse séparé de stockout_general (#106) pour analytics routing.
Que doit contenir le document MWSTOCK-POLICY interne ?
Le document MWSTOCK-POLICY aligne support, ops et merchandising sur ce qu'on peut promettre au client.
14 blocs policy
Liste locations : nom client-facing, ville, rôle (web, retail, 3PL)
Affichage stock PDP : qty agrégée vs « disponible » binaire
Règles order routing Shopify : ordre des 4 règles actives
Split shipment : autorisé oui/non, seuil nb colis max
Communication split : email auto J+0 ou silence jusqu'expédition
ETA par zone : matrice entrepôt origine × zone client
Fallback stockout nœud : entrepôt adjacent, hold, annulation partielle
Buffer safety stock : qty masquée online par location
Markets séparés : stock UK vs EU non interchangeable
SLA réponse agent : lookup inventaire sous 4 h ouvrées
Compensation routing : geste si délai > X j vs promesse checkout
Interdit agent : promettre entrepôt origine sans vérifier fulfillment
Escalade ops : si routing récurrent contesté sur un SKU
Owner : support collecte, ops valide changement routing
Rappel Shopify routing
Shopify recommande de classer « minimize split fulfillments » en priorité haute, « ship from closest » souvent en tie-breaker (Shopify, shipping routing 2026). Documenter cet ordre dans MWSTOCK-POLICY évite que le support promette un entrepôt « proche » que l'algo ne choisira pas.
Comment expliquer la disponibilité avec MWSTOCK-DISPLAY ?
Le protocole MWSTOCK-DISPLAY définit ce que l'agent (ou le site) dit selon le niveau de détail autorisé.
Trois niveaux d'affichage
Niveau 1 public : « En stock » / « Rupture » qty agrégée réseau
Niveau 2 pré-achat agent : « Disponible, expédition depuis notre entrepôt {region}, livraison estimée {date} »
Niveau 3 post-commande auth : location fulfillment assignée + tracking par colis
Intent mw_avail_pdp
Demander SKU ou lien produit + qty souhaitée
Lookup inventaire toutes locations web-enabled
Si qty agrégée >= demande : confirmer disponible + ETA zone client via matrice section 4
Si agrégée OK mais aucun nœud seul ne couvre : avertir split possible avant achat si policy l'exige
Si agrégée < demande : rupture partielle, proposer qty max ou alerte réassort (#106)
Intent mw_eta_by_region
Input : CP client + heure + cutoff entrepôt probable (entrepôt le plus proche avec stock). Output : « Commandé avant {cutoff} depuis {ville_entrepôt} : réception estimée {date_concrète}. » Éviter « 3-5 jours ouvrés » vague. SafetyCulture recommande une visibilité unifiée pour réduire les angles morts entre sites (SafetyCulture, multi-warehouse 2026).
Interdit support
Ne jamais dire « nous avons 47 en stock à Paris » si la policy interdit de divulguer qty par location (concurrence, sécurité). Dire « disponible pour expédition rapide depuis notre hub Île-de-France ».
Comment répondre quand le colis ne part pas de l'entrepôt « logique » ?
Le protocole MWSTOCK-ROUTING traduit la logique order routing en langage client sans jargon OMS.
Intent mw_wrong_origin
Auth n° commande
Lire fulfillment location(s) assignée(s) dans Shopify admin
Croiser avec règles MWSTOCK-POLICY actives
Expliquer cause probable parmi : minimize split, market rule, stock épuisé entrepôt proche, ranked location (3PL prioritaire)
Donner ETA réel depuis entrepôt effectif, pas entrepôt supposé
Messages type agent
Minimize split : « Votre commande regroupe 3 articles. Pour vous les recevoir en un seul colis, nous expédions depuis {ville} où les trois sont disponibles. Un entrepôt plus proche n'avait qu'une partie du stock. » Closest avec stock partiel : « L'article A part de {ville_A}, l'article B de {ville_B} pour respecter nos délais. Vous recevrez deux suivis distincts. »
Quand le client insiste sur entrepôt local
Si commande non expédiée et policy le permet : escalade ops routing_reassign_request. Si déjà en transit : expliquer impossibilité technique, proposer geste livraison si délai > promesse checkout. Shopify Smart Order Routing calcule distance adresse-entrepôt automatiquement (Shopify, smart routing 2026) : le support ne « choisit » pas l'entrepôt manuellement sans ops.
Intent mw_market_hold
Stock réservé marché destination : « Votre adresse est en {pays}. Nos stocks {autre_pays} ne sont pas expédiables vers vous pour conformité douanière/TVA. Expédition depuis {hub_market}. » Lier questions livraison pré-achat si questions douane.
Comment gérer le split shipment avec MWSTOCK-SPLIT ?
Le protocole MWSTOCK-SPLIT structure la communication quand une commande devient N colis.
Intent mw_split_shipment
Auth commande
Lister fulfillments et tracking par ligne
Identifier cause : multi-location stock, poids/volume, preorder mixte, backorder partiel
Communiquer calendrier colis par colis avec dates concrètes
Proposer annulation lignes non expédiées si client refuse split post-achat (selon policy)
Prévention pré-achat
Si MWSTOCK-POLICY exige transparence : message checkout « Votre panier peut être expédié en {n} colis selon disponibilité entrepôts ». Ecommerce Times recommande de n'autoriser le split que si le client l'a explicitement accepté, sinon hold et communication proactive (Ecommerce Times, multi-node 2026).
Email et macros split
Macro MW-SPLIT-01 : « Colis 1/2 expédié le {date1}, suivi {track1}. Colis 2/2 prévu le {date2}. Raison : articles stockés dans deux hubs pour minimiser votre délai total. » Toujours inclure lien suivi actif par colis.
Litige « je voulais un seul colis »
Si split non annoncé checkout et policy compensation routing active : geste livraison colis 2 ou code -X % selon matrice #324 section 4. Logger mw_compensation_routing pour revue ops : faut-il ajuster règle minimize split ?
Que faire quand un entrepôt est en rupture mais le réseau a encore du stock ?
Le protocole MWSTOCK-FALLBACK documente la hiérarchie quand le nœud prévu est vide.
Intent mw_partial_node_oos
Détecter ligne non fulfillable sur location assignée
Vérifier qty autres locations (adjacent ou réseau)
Appliquer fallback policy : réassigner, split, hold client, annuler ligne
Contacter client avant qu'il ne découvre le retard seul
Hiérarchie fallback type
Réassigner entrepôt adjacent même si zone shipping +1 (coût absorbé marque)
Split si client a accepté multi-colis
Hold + ETA réappro entrepôt proche si transfert inter-nœuds < 48 h
Annulation partielle ou intégrale avec compensation si attente > seuil
Intent mw_transfer_pending
Stock en transit entre entrepôts : « Votre article arrive à notre hub {ville} le {date_transfert}. Expédition client prévue {date_exp}. Délai total {jours} j ouvrés. » Ne pas promettre date transfert sans confirmation WMS.
Lien erreurs stock #319
Si rupture nœud due à sync lag et non répartition réelle : tag stock_display_error et appliquer STOCK-DISP-RECOVER (#319), pas simple excuse routing. Distinction ops critique pour post-mortem.
Proactivité Klaviyo / Gorgias
Ecommerce Times : automatiser SMS ou email quand fallback déclenché, avec options attendre / annuler / split (Ecommerce Times, stockout escalation 2026).
Quels intents prioriser selon votre modèle multi-entrepôt ?
La matrice segment MWSTOCK adapte le déploiement policy et macros.
DTC 2 entrepôts France
Nord + Sud. Intents dominants : mw_wrong_origin, mw_eta_by_region. Activer minimize split + closest tie-breaker. Macro MW-ORIGIN-01 prête.
DTC + 3PL ShipBob / similar
Locations 3PL opaques pour le client. Ne pas nommer le 3PL sauf litige. Dire « notre centre de préparation {région} ». Intents : mw_split_shipment, mw_routing_delay. ShipBob estime 13 % d'économies bottom-line via routing algo (ShipBob, distributed inventory 2026).
Multi-market EU + UK
Prioriser mw_market_hold. Stock non fungible post-Brexit. Checkout markets séparés. Support ne promet jamais expédition cross-market.
Marque retail + entrepôt web
Chevauchement #271 : ship-from-store vs entrepôt. Si ranked locations met entrepôt web avant magasins : expliquer que le stock magasin est réservé retrait. Lien #271.
Gros paniers B2B multi-SKU
Intent mw_qty_network_block fréquent : 200 unités demandées, 120 réseau total. Proposer livraison partielle ou délai production. Lien wholesale support.
Quels KPI mesurer pour le support multi-entrepôt ?
Mesurez friction routing perçue, pas seulement le volume stock global.
KPI mensuels MWSTOCK
mw_ticket_rate : tickets MWSTOCK-INTENT / commandes multi-location
mw_split_surprise_rate : tickets split non anticipés checkout / commandes splitées
mw_wrong_origin_rate : contestations origine / fulfillments multi-nœuds
mw_fallback_contact_sla : % clients contactés pro activement avant plainte
mw_first_contact_resolution : résolution sans escalade ops
mw_compensation_routing_cost : gestes liés routing / CA concerné
mw_eta_accuracy : ETA annoncé support vs livraison réelle
Benchmarks
Objectif phase 1 (90 j post second entrepôt) : mw_split_surprise_rate < 8 %, mw_first_contact_resolution > 70 %. Si mw_wrong_origin_rate monte sur un SKU : revue allocation merchandising, pas seulement macros support. Ecommerce Times : revue formelle à J+90 post-lancement multi-nœud avec WAZ (weighted average zone) et split rate (Ecommerce Times, KPI 2026).
Dashboard hebdo
Top 5 SKU par mw_ticket_rate. Verbatim cloud « pourquoi Lille / pourquoi 2 colis ». Partager avec ops fulfillment chaque lundi 15 min.
Comment Qstomy qualifie-t-il les questions stock multi-entrepôt ?
Qstomy ne remplace pas votre order routing Shopify, mais automatise qualification MWSTOCK-INTENT, ETA zone et explication split.
Capacités
Router intents mw_* depuis message naturel
Lecture inventaire agrégé + fulfillment locations commande
ETA chiffrée depuis matrice MWSTOCK-POLICY et cutoff
Explication split avec tracking par colis post-auth
Escalade ops payload (order, SKUs, locations, intent)
Respect interdit divulgation qty par entrepôt si policy
Scénario DTC chiffré
Marque sport, 2 entrepôts FR + 1 3PL EU. Avant #324 : 41 tickets multi-nœuds/mois, mw_first_contact_resolution 52 %, mw_split_surprise_rate 19 %, 2,1 escalades ops/ticket. Après MWSTOCK-POLICY + Qstomy (10 semaines) : tickets 24/mois, FCR 74 %, split surprise 7 %, mw_compensation_routing_cost −44 %. CSAT stock/livraison 4,3/5 vs 3,7 avant second hub.
Intégration
Sync MWSTOCK-POLICY depuis base connaissance. Voir support client IA, Shopify, démo. Maillage : bot multi-entrepôt (#325).
Quels playbooks déployer pour structurer le support multi-entrepôt ?
Playbook 1 : audit tickets stock 90 j (3 h)
Export verbatims « entrepôt », « colis », « deux envois », « pourquoi si long ». Classer MWSTOCK-INTENT. Mesurer part multi-nœuds vs mono.
Playbook 2 : MWSTOCK-POLICY + routing doc (1 j)
Rédiger 14 blocs section 4. Capturer écran règles Shopify order routing. Partager Notion support + ops.
Playbook 3 : macros MW + matrice ETA (4 h)
8 macros : MW-AVAIL, MW-ETA, MW-SPLIT-01, MW-ORIGIN-01, MW-FALLBACK, MW-MARKET, MW-TRANSFER, MW-COMP. Tester 15 scénarios role-play.
Playbook 4 : flow proactif fallback (1 semaine)
Trigger ops → Klaviyo SMS quand réassignation entrepôt. Template options attendre/annuler. Mesurer mw_fallback_contact_sla.
Playbook 5 : revue J+90 multi-nœud (2 h)
KPI section 10 vs baseline pré-second hub. Ajuster allocation SKU ou règle minimize split si mw_wrong_origin_rate élevé.
Maillage utile
Enzo
6 juillet 2026
