E-commerce
1 juillet 2026
« Vous saviez que ça allait partir, pourquoi j'ai pu commander ? » « La rupture était annoncée sur Instagram, pas sur la fiche produit. » « J'attends une alternative depuis une semaine, personne ne répond. » Trois messages où une rupture anticipée mal préparée transforme un plan ops en crise SAV.
Le support client avant rupture annoncée e-commerce aligne ops, merchandising et SAV : timeline T-14, communication PDP, alternatives validées, macros agents et file prioritaire avant que le stock tombe à zéro.
Ce guide #404 couvre policy PLAN-STOCK, flow PLAN-FLOW et KPI planned_oos. Distinct des incidents stock réactifs (#320) et des questions rupture générale (#106) : ici, rupture planifiée, communication proactive et alternatives.
Summary
Pourquoi une rupture annoncée génère-t-elle autant de tickets ?
Une rupture annoncée support survient quand ops, achats ou production savent que le SKU sera indisponible dans X jours, mais le site continue de vendre ou affiche mal le statut.
Cinq tensions client typiques
Commande tardive : client achète J-1 avant rupture, colis bloqué
Communication éclatée : info Instagram, PDP silencieuse
Alternative floue : agent propose SKU non équivalent
Attente réassort : date promise non tenue (#167)
Panier mixte : 1 SKU rupture bloque expédition complète (#357)
Opensend estime que 69 % des acheteurs abandonnent si l'article est indisponible, et que les ruptures représentent environ 20 % des abandons panier (Opensend, stats rupture 2026). Gorgias observe que les marques sans playbook rupture planifiée voient 40-55 % tickets OOS devenir litiges refund ou chargeback (Gorgias, stats SAV 2026).
Angle #404 vs contenus voisins
Rupture générale #106 : workflow SAV quotidien. Le #404 = préparation avant que la rupture arrive.
Incident stock #320 : oversell réactif, webhook. Le #404 = rupture anticipée, pas surprise qty négative.
Erreurs affichage #319 : stock PDP incorrect. Le #404 = communication volontaire fin de série.
Réassort #167 : ETA retour stock. Le #404 = fenêtre avant rupture + pendant indisponibilité.
Bot précommande #405 : futur file d'attente limitée. Le #404 = rupture sans précommande structurée.
Exemple DTC
Marque skincare, bestseller serum fin de production. Sans PLAN-STOCK : 89 tickets en 10 j, CSAT OOS 2,8/5. Après playbook : planned_oos_ticket_rate -52 %, alternative_accept_rate 41 %, chargeback OOS 0.
Rupture planifiée vs incident
Planifiée : date connue, dernier lot limité, reformulation à venir. Incident : oversell, bug sync, erreur entrepôt. Deux playbooks distincts.
En quoi la préparation diffère-t-elle de la rupture réactive ?
Trois phases rupture stock, trois responsabilités support.
Matrice phase → playbook
#404 PLAN-STOCK : T-14 à T+7, rupture annoncée
#320 STOCK-INC : oversell détecté, résolution urgente
#106 OOS general : rupture courante sans contexte plan
Quatre déclencheurs rupture planifiée
Fin de série : produit discontinué, pas de réassort
Dernier lot production : MOQ atteint, 4-8 sem stock restant
Reformulation : V2 en préparation, V1 épuisée
Saisonnier fin de collection : soldes puis arrêt définitif
Avantage préparation
14 jours avant rupture : PDP banner, macros prêtes, alternatives validées merchandising, file SAV tag planned_oos. Support passe de réactif à orchestré.
Promesse #404
Policy PLAN-STOCK, timeline T-14, matrice alternatives ALT-MAP, flow PLAN-FLOW, macros PLAN-*, KPI.
Quelles typologies planned_oos_* cartographier ?
Douze typologies tickets rupture annoncée pour routing support cohérent.
Douze scénarios planned_oos
planned_oos_pre_purchase : « encore dispo ? » avant achat
planned_oos_last_units : « combien reste-t-il ? »
planned_oos_post_order_hold : commande payée, stock épuisé avant ship
planned_oos_alternative_request : client demande substitut équivalent
planned_oos_wait_restock : préfère attendre (fin de série = non)
planned_oos_cancel_refund : annulation + remboursement demandé
planned_oos_mixed_cart : 1 ligne OOS bloque commande multi-SKU
planned_oos_reformulation : « quand sort la V2 ? »
planned_oos_loyalty_vip : client fidèle, accès derniers lots
planned_oos_wholesale_b2b : commande pro, volume restant insuffisant
planned_oos_communication_gap : « personne ne m'a prévenu »
planned_oos_partial_ship : ship disponible, hold OOS line
Tags helpdesk
planned_oos, oos_sku_[ref], oos_phase_pre|during|post, oos_alt_offered, oos_alt_accepted, oos_fin_serie, oos_reformulation. Distinct stock_incident, oos_reactive.
Mining avant lancement playbook
Historique SKU similaire fin de série : volume tickets, top verbatim, taux alternative acceptée. Calibre staffing T-0 à T+7.
Priorisation typologies
planned_oos_post_order_hold et planned_oos_cancel_refund = P1 (décision financière). planned_oos_pre_purchase = bot tier 0 (#245). planned_oos_alternative_request = agent script ALT-MAP.
Quelle timeline T-14 avant la rupture ?
La timeline préparation rupture T-14 synchronise ops, marketing et SAV.
Jalons T-14 à T+7
T-14 ops : confirmer date rupture, qty restante, fin série ou réassort lointain
T-12 merchandising : valider 2-3 alternatives ALT-MAP section 5
T-10 support : rédiger policy PLAN-STOCK + macros PLAN-*
T-7 PDP : banner « Dernières unités · Fin de série [date] » + badge stock bas
T-5 marketing : email VIP accès anticipé ou last chance (optionnel)
T-3 bot : activer intents planned_oos sur SKU (#245 alternatives)
T-0 rupture : PDP sold out, redirect alternatives, disable add-to-cart
T+1 à T+7 : file planned_oos priority, review tickets quotidien
Coordination Slack #planned-oos
Canal temporaire : ops qty daily, support ticket count, merchandising alt stock check. Fermé T+14 post-résolution backlog.
Shopify actions T-0
Inventory 0, continue selling OFF, metafield oos_type=planned_fin_serie, collection redirect vers alternative hero. Sync marketplaces si multichannel.
Communication reformulation
Si V2 prévue : date fourchette PDP, waitlist Klaviyo (#48), macro PLAN-REFORM-01. Pas promettre date ferme sans production validée.
Quelle matrice ALT-MAP pour proposer des alternatives ?
La matrice alternatives rupture ALT-MAP évite substituts incohérents proposés par agents sous pression.
Quatre critères alternative valide
Équivalence fonction : même usage client (ex. serum hydratant → autre serum même actif)
Stock confirmé : qty > 30 j forecast ou MOQ sécurisé
Prix ±15 % : pas downgrade visible sans geste
Validé merchandising : sign-off écrit T-12
Trois niveaux alternative
Alt A directe : même gamme, même tier prix (priorité)
Alt B upgrade : gamme supérieure, geste -10 % si écart prix
Alt C bundle : 2 produits complémentaires = valeur équivalente
Fin de série sans alt
Refund intégral ou credit +15 % future commande. Pas inventer alt hors stock. Macro PLAN-NOALT-01 section 7.
Commande post_order_hold
Contact client sous 24 h : Alt A proposée + option refund. Pas ship partiel sans accord si policy ship complet (#357 exception documentée).
Lien bot #245
Bot pré-achat propose Alt A/B depuis ALT-MAP. Agent exécute swap order ou refund post-achat.
Comment rédiger la policy PLAN-STOCK en huit règles ?
La policy rupture annoncée PLAN-STOCK documente décisions avant T-14.
Huit règles PLAN-STOCK
Type rupture : fin_serie | dernier_lot | reformulation | saisonnier
Date T-0 : inventory 0 prévue, marge 48 h si incertitude prod
PDP communication : banner T-7 minimum, sold out T-0
ALT-MAP : 2-3 alternatives signées merchandising ou policy no-alt
post_order_hold : contact 24 h, alt ou refund, pas silence
Geste commercial : -10 % alt upgrade ou credit +15 % si fin série
SLA planned_oos : FRT 4 h ouvrées phase during, 2 h post_order_hold
Escalade : chargeback menace → head support + refund immédiat si hold > 48 h
Publication Notion + formation
Fiche SKU : photo, qty restante, ALT-MAP, macros, date T-0. Brief agents 30 min T-5. Lien playbook #118 module stock.
Distinction précommande
Si réassort confirmé < 60 j : basculer playbook précommande (#187) ou futur bot #405. PLAN-STOCK = pas de date livraison ferme.
Revue post-mortem T+14
Ticket volume vs forecast, alternative_accept_rate, verbatim communication_gap. Archive fiche Notion pour prochain SKU.
Quelles macros PLAN-* et touchpoints configurer ?
Huit macros agents rupture annoncée et touchpoints site/email.
PLAN-PRE-01 (pré-achat, dernières unités)
« Il reste [qty] unités de [SKU]. Fin de série prévue [date]. Alternative recommandée : [Alt A lien]. »
PLAN-HOLD-01 (post_order_hold contact)
« Votre commande #[X] inclut [SKU] devenu indisponible avant expédition. Nous proposons : (1) [Alt A] expédié sous 48 h, (2) remboursement ligne ou commande complète. Merci de répondre sous 72 h. »
PLAN-ALT-01 (alternative acceptée swap)
« Nous avons remplacé [SKU] par [Alt A] dans votre commande #[X]. Expédition prévue [date]. Geste -10 % appliqué si upgrade. »
PLAN-REFUND-01 (refund post hold)
« Remboursement [montant] initié pour [SKU]. Délai banque 5-10 j ouvrés (#370). Code -15 % future commande : [CODE]. »
PLAN-REFORM-01 (reformulation V2)
« [SKU] est remplacé par [V2] prévu [fourchette]. Inscription waitlist : [lien]. Vous serez notifié en priorité (#48). »
PLAN-NOALT-01 (fin série sans substitut)
« [SKU] ne sera plus réapprovisionné. Remboursement intégral ou credit +15 % : votre choix. »
Touchpoints site
PDP banner T-7 « Dernières unités »
Cart drawer alert si qty < 5 et SKU planned_oos
Sold out page avec Alt A hero + waitlist si reformulation
Checkout note si SKU tagged planned_oos_last_lot
Klaviyo flow post-purchase hold alert ops
Email proactive post_order_hold
Auto-send PLAN-HOLD-01 within 4 h detection unfulfilled + inventory 0. Réduit tickets entrants 35-45 % selon Gorgias DTC benchmarks.
Comment appliquer le flow PLAN-FLOW en huit étapes ?
Le framework PLAN-FLOW structure traitement ticket rupture annoncée.
Huit étapes PL-1 à PL-8
PL-1 Identifier SKU : tag planned_oos, lookup inventory + order line
PL-2 Classifier typologie : section 3 planned_oos_*
PL-3 Lire ALT-MAP : alternatives validées ou no-alt policy
PL-4 Proposer option : alt swap | refund | wait (si applicable) | partial ship
PL-5 Exécuter : Shopify edit order, refund, ou split fulfillment
PL-6 Confirmer client : macro PLAN-ALT ou PLAN-REFUND
PL-7 Tag outcome : oos_alt_accepted | refund | waitlist | escalated
PL-8 Documenter : note SKU, qty hold restant, pattern verbatim
PL-2 routing priorité
post_order_hold P1 queue. pre_purchase → bot #245 si configuré. communication_gap → empathie + lien banner PDP screenshot.
PL-5 Shopify edit order
Remove line OOS, add Alt A, adjust total, partial refund si downgrade. Ou full refund + cancel si client refuse alt.
Mixed cart PL-4
Option A : ship disponible lines, hold OOS (client accord). Option B : wait all. Option C : remove OOS + refund line, ship rest. Documenter choix policy PLAN-STOCK règle 5.
Escalade PL-8
Hold > 48 h sans réponse client : 2e email + SMS si phone. Hold > 72 h : refund proactive + note ops.
Quels KPI planned_oos mesurer ?
Les KPI rupture annoncée pilotent playbook et amélioration continue.
Huit métriques clés
planned_oos_ticket_rate : tickets SKU planned / total période T-7 à T+7
post_order_hold_count : commandes bloquées avant ship
hold_contact_sla : % contact client sous 24 h hold
alternative_accept_rate : alt acceptée / alt proposée
planned_oos_refund_rate : refund / post_order_hold
communication_gap_rate : tickets « pas prévenu » / total planned_oos
planned_oos_csat : satisfaction tickets tag planned_oos
planned_oos_chargeback : chargebacks SKU période (cible 0)
Benchmark DTC
alternative_accept_rate 35-45 %, hold_contact_sla > 95 %, communication_gap < 8 %, planned_oos_csat > 4,0/5, chargeback 0 si hold SLA respecté.
Dashboard T-7 à T+14
Daily ticket count, typologie breakdown, alt vs refund split, verbatim tag cloud communication_gap.
Comparaison avec/sans playbook
SKU précédent fin série sans PLAN-STOCK vs SKU actuel : delta ticket rate et CSAT. Justifie effort T-14 ops.
Alerte ops
post_order_hold > 10 sans contact 24 h : alert Slack #planned-oos P0.
Quels anti-patterns éviter sur rupture planifiée ?
Dix anti-patterns rupture annoncée à bannir.
1. Vendre jusqu'à qty négative sans plan
Dernier lot sans disable continue selling = incident #320, pas planned.
2. Banner T-0 seulement
Client commande J-3 sans info. communication_gap explosion.
3. Alternative non validée merchandising
Agent propose SKU hors ALT-MAP, mauvais actif ou rupture aussi.
4. Silence post_order_hold
48 h sans contact = chargeback. PLAN-HOLD-01 auto obligatoire.
5. Promettre réassort fin de série
Agent dit « bientôt de retour » sur discontinué. Perte confiance.
6. Mélanger playbook incident et planned
Oversell webhook #320 sur SKU planned = double confusion macros.
7. Partial ship sans accord
Client attend commande complète. Policy ship hold documentée.
8. Pas de file priority during
Tickets planned_oos noyés dans backlog standard. Tag + queue dédiée.
9. Oublier marketplaces sync
Amazon encore en vente alors que DTC sold out. Tickets cross-channel.
10. Skip post-mortem T+14
Erreurs répétées SKU suivant. Archive Notion obligatoire.
11. Bot #245 non configuré T-3
pre_purchase tickets inutiles si bot alternatives inactive sur SKU.
Comment Qstomy aide à préparer la rupture annoncée ?
Qstomy sur Shopify : intents planned_oos, ALT-MAP bot, post_order_hold alert, macros PLAN-* templates, file priority tag planned_oos, dashboard KPI hold SLA.
Capacités planned OOS Qstomy
planned_oos_intent : 12 typologies section 3
planned_alt_suggest : ALT-MAP bot pré-achat #245
planned_hold_detect : webhook unfulfilled + inv 0
planned_hold_email : auto PLAN-HOLD-01 trigger
planned_priority_queue : routing P1 post_order_hold
planned_no_restock_promise : block bot si fin_serie
Complément #320 et #245
STOCK-INC réactif oversell. Bot alternatives #245 pré-achat. PLAN-STOCK #404 orchestre amont. Qstomy unifie les trois layers sur même SKU tag.
Scénario DTC chiffré
Cosmétiques, serum fin série, 340 unités restantes, T-14 playbook lancé.
Après PLAN-STOCK + Qstomy : planned_oos_ticket_rate -54 %, hold_contact_sla 98 %, alternative_accept_rate 43 %, planned_oos_csat 4,2/5, chargeback 0.
Explorez support client et demander une démo.
Quelle checklist pour déployer PLAN-STOCK ?
Checklist PLAN-STOCK (12 étapes)
Confirmer type rupture + date T-0 avec ops/achats
Valider ALT-MAP 2-3 alternatives merchandising T-12
Rédiger policy PLAN-STOCK 8 règles Notion fiche SKU
Créer macros PLAN-* section 7 dans helpdesk
Configurer PDP banner T-7 + sold out T-0
Activer bot planned_oos intents T-3 (#245)
Setup post_order_hold alert + email auto PLAN-HOLD-01
Brief agents PLAN-FLOW 30 min T-5
Ouvrir Slack #planned-oos + daily standup T-7 à T+7
Queue priority tag planned_oos during phase
Dashboard KPI section 9 daily
Post-mortem T+14 archive + lessons learned
En bref
#404 = rupture anticipée, pas incident réactif (#320)
T-14 timeline : ops → alt → support → PDP → T-0
ALT-MAP : alternatives validées avant pression tickets
post_order_hold : contact 24 h, alt ou refund
KPI alternative_accept_rate : mesure succès playbook
FAQ
Différence avec rupture #106 ?
#106 = SAV quotidien OOS. #404 = préparation 14 j avant rupture connue.
Et si réassort confirmé sous 30 j ?
Basculer playbook précommande #187 ou bot #405. PLAN-STOCK = pas de date ferme.
post_order_hold : refund ou alt d'abord ?
Proposer alt A d'abord (PLAN-HOLD-01). Refund si refus ou fin série no-alt.
Relation incident #320 ?
Planned = anticipé. Incident = oversell surprise. Deux flows, un SKU peut basculer incident si oversell.
Faut-il couper les ventes avant T-0 ?
Non si dernier lot vendu volontairement. Oui disable continue selling à inventory 0 exact.
Aller plus loin
Cette semaine : identifiez le prochain SKU fin de série, lancez timeline T-14, validez ALT-MAP avec merchandising, publiez fiche PLAN-STOCK Notion.
Partagez ce guide #404 avec ops et head support : une rupture annoncée n'est pas une mauvaise nouvelle si le SAV est prêt avant le dernier colis.
Peut-on vendre en précommande pendant planned OOS ?
Si V2 ou réassort daté : oui via playbook #187/#405. Fin de série définitive : waitlist #48, pas précommande.
Enzo
1 juillet 2026
