E-commerce
29 juin 2026
« Comment savez-vous que j'ai commandé ça en octobre ? » Le client n'est pas flatté. Il se demande qui d'autre voit ses achats. L'agent, lui, avait ouvert la sidebar Shopify et recopié l'historique mot pour mot. La personnalisation support par historique d'achat doit raccourcir le diagnostic, pas donner l'impression de surveillance.
Salesforce estime que 71 % des clients font davantage confiance à une marque qui explique clairement l'usage de leurs données (CMSWire, confiance IA 2026). AnswerLab parle de « recognition gap » : le client se sent reconnu quand vous résolvez vite, pas quand vous citez ses achats passés (AnswerLab, recognition gap 2025). ButtonBlock : l'historique d'achat est l'une des sources les plus acceptées (45 %), à condition qu'il serve la demande en cours (ButtonBlock, creep factor 2026).
Ce guide #257 traite le support client et historique d'achat : quoi utiliser, quoi taire, comment formuler. Complète clients récurrents (#206) (ton fidèle) : ici, limites, perception client et garde-fous opérationnels.
Sommaire
Pourquoi l'historique d'achat aide-t-il et effraie-t-il le client ?
L'historique achat support est la donnée la plus pertinente pour résoudre un ticket. C'est aussi celle qui bascule le plus vite en malaise.
Utile quand...
Le client demande WISMO : lookup commande sans reposer l'e-mail
2e retour même SKU : proposer taille adjacente sans re-diagnostic
Replenishment : rappeler intervalle d'achat si le client le demande
Litige récurrent : reprendre résolution ticket précédent sans faire répéter l'histoire
Intrusif quand...
L'agent cite des achats non liés au ticket
Le bot mentionne l'heure ou la fréquence de navigation
Le ton devient familier sans relation établie
Le client n'a pas authentifié son identité et vous citez quand même ses commandes
Gartner via Retently : 53 % des clients ont vécu une expérience négative de ciblage, 44 % moins enclins à racheter (Retently, sur-personnalisation 2026). AnswerLab : la reconnaissance perçue monte quand le délai baisse, pas quand vous listez les achats (AnswerLab, recognition gap).
Exemple DTC skincare
Marque, agent formé « tout afficher ». CSAT personnalisation 3,2. Refonte règles HISTORY : données sidebar oui, citation client ciblée. CSAT 4,3, repeat purchase post-ticket +12 %, plaintes « vous me surveillez » −78 %.
Règle d'or opérationnelle
L'historique sert l'agent en coulisses. Le client ne voit que ce qui répond à sa question du moment. Si vous hésitez, gardez l'info en sidebar.
En quoi diffère-t-il des guides personnalisation voisins ?
Cinq contenus personnalisation, cinq angles.
Clients récurrents (#206)
Récurrents (#206) : macros, segments lifecycle. Le #257 : limites et test du creepy sur tout usage historique.
Bot données Shopify (#20)
Bot Shopify (#20) : quels champs lire. Le #257 : comment l'agent humain formule sans effrayer.
Statut commande (#personalize-order)
Par statut commande : WISMO vs unfulfilled. Le #257 : historique multi-commandes et LTV.
CRM support
CRM (#CRM) : sync tags. Le #257 : règles d'exposition client.
Bot historique (#258)
Bot historique (#258) : flows, whitelist et automatisation. Le #257 fixe la policy humaine que le bot #258 applique.
Quelles données historique utiliser côté agent ?
La matrice données support sépare ce qui aide l'agent de ce qui peut apparaître dans la réponse client.
Afficher sidebar (interne)
orders_count, total_spent, first_order_date
3 dernières commandes : #, date, statut, SKU principal
Tickets 90 j : sujet, résolution
Tags : VIP, subscriber, high_return
Taux retour interne (ne jamais citer au client)
Citer au client (si pertinent ticket)
Commande en cours : #, statut, tracking
Commande précédente liée au problème (même SKU, même taille)
« Vous aviez contacté le [date] pour [sujet] » si continuité
Ne jamais citer
LTV exact, marge, notes internes, score fraude, autres achats non liés, « nous voyons que vous avez consulté X fois ». Gorgias Customer Timeline : contexte avant réponse, pas script mot à mot (Gorgias, customer timeline).
Quel test « creepy » appliquer avant chaque réponse ?
Le test du creepy support : si vous ne diriez pas cette phrase à voix haute en magasin, ne l'envoyez pas par chat.
Phrases à bannir
« Nous savons que vous achetez souvent le soir »
« Vous avez aussi commandé [produit intime] en mars » (hors sujet)
« En tant que gros client, vous méritez... » (LTV exposé)
« Notre système indique que vous êtes un retourneur fréquent »
« D'après votre profil, vous préférez le bleu » (hors contexte ticket)
Phrases acceptées
« Votre commande #4521 du 12 juin est en transit »
« Je reprends votre échange taille M signalé en octobre »
« Pour le même produit que votre dernière commande, voici L en stock »
« Je consulte votre dossier pour traiter votre retour » (transparence légère)
Règle need-to-know
Ecom Design Pro : chaque donnée utilisée doit servir la demande en cours (Ecom Design Pro, privacy-first 2026). BBMM : « Nous utilisons votre historique pour le bon refill » = OK. Heure de navigation = non (BBMM, confiance IA 2026).
Exercice équipe (15 min)
Distribuez 10 vraies réponses agents anonymisées. Chaque agent classe OK / creepy / incertain. Débattez les cas limites. Documentez 5 formulations validées dans Gorgias. Refaire après chaque recrutement.
Comment configurer la sidebar Gorgias pour l'historique ?
La sidebar historique agent doit donner le contexte en 5 secondes, sans surcharge.
Setup recommandé
Customer Timeline : tickets + orders activés
Widget Shopify : cog → drag champs utiles (order status, tracking, tags)
Metafields importés : taille_habituelle, skin_type si pertinent
AI summary ticket précédent si disponible
Lien rapide Shopify admin (interne agent)
Gorgias : filtrer timeline Orders only pour WISMO, Tickets only pour litige (Gorgias, orders timeline 2025).
Brief agent 15 min
« La sidebar est pour vous. Le client ne voit que ce que vous choisissez de mentionner, lié à sa demande. » Formation : ouvrir timeline avant réponse, pas après dispute.
Merge profils
Client multi-e-mails : merge Gorgias pour historique complet. Lien doublons (#256).
Quelles macros HISTORY-* par contexte achat ?
Six macros historique achat personnalisent sans sur-exposer. Import Gorgias : Settings → Macros → Create. Variables Shopify via {{customer.first_name}}, {{ticket.customer.integrations.shopify.orders[0].name}}.
HISTORY-WISMO-01
« Bonjour [Prénom], commande #[X] du [date] : [statut]. Suivi : [lien]. » Pas de liste des 5 dernières commandes. Si plusieurs commandes ouvertes : demander laquelle concerne le ticket.
HISTORY-CONTINUE-01 (ticket précédent)
« Je reprends votre demande du [date] concernant [sujet]. Voici où nous en sommes : [1 ligne]. » Lien interne ticket parent en note, pas visible client.
HISTORY-REPEAT-SKU-01
« Je vois que le [SKU] vous convient en [taille] depuis vos commandes passées. Pour cet échange, je vous propose [variante]. » Uniquement si retour taille. Ne jamais citer commandes de cadeaux (adresse différente).
HISTORY-REPLENISH-01
« Vous aviez commandé [SKU] il y a [X] semaines. Souhaitez-vous le même produit ? Lien : [PDP]. » Seulement si client demande réassort. Interdit en ticket litige colis perdu.
HISTORY-VIP-01 (discret)
« Merci pour votre fidélité. Je traite votre demande en priorité. » Sans montant dépensé. Aligner VIP policy. Gestes commerciaux via policy interne, pas annoncés comme « vous avez dépensé X € ».
HISTORY-FIRST-01 (premier achat)
« Bienvenue chez [marque]. Pour votre première commande #[X], voici le statut : [...]. » Chaleureux, pas d'historique inventé.
HISTORY-PRIVACY-01
« Nous consultons votre historique commandes sur [marque] pour traiter votre demande SAV. Ces données ne sont pas utilisées à des fins publicitaires via ce canal. Politique : [lien]. » À envoyer si le client questionne la source de l'info.
Comment segmenter l'usage historique par profil client ?
Quatre profils historique support imposent des règles différentes. Chaque profil = macro par défaut + champs sidebar autorisés.
Premier acheteur
Historique = commande en cours uniquement. Ton accueillant. Ne pas simuler une relation passée. Macro HISTORY-FIRST-01. Sidebar : masquer orders_count et total_spent pour éviter biais agent.
Récurrent fidèle (3+ commandes)
Reconnaissance légère, pas de flatterie LTV. Éviter re-demander infos connues (taille, adresse). Voir #206. Si abonnement actif : mentionner statut abo seulement si ticket porte dessus. Lien programme fidélité.
Client retours fréquents
Tag interne high_return : appliquer policy retour, ne jamais verbaliser le tag. Proposer guide taille ou échange, pas « vous retournez souvent ». Agent applique règles standard sans commentaire sur le comportement passé.
Inactif qui revient
« Content de vous revoir » OK. Citer dernière commande seulement si le ticket porte dessus (ex. défaut produit acheté il y a 18 mois). Ne pas rappeler date exacte si le client ne la mentionne pas.
Shopify Flow tags
first_order, repeat_loyal, lapsed_return, high_return_internal (agent only, jamais sync vers Klaviyo). Rules Gorgias : macro conditionnelle selon tag. Exemple : si repeat_loyal → HISTORY-VIP-01 en suggestion, pas en envoi auto.
Quelles règles bot et handoff avec historique ?
Le bot historique achat lit plus que ce qu'il dit au client. La règle : contexte riche en handoff, message client minimal.
Bot peut utiliser en interne
Lookup dernière commande pour WISMO après auth e-mail
Routing VIP si tag + urgence détectée
Skip questions déjà répondues ticket open (#256)
Handoff package : 3 commandes + tickets récents + tags internes
Pré-remplir macro HISTORY-CONTINUE si repeat ticket
Bot ne dit pas au client
Liste complète achats passés non sollicitée
Cross-sell agressif « clients comme vous achètent aussi »
Données browsing ou panier abandonné hors contexte
« Vous êtes client depuis X ans et avez dépensé Y € »
Message bot WISMO type
« Bonjour, votre commande #[X] du [date] est [statut]. Suivi : [lien]. Autre question sur cette commande ? » Une commande, pas un récapitulatif de compte.
Handoff : transmettre historique complet à l'agent, message client minimal. Contexte (#155). Préparer bot #258. Aligner champs bot avec Shopify (#20).
Quelles limites RGPD et consentement respecter ?
L'historique achat RGPD en support repose sur l'exécution du contrat, pas sur le marketing.
Base légale support
Traiter commande, retour, SAV = intérêt contractuel. Pas besoin de consentement marketing pour lire commande en ticket. Mentionner historique dans réponse = même base.
Transparence si question client
Macro HISTORY-PRIVACY-01 : « Nous consultons votre historique commandes sur [marque] pour traiter votre demande SAV. Ces données ne sont pas partagées à des fins publicitaires via ce canal. Politique : [lien]. »
Droit accès
Export commandes via compte client ou demande DPO. Support ne envoie pas export complet par chat sans auth (#122).
Minimisation
Ne pas copier historique complet dans notes ticket public client. Notes internes OK, PII limitée.
Quels anti-patterns personnalisation historique éviter ?
Six erreurs historique support détruisent la confiance.
Dump historique dans le premier message
« Vous avez 7 commandes, voici la liste... » Fix : une commande pertinente.
Cross-sell en ticket litige
Colis abîmé + suggestion nouveauté. Fix : résoudre d'abord.
Ton « on se connaît » premier achat
Fix : HISTORY-FIRST-01.
Mentionner LTV ou marge
Fix : VIP discret, gestes via policy (#238).
Bot qui cite produits non demandés
Fix : need-to-know section 4.
Ignorer demande « comment me connaissez-vous ? »
Fix : HISTORY-PRIVACY-01 immédiat, ton calme.
Comment Qstomy personnalise-t-il sans effet surveillance ?
Qstomy lit l'historique Shopify pour résoudre, expose au client uniquement le strict nécessaire. L'agent reçoit le contexte complet au handoff.
Fonctionnalités historique
Lookup commande session + e-mail vérifié
Need-to-know filter : whitelist champs réponse bot (statut, tracking, SKU ticket)
Handoff riche : agent voit timeline, client non
Repeat ticket detect : HISTORY-CONTINUE flow auto
VIP routing silencieux selon tags Shopify
Privacy macro si question données
Auth gate : pas de citation historique sans e-mail validé (#122)
Scénario DTC chiffré
Marque mode, 1 200 tickets/semaine, 62 % clients repeat. Bot « tout dire » : plaintes creepy 4,2 %, CSAT 3,8, escalades « comment me connaissez-vous » 89/semaine. Qstomy need-to-know + handoff : plaintes 0,6 %, CSAT 4,4, FCR +14 pts, temps agent lookup −35 % (contexte pré-chargé), repeat purchase post-ticket +9 %.
Déploiement type (2 semaines)
Semaine 1 : connecter Shopify, définir whitelist champs bot, importer macros HISTORY. Semaine 2 : former 8 agents test magasin, mesurer CSAT segment repeat vs contrôle. Ajuster formulations bot selon transcripts.
Explorez intégration Shopify, support client IA, demander une démo.
Quels playbooks opérationnels déployer en 3 semaines ?
Playbook 1 : audit creepy (4 h, semaine 1)
Tirer 30 transcripts au hasard (10 WISMO, 10 retours, 10 récurrents). Taguer phrases intrusives. Partager 5 exemples interdits et 5 validés en réunion 30 min. Mesurer baseline : % tickets avec citation achats hors sujet.
Playbook 2 : sidebar Gorgias (2 h)
Configurer section 5. Masquer total_spent pour agents junior si besoin. Test 5 agents, 10 tickets chacun : temps ouverture sidebar, phrases citées au client.
Playbook 3 : macros HISTORY (2 h)
Importer 7 macros section 6. Variables dynamiques Shopify. Rule Gorgias : suggérer macro selon tag client, pas envoi automatique sans relecture agent.
Playbook 4 : brief équipe (1 h)
Test magasin + need-to-know. Quiz 5 phrases OK / KO. Afficher matrice section 3 en poster Slack #support.
Playbook 5 : tags Flow (1 semaine)
Créer first_order, repeat_loyal, high_return_internal dans Shopify Flow. Sync Gorgias. Rules macros conditionnelles. Exclure high_return_internal de tout export marketing.
Playbook 6 : revue mensuelle (2 h)
CSAT segment récurrent, plaintes privacy, tickets tagués creepy_review. Ajuster bot en préparation #258. KPI cibles : plaintes creepy < 1 %, FCR repeat +10 pts.
Maillage utile
Personnaliser avec l'historique d'achat, ce n'est pas prouver que vous savez tout sur le client. C'est lui éviter de répéter, résoudre plus vite, et rester digne de confiance. Quand la sidebar nourrit l'agent et que le client ne voit que l'essentiel, l'historique devient un service, pas une surveillance.
Enzo
29 juin 2026
