E-commerce
30 juin 2026
« Je veux recommander le même produit, comment faire ? » « Arrêtez de m'envoyer des rappels, j'en ai encore pour un mois. » « Mon chien a changé de croquettes, comment modifier ma prochaine commande ? » La majorité de vos clients récurrents ne sont pas abonnés. Ils rachètent quand ils le décident, mais ils écrivent quand même au support pour un lien, un rappel mal calibré ou un besoin qui a évolué.
SubSummit distingue deux modèles complémentaires : Subscribe & Save pour les profils prévisibles, et reorder agents pour ceux qui veulent être rappelés sans engagement (SubSummit, Replenishment Playbook 2026). Ecommerce Coffee Break estime qu'un système reorder basé sur l'historique d'achat individuel convertit les hésitants en récurrents sans pression abonnement (Ecommerce Coffee Break, reorder 2026).
Ce guide #309 traite le support client ventes récurrentes hors abonnement strict : renouvellements, rappels replenishment, changements de besoin. Il complète support abonnement avec l'angle réachat flexible, buy again et rappels snooze.
Summary
Pourquoi les ventes récurrentes hors abonnement génèrent-elles un SAV spécifique ?
Environ 80 % des clients récurrents DTC ne souscrivent pas à un abonnement. Ils rachètent quand le pot est vide, quand l'e-mail arrive au bon moment, ou quand le chat leur rappelle le bon SKU. Pourtant ils contactent le support : lien buy again cassé, rappel trop tôt, changement de variante, confusion avec un abonnement qu'ils n'ont pas.
Trois frustrations récurrentes
Friction reorder : compte client incomplet, variante introuvable, promo non cumulable
Rappels mal calibrés : e-mail J+20 alors que le produit dure 45 j → désabonnement marketing + ticket « stop »
Évolution du besoin : taille enfant, changement régime, nouveau produit gamme, le client ne sait pas comment pivoter
Coût sans process
StoreBuilt rappelle qu'imposer un abonnement là où le réachat est exploratoire ajoute coût support et churn sans matcher la demande (StoreBuilt, loyalty vs subscription 2026). Un agent qui traite un rappel replenishment comme une résiliation abonnement envoie le mauvais script et perd le client.
Principe #309
Séparer clairement abonnement contractuel et réachat volontaire. Document REORDER-POLICY, intents REORDER-INTENT, macros et bot alignés sur l'historique commande, pas sur un contrat Recharge.
En quoi diffère-t-il du support abonnement, de la fidélité et du pack découverte #308 ?
Cinq contenus voisins, cinq logiques.
Support abonnement
Support abonnement : pause, skip, swap, prélèvement récurrent, résiliation contrat. Le #309 : pas de contrat, commande à commande, rappels opt-out et buy again.
Abonnement cadeau (#273)
Abonnement cadeau (#273) : donneur, destinataire, rédemption. Le #309 : acheteur = utilisateur, réachat direct.
Pack découverte (#308)
Support starter kit (#308) : essai → pleine taille, crédit trial. Le #309 : cycle réachat après premier format pleine taille ou réorders 2+.
Personnalisation retour client
Support client récurrent (#274 voisin) : ton et données client. Le #309 : playbooks opérationnels reorder et changement besoin.
Historique achat bot
Bot historique achat : lookup commandes. Le #309 définit quoi faire une fois l'historique identifié : reorder, snooze, pivot SKU.
Promesse #309
REORDER-INTENT, REORDER-POLICY, macros REORDER, bot replenishment, gestion changement besoin, KPI réachat.
Quelle cartographie REORDER-INTENT pour les tickets réachat ?
La taxonomie REORDER-INTENT classe les demandes récurrentes sans abonnement.
15 intents ventes récurrentes
reorder_same: recommander exactement la même commandereorder_link: lien buy again / panier pré-remplireorder_variant: même produit, autre taille/couleur/saveurreorder_quantity: doubler ou réduire quantité habituellereorder_promo: code fidélité, cumul subscribe & savereorder_snooze: reporter rappel replenishmentreorder_stop_reminder: désactiver rappels sans blacklistreorder_timing: « quand dois-je racheter ? » durée produitreorder_subscribe_upgrade: passer en abonnement après 2+ commandesreorder_need_change: besoin évolutif, autre SKU gammereorder_substitute: produit discontinué, alternativereorder_gift_repeat: renvoyer même cadeau annuelreorder_address: livrer ailleurs pour prochain achatreorder_payment: carte enregistrée, Shop Pay, BNPL réachatreorder_handoff: litige prix reorder, B2B volume récurrent
Tags helpdesk
reorder, replenishment, repeat_customer. Exclure tag subscription si pas de contrat Recharge actif.
Comment rédiger le document REORDER-POLICY pour agents et marketing ?
Le document REORDER-POLICY aligne support, Klaviyo et bot sur les règles de réachat hors abonnement.
9 blocs obligatoires
SKU replenishment : liste produits à cycle réachat, durée usage moyenne (jours)
Intervalle rappel : formule (dernier achat + X j), pas fixe 30 j pour tous
Exclusion abonnés actifs : ne pas envoyer replenishment si contrat Recharge actif (Ecommerce Circle, replenishment flow 2026)
Snooze : options 2 semaines / 1 mois / 3 mois, lien one-click e-mail
Buy again : URL compte, deep link panier, variante par défaut = dernière commandée
Upgrade abonnement : seuil (ex. 3e commande même SKU), remise -10 à 15 %
Changement besoin : arbre pivot SKU (ex. chiot → adulte, peau sèche → mixte)
Promo réachat : codes fidélité, cumul ou non avec soldes
Escalade : produit discontinué, prix reorder contesté → merchandising
Règle timing dynamique
Replenit compare rappels intervalle fixe (20-30 % pertinence) vs modèle consommation individuel (70-85 % selon vertical) (Replenit, repeat purchase 2026). REORDER-POLICY doit documenter la source du timing : moyenne catégorie ou calcul par client.
Quelles macros REORDER pour traiter les demandes en moins de 90 secondes ?
Les macros REORDER couvrent reorder, snooze et pivot sans script abonnement.
8 macros essentielles
REORDER-001 Buy again : lien panier pré-rempli dernière commande #{order}, variante {variant}
REORDER-002 Timing : « Votre {product} dure environ {days} j. Prochain rachat suggéré : {date} »
REORDER-003 Snooze : « Rappel reporté de {snooze_period}. Lien modifier : {snooze_url} »
REORDER-004 Stop reminders : désinscription flux replenishment only, pas newsletter globale
REORDER-005 Variant change : guide changement taille/saveur + lien SKU cible
REORDER-006 Need change : arbre pivot 2 questions → SKU recommandé + pourquoi
REORDER-007 Subscribe upgrade : « Après {n} commandes, Subscribe & Save -{pct} % » + lien one-click
REORDER-008 Discontinued : alternative {sku_b} + geste {credit} si applicable
Lookup obligatoire avant réponse
Shopify customer → dernière commande SKU → statut abonnement Recharge (actif ?) → profil Klaviyo replenishment segment. Si abonné actif : renvoyer vers macro abonnement skip/pause, pas REORDER-001.
Ton sans pression
Ecommerce Coffee Break : proposer snooze plutôt que relance agressive. Le client qui dit « j'en ai encore » doit recevoir REORDER-003, pas un code promo immédiat.
Comment configurer le bot sur les intents réachat et replenishment ?
Le bot ventes récurrentes connecte historique Shopify et REORDER-POLICY pour répondre en contexte.
Flows bot prioritaires
reorder_same : lookup e-mail → dernière commande → lien add-to-cart + total estimé
reorder_snooze : boutons 2 sem. / 1 mois / 3 mois → webhook Klaviyo update profile
reorder_need_change : 2 questions (usage, contrainte) → pivot SKU depuis arbre policy
reorder_subscribe_upgrade : si orders_count ≥ seuil → lien Recharge/Shopify Subscriptions
Chips compte client
Page /account : « Recommander », « Reporter mon rappel », « Changer de produit ». Easy Subscription rappelle que chaque action manquante en self-service devient ticket (Easy Subscription, manage subscriptions 2026). Même logique pour reorder hors abonnement.
Interdit bot
Confondre replenishment e-mail et abonnement actif. Promettre snooze sans intégration Klaviyo. Forcer upgrade abonnement si client demande stop reminders.
Pour le timing IA (fenêtres peak, suppressions, suggestion proactive), voir bot réachat (#310).
Comment gérer un changement de besoin sans perdre le client récurrent ?
Le changement de besoin est le moment où le réachat identique échoue et le support devient conseil.
Arbre pivot en 4 branches
Usage modifié : sport intensif, voyage, saison → SKU format ou variante adaptée
Profil modifié : enfant grandit, animal stérilisé, peau réactive → autre gamme documentée
Budget : downsize format ou gamme entrée sans culpabiliser
Insatisfaction légère : essai concurrent, « moins bien qu'avant » → diagnostic + substitute ou geste
Protocole agent REORDER-006
Confirmer SKU et date dernier achat
Question ouverte : « Qu'est-ce qui a changé dans votre usage ? »
Proposer 1 SKU pivot + 1 alternative budget
Mettre à jour profil Klaviyo
replenishment_skupour futurs rappelsSnooze ancien SKU replenishment flow
Loop et flexibilité
Loop documente que « trop de produit » se traite par skip, « besoin différent » par swap (Loop, pause skip swap 2026). En hors abonnement : swap = nouveau SKU recommandé + désactivation rappel ancien produit.
Quel parcours Klaviyo replenishment synchroniser avec le SAV ?
Le flow replenishment Klaviyo et le support doivent partager les mêmes règles REORDER-POLICY.
Architecture flow type
Trigger : fulfilled order SKU replenishment + property
predicted_reorder_dateTouch 1 : J-7 run-out, lien buy again + option Subscribe & Save
Touch 2 : J-3 si pas de commande, snooze one-click
Split : exclude segment
active_subscriberExit : nouvelle commande même SKU ou snooze > 90 j → sunset flow
Alignement SAV ↔ marketing
Si agent envoie REORDER-003 snooze, webhook met à jour Klaviyo immédiatement. Si marketing envoie rappel J-7 et client ticket « trop tôt », agent vérifie predicted_reorder_date et corrige profil, pas seulement excuse.
Upgrade abonnement in-flow
Ecommerce Circle : 15 % des acheteurs replenishment convertissent en abonnement au 3e reorder si CTA cohérent dans touch 2 (Ecommerce Circle 2026). Macro REORDER-007 reprend exactement la même remise que l'e-mail.
Quels playbooks verticaux pour beauté, alimentaire, pet care et maison ?
Le support réachat varie selon cycle consommation et réglementation.
Beauté / skincare
Durée mini 30-45 j. Questions reorder_timing et reorder_variant dominent. Revenue Hunt : commandes post-quiz +11-15 % vs moyenne (Revenue Hunt 2026). SAV : lier reorder au profil peau si quiz complété.
Alimentaire / boisson
Cycle court 14-30 j. reorder_quantity fréquent (famille, stock placard). Snooze vital si vacances scolaires.
Pet care
reorder_need_change à chaque changement poids chien/chat. Documenter table pivot poids → SKU croquettes.
Maison / consommables
Multi-SKU panier récurrent. reorder_same = refaire commande complète. Vérifier stock OOS item bloquant avant lien buy again.
Non-replenishment
Mode, décoration, cadeaux : pas de flow replenishment. Tickets reorder_gift_repeat ou reorder_same saisonnier seulement. StoreBuilt : ne pas forcer récurrence si pattern achat = exploration.
Quels KPI mesurer sur le support ventes récurrentes ?
Mesurez efficacité reorder et qualité rappels, pas le volume tickets seul.
KPI mensuels
repeat_purchase_rate : % clients 2+ commandes / cohorte 90 j
reorder_ticket_rate : tickets REORDER-INTENT / commandes repeat
replenishment_email_cvr : commandes attribuées flow / envois
snooze_rate : snooze / rappels envoyés (signal timing à ajuster si > 25 %)
reorder_bot_deflection : intents résolus sans humain
pivot_success_rate : commandes post reorder_need_change sous 14 j
subscribe_upgrade_rate : conversions REORDER-007 / éligibles 3+ commandes
Revue trimestrielle
Si snooze_rate monte : recalibrer predicted_reorder_date. Si reorder_ticket_rate haut sur reorder_link : réparer buy again compte client. Comparer CSAT repeat vs first-time.
Comment Qstomy gère-t-il renouvellements, rappels et changements de besoin ?
Qstomy exécute REORDER-INTENT, lookup historique Shopify et synchronise snooze avec les flows marketing.
Capacités
Buy again one-click depuis lookup commande
Snooze replenishment 2 sem. / 1 mois / 3 mois via webhook
Arbre pivot reorder_need_change depuis metafields gamme
Détection abonné actif → redirect macros abonnement
CTA Subscribe upgrade si seuil commandes atteint
Handoff reorder_handoff avec LTV + historique SKU
Scénario DTC chiffré
Marque compléments DTC, 62 % réachat hors abonnement. Avant Qstomy : 340 tickets reorder/mois, reorder_bot_deflection 28 %, snooze_rate 31 % (timing fixe 30 j). Après REORDER-POLICY + bot timing dynamique : tickets 198/mois, deflection 71 %, snooze_rate 12 %, repeat_purchase_rate +8 pts sur 12 semaines.
Voir support IA, agent vente, Shopify, démo.
Quels playbooks pour déployer le support récurrent en quatre semaines ?
Playbook 1 : audit repeat vs subscription (4 h)
Export tickets « recommander », « rappel », « abonnement » 90 j. Séparer contrat Recharge vs reorder volontaire. Lister top 8 REORDER-INTENT.
Playbook 2 : REORDER-POLICY + durées SKU (1 j)
Remplir 9 blocs section 4. Merchandising valide durée usage par SKU replenishment. Publier Notion + metafields.
Playbook 3 : macros REORDER + buy again (4 h)
Rédiger REORDER-001 à 008. Tester lookup Shopify sur 10 clients repeat. Vérifier exclusion abonnés.
Playbook 4 : sync Klaviyo snooze (1 j)
Webhook bot + lien snooze e-mail. Test : snooze chat → pas de rappel J+3. Aligner copy avec macros.
Playbook 5 : arbre pivot need_change (3 h)
Documenter 5 cas pivot vertical. Entraîner bot + agents sur REORDER-006.
Maillage utile
Cette semaine : cherchez « recommander » dans vos tickets du dernier mois. Combien concernent un client sans abonnement actif ? Si la majorité, le playbook 1 confirme que le #309 est votre priorité ops.
Enzo
30 juin 2026
