E-commerce
30 juin 2026
Proposer un réassort au mauvais moment, c'est perdre le client deux fois : il ignore le message, puis il achète chez Amazon parce que votre rappel est arrivé trop tôt ou trop tard. Un chatbot réachat efficace ne repose pas sur « voulez-vous recommander ? » à chaque ouverture de widget, mais sur quand proposer, quoi suggérer et quand se taire.
Replenit estime que le timing prédictif individuel convertit à 2,4× le taux des rappels intervalle fixe 30 j (Replenit, Shopify replenishment 2026). SubSummit distingue reorder agents (sans engagement) et Subscribe & Save : le bot doit servir les deux profils sans les confondre (SubSummit, Replenishment Playbook 2026).
Ce guide #310 traite le chatbot IA réachat : fenêtres timing, triggers, suppression, flows. Il complète support ventes récurrentes (#309) avec l'angle automation IA du moment de proposition reorder.
Sommaire
Pourquoi le timing compte-t-il plus que le copywriting sur un bot réachat ?
Deux clients achètent le même sérum 50 ml. L'un l'utilise en 35 j, l'autre en 52 j. Un rappel fixe J+30 agace le second et arrive trop tard pour le premier déjà passé sur un concurrent.
Coût d'un mauvais timing
Trop tôt : perception spam, snooze, désabonnement flux replenishment
Trop tard : client déjà racheté ailleurs, fenêtre fermée
Hors contexte chat : proposition reorder pendant litige livraison → perte confiance
Ce que change l'IA
Bitontree décrit l'agent retention : rappel semaine 7 sur un stock 8 semaines, pas jour 30 générique (Bitontree, retention agent 2026). reOtter segmente reorder reminder, at-risk et winback selon écart à la date prédite (reOtter, reorder prediction 2026).
Principe #310
Le bot réachat = moteur de fenêtres + guardrails. La recommandation n'apparaît que si le score timing dépasse le seuil et qu'aucune règle de suppression n'est active.
En quoi diffère-t-il du support #309, de l'historique #258 et du cross-sell #152 ?
Cinq contenus voisins, cinq responsabilités bot.
Support récurrent (#309)
Ventes récurrentes (#309) : REORDER-INTENT, macros REORDER, REORDER-POLICY humain. Le #310 automatise le timing et la décision proposer / attendre / snooze.
Historique achat (#258)
Historique bot (#258) : auth, whitelist, confiance. Le #310 utilise l'historique pour calculer predicted_runout, pas seulement lookup WISMO.
Cross-sell (#152)
Cross-sell (#152) : complément panier session. Le #310 : même SKU ou routine consommables au moment run-out.
Routine / refill
Reco routine : intervalles produit. Le #310 : orchestration chat proactive + réactive avec suppressions.
AOV bot (#305)
Bot AOV (#305) : packs, franco. Le #310 : reorder d'abord, upgrade format ou Subscribe seulement si fenêtre peak et consentement.
Promesse #310
Modèle REORDER-TIMING, REPEAT-BOT-INTENT, guardrails NO-REORDER-PRESSURE, triggers, prompt REPEAT-BOT-01, KPI.
Quelle cartographie REPEAT-BOT-INTENT pour le chatbot réachat ?
La taxonomie REPEAT-BOT-INTENT sépare demande client, suggestion proactive et gestion refus.
12 intents bot réachat
repeat_reorder_request: client demande à recommanderrepeat_suggest_proactive: bot propose reorder (fenêtre peak)repeat_timing_question: « quand racheter ? »repeat_not_yet: « j'en ai encore » → snoozerepeat_snooze_chat: reporter rappel depuis chatrepeat_variant_change: même gamme, autre varianterepeat_need_change: pivot SKU (besoin évolutif)repeat_subscribe_offer: upgrade Subscribe après 2+ reordersrepeat_complement: complément routine (post-reorder only)repeat_decline_stop: ne plus proposer ce SKUrepeat_multi_sku: plusieurs produits due same windowrepeat_handoff: litige, B2B récurrent, wholesale
Priorité routing
Intent SAV actif (WISMO, retour, réclamation) bloque repeat_suggest_proactive. repeat_reorder_request toujours servi, même hors fenêtre.
Comment construire le modèle REORDER-TIMING pour décider quand proposer ?
Le modèle REORDER-TIMING calcule une fenêtre par paire client × SKU replenishment.
Inputs calcul
last_order_date + line item SKU
days_supply : metafield produit ou médiane catégorie (ex. 42 j)
velocity_adjust : écart vs médiane si 2+ commandes même SKU (intervalle réel)
quantity_multiplier : achat 2 unités = +100 % days_supply
Fenêtres lifecycle
pre_window : runout - 14 j à - 8 j (pas de proactive chat, email soft only)
peak_window : runout - 7 j à runout + 3 j → repeat_suggest_proactive autorisé
late_window : runout + 4 j à + 21 j → winback ton, pas upsell agressif
dormant : + 21 j sans achat → at-risk, handoff marketing, pas 3e nudge chat
Score timing
Score 0-100 : 80+ peak eligible proactive. Replenit : fenêtre « not too early, not too late » (Replenit, replenishment agent 2026). Formule simple sans ML : score = 100 - abs(today - predicted_runout) × 5, cap 0-100.
Quelles règles de suppression avant toute suggestion proactive ?
Les guardrails suppression reorder empêchent le bot de proposer au mauvais moment.
10 suppressions obligatoires
Commande même SKU < 14 j : client vient d'acheter
Abonnement actif sur SKU : redirect portail sub
snooze_until profile Klaviyo non expiré
repeat_decline_stop sur SKU : blacklist 180 j
Ticket SAV ouvert tag litige / retour
Retour récent même SKU 60 j
Score timing < 60 : pas de proactive
Visiteur non auth : pas de « vous achetez souvent... »
SKU non replenishment : mode, durable, one-shot
2 proactive repeat / 30 j max par client : cap fréquence
NO-REORDER-PRESSURE
Extension guardrails #305 : jamais reorder après refus même session. Jamais reorder + cross-sell même message. Toujours option « pas maintenant » visible. Insider One : client 51+ j sans achat (cycle 30 j) = at-risk, incitation douce, pas rappel produit (Insider One, lifecycle chatbot 2026).
Quels triggers chat activer pour le réachat : proactif vs réactif ?
Le orchestrateur triggers réachat mappe contexte session vers action bot.
Triggers proactifs (peak_window + suppressions OK)
Compte client /account : chip « Recommander {sku} » si score ≥ 80
Return visit J+35-50 post-achat consumable : message 1 ligne après 15 s dwell
Post-WISMO résolu : si delivered + replenishment SKU + peak → « Besoin de réassort bientôt ? »
Triggers réactifs (toujours actifs)
Chip « Recommander ma dernière commande » toute session auth
Intent repeat_reorder_request entrant
Deep link e-mail replenishment → chat pré-rempli SKU
rePete pattern
rePete envoie nudge SMS/e-mail/on-site quand prédiction ready, one-click cart (rePete, reorder agent 2026). Le chat #310 reprend le même SKU et timing, sans dupliquer le message même heure que Klaviyo (délai min 4 h entre canaux).
Quel flow conversationnel pour proposer un réachat sans pression ?
Le flow bot réachat suit une séquence fixe en 4 étapes maximum.
Flow repeat_suggest_proactive
Contexte : « Vous aviez commandé {product} le {date}. D'après l'usage habituel, vous pourriez bientôt en manquer. »
Choix : boutons [Recommander] [Pas encore] [Autre produit]
Recommander : lien panier pré-rempli + prix + stock live
Pas encore → repeat_snooze_chat 2 sem. / 1 mois
Flow repeat_reorder_request
Skip étape 1 si client a demandé. Lookup dernière commande → confirm SKU → add-to-cart. Si variante OOS : repeat_variant_change ou substitute.
Upgrade Subscribe conditionnel
Si orders_count SKU ≥ 3 et pas abonné : après clic Recommander, footer « Livraison auto -10 % ? » non bloquant. Ecommerce Circle : 15 % convertissent au 3e reorder (Ecommerce Circle 2026).
Comment structurer le prompt REPEAT-BOT-01 et les signaux data ?
Bloc system prompt REPEAT-BOT-01 250-350 mots, extension #163.
Blocs prompt
Rôle : assistant réachat, pas vendeur pushy
Signaux : predicted_runout, timing_score, window_name, snooze_until
REORDER-POLICY #309 : durées SKU, upgrade sub, pivot need_change
Suppressions : liste section 5, vérifier avant proactive
NO-REORDER-PRESSURE : max 1 suggestion proactive / session
Handoff : repeat_handoff si wholesale ou 3 échecs lien panier
Metafields Shopify sync bot
replenishment_days, replenishment_eligible, pairs_with_sku. AeroChat : post-achat bot = usage tips + reorder reminders dans le même fil support (AeroChat, repeat sales 2026).
Comment synchroniser le bot chat avec Klaviyo et les agents replenishment ?
Le sync bot ↔ ESP évite double nudge et incohérence snooze.
Architecture data
Shopify orders → calcul predicted_runout (cron daily ou Replenit/reOtter webhook)
Profile Klaviyo :
predicted_reorder_date,timing_score,snooze_untilBot lit mêmes properties via API ou metafield customer sync
repeat_snooze_chat → webhook update Klaviyo + cancel pending flow send
Règle canal
E-mail peak J-5 → chat proactive seulement si e-mail non ouvert J-2 ET score ≥ 85. Stormy AI : séquence T-5 e-mail, T-3 SMS, T-1 push (Stormy AI, replenishment 2026). Chat = canal de secours ou réponse demande, pas spam parallèle.
Exclusion abonnés
Segment active_subscriber exclu des triggers repeat_suggest_proactive. Bot redirect vers support abonnement intents skip/pause.
Quels cas limites traiter : multi-SKU, cadeau, pivot besoin ?
Les edge cases bot réachat demandent des branches explicites dans l'orchestrateur.
Multi-SKU même fenêtre
repeat_multi_sku : 2+ produits due ± 5 j → un panier consolidé, un message « Votre routine complète ». reOtter rollup event unique.
Achat cadeau
Shipping address ≠ billing ou tag gift : ne pas proactive reorder. Demander « achetez-vous pour vous ? » avant suggestion (#258 edge case).
repeat_need_change
Reprendre arbre pivot #309 section 7. Bot : 2 questions → nouveau SKU → update replenishment_sku profile → snooze ancien.
Stock OOS
SKU due mais stock 0 : substitute documenté + alerte back-in-stock, pas lien panier mort. Replenit pause triggers OOS automatiquement.
Quels KPI mesurer pour le bot réachat ?
Mesurez timing et conversion, pas le volume de suggestions.
KPI mensuels
repeat_proactive_accept_rate : clics Recommander / suggestions proactive
repeat_chat_cvr : commandes attribuées chat repeat / sessions auth peak
snooze_from_chat_rate : repeat_not_yet + snooze (signal timing à recalibrer si > 30 %)
repeat_decline_stop_rate : opt-out SKU (qualité suggestion)
subscribe_upgrade_from_chat : conversions repeat_subscribe_offer
suppression_hit_rate : % sessions où proactive bloquée (audit règles)
second_purchase_rate_60d : impact global cohorte bot actif
Revue S+30
Comparer repeat_chat_cvr peak vs late window. Ajuster pre/peak boundaries si snooze_rate élevé en peak = predicted_runout trop tôt.
Comment Qstomy décide-t-il quand proposer un réachat ?
Qstomy exécute REORDER-TIMING, REPEAT-BOT-INTENT et NO-REORDER-PRESSURE en temps réel.
Capacités
Calcul predicted_runout par SKU depuis historique Shopify
Orchestrateur suppressions 10 règles section 5
Flows repeat_suggest_proactive et repeat_reorder_request
Snooze chat → sync Klaviyo profile
Panier pré-rempli + stock live API
CTA Subscribe non bloquant post-reorder
Scénario DTC chiffré
Marque pet care DTC, 8 SKU replenishment. Avant Qstomy : rappel chat fixe J+30, repeat_proactive_accept_rate 4,2 %, repeat_decline_stop_rate 9 %. Après REORDER-TIMING + suppressions : accept_rate 11,8 %, repeat_chat_cvr +62 %, snooze_from_chat 14 % (vs 38 %), second_purchase_rate_60d +11 pts sur 10 semaines.
Voir agent vente, Shopify, démo.
Enzo
30 juin 2026
