E-commerce
4 juillet 2026
Un webhook signale qty négative sur votre bestseller. Quatorze commandes sont en survente. Votre équipe découvre l'incident trois heures plus tard, quand les premiers clients écrivent furieux. Entre-temps, deux ont déjà contesté le paiement.
US Tech Automations recommande une alerte immédiate vers la file SAV dès qu'un SKU passe sous zéro, avec order IDs et chemin de résolution suggéré (US Tech, oversell detection 2026). Zipchat estime qu'un bot alternatives bien configuré récupère 35 à 50 % des ventes perdues sur rupture en proposant 2-3 substituts avec raison claire (Zipchat, OOS assistant 2026).
Ce guide #320 traite le chatbot IA pour incidents stock : détection proactive, alternatives, alertes réassort et gestes commerciaux encadrés. Il exécute en conversation la policy erreurs stock (#319), distinct du bot alternatives pré-achat (#245).
Summary
Pourquoi automatiser les incidents stock en bot plutôt qu'en macros seules ?
Un incident stock exige vitesse, cohérence et données live. Les macros humaines excellent sur le ton ; elles échouent quand l'agent doit vérifier inventaire, commande et policy en parallèle sous pression.
Trois avantages bot incident
Latence : contact client en minutes via webhook, pas en heures
Stock live : substituts filtrés qty > 0 avant recommandation (Denser, sync stock 2026)
Geste encadré : code ou refund partiel selon plafonds policy, sans approbation manager à 23 h
Coût de l'attente
Embed360 : contacter sous 2 h après survente limite chargebacks (Embed360 2026). GuruSup montre qu'une carte produit riche (image, variantes, lien achat) convertit les requêtes stock en vente immédiate (GuruSup, stock queries 2026).
Principe #320
Pipeline STOCK-INC-LOOP : détecter (webhook) → alerter client → proposer résolution → appliquer STOCK-COMP bot → logger incident ops.
En quoi diffère-t-il du SAV #319, du bot OOS #245 et de la rupture #106 ?
Quatre contenus stock, quatre rôles complémentaires.
Erreurs stock SAV (#319)
Stock affiché (#319) : STOCK-DISP-RECOVER, matrice STOCK-COMP, macros humaines. Le #320 : exécution automatisée de cette policy en bot.
Bot alternatives (#245)
Alternatives OOS (#245) : substituts pré-achat PDP rupture. Le #320 : incidents post-commande, survente, panier perdu, outreach proactif.
Rupture générale (#106)
Rupture (#106) : scripts SAV humain. Le #320 : triggers webhook et flows bot end-to-end.
Alertes retour (#48)
Alertes (#48) : widget email. Le #320 intègre l'alerte dans le flow incident après échec swap.
Promesse #320
STOCK-INC-INTENT, INCIDENT-TRIGGER, BOT-ALT-RULES, INCIDENT-FLOW, BOT-COMP-GUARD, sync Shopify, KPI bot incident, playbooks.
Quelle taxonomie STOCK-INC-INTENT pour router le bot ?
La taxonomie STOCK-INC-INTENT étend STOCK-DISP (#319) avec intents bot-specific.
10 intents bot incident
inc_oversell_proactive: outreach bot post-webhook qty négativeinc_oversell_inbound: client écrit après email annulationinc_cart_lost: stock épuisé entre panier et checkoutinc_partial_unfulfill: item manquant commande partielleinc_swap_request: client accepte alternativeinc_wait_restock: client choisit attente ETA fermeinc_cancel_refund: annulation + refund intégralinc_comp_claim: demande geste après incidentinc_pdp_oos_live: rupture temps réel pré-achat (bridge #245)inc_low_stock_urgency: qty < 3, urgence légitime
Routing priorité
P1 bot : inc_oversell_proactive et inc_partial_unfulfill. Mode incident : bot bypass file générale, accès order API + refund tool plafonné. CallSphere recommande transparence stock et alternatives si OOS (CallSphere, inventory agent 2026).
Quels triggers INCIDENT-TRIGGER activer côté Shopify ?
Les triggers INCIDENT-TRIGGER lancent le bot avant le ticket humain.
6 webhooks et signaux
inventory_levels/update : qty ≤ 0 ou < buffer → freeze + alerte
orders/create + qty négative post-décrement → inc_oversell_proactive
orders/cancelled motif stock → message proactif clients file d'attente même SKU
Panier abandon + SKU OOS : trigger inc_cart_lost si session active
PDP dwell + stock 0 : proactive alternatives (#245 bridge)
Feed réconciliation drift : qty Shopify ≠ WMS > seuil → mode prudence bot
Outreach proactif type
SMS ou email + lien chat pré-rempli : « Bonjour {first_name}, nous avons un écart stock sur votre commande {order_ref}. Cliquez pour choisir : alternative, attente ou remboursement. » US Tech : alerte CS queue avec order IDs et path refund vs substitution.
Garde-fous trigger
Ne pas spammer si client déjà en conversation active. Max 1 outreach / 24 h / commande. Respect opt-out SMS. Voir instructions bot (#299).
Comment configurer BOT-ALT-RULES pour les alternatives en incident ?
Les BOT-ALT-RULES diffèrent des substituts pré-achat (#245) : ici le client a déjà acheté, l'enjeu est équivalence perçue.
Grille sélection substitut incident
Priorité 1 : mapping manuel
replacement_skus(#245 OOS-MAP)Priorité 2 : même produit autre variante qty > 0
Priorité 3 : même collection, prix ±15 %, attributs identiques
Priorité 4 : Replenit pattern profil client si historique (Replenit, Substitute Agent 2026)
Règles présentation bot
Max 2 options + bouton « autre choix » vers agent. Chaque option : photo, prix delta, raison (« même coupe, coloris proche »). Lien swap one-click si Shopify order edit API disponible. Jamais recommander SKU qty=0 : re-query inventaire avant envoi.
Exemple message swap
« Votre veste bleu M n'est plus disponible. Option 1 : veste navy M, même modèle, livraison identique. Option 2 : veste bleu ciel M. Je peux modifier votre commande {order_ref} immédiatement. »
Comment structurer INCIDENT-FLOW en quatre branches ?
Le flow INCIDENT-FLOW couvre pré-achat et post-commande en moins de 3 minutes mobile.
Branche A : oversell post-paiement
Bot confirme incident + excuse factuelle (pas jargon sync)
Présente 4 options Casekit : attendre ETA, swap, annulation partielle, annulation totale
Exécute choix : order edit, refund partiel ou total (Casekit 2026)
Applique BOT-COMP si branche refund ou attente refusée
Branche B : panier perdu (inc_cart_lost)
« Le stock a changé pendant votre session. Il reste {variant_alt} ou ces 2 alternatives : {alt1}, {alt2}. » Deep link panier pré-rempli.
Branche C : attente réassort
Shoply pattern : capturer email/phone in-chat, déclencher alerte auto au restock (Shoply, back-in-stock bot 2026). ETA obligatoire si promesse ; sinon waitlist sans date.
Branche D : escalade humaine
Montant > plafond COMP, client VIP, 2e incident 12 mois, ton agressif. Handoff avec contexte : order, SKU, options déjà proposées, root cause si connue.
Comment encadrer les gestes commerciaux avec BOT-COMP-GUARD ?
Le module BOT-COMP-GUARD applique STOCK-COMP (#319) sans sur-rembourser. Pattern refund-guard : policy avant appel API paiement (refund-guard, agentic 2026).
7 règles guardrail
Montant refund ≤ paid remaining (partials cumulés)
Code COMP ≤ plafond N1-N4 (#319), génération one-use
Pas de COMP si client choisit swap réussi
Pas de double COMP même incident (order_id lock)
SKU final-sale : refund only, pas swap promo
Raison COMP dans enum policy (oversell, cart_lost, delay)
> seuil manual review → escalade, bot n'exécute pas
Mapping STOCK-COMP → bot
N3 annulation post-paiement : bot propose code -15 % auto si refund choisi. N2 swap : livraison express offerte via note commande. Zipchat : code 5-15 % sur alternative pour convertir (Zipchat 2026). Logger chaque COMP : order_id, tier, montant, agent=bot.
Interdit bot
Refund sans vérification order API. Promettre date réassort sans metafield restock_eta. Créer remise ad hoc hors STOCK-COMP-POLICY.
Quelles instructions system prompt pour le mode incident stock ?
Le mode bot incident active un prompt dédié, distinct du mode vente standard.
Bloc prompt STOCK-INC-MODE
Reconnaître l'erreur stock sans blâmer client ni ops
Toujours query inventaire live avant alternative
Présenter options numérotées, une question à la fois
Citer délai refund (3-5 j ouvrés) si annulation
Escalader si sentiment négatif 2 messages consécutifs
Ne jamais dire « bug informatique » : « écart stock temporaire »
Corpus RAG incident
Chunks : STOCK-COMP-POLICY, OOS-MAP top 100 SKU, macros DISP-* (#319), page /pages/stock-policy. Exclure promos passées et anciens ETA. Refresh corpus J-1 avant soldes ou drop.
Tools bot requis
get_order, get_inventory, list_alternatives, apply_swap, issue_refund (guarded), create_comp_code (guarded), subscribe_restock, log_stock_incident. Lien entraîner bot Shopify, guardrails promesses (#209).
Quels playbooks verticaux mode, beauté et multi-canal ?
Les flows bot incident varient selon catalogue et canaux.
Mode / footwear
Priorité swap variante taille/couleur. BOT-ALT-RULES : grille adjacence tailles. inc_cart_lost fréquent sur tailles uniques. Geste N2 par défaut si swap accepté.
Beauté / drops limités
inc_oversell_proactive massif post-drop. Pas d'attente sans ETA fournisseur. COMP N3 systématique si refund. Lien lancement produit.
Multi-canal DTC + marketplace
Webhook qty négative : bot explique délai sync inter-plateforme si inc_pdp_oos_live. Outreach séparé par canal (email Shopify vs message Amazon géré humain).
Soldes (#318)
Soldes (#318) : activer mode incident J1-J5. Buffer réduit = plus de triggers. Revue BOT-COMP-GUARD plafonds avant ouverture.
Dropshipping
inc_wait_restock interdit sans confirm fournisseur 24 h. Escalade humaine si fournisseur OOS confirmé. Voir dropshipping (#96).
Quels KPI mesurer sur le bot incidents stock ?
Mesurez recovery et containment incident, pas le volume chat brut.
KPI bot mensuels
inc_proactive_sla : % outreach < 15 min post-webhook
inc_bot_containment : incidents résolus sans humain
inc_recover_save_rate : swap ou attente vs refund total
inc_alt_conversion : % swaps acceptés / proposés
inc_comp_cost_bot : montant COMP émis par bot
inc_chargeback_rate : contestations / incidents oversell
inc_csat_post_incident : CSAT conversation incident only
inc_false_alt_rate : alternatives proposées qty=0 (QA, cible 0)
Objectifs DTC type
inc_proactive_sla > 90 %. inc_bot_containment > 55 %. inc_recover_save_rate > 30 %. inc_chargeback_rate < 2 % incidents. Zipchat : 40-55 % abandon panier OOS évité avec alternatives proactives.
Comment Qstomy orchestre-t-il STOCK-INC-LOOP en production ?
Qstomy exécute STOCK-INC-LOOP : webhooks Shopify, outreach proactif, INCIDENT-FLOW, BOT-ALT-RULES et BOT-COMP-GUARD intégrés.
Capacités incident
Mode STOCK-INC-MODE activable par SKU ou globalement
Webhook qty ≤ 0 → file P1 + message client auto
Substituts live depuis OOS-MAP + matching catalogue
Swap commande et refund plafonné via guardrails
Alerte réassort in-chat + trigger Klaviyo
Export incident vers Notion STOCK-ROOT (#319)
Scénario DTC chiffré
Marque skincare, drop mensuel, 3 200 commandes/semaine pic. Avant #320 : 11 oversells/mois, contact moyen 4 h, containment 12 %, 2 chargebacks/trimestre. Après Qstomy STOCK-INC : outreach 8 min médian, containment 61 %, recover_save_rate 34 %, chargebacks 0 sur 6 mois, inc_comp_cost 280 €/mois vs LTV sauvé estimé 4 200 €.
Voir support IA, agent vente, Shopify, démo. Policy humaine : #319.
Quels playbooks pour déployer le bot incident en quatre semaines ?
Playbook 1 : importer policy #319 (4 h)
STOCK-COMP-POLICY, OOS-MAP, macros DISP-*. Configurer BOT-COMP-GUARD plafonds.
Playbook 2 : webhooks + triggers (1 j)
6 signaux section 4. Test staging oversell. Template outreach SMS/email.
Playbook 3 : INCIDENT-FLOW + prompt (4 h)
4 branches section 6. Rédiger STOCK-INC-MODE. 20 tests conversation par intent.
Playbook 4 : pilote 14 j (2 semaines)
Activer sur top 20 SKU à risque. Monitor KPI section 10. QA false_alt_rate.
Playbook 5 : scale + debrief (60 min)
Étendre tous SKU trackés. Revue inc_chargeback_rate. Ajuster BOT-ALT-RULES.
Maillage utile
Cette semaine : simulez un oversell en staging, mesurez le temps entre webhook qty négative et première proposition bot au client test. Si ce délai dépasse 15 minutes, vos INCIDENT-TRIGGER ne sont pas encore production-ready.
Enzo
4 juillet 2026
