E-commerce
30 juin 2026
« Vous l'avez en magasin Lyon ? » « Puis-je retirer demain ? » « J'ai acheté online, je retourne en boutique ? » Trois questions, trois canaux, un seul widget chat souvent calibré pour le web pur.
Kn8 rappelle qu'un agent storefront doit lire données produit live : prix, stock, commandes, sans recommander un SKU épuisé (Kn8, agents e-commerce 2026). Denser AI insiste sur requêtes inventaire temps réel via RAG, pas sync batch (Denser, sync stock chatbot 2026).
Ce guide #272 traite le chatbot IA omnicanal : stock magasin, retrait, livraison et retours dans un même parcours conversationnel. Complète disponibilité humaine (#271) et support POS omnicanal avec l'angle automation IA cross-canal, pas macros agents seules.
Sommaire
Pourquoi un bot web-only échoue-t-il en omnicanal ?
Le chatbot omnicanal doit parler locations Shopify, BOPIS et retour magasin, pas seulement WISMO et livraison entrepôt.
Trois échecs typiques
Stock agrégé : « oui disponible » alors que seul l'entrepôt distant a des unités
BOPIS ignoré : online OOS, bot ne propose pas retrait magasin
Retour contradictoire : bot dit « retour web only », policy autorise le magasin
Signal marché
Glance CX : 93 % des consommateurs doivent parfois se répéter en changeant de canal support (Glance CX, 2025). Un bot silo web reproduit la fracture au lieu de la combler.
Exemple DTC 3 boutiques
Bot catalogue standard : 22 % auto-résolution sur intents omnicanal. Bot intents OMNI + lookup location : 41 %, conversion BOPIS assistée +19 %, tickets « renvoi vers magasin » −52 %.
En quoi diffère-t-il des guides support humain voisins ?
Six contenus, six rôles dans la chaîne omnicanale.
Disponibilité humaine (#271)
Stock cross-canal (#271) : protocole agent 7 étapes, macros AVAIL. Le #272 : bot tier 1 lookup location, orientation canal, handoff enrichi.
Click & Collect (#177)
Support BOPIS (#177) : statut retrait post-commande. Le #272 : éligibilité retrait avant checkout et explication règle multi-location.
Support POS omnicanal
Guide POS omnicanal : policies unifiées humaines. Le #272 : intents bot return_in_store, bopis_status, store_stock.
Bot rupture (#245)
Bot OOS (#245) : substitut online. Le #272 intègre oos_channel : magasin OK quand entrepôt OOS.
Handoff (#12)
Handoff bot (#12) : règles générales. Le #272 : payload omnicanal (location, canal commande, promesse stock).
Promesse #272
Matrice intents, flows stock/BOPIS/livraison/retour, templates BOT-OMNI, guardrails inventaire live, KPI, playbooks.
Quelle matrice intents omnicanal automatiser vs handoff ?
La matrice intents bot omnicanal sépare réponses factuelles sûres et dossiers à risque.
Auto (API inventaire + policy KB + confidence ≥ 95 %)
omni_store_stock: qty par location, buffer appliquéomni_bopis_eligibility: retrait possible ou non, pourquoiomni_sfs_option: ship-from-store si entrepôt OOSomni_delivery_vs_pickup: comparer délai/coût canauxomni_return_policy_cross: retour web en magasin selon policyomni_bopis_status: statut commande retrait (lookup order)omni_store_hours: horaires boutique + comptoir retraitomni_nearest_store: liste magasins triés par proximité code postal
Handoff immédiat
omni_stock_dispute: client sur place, site et rayon divergentomni_bopis_litige: commande pas prête, article manquantomni_return_exception: hors délai, final sale, produit utiliséomni_pos_purchase_sav: achat comptoir, garantie complexe
Règle or
Jamais confirmer qty magasin sans appel API location. Si latence sync > 15 min connue, bot ajoute disclaimer « stock indicatif, confirmation sous 15 min ».
Triggers conversation
Activer intents omni_* si message contient : nom de ville boutique, « magasin », « retrait », « click and collect », « en boutique », « sur place », « retourner en magasin ». Croiser avec page contexte : PDP OOS, page magasins, confirmation commande BOPIS.
Quelles données Shopify alimenter le corpus omnicanal ?
Le corpus bot omnicanal combine help center, API live et metafields ops.
Sources API temps réel
InventoryLevel : on-hand par location et variante
Locations : adresse, horaires, rôle fulfillment
Orders : canal, fulfillment location, statut BOPIS
Delivery profiles : shipping vs pickup par zone
Chunks help center obligatoires
Pages : retour web en magasin, délais BOPIS, ship-from-store, buffer stock walk-in. Tag vertical:omnichannel pour retrieval filtré. Aligner wording avec intranet vendeurs POS (éviter contradictions support).
Metafields ops
omni.bopis_prep_hours: délai préparation par magasinomni.store_buffer_qty: unités réservées comptoiromni.sfs_enabled: booléen ship-from-store par location
Sync webhook
Update inventory → invalidation cache bot sous 2 min. Denser : requête RAG au moment de la question, pas batch nocturne (Denser, RAG inventaire live).
Quel flow bot pour le stock magasin en cinq étapes ?
Le flow stock magasin bot reprend la logique #271 en conversation guidée.
Detect intent : ville, SKU, variante mentionnés ou demandés
Lookup API : qty par location, soustraire buffer metafield
Classer scénario : avail_online_oos_store_ok, bopis_blocked, etc.
Proposer canal : lien checkout BOPIS, SFS, ou visite comptoir
Log conversation : location, qty vue, timestamp pour litige
Exemple conversation
Client : « Parka L dispo à Bordeaux ? » Bot : « Au magasin Bordeaux : 2 unités Parka L (stock indicatif). Retrait sous 2 h ou livraison depuis entrepôt J+2. Préférez-vous retrait ou livraison ? » Lien deep-link checkout avec location pré-sélectionnée si Shopify le permet.
Règle Shopify BOPIS
Retrait affiché seulement si une location détient la qty totale de la ligne (Shopify, pickup in store). Bot explique avant frustration checkout.
Quel flow BOPIS et retrait en conversation ?
Le flow BOPIS bot couvre pré-achat et post-commande dans le même widget.
Pré-achat (intent omni_bopis_eligibility)
Confirmer variante et magasin cible
Vérifier qty location ≥ quantité souhaitée
Annoncer délai prep (metafield
bopis_prep_hours)Envoyer lien PDP avec pickup activé ou panier pré-rempli
Post-achat (intent omni_bopis_status)
Lookup order : fulfillment location, statut unfulfilled / ready for pickup / picked up. Réponse : adresse comptoir, horaires jour J, document à apporter. Voir macros BOPIS-STATUS #177 pour alignement wording.
Inspiration Interlinked
Interlinked documente un parcours pickup IA : sélection magasin, délai préparation communiqué, paiement avance optionnel (Interlinked, pickup IA). Adapter : bot annonce fenêtre retrait et cut-off jour même selon policy maison.
Multi-magasin
Si client hésite, bot liste 3 locations les plus proches du code postal avec qty et délai prep triés.
Cut-off et fenêtre retrait
Paramétrer par location : commande avant 14 h → retrait jour même ; après 14 h → J+1. Bot cite cut-off avant envoi lien checkout. Fenêtre conservation commande : 7 j calendaires, rappel J+5 si non retirée (aligné #177).
Trigger widget PDP
Afficher bulle chat si variante online OOS et qty magasin > 0 : « Disponible en retrait à [Ville] ? Demandez au bot. » Taux clic chat sur PDP OOS + stock magasin : +40 à 60 % vs widget passif.
Comment le bot arbitre livraison, SFS et click & collect ?
Le bot arbitrage canal fulfillment recommande l'option la plus rapide ou la moins chère selon intent client.
Arbre décision
Entrepôt OK + urgence faible : livraison standard, ETA dynamique
Entrepôt OOS + magasin proche OK : BOPIS ou SFS selon urgence
Client mentionne « gratuit » : BOPIS si éligible, sinon seuil livraison offerte
Qty > stock location unique : split order expliqué ou livraison partielle
Comparatif conversationnel
« Option 1 : retrait Lyon demain 14 h, 0 € port. Option 2 : livraison J+3, 4,90 €. Option 3 : expédition depuis Paris J+1, 4,90 €. Laquelle choisissez-vous ? »
Shopify Enterprise
L'omnicanal mature combine inventaire unifié POS + online et fulfillment intelligent (Shopify, omnichannel POS 2026). Le bot reflète cette logique, pas un entrepôt fictif unique.
Exemple arbitrage chiffré
Client Paris 75011, sneaker taille 42 : entrepôt 0, boutique Bastille 1, boutique La Défense 3. Bot propose : (1) retrait Bastille 2 h, 0 € ; (2) SFS La Défense J+1, 4,90 € ; (3) alerte retour entrepôt si client préfère attendre. 62 % choisissent retrait Bastille dans ce pattern observé sur 340 conversations test.
Quels messages BOT-OMNI-* injecter par intent ?
Huit templates bot omnicanal alignés macros AVAIL #271.
BOT-OMNI-STOCK
« [SKU] à [Ville] : [X] unité(s) disponible(s) (stock indicatif). Retrait sous [délai] ou livraison [ETA]. Souhaitez-vous le lien commande ? »
BOT-OMNI-OOS-WEB-STORE-OK
« Entrepôt web épuisé. [Ville] a [X] unité(s). Commandez en retrait magasin ou rendez-vous au comptoir. »
BOT-OMNI-BOPIS-BLOCKED
« Retrait indisponible : une boutique doit détenir [N] unités ; [Ville] en a [M]. Alternatives : livraison, autre magasin [liste], retrait partiel. »
BOT-OMNI-SFS
« Expédition depuis [Ville] possible : livraison estimée [date], mêmes frais de port. Je prépare le lien si vous confirmez. »
BOT-OMNI-BOPIS-STATUS
« Commande #[num] | Magasin [Ville] | Statut : [En préparation / Prête]. Comptoir : [adresse]. Horaires aujourd'hui : [X-Y]. »
BOT-OMNI-RETURN-STORE
« Oui, retour commande web en magasin accepté sous [délai] j, état neuf, preuve achat (e-mail ou # commande). Magasins : [liste]. »
BOT-OMNI-RETURN-WEB-ONLY
« Retour en magasin non disponible pour cette commande. Portail retour : [lien]. Délai : [X] j. »
BOT-OMNI-DISCLAIMER-SYNC
« Stock indicatif synchronisé toutes les [X] min. Je confirme la disponibilité au comptoir si vous êtes déjà en magasin. »
Comment gérer retours cross-canal et handoff litige ?
Le bot retour omnicanal cite policy versionnée, jamais mémoire agent isolée.
Flow retour (intent omni_return_policy_cross)
Identifier canal achat : web, POS, marketplace
Vérifier délai, état produit, exceptions soldes
Répondre : magasin accepté oui/non + documents requis
Envoyer lien portail retour web si applicable
Handoff litige stock
Intent omni_stock_dispute : bot collecte SKU, magasin, screenshot optionnel, qty promue par site. Payload ticket : conversation_id, locations_snapshot JSON, heure lookup. Routing file omnichannel_specialist. Voir handoff (#12).
POS achat, question SAV web
Lookup customer par e-mail : historique POS + web. Bot confirme garantie identique si policy l'indique, sinon handoff avec canal achat original.
Payload handoff litige (JSON)
Transmettre au minimum : sku, variant_id, requested_location, qty_api_snapshot, qty_website_displayed, conversation_summary, customer_on_site (bool). Délai annoncé agent : 15 min si client au comptoir, 4 h ouvrées sinon.
Quels guardrails et KPI mesurer chaque mois ?
Les guardrails bot omnicanal protègent contre sur-promesse stock et contradiction POS.
Guardrails interdits
Confirmer stock sans appel API location
Promettre retrait si qty location < ligne commandée
Inventer délai prep hors metafield
Contredire page policy retour magasin
Renvoyer « appelez le magasin » sans lookup préalable
KPI mensuels
Taux résolution intents omni_* : cible > 35 %
Conversion assistée BOPIS : sessions bot → commande retrait
Escalade omni_stock_dispute : volume et délai
Erreurs stock bot : audit 0 tolérance vs POS
CSAT widget omnicanal vs bot web-only
Pack test 30 questions
10 stock location, 8 BOPIS pré/post achat, 5 retour cross-canal, 4 arbitrage livraison/SFS, 3 pièges sur-promesse (bot doit refuser). Seuil go-live : 28/30 exactitude.
Comment Qstomy déploie-t-il le bot omnicanal ?
Qstomy connecte inventaire Shopify multi-location, policies omnicanal et intents OMNI dans un widget unique web + QR magasin.
Capacités
Inventory live : lookup location par variante
Intents omni_* : matrice section 3 + templates BOT-OMNI
Order lookup : BOPIS status cross-canal
Guardrails stock : blocklist sans API confirm
Handoff enrichi : snapshot locations + canal
QR caisse : même bot, historique central
Scénario DTC chiffré
Marque mode, 3 boutiques + DTC, 1 900 conv/mois dont 28 % intents omnicanal. Avant Qstomy OMNI : auto 22 %, 76 litiges stock/trimestre. Après 8 intents + API inventaire + BOT-OMNI : auto 43 %, litiges −61 %, BOPIS assisté +24 %, CSAT omnicanal 4,4/5.
Explorez support client IA, Shopify, demander une démo.
Quels playbooks déployer en deux semaines ?
Playbook 1 : prérequis humains (2 j)
Valider policy retour magasin, buffers location, macros AVAIL #271 live. Sans socle humain, le bot manque de sources.
Playbook 2 : corpus + metafields (2 j)
Pages help omnicanal taggées, metafields bopis_prep et store_buffer sur top locations. Audit contradictions avec POS.
Playbook 3 : intents + API (2 j)
Configurer matrice section 3, connecter InventoryLevel, tester latence < 3 s par lookup.
Playbook 4 : templates BOT-OMNI (1 j)
Importer 8 messages section 8, variables dynamiques ville/qty/délai.
Playbook 5 : pack test 30 (1 j)
Protocole section 10. Corriger guardrails avant 100 % trafic omnicanal.
Playbook 6 : QR magasin + revue hebdo
Affiche comptoir retrait, 10 conversations omni_* / semaine. Maillage : disponibilité (#271), BOPIS (#177), bot OOS (#245), POS omnicanal.
Un bot omnicanal crédible ne remplace pas le magasin : il rend visible la même vérité stock, quel que soit l'écran d'où le client écrit.
Enzo
30 juin 2026
