E-commerce
30 juin 2026
« Quelle est votre politique de retour ? » « Pourquoi mon collègue a eu les frais offerts et pas moi ? » « Le bot a promis 48 h, l'agent dit 5 jours. » Sans document unique, chaque réponse devient une règle ad hoc. La marge et la confiance fuent en parallèle.
Gorgias rappelle qu'une politique support est un document interne qui fixe standards et autorités, distinct des pages publiques retour ou livraison, mais source pour les aligner (Gorgias, customer service policy). Business-in-a-Box note qu'elle sert de preuve de bonne foi en cas de chargeback ou d'avis public (Business-in-a-Box, policy template).
Ce guide #280 formalise la politique support e-commerce : règles internes + extrait public cohérent. Aucun article voisin ne couvrait ce socle documentaire. Distinct de SLA (#101) (délais seuls) et du playbook DTC (#118) (10 modules ops) : ici le contrat support écrit que tout le reste exécute.
Sommaire
Pourquoi une politique support écrite change-t-elle le quotidien ?
La politique support e-commerce transforme des intentions floues en comportements mesurables pour agents, bot et fondateur.
Trois coûts sans document
Incohérence : même question, trois réponses, trois promesses
Escalade floue : personne ne sait qui approuve un remboursement > 50 €
Onboarding lent : la recrue copie le senior, bon ou mauvais
Ce qu'elle n'est pas
Pas les CGV générales. Pas la page « Retours » seule. Pas un PDF oublié dans Drive. C'est le manuel ops : qui répond, sous quel délai, avec quelle autorité, sur quel ton.
Exemple DTC skincare
Marque 650 tickets/mois, 4 agents. Avant policy : variance CSAT agents 0,9 pt, 23 gestes/refunds hors plafond/mois. Après policy v1 (Notion 12 pages + page publique Support) : variance 0,3 pt, gestes hors grille −78 %, onboarding autonome 5 j vs 18 j.
En quoi diffère-t-elle des guides support voisins ?
Sept contenus, sept niveaux.
SLA (#101)
SLA (#101) : chapitre délais. Le #280 : document parent incluant SLA + autorités + ton.
Playbook DTC (#118)
Playbook (#118) : 10 modules scale. Le #280 alimente le module Policies du playbook.
Policy VIP (#207)
VIP (#207) : annexe segment top LTV. Le #280 pose la base tous clients.
Gestes (#238) et DEC (#237)
Gestes (#238) et DEC (#237) : matrices et logs. Le #280 référence ces annexes sans les dupliquer.
Templates (#templates)
Scripts SAV : exécution. Le #280 définit règles que les macros doivent respecter.
Pages légales retour/livraison
Pages Shopify publiques = promesse client. Policy interne = comment les appliquer sans les contredire.
Tickets CGV (#301)
CGV support (#301) : réduire questions rétractation et garantie via CGV-PLAIN. Le #280 = manuel agents ; le #301 = contenu client et macros CGV-*.
Promesse #280
Structure 12 chapitres, double couche public/interne, matrice autorités, extrait page Support, gouvernance version, playbooks rédaction.
Comment séparer promesses publiques et règles internes ?
Le modèle double couche policy support évite de publier des plafonds remboursement ou des tiers VIP au client.
Couche publique (site + auto-reply)
Canaux : email, chat, Instagram DM, WhatsApp si actif
Heures : lun-ven 9h-18h CET, bot 24/7 info
Engagements délai : email sous 24 h ouvrées, chat humain sous 5 min en heures commerce
Liens : retours, livraison, garantie, contact
Couche interne (Notion / Gorgias sidebar)
SLA internes 10-20 % plus agressifs que public (Corebee : dépasser l'engagement client, pas le rater) (Corebee, SLA templates 2026). Plafonds remboursement par tier agent. Escalade matrix #193. Exceptions DEC obligatoires.
Règle de cohérence
Toute phrase publique doit exister en interne avec définition mesurable. Inverse interdit : règle interne secrète qui contredit la page retour. Test mensuel : 5 tickets aléatoires, policy interne vs réponse agent vs page publique.
Quelle structure en douze chapitres adopter ?
Douze chapitres politique support couvrent une boutique DTC Shopify sans sur-documenter.
Mission et promesse marque : une phrase, ton, priorités
Périmètre : canaux, langues, marchés, B2B exclu ou non
Heures et SLA : renvoi #101, variantes BFCM
Priorisation : P0-P3, renvoi priorisation (#26)
Autorités et escalade : section 5 ci-dessous
Policies métier : retour, livraison, promo, annulation (liens pages)
Gestes commerciaux : renvoi #238
Ton et communication : vous/tu, empathie, interdits
Bot et automation : dire vs faire, renvoi gouvernance (#142)
Qualité et rituels : revue #277, audit #259
Incidents : renvoi #278
Versioning : owner, date revue, changelog
Format Notion recommandé
1 page sommaire + 12 sous-pages. Sidebar Gorgias : lien « Policy v3.2 » épinglé. ScaleOps : SOP Shopify brands suit la même logique chapitres (ScaleOps, SOP 2026).
Comment définir les niveaux d'autorité et d'escalade ?
La matrice autorités support supprime le « demandez au manager » systématique.
Quatre niveaux type PME
L0 Agent : remboursement ≤ 30 €, renvoi portail retour, macro standard
L1 Senior : ≤ 80 €, exception retour hors délai 1×/client/an, reship
L2 Support lead : ≤ 200 €, litige chargeback, wholesale edge case
L3 Ops / fondateur : > 200 €, erreur prix bulk, incident SEV1, legal
Escalade obligatoire (sans négociation)
Menace juridique, produit dangereux, influenceur > 50 k followers, client VIP tier Gold (#207), bot a promis hors policy. Aligner matrice escalade (#193).
Champ ticket obligatoire
authority_level_used, decision_ref (policy section), dec_exception si hors grille. DEC #237 si exception.
Exemple décision retour hors délai
Client J+35, produit neuf, first incident. Agent L0 : refus policy page retour 30 j + lien. Client menace avis. Agent L0 : escalade L1 sans geste. L1 : exception 1×/an, étiquette retour offerte, tag dec_exception, DEC rempli. > 80 € valeur panier : L2 valide même si geste < 80 €.
Quels SLA internes et publics fixer par canal ?
Table SLA policy support DTC starter (ajuster après 30 j mesure interne, Zendesk recommande test privé avant publication publique).
Grille starter
Chat bot : réponse instantanée ; public « assistant IA 24/7 »
Chat humain : interne 3 min / public 5 min (heures commerce)
Email : interne 4 h / public 24 h ouvrées (ScaleOps benchmark 2026)
Instagram DM : interne 2 h / public 24 h
Résolution WISMO : interne 24 h / public 48 h
Hybrid bot + humain (2026)
Corebee Template 4 : distinguer SLA « première réponse bot » et « résolution humaine si escalade ». Client comprend : bot informe, humain tranche litige.
Variante pic
Annexe BFCM : email public 48 h, chat 10 min. Publier sur page statut, pas modifier policy core sans changelog.
SLA par intent (interne)
Litige remboursement : first response 2 h, résolution 48 h
Retour initiation : 4 h / self-service immédiat bot
Pré-achat produit : 4 h email, 2 min chat
Wholesale / B2B : file dédiée 8 h
Comment rédiger la page publique « Contact & Support » ?
La page support publique extrait la couche client sans jargon interne.
Structure 6 blocs
Intro : « Nous répondons sous [X]. Voici comment nous joindre. »
Canaux : email, chat, DM Insta avec liens
Délais : engagements publics section 6
Avant de nous écrire : lien suivi, portail retour, centre d'aide
Transparence IA : « Assistant IA disponible ; humain sur demande » (UE)
Liens policies : retour, livraison, confidentialité
Paragraphe type délais
« E-mail : réponse sous 24 h ouvrées (lun-ven 9h-18h, hors jours fériés FR). Chat : réponse immédiate par assistant IA ; agent humain sous 5 minutes en heures d'ouverture. Instagram : sous 24 h ouvrées. »
Auto-reply email
Reprendre les mêmes chiffres. Numéro ticket. Lien page statut si incident actif (#278).
Quelles règles de ton et de précision imposer ?
Le chapitre standards communication support aligne agents, bot et fondateur.
Charte tonale (5 lignes)
Registre : vous, chaleureux, jamais condescendant
Structure : empathie → fait → action → délai
Précision : citer policy ou données commande, pas « normalement »
Interdits : « ce n'est pas notre faute » seul, « lisez le site », promesse non validée
Langues : FR + EN si export ; bot reprend même registre
Règle bot = agent
Bot ne promet jamais ce qu'un agent L0 ne peut pas tenir. Corpus bot sync à chaque changement chapitre 6 policies métier. Voir voix marque bot.
Macros gouvernées
Chaque macro Gorgias : owner, date revue, section policy source. Macro sans source = interdite en prod.
Exemple conforme vs non conforme
Retard colis. Conforme : « Je comprends votre impatience. Commande #1042 en transit, livraison estimée jeudi selon Colissimo. Je surveille avec vous. » Non conforme : « Comme indiqué sur le site, les délais sont de 3-5 j. » sans lien ni statut.
Comment maintenir et versionner la politique ?
La gouvernance policy support évite le document zombie.
RACI
Owner : Head Support ou ops (A)
Rédacteur : support lead (R)
Validateurs : finance (gestes), legal light (claims), bot owner (ch.9)
Équipe : informée changelog (I)
Calendrier revue
Trimestriel : SLA, autorités, top 5 tickets « policy unclear ». Ad hoc : changement page retour, lancement marché, incident SEV1. Gorgias recommande aligner policy interne et KPI mesurés (Gorgias, policy KPI).
Changelog obligatoire
v3.3 · 2026-06-30 · SLA email public 24→48 h BFCM annexe · owner Marie · formation 15 min Slack #support.
Quels KPI prouvent que la policy est suivie ?
Mesurer l'adhérence policy support, pas seulement le CSAT.
KPI mensuels
SLA breach rate par canal vs ch.6
Exceptions DEC / tickets : tendance ↓
Variance CSAT inter-agents : cible < 0,4 pt
Macros hors date revue : 0 en prod
Tickets tag policy_unclear : root cause → update chapitre
Escalades sans authority_level : cible 0
Rituel trimestriel 60 min
Owner + lead : lire 10 tickets DEC, 5 plaintes « incohérent », ajuster 1 chapitre minimum. Publier changelog vX.Y.
Comment Qstomy s'aligne-t-il sur votre politique support ?
Qstomy exécute la policy : plafonds geste, ton, escalade et guardrails bot synchronisés avec votre document Notion.
Capacités
Import policy chunks : chapitres 6-9 indexés bot
Guardrail autorité : block remboursement > L0 bot
SLA-aware messaging : délais publics en widget
Handoff payload : authority_level suggéré
Sync versioning : alerte si corpus stale vs policy
Scénario DTC chiffré
Marque mode, policy v2 déployée + Qstomy guardrails. Avant : 31 promesses bot hors policy/mois, 14 DEC non justifiées. Après sync chapitres 5-9 + block L0 : promesses hors policy 2/mois (audit #143), DEC justifiées 100 %, CSAT +0,3 pt, temps onboarding agent −60 %.
Explorez support client IA, Shopify, demander une démo.
Quels playbooks pour rédiger la policy en deux semaines ?
Playbook 1 : audit existant (1 j)
Collecter pages retour/livraison, macros top 20, DEC 30 j, plaintes « incohérent ». Lister gaps.
Playbook 2 : draft 12 chapitres (3 j)
Remplir structure section 4. Atelier 2 h support + finance : valider matrice section 5.
Playbook 3 : SLA mesure 30 j
Exporter FRT Gorgias 30 j. Fixer interne + public section 6. Ne pas publier avant mesure (Zendesk).
Playbook 4 : page publique + auto-reply (4 h)
Publier footer « Support ». Sync auto-reply. Test mobile.
Playbook 5 : formation équipe (90 min)
Walkthrough chapitres 5, 6, 8. Quiz 10 situations. Épingler Notion sidebar Gorgias.
Playbook 6 : boucle qualité
Brancher revue #277 sur tag policy_unclear. Maillage : SLA (#101), playbook (#118), gestes (#238).
Une policy support claire ne garantit pas la perfection : elle garantit que l'imperfection ne devient pas le standard.
Enzo
30 juin 2026
