E-commerce
30 juin 2026
Le chargeback est déclaré. L'agent junior avait promis un remboursement sous 24 h sans vérifier la policy. Le dossier n'existe nulle part sauf dans le ticket archivé. Six semaines plus tard, le même scénario se reproduit avec une autre recrue.
ZandaX rappelle que chaque litige est un outil d'apprentissage si l'équipe examine l'évidence et en tire une règle, pas si elle « envoie le dossier à la banque et passe à autre chose » (ZandaX, formation litiges 2026). eDesk estime qu'une base de connaissance structurée doit inclure procédures d'escalade et edge cases internes, pas seulement des articles client (eDesk, knowledge base IA 2026).
Ce guide #300 traite la bibliothèque de cas difficiles support : litiges, chargebacks, réclamations, exceptions. Il complète formation cas gold (#299) et base réponses REP (#102) avec l'angle capitaliser l'échec et le complexe.
Sommaire
Pourquoi capitaliser sur les cas difficiles plutôt que les archiver ?
Les tickets routiniers (WISMO, retour standard) alimentent macros et bot. Les cas difficiles (chargeback, client menaçant un avis public, exception policy refusée) coûtent 5 à 20 fois plus de temps et de marge. Pourtant ils disparaissent souvent après clôture, sans capitalisation.
Coût de l'amnésie ops
Répétition erreurs : même sur-promesse, même escalade tardive
Onboarding incomplet : le junior n'a jamais vu un 13.1 ou un VIP colère
Representment faible : preuves éparpillées, ticket mal documenté
Policy floue : l'exception devient règle informelle non écrite
Ce qu'une bibliothèque apporte
Transactions.top alerte : un client avec trois tickets en 48 h ne devrait pas attendre dans la même file qu'un reset mot de passe (Transactions.top, prévention chargeback 2026). Capitaliser les cas difficiles permet de router plus tôt, former avec des exemples réels et mettre à jour policies avec preuves terrain.
Principe #300
Chaque litige, échec CSAT ou chargeback perdu devient une fiche DIFF-CASE avec décision, preuves et leçon ops, pas un ticket oublié.
En quoi diffère-t-il de CONV-LIBRARY #299, REP #102 et matrice escalade #193 ?
Quatre ressources internes, quatre fonctions.
CONV-LIBRARY gold (#299)
Formation cas gold (#299) : CSAT 4-5, réponses exemplaires onboarding. Le #300 : échecs, litiges, edge cases pour seniors et post-mortems.
Base REP (#102)
Base réponses (#102) : macros routine WISMO, retour. Le #300 : arbres décision quand la routine ne suffit pas.
Matrice escalade (#193)
Matrice (#193) : qui route vers quel tier. Le #300 : comment traiter une fois escaladé, avec historique cas similaires.
Chargebacks (#86)
Chargebacks (#86) : process representment. Le #300 : archiver et apprendre de chaque dossier, fight ou accept.
Client colère (#214)
Client colère (#214) : protocole CALME live. Le #300 : cas résolus ou ratés pour calibrer l'équipe.
Promesse #300
DIFF-LIBRARY, taxonomie HARD-CASE, fiche DIFF-CASE-01, post-mortems, alimentation continue, playbooks par famille, formation seniors, KPI.
Quelle taxonomie HARD-CASE pour classer les cas complexes ?
Une taxonomie HARD-CASE homogène permet de retrouver un précédent en 30 secondes.
10 familles DTC
hard_pay_dispute : chargeback, double débit, contestation montant
hard_ship_lost : colis perdu, POD contesté, promesse site vs réalité
hard_product_damage : casse, non-conformité, NTF (fragiles #182)
hard_return_exception : hors délai, hygiène, portail bloqué
hard_angry_public : menace avis, post social, plainte Signal Conso
hard_vip_exception : LTV élevé, geste au-delà policy (VIP)
hard_pricing_error : bug prix, promo mal appliquée (erreur prix)
hard_sub_billing : abonnement, renouvellement contesté
hard_regulated : allégation santé, réaction produit (réglementé)
hard_ops_failure : rupture stock post-commande, expédition oubliée
Tags helpdesk miroir
Tag ticket hard_* + sous-tag outcome : resolved_csat4, chargeback_fought_won, chargeback_lost, policy_updated. Aligner sur tagging irritants.
Quels critères pour inclure un cas dans la DIFF-LIBRARY ?
Tous les tickets ne méritent pas une fiche. Critères d'inclusion DIFF-LIBRARY :
Inclure si au moins un critère
Escalade tier 2+ ou supervisor
Chargeback déclaré ou menace explicite banque
CSAT 1-2 malgré résolution ou ticket réouvert 2+ fois
Geste commercial > seuil L1 (gestes commerciaux)
Exception policy documentée ou refusée avec tension
Menace réputation (avis, social, presse)
Leçon ops : process, site ou macro à corriger
Exclure
WISMO résolu en 1 message, retour portail standard sans friction, questions pré-achat routine (→ CONV-LIBRARY #299 ou REP #102).
Priorisation build
Export 12 mois : tickets tag escalade + chargeback + CSAT ≤ 2. Retenir 30 cas : 3 par famille HARD-CASE minimum. Compléter avec 2 cas/mois en revue hebdo.
Quelle fiche DIFF-CASE-01 pour documenter un litige ?
Template DIFF-CASE-01 : une page Notion par cas, reproductible en post-mortem 20 min.
Champs obligatoires
ID : DIFF-2026-042
Famille : hard_pay_dispute
Résumé 2 lignes : contexte client + enjeu €/réputation
Chronologie : dates commande, tickets, chargeback, résolution
Décisions clés : qui a décidé quoi, seuil autorité
Preuves capturées : tracking, POD, screenshots, e-mails
Outcome : CSAT, chargeback won/lost, geste €
Erreur évitée next time : sur-promesse, délai, ton
Règle ops : IF/THEN actionnable
Liens : ticket Gorgias, macro, policy URL
Exemple hard_ship_lost
Commande 890 €, tracking « livré » sans POD, client menace chargeback 13.1. Décision : replacement + investigation transporteur, pas refund immédiat. Preuves : 3 échanges, photo boîte vide. Outcome : CSAT 4, pas de chargeback. Règle : POD absent + montant > 300 € → supervisor + replacement avant refund.
Fight vs accept (chargeback)
ZandaX : évaluer preuves, montant, probabilité gain (ZandaX). Documenter dans DIFF-CASE même si accept : « service failure avéré, fight inutile ».
Comment structurer la DIFF-LIBRARY dans Notion ou Guru ?
Base searchable, permissions lecture équipe, édition lead support + ops.
Vues Notion
Par famille : board hard_*
Par outcome : won/lost/CSAT recovery
Formation : flag
onboarding_seniorÀ revoir : policy obsolète, > 12 mois
Recherche agent
Test : « chargeback 13.1 POD absent » → fiche en < 15 s. Mots-clés client dans champ « formulations » : « banque », « avocat », « arnaque », « TikTok ».
Sync Gorgias sidebar
Lien Notion/Guru dans macro ESC-DIFF-01 : « Consulter DIFF-LIBRARY [famille] avant décision refund > X € ». eDesk : edge cases internes séparés des articles publics (eDesk).
Versioning
Header fiche : date, auteur post-mortem, policy version. Policy changée → flag review_needed sur fiches liées.
Comment organiser les post-mortems après litige ou échec ?
Evergreen Support recommande 15 min/semaine d'audit tickets chargeback risk (ZandaX, audit litiges 2026). Étendre à tous les cas hard_*.
Déclencheurs post-mortem obligatoire
Chargeback déclaré (won, lost, accept)
CSAT 1-2 sur ticket hard_*
Geste > plafond sans approbation
Avis 1★ public lié à ticket existant
Déroulé 20 min
5 min : chronologie factuelle (pas blâme)
5 min : décision vs matrice #193
5 min : preuves manquantes ou suffisantes
5 min : rédiger règle ops + owner action (macro, site, process)
Output
Fiche DIFF-CASE-01 publiée sous 48 h. Action trackée Notion : macro patch, policy clarification, formation ciblée. Disputifier : playbook documenté évite rebuild ad hoc (Disputifier, playbook chargeback 2026).
Comment alimenter la bibliothèque en continu depuis QA et escalades ?
La DIFF-LIBRARY vit : 2 à 4 fiches/mois minimum sur une boutique 2 000+ tickets/m.
Sources d'alimentation
Revues QA hebdo : tickets hard_* notés < 70 % (revue QA)
Clinics escalade : 1 cas/semaine depuis formation #299
Export chargebacks : Shopify Payments disputes mensuel
Audit mensuel : audit conversations
Workflow owner
Lead support = curator DIFF-LIBRARY. Vendredi 30 min : 1 nouveau cas ou mise à jour fiche existante. Agent senior propose candidat via Slack #hard-case avec lien ticket.
Boucle policy
3 fiches même pattern (ex. retour hors délai accepté) → revue policy ou macro REP-RET. 0 fiche sur intent récurrent → gap bibliothèque.
Quels playbooks décisionnels par famille de cas difficile ?
Chaque famille HARD-CASE embarque un playbook décision résumé en tête de fiche type.
hard_pay_dispute
IF menace chargeback THEN capturer preuves ticket (voir chargebacks #86) + offrir résolution avant banque + tag chargeback_risk. Escalade supervisor si > 150 €.
hard_angry_public
IF menace avis/TikTok THEN protocole #214 + canal privé sous 2 h + pas de débat public.
hard_return_exception
IF hors délai + client fidèle THEN matrice LTV : geste partiel ou bon achat, pas refund systématique. Documenter exception dans DIFF-CASE.
hard_vip_exception
IF tag VIP THEN tier 2 under 1 h + plafond geste étendu documenté + pas de refund bot auto.
hard_regulated
IF allégation santé THEN escalade immédiate, pas de conseil médical, script REG-* (réglementé).
eesel AI : tickets « judgment » (litige, colère, VIP) → humain avec contexte, jamais auto-resolve (eesel AI, routing 2026).
Comment former l'équipe avec les cas difficiles archivés ?
La DIFF-LIBRARY sert onboarding senior et montée en compétence L1, pas seulement archive.
Parcours agent confirmé
Mois 2-3 post-J21 : 1 fiche DIFF/semaine en lecture + quiz 3 questions. Role-play depuis transcript anonymisé (format #299 CONV-RP).
Session mensuelle « cas du mois »
45 min équipe : 2 fiches récentes, discussion fight/accept, update playbook. Inviter ops ou finance sur hard_pay_dispute.
Certification tier 2
Exit criteria : résoudre 3 role-play hard_* avec score ≥ 5/6 + connaître 10 fiches DIFF core. Accès plafond geste étendu.
Bot et IA
Stormy AI : 62 % échecs IA = KB obsolète (Stormy AI, automation 2026). DIFF-LIBRARY alimente Guidance bot sur triggers escalade, pas réponses auto litiges.
Quels KPI mesurer pour une bibliothèque de cas difficiles efficace ?
Mesurez répétition et préparation, pas le volume de fiches seul.
KPI mensuels
Fiches DIFF actives : cible 30+ core, +2/mois
Repeat hard pattern : même erreur 2×/mois → 0 après règle ops
Chargeback rate : tendance vs tickets hard_pay
Representment win rate : preuves ticket complètes / total fight
CSAT hard_* : ≥ 3,8/5 recovery
Time-to-escalade : baisse si routing amélioré
Signal bibliothèque morte
0 consultation fiches 30 j → problème recherche ou ownership. Agents improvisent encore sur litiges documentés → formation insuffisante.
Comment Qstomy capitalise-t-il les cas difficiles pour l'équipe ?
Qstomy tague automatiquement les tickets litige, suggère fiches DIFF similaires au handoff et exporte post-mortems structurés.
Capacités
Détection hard_* (sentiment, montant, mots-clés chargeback). Sidebar fiche DIFF-CASE liée. Export post-mortem DIFF-CASE-01 pré-rempli. Alert repeat pattern. Sync escalade matrice #193. Bot : handoff obligatoire sur judgment tickets.
Scénario DTC chiffré
Cosmétiques DTC, 2 600 tickets/mois, 0 DIFF-LIBRARY, chargebacks 0,42 %, win rate representment 28 %, 11 tickets/mois repeat « refund promis sans policy ». Déploiement DIFF-LIBRARY 28 fiches + post-mortem hebdo + playbooks 5 familles. Après 14 semaines : chargebacks 0,31 %, win rate 41 %, repeat erreur refund −64 %, CSAT hard_* 4,0/5 (avant 3,2).
Voir support IA, Shopify, démo.
Enzo
30 juin 2026
