E-commerce
28 juin 2026
« Mon chargeur v1 fonctionne avec la batterie v2 ? » « J'ai l'ancienne formule, c'est la même chose que la nouvelle ? » « Mon abonnement affiche encore l'ancienne référence. » Trois clients, une même migration de gamme mal expliquée, trois tickets évitables.
Overtone a montré en 2025 qu'une reformulation transparente (quoi, pourquoi, pour qui) réduit la méfiance des clients fidèles (Overtone, formula update). The Gel Bottle recommande d'indiquer clairement sur chaque PDP quelle version est vendue quand deux formules coexistent (Gel Bottle, BIAB migration).
Ce guide #244 traite le support client lors d'une migration de gamme : anciennes références, nouvelles versions, compatibilité. Nouveau sujet backlog. Distinct de produits discontinués (#243) (retrait sans remplaçant officiel) : ici, transition structurée v1 → v2 avec accompagnement client.
Sommaire
Pourquoi une migration de gamme génère-t-elle des tickets ?
Une migration gamme produit touche les clients les plus fidèles : ceux qui connaissent l'ancienne référence par cœur.
Trois sources de confusion
Référence obsolète : client cherche SKU v1, site affiche v2
Compatibilité floue : accessoires, consommables, pièces détachées
Changement perçu : formule, format, usage différent sans explication
Coût support
Tribe Studio rappelle que l'absence de communication proactive sur un changement d'abonnement ou de référence pousse au churn plutôt qu'au ticket (Tribe Studio, migration DTC 2026). AnnounceKit estime que les emails de changement majeur avec action claire obtiennent des taux d'ouverture supérieurs aux promos (AnnounceKit, update emails 2026).
Exemple DTC tech
Lanceur batterie v2, v1 retiré mais 1 200 clients v1 actifs. Sans fiche migration : 89 tickets/semaine compatibilité. Avec table compat + macro MIG : tickets −58 %, taux rachat v2 chez clients v1 34 % en 8 semaines.
En quoi diffère-t-il des contenus voisins ?
Quatre situations catalogue, quatre playbooks support.
Produits discontinués (#243)
Discontinués (#243) : retrait sans substitut ou avec alternative générique. Le #244 : remplaçant officiel v2, campagne transition, compatibilité documentée.
Rupture temporaire (#167)
Réassort (#167) : même SKU reviendra. Migration gamme : changement permanent de référence, pas d'ETA retour v1.
Comparaison produit chatbot
Comparaison produit : aider à choisir entre SKU concurrents. Le #244 : v1 vs v2 même gamme, souvent avec obligation de migrer.
Bot alternatives (#245, à venir)
Le futur guide bot rupture recommandera un substitut quand stock zéro. Le #244 couvre la transition planifiée avec communication amont.
Promesse #244
Typologie migration, fiche MIG-SKU, comms client, macros, compatibilité, abonnements, KPI, playbooks.
Quels types de migration de gamme cartographier ?
Nommez le type migration catalogue avant de rédiger la macro. Le niveau de changement et le ton diffèrent.
Six scénarios
mig_reformulation : même nom produit, nouvelle formule (cosmétique, alimentaire)
mig_version_upgrade : v1 → v2 explicite (tech, électroménager)
mig_rename_rebrand : nouveau nom, même fonction
mig_format_change : 500 ml → 480 ml, packaging différent
mig_line_consolidation : 3 SKU fusionnés en 1
mig_partial_compat : v2 compatible partiellement avec accessoires v1
Tags Gorgias
product_migration, sous-tags mig_compat, mig_subscriber, mig_dual_stock, mig_confusion_pdp.
Période de transition
Documenter si v1 et v2 coexistent (dual stock) ou coupure nette (hard switch). Gel Bottle : transition graduelle avec stock v1 UK encore disponible pendant bascule v2 (Gel Bottle BIAB). Support doit connaître la date de coupure officielle.
Comment préparer la migration ops avant le lancement v2 ?
La préparation migration gamme se joue 4 à 8 semaines avant la première commande v2.
Timeline ops (8 semaines)
S-8 : valider mapping v1 → v2, table compatibilité, différences produit
S-6 : créer fiche MIG-SKU (section 5), brief support + macros
S-4 : swap abonnements test sur échantillon Recharge/Skio
S-2 : e-mail segment repurchaseurs v1 + bandeau PDP v1
S-1 : redirect 301 URLs v1 → v2 si hard switch, QA bot + agents
J0 : lancement v2, monitoring tickets mig_* horaire 48 h
Mapping variant obligatoire
Skio exige un CSV variant-mapping old_id → new_id avant swap abonnements (Skio, variant mapping). Même logique sur un seul store : table interne SKU_v1 | SKU_v2 | compat | diff_notes.
Cross-fonctionnel
Participants : merchandising (substitut), ops (stock dual), support (macros), marketing (email), legal si claims produit changent.
Quelle fiche MIG-SKU alimenter support et PDP ?
Chaque migration gamme exige une fiche MIG-SKU unique, source de vérité support et bot.
Champs obligatoires
SKU_v1 / SKU_v2 : IDs Shopify + noms commerciaux
Type mig_* : reformulation, upgrade, etc.
Différences client : 3-5 bullets plain language (format, ingrédients, perf)
Compatibilité : oui/non/partiel + liste accessoires v1 OK sur v2
Action client : aucune, racheter v2, échanger, mettre à jour abonnement
Dual stock : dates début/fin vente v1, pays concernés
Redirect URL : v1 → v2 si applicable
Code transition : MIG10 si policy geste découverte v2
Bloc PDP v2
Bandeau sous titre : « Nouvelle version 2026. Ancienne référence : [nom v1]. Voir différences » + lien ancre comparatif. Overtone : préciser quels produits sont concernés par le changement, pas toute la gamme.
Corpus bot
Indexer fiche MIG dans RAG Qstomy. Intent product_migration lit SKU page + historique commande client si authentifié.
Comment structurer la communication client ?
La communication migration gamme suit la structure quoi / pourquoi / action.
Email segment repurchaseurs v1
Objet : « Important : évolution de [produit v1] → [produit v2] ». Corps : 1) ce qui change, 2) pourquoi (réglementation, perf, durabilité), 3) compatibilité accessoires, 4) CTA PDP v2 + code MIG10. IdeaPlan : si action requise (abonnement), lead with action, deadline visible (IdeaPlan, action email 2026).
Packaging transition
QR code vers page « v1 vs v2 » sur colis v2 pendant 90 j. Réduit tickets post-livraison « ce n'est pas la même boîte ».
Centre d'aide
Article dédié par migration majeure : tableau comparatif, compatibilité, questions abonnement. Lier depuis macros support.
Règle dual stock
Si v1 encore vendu : chaque PDP indique « Version originale » vs « Nouvelle formule » (Gel Bottle). Support ne doit jamais envoyer v2 à un client qui a commandé v1 en dual stock sans confirmation.
Quelles macros support par scénario migration ?
Macros MIG-* Gorgias branchées sur fiche MIG-SKU, variables {v1}, {v2}, {diff}, {compat}, {code}.
MIG-UPGRADE-01 (v1 → v2 direct)
« [v1] évolue en [v2]. Changements : {diff}. Compatible avec vos accessoires v1 : {compat}. Découvrir v2 : {lien}. Code {code} -10 % pour clients fidèles. »
MIG-COMPAT-01 (question compatibilité)
« Votre [accessoire v1] est {compat} avec [v2]. Détail : {liste}. Si vous possédez encore [v1], il reste utilisable {conditions}. »
MIG-REFORM-01 (reformulation même nom)
« La formule de [produit] a évolué depuis [date]. {diff}. Même usage quotidien. Si vous préférez l'ancienne version : {dual_stock_status}. »
MIG-SUB-01 (abonné)
« Votre abonnement passe de [v1] à [v2] au cycle [date]. Différences : {diff}. Modifier ou annuler avant [date] : {portail}. Aucun surcoût si prix identique. »
MIG-CONFUS-01 (client reçoit v2, attendait v1)
« Commande #[X] : nous expédions désormais [v2], successeur de [v1]. {diff}. Retour gratuit sous 30 j si non adapté, ou échange si dual stock v1 encore dispo. »
Comment documenter compatibilité ancien et nouveau ?
La matrice compatibilité migration évite les réponses inventées par l'agent.
Table compat (exemple tech)
Batterie v1 + chargeur v2 : oui, même connecteur USB-C
Coque v1 + appareil v2 : non, dimensions +2 mm
Filtre v1 + machine v2 : non, référence filtre F-200 requise
Format fiche
Sheets ou Notion : Accessoire | v1 OK | v2 OK | Notes | Lien PDP remplacement. Merchandising valide, support consomme, bot indexe.
Cas partiel
Si compat partielle : expliquer limite concrète (« fonctionne en charge lente, pas charge rapide »). Proposer accessoire adaptateur si existe.
Litiges retour
Client v1 incompatible v2 par erreur achat : échange ou refund selon policy. Tag mig_wrong_expectation alimente clarification PDP si volume > 5/semaine.
Comment migrer abonnements et clients récurrents ?
Les abonnés migration gamme exigent swap technique + communication avant facturation.
Workflow Recharge/Skio
Export abonnements actifs sur SKU_v1
Variant mapping CSV validé ops
Bulk product swap v1 → v2 (Recharge import ou Skio bulk)
Vérifier queued charges : line_item_sku = v2 (Recharge, SKU update)
E-mail MIG-SUB-01 J-7 minimum avant cycle impacté
Prix différent v2
Si v2 plus cher : grandfathering 1-2 cycles au prix v1 ou communication transparente + option annulation sans frais. Tribe Studio : un abonné surpris par un changement de facturation annule sans demander.
Repurchase sans abonnement
Voir support réassort et support abonnement. Segment Klaviyo acheteurs v1 ×2 en 12 mois : email S-14 + S-2.
Quels anti-patterns lors d'un changement de gamme ?
Cinq erreurs migration gamme transforment une évolution produit en crise SAV.
Roll-out silencieux
Gel Bottle reconnaît qu'une communication trop discrète sur reformulation BIAB a généré de la méfiance pro. Annoncer clairement.
v1 et v2 indifférenciés sur PDP
Client commande au hasard. Labels explicites obligatoires en dual stock.
Compatibilité au feeling agent
« Ça devrait marcher » sans table validée = retour + avis négatif.
Swap abonnement sans préavis
Colis v2 surprise au renouvellement. E-mail MIG-SUB avant cycle.
Redirect v1 → v2 sans page comparatif
SEO préservé mais client perdu. Landing v2 doit expliquer le lien avec v1.
Comment Qstomy accompagne-t-il la migration de gamme ?
Qstomy lit les fiches MIG-SKU et l'historique commande pour répondre en contexte v1/v2.
Fonctionnalités migration
Intent product_migration : lookup MIG-SKU par page ou commande
Table compat : réponses accessoires traçables
Compare v1/v2 : différences en langage client
Branch abonné : statut swap + lien portail
Code MIG auto : repurchaseur v1 détecté
Scénario DTC chiffré
Marque maison, migration purificateur v1 → v2, 620 abonnés + 2 400 repurchaseurs v1 24 mois. Fiches MIG + email S-14 + bot migration + swap Recharge bulk. Après 10 semaines : tickets mig_* −51 % vs migration précédente sans SOP, rachat v2 repurchaseurs contactés 37 %, churn abonnés −18 pts, FCR migration 74 %.
Explorez intégration Shopify, support client IA, demander une démo.
Quels playbooks opérationnels lancer ?
Playbook 1 : fiche MIG-SKU (4 h / gamme)
Remplir champs section 5 avec merchandising + ops. Valider compatibilité avec R&D ou sourcing.
Playbook 2 : timeline S-8 (1 réunion)
Calendrier section 4, owners, segments email, date hard switch vs dual stock.
Playbook 3 : macros + centre d'aide (1 jour)
Rédiger MIG-* section 7, article aide comparatif, sidebar Gorgias fiche MIG.
Playbook 4 : abonnements (2 j)
Mapping CSV, swap test 20 comptes, bulk swap prod, vérif queued charges.
Playbook 5 : war room J0-J+7 (30 min/jour)
Export tags mig_*, top verbatims, 1 tweak PDP ou macro/jour. Debrief J+14 vers roadmap support (#240).
Maillage utile
Changer de gamme, ce n'est pas effacer l'ancienne référence : c'est accompagner ceux qui l'ont adoptée. Quand support, ops et merchandising partagent la même fiche MIG, la migration devient une évolution maîtrisée, pas une boîte noire pour le client.
Enzo
28 juin 2026
