E-commerce
3 juillet 2026
« C'était marqué en stock, j'ai payé, et vous m'annulez deux jours plus tard. » « Google Shopping affichait disponible, votre site dit rupture. » « J'ai ajouté au panier pendant qu'il restait une unité, checkout refusé. » Ce ne sont pas des questions rupture classiques : ce sont des erreurs d'affichage stock, où la promesse visible ne correspond pas à l'inventaire réel.
Skulabs estime qu'environ 34 % des retailers e-commerce ont signalé des écarts inventaire menant à la survente en 2024, avec un coût opérationnel de 25 à 75 dollars par commande oversold (Skulabs, coût overselling 2025). Embed360 recommande de contacter le client dans les deux heures après découverte de la survente, avant qu'il ne découvre l'annulation seul (Embed360, overselling 2026).
Ce guide #319 traite le support des erreurs stock affiché : prévenir, expliquer, compenser. Il complète rupture générale (#106) avec l'angle survente, décalage sync et matrice compensation, distinct du bot incidents stock (#320).
Sommaire
Pourquoi une erreur d'affichage stock est-elle plus grave qu'une rupture annoncée ?
Une rupture claire sur la fiche produit crée de la déception. Une erreur d'affichage crée de la trahison perçue : le client a agi sur une information fausse, souvent après paiement.
Trois différences vs rupture transparente
Promesse rompue : « en stock » affiché, commande annulée ensuite
Responsabilité marchand : le client n'a pas ignoré un badge rupture
Risque chargeback : annulation mal expliquée = contestation carte
Coût réel d'un incident
US Tech Automations chiffre un oversell entre 65 et 120 dollars par événement, incluant remboursement, logistique inversée et temps SAV (US Tech, oversell 2026). StockPilot estime 15 à 50 dollars de coûts directs plus 100 à 300 dollars de valeur client perdue sur Shopify (StockPilot, overselling Shopify 2026). PwC via Skulabs : 32 % des clients cessent d'acheter après une seule mauvaise expérience fulfillment.
Principe #319
Pipeline STOCK-DISP-LOOP : prévenir affichage → détecter écart → récupérer client (STOCK-DISP-RECOVER) → compenser (STOCK-COMP) → post-mortem ops.
En quoi diffère-t-il de la rupture #106, du réassort #167 et du bot #320 ?
Quatre contenus voisins, quatre angles stock.
Rupture générale (#106)
Rupture (#106) : alternatives, alertes, scripts OOS honnête. Le #319 : survente et décalage affichage/réel, avec protocole compensation renforcé.
Délais réassort (#167)
Réassort (#167) : ETA et attente client. Le #319 : incident où le stock affiché était faux, pas simple attente.
Bot alternatives OOS
Bot alternatives OOS : reco pré-achat. Le #319 : post-commande oversold et sync multi-canal.
Bot incidents (#320)
Le #319 pose policy SAV, macros et matrice compensation ; voir bot incidents (#320) pour l'exécution automatisée.
Soldes (#318)
Soldes (#318) : pic promo. Le #319 : cause racine sync et affichage, amplifiée en flash sale.
Promesse #319
STOCK-DISP-INTENT, STOCK-DISP-PREVENT, STOCK-DISP-RECOVER, STOCK-COMP, STOCK-ROOT, macros, handoff ops, KPI oversell.
Quelle taxonomie STOCK-DISP-INTENT pour classifier les tickets ?
La taxonomie STOCK-DISP-INTENT distingue erreur affichage de simple question disponibilité.
10 intents erreur stock
disp_oversell_postpay: commande payée, annulation stock insuffisantdisp_checkout_block: panier perdu entre affichage et paiementdisp_pdp_mismatch: « en stock » PDP vs rupture checkoutdisp_marketplace_lag: Google Shopping / Meta vs sitedisp_multichannel: vendu sur Amazon + site, même pool stockdisp_partial_fulfill: commande partielle, item manquantdisp_preorder_confusion: client croyait stock immédiatdisp_qty_wrong: « Plus que 2 » alors que 0 entrepôtdisp_dropship_lag: fournisseur OOS, site encore ouvertdisp_compensation_claim: demande geste après incident
Priorisation SAV
P1 : disp_oversell_postpay et disp_partial_fulfill non expédié. P2 : disp_checkout_block client actif. P3 : disp_marketplace_lag pré-achat. Tag stock_display_error séparé de stockout_general (#106) pour analytics et post-mortem.
Comment prévenir les erreurs d'affichage avec STOCK-DISP-PREVENT ?
Le protocole STOCK-DISP-PREVENT réduit les incidents avant qu'ils n'atteignent le SAV.
8 mesures Shopify DTC
Track quantity activé sur 100 % des SKU vendables
Continue selling when out of stock désactivé sauf précommande documentée
Buffer sécurité : afficher max (stock réel - N), ex. N=2 ou 10 % (Dropioneer, buffer 2026)
Sync multi-canal : push inventaire < 60 s entre canaux (US Tech 2026)
Alerte stock négatif : webhook si qty < 0, file SAV P1
Job réconciliation : comparer projection vs Shopify toutes les 10 min en peak (72Technologies, sync 2026)
Feed Google/Meta : pause SKU OOS, pas de délai 24 h
Test staging : scénario oversell avant BFCM ou drop
UX préventive
Badge « Stock limité » si qty < 5. Compte à rebours réservation panier 15 min. Message checkout si qty change entre panier et paiement. Voir alertes retour stock.
Comment exécuter STOCK-DISP-RECOVER quand la survente est détectée ?
Le protocole STOCK-DISP-RECOVER structure la réponse SAV dans les 2 h après détection ops.
7 étapes recover
Freeze SKU : qty à 0 sur tous canaux, pause ads SKU
Lister commandes impactées : export Shopify unfulfilled + qty négative
Contacter client avant annulation auto : email + SMS si tel, Embed360 règle 2 h
Proposer 4 options : attendre réassort (ETA ferme), swap, annulation partielle, annulation totale (Casekit, annulation OOS 2026)
Exécuter choix client : refund immédiat si annulation, pas de blocage enquête
Appliquer STOCK-COMP section 6 si policy le prévoit
Logger incident : SKU, cause, résolution, coût, ticket ID → post-mortem ops
Interdits recover
Annulation silencieuse sans email. Backorder vague « bientôt » sans date. Blame client (« vous auriez dû commander plus vite »). Retenir remboursement pendant investigation interne.
Commande partielle
Casekit recommande split ship : expédier items dispo, proposer swap ou refund item OOS (Casekit, backorder 2026). Macro variables : {order_ref}, {items_oos}, {refund_timeline}, {swap_options}.
Quelle matrice STOCK-COMP pour compenser sans sur-donner ?
La matrice STOCK-COMP standardise gestes commerciaux selon gravité et valeur client.
Grille 4 niveaux
N1 Pré-achat décalage (PDP/checkout, pas de paiement) : excuses + lien alerte stock ou alternative. Geste : code -5 % usage unique optionnel.
N2 Oversell résolu swap : client accepte alternative équivalente. Geste : livraison express offerte ou -10 % prochaine commande.
N3 Annulation post-paiement : refund intégral + geste. Geste : code -15 % ou refund partiel 10 % si attente refusée (Dropioneer pattern rétention).
N4 Répétition ou VIP : 2e incident 12 mois ou client LTV > seuil. Geste : refund + code -20 % + escalade manager + note compte.
Plafonds agent
Document STOCK-COMP-POLICY : montant max sans manager (ex. 25 € ou 15 % commande). Au-delà : validation lead. Jamais promettre compensation non budgétée en macro bot.
Ce qui ne compense pas
Erreur client (mauvaise variante choisie alors que stock correct). Rupture annoncée clairement avant achat. Précommande avec délai affiché et respecté.
Exemple chiffré
Commande 89 €, oversell taille M, annulation. Refund 89 € sous 48 h + code SORRY15 (-15 %, 30 j). Coût direct ~12 € marge code + 8 min SAV. Coût évité : chargeback ~89 € + avis 1 étoile.
Quelles macros STOCK-DISP utiliser selon l'intent ?
Les macros STOCK-DISP garantissent ton empathique et options claires. Préfixe DISP- dans le helpdesk.
6 macros essentielles
DISP-OVERSOLD : « Nous avons constaté un écart stock sur {sku}. Votre commande {order_ref} est concernée. Voici vos options : A) réassort {eta} B) alternative {swap} C) remboursement intégral sous {refund_timeline}. »
DISP-CHECKOUT : « Le stock a évolué pendant votre session. Il reste {variant_alt} ou alerte retour : {link}. »
DISP-MARKETPLACE : « Notre flux Google peut afficher un délai de mise à jour 4-6 h. Stock site en temps réel : {status}. »
DISP-PARTIAL : « Nous expédions {items_ok} aujourd'hui. Pour {item_oos} : swap ou remboursement partiel {amount}. »
DISP-COMP : « En geste commercial pour cet incident : {geste}. Code : {code}. »
DISP-ROOT-ACK : « Nous avons corrigé la cause ({sync/canaux}) pour éviter récidive. »
Règles rédaction
ChannelEngine : reconnaître l'erreur sans jargon WMS (ChannelEngine, confiance 2026). Factuel, options numérotées, délai remboursement explicite (3-5 j ouvrés). Lien templates support (#34), modification commande.
Comment tracer la cause racine avec STOCK-ROOT et handoff ops ?
Chaque ticket stock_display_error alimente un post-mortem STOCK-ROOT ops, pas seulement un refund.
6 causes racines type
root_sync_lag: délai API WMS/3PL > 15 minroot_multichannel_race: deux canaux, même unitéroot_continue_selling: paramètre Shopify mal configuréroot_manual_override: qty éditée admin sans syncroot_feed_stale: Google/Meta pas rafraîchiroot_dropship_unreliable: fournisseur OOS, site ouvert
Fiche incident Notion
Champs : date, SKU, qty affichée vs réelle, commandes impactées, root cause, fix ops, coût STOCK-COMP total, owner, statut closed. Revue hebdo si > 2 incidents/semaine.
Handoff support → ops
Agent ne modifie pas inventaire sans ticket ops. Slack #stock-incidents : template 5 lignes (SKU, order IDs, verbatim client, screenshot PDP si pertinent). Ops confirme fix + réponse DISP-ROOT-ACK sous 24 h.
Lien soldes et drops
Flash sale et influenceur amplifient root_multichannel_race. Voir soldes (#318), dropshipping (#96), priorisation tickets (#26).
Quels playbooks verticaux pour mode, beauté et marketplace ?
Les incidents stock affiché varient selon catalogue et canaux.
Mode / footwear
Pic disp_checkout_block taille unique restante. Swap taille/couleur prioritaire. Buffer par variante, pas par produit parent. Grille STOCK-COMP N2 favorisée (client veut le modèle).
Beauté / limited drops
Survente flash fréquente. Freeze SKU + communication Instagram story si volume tickets. Pas de backorder sans date ferme fournisseur. Lien lancement produit.
Multi-canal Amazon + DTC
root_multichannel_race dominant. OMS orchestration obligatoire. Macro DISP-MARKETPLACE insuffisante : expliquer délai sync inter-plateforme. US Tech : push-down qty=0 tous canaux en < 60 s.
Dropshipping
root_dropship_unreliable. Policy : ne jamais afficher qty fournisseur brut. Délai sync 4 h max ou masquer SKU. Voir dropshipping (#96).
B2B / wholesale
MOQ et réservations : erreur affichage = escalade account manager, pas macro DTC. Stock réservé vs disponible vente : deux champs inventaire distincts.
Quels KPI mesurer sur les erreurs stock affiché ?
Mesurez incidents et récupération, pas le volume rupture brut (#106).
KPI mensuels
oversell_rate : commandes annulées stock / commandes totales
disp_ticket_rate : tickets stock_display_error / commandes
recover_contact_sla : % clients contactés < 2 h post-détection
recover_save_rate : swap ou attente vs refund total
stock_comp_cost : montant total STOCK-COMP
repeat_disp_12m : clients 2+ incidents (alerte churn)
root_recurrence : même root cause 2×/mois = fix ops requis
chargeback_disp : contestations liées annulation stock
Objectifs DTC type
oversell_rate < 0,3 % commandes. recover_contact_sla > 95 %. recover_save_rate > 25 % (swap ou attente). stock_comp_cost < 2 % marge mensuelle. Loopwork cite 79 % clients ne revenant pas après mauvaise expérience stock (Loopwork, sync 2026).
Comment Qstomy gère-t-il les incidents stock affiché en conversation ?
Qstomy exécute STOCK-DISP-RECOVER en chat : détection intent, options swap/refund, sync commande Shopify, application STOCK-COMP plafonnée.
Capacités
Intent
disp_oversell_postpayavec arbre 4 options CasekitLecture statut commande + items unfulfilled temps réel
Reco alternatives SKU même collection (stock live)
Application code STOCK-COMP selon matrice N1-N4
Escalade P1 si qty négative détectée webhook
Export incident STOCK-ROOT vers Notion ops
Scénario DTC chiffré
Marque accessoires, 6 800 commandes/mois, sync multi-canal. Avant #319 : 14 oversells/mois, contact client moyen 18 h post-annulation, recover_save_rate 8 %, 3 chargebacks trimestre. Après STOCK-DISP-RECOVER + Qstomy : oversells 9/mois (buffer + réconciliation), contact < 1 h (webhook + bot proactif), recover_save_rate 31 %, chargebacks 0, stock_comp_cost 420 €/mois vs coût chargeback évité estimé 1 800 €.
Voir support IA, agent vente, Shopify, démo. Guide dédié : bot incidents stock (#320).
Quels playbooks pour déployer STOCK-DISP-LOOP en quatre semaines ?
Playbook 1 : audit affichage (4 h)
Export SKU : track qty, continue selling, buffer. Scan feed Google. Lister 90 j tickets stock_display_error ou annulations stock.
Playbook 2 : STOCK-DISP-PREVENT (1 j)
Appliquer 8 mesures section 4. Config alerte qty négative. Test oversell staging.
Playbook 3 : policy + macros (4 h)
Rédiger STOCK-COMP-POLICY + 6 macros DISP-*. Former équipe arbre 4 options.
Playbook 4 : runbook recover (2 h)
Document STOCK-DISP-RECOVER 7 étapes. Canal Slack #stock-incidents. Owner ops + support.
Playbook 5 : revue mensuelle (60 min)
KPI section 10. Post-mortem root_recurrence. Ajuster buffer et plafonds COMP.
Maillage utile
Cette semaine : taggez vos annulations stock des 30 derniers jours avec disp_oversell_postpay et mesurez le délai moyen entre annulation Shopify et premier contact client. Si ce délai dépasse 2 h, STOCK-DISP-RECOVER n'est pas encore en place.
Enzo
3 juillet 2026
