Gestion des exceptions au support : comment accorder, consigner et tirer des leçons des dérogations aux politiques

En bref

La gestion des exceptions au support, ce sont trois tâches : décider qui a le droit d'assouplir quelle politique, consigner chaque exception de la même façon et passer le registre en revue pour que les exceptions répétées deviennent des règles. La plupart des équipes font la première à moitié et sautent les deux autres, ce qui explique pourquoi un même client obtient un oui d'un agent et un non du suivant.

Le changement que je défends : une exception que vous accordez la plupart du temps est déjà votre politique, elle n'est simplement pas écrite. Et l'endroit pour la repérer n'est pas une note interne. C'est un champ à liste déroulante obligatoire sur lequel votre helpdesk peut produire des rapports. Attention aux pièges : le « requis pour résoudre » de Zendesk peut être contourné par les déclencheurs, les automatisations et les fusions, et le rapport sur les champs de ticket de Gorgias ne compte que les champs à liste déroulante.

Je travaille chaque jour dans la file de support d'eesel, et pour les exceptions, les agents comme l'IA ont besoin des règles les plus claires. Dans un essai sur du trafic réel, sur une boîte de réception Zendesk d'e-commerce, 96,4 % des brouillons d'eesel sur les demandes de garantie ont été utiles à l'agent. C'est pour cela que le coéquipier IA d'eesel existe : il applique les exceptions que vous avez écrites, retient pour la bonne personne tout ce qui coûte de l'argent et confie le reste à votre équipe avec une note.

Ce qui compte comme exception au support

Une exception, c'est chaque fois qu'un agent donne à un client quelque chose que la politique écrite ne prévoit pas. Certaines sont minuscules, d'autres coûtent de l'argent, mais toutes ont un point commun : elles reposent sur un jugement, si bien que deux agents peuvent trancher différemment sur le même ticket.

Voici celles que je vois le plus souvent dans la file, avec la politique qu'elles assouplissent :

Cette dernière colonne compte plus qu'il n'y paraît. La plupart des équipes ont une matrice d'approbation des remboursements ou au moins un plafond en dollars pour les remboursements. Très peu ont la même clarté pour le reste du tableau, si bien que les exonérations de frais et les avoirs commerciaux sont décidés à l'humeur.

Pourquoi les exceptions non gérées coûtent plus cher que les exceptions elles-mêmes

Le coût d'une exception n'est pas seulement l'avoir de 10 $. C'est ce qui se passe quand les exceptions sont incohérentes, invisibles et impossibles à revoir.

Les clients apprennent à chercher un autre agent. Si la réponse dépend de qui décroche, le bon réflexe est de redemander. Les gens le disent ouvertement :

"I've learned to play customer service roulette.

Don't get the answer I'm looking for?

Hang up and call back."

sirspacey, Hacker News

Les exceptions se cachent dans d'autres catégories. Quand les agents n'ont pas de moyen autorisé d'accorder quelque chose, ils en trouvent un non autorisé. Un commentateur a décrit comment cela se passe dans les banques et chez les émetteurs de cartes :

"If you're not yelling at them, you can often get what you want via some other method (which only they know) - like them reclassifying the problem to something else they have leeway for."

bombcar, Hacker News

Ce ticket reclassé apparaît désormais dans vos rapports comme autre chose que ce qu'il était. Votre étiquetage des tickets est faux et l'exception est invisible.

Les exceptions promises disparaissent. La pire version est une exception convenue mais jamais consignée. Un client sur r/Comcast_Xfinity a raconté avoir trouvé une solution au téléphone avec le support : "they said they would note this on my account. I reached back out after a week to confirm the notes on the account an there is no record of the solution offered" (cali1302, Reddit). L'agent suivant doit alors choisir entre honorer une promesse qu'il ne voit pas ou traiter le client de menteur.

Les petits refus deviennent de gros précédents. L'exemple le plus connu est l'affaire du chatbot d'Air Canada, où un remboursement pour deuil refusé s'est retrouvé devant un tribunal. Un commentateur de Hacker News l'a résumé ainsi : cela "should've been well within some second-tier customer service manager's discretionary refund budget. Instead they've got a precedent-setting ruling that makes the chatbot a huge liability" (ceejayoz, Hacker News).

La boucle de gestion des exceptions au support

Chaque exception devrait passer par les mêmes cinq étapes. Celle que la plupart des équipes sautent est la dernière flèche, de la revue mensuelle vers la politique écrite. Sans elle, vous accordez la même exception 40 fois par mois pour toujours sans jamais remarquer qu'elle aurait dû devenir une règle.

Le reste de ce guide parcourt la boucle dans l'ordre : qui décide, comment consigner, quels outils gèrent déjà les exceptions ponctuelles, comment revoir, et comment donner à votre agent IA les mêmes règles que celles de vos équipes.

Étape 1 : Décidez qui peut accorder quoi

Commencez par trier les exceptions selon deux questions : à qui la faute, et combien ça coûte ? Ces deux réponses indiquent qui doit décider bien mieux qu'un simple plafond en dollars.

La case en bas à gauche est celle que les gens ratent. Si un envoi est arrivé en retard à cause de vous et que la solution coûte moins que le temps nécessaire pour l'approuver, ce ne devrait pas être une exception du tout. Un employé de magasin a bien formulé l'argument de la masse salariale :

"Especially on clothes that have a ridiculously high margin, it's costs more money in payroll wasting that time than just giving them a BOGO."

Rhewin, Reddit r/TalesFromRetail

Pour tout le reste, donnez à chaque rôle un budget de discrétion écrit. Les banques fonctionnent déjà ainsi. Comme l'a dit un commentateur, "most banks/credit cards let the first-level hit the 'refund one fee' button, and the higher up you get, the more discretion they have" (bombcar, Hacker News). Le budget doit dire trois choses :

1. Ce que le rôle peut accorder seul. Par exemple : une exonération de frais par client et par an, des avoirs commerciaux jusqu'à 15 $, des retours jusqu'à 7 jours après le délai.
2. Ce qu'il ne peut pas accorder du tout. Dérogations à la vente finale, avoirs contractuels, tout ce qui touche à une contestation de paiement en cours.
3. À qui demander le reste. Une personne nommée et une suppléante, pas « le canal des leads ». Si vous voulez réviser le routage, mon guide sur le processus d'escalade des tickets le couvre.

Une chose de plus à écrire : à quoi sert l'exception. Sans cela, la discrétion dérive vers celui qui insiste le plus. Un agent sur r/talesfromcallcenters décrivait des superviseurs qui "pick to be nice to rude people and give hard stops to really nice people" (Asha990, Reddit). Une ligne comme « les avoirs commerciaux sont pour les défaillances de service de notre côté, pas pour récompenser l'insistance » règle bien des débats avant qu'ils ne commencent.

Étape 2 : Consignez chaque exception dans un champ, pas dans une note

C'est la partie que presque tous les guides sur les exceptions sautent. Une note sur le ticket (« remboursement commercial exceptionnel accordé ») vaut mieux que rien, mais on ne peut pas compter des notes. Pour revoir les exceptions, il vous faut des données structurées, ce qui, dans un helpdesk, veut dire des champs de ticket personnalisés.

Le schéma que je mettrais en place comprend quatre champs, dont trois n'apparaissent que si le premier est sur Oui :

• Exception accordée : une liste déroulante avec Non et Oui. Rendez-la obligatoire à la clôture du ticket.
• Type d'exception : une liste déroulante avec les types du tableau ci-dessus.
• Motif de l'exception : une liste déroulante de motifs (retard du transporteur, article endommagé, notre erreur, situation du client), plus une option « autre ».
• Valeur et approbateur : un champ numérique pour le coût et une liste déroulante des noms d'approbateurs.

Les listes déroulantes l'emportent sur le texte libre pour une raison simple. La documentation de Zendesk elle-même dit que les valeurs des champs texte "peuvent être incohérentes ou contenir des fautes d'orthographe", ce qui les rend "moins utiles pour les rapports" (Zendesk). Le conseil de Freshdesk est le même : "favor dropdowns over text fields where possible" (Freshdesk).

Ce que prend en charge chaque helpdesk

Tous les grands helpdesks savent faire une version de cela, mais les restrictions de formule et les limites diffèrent beaucoup. Voici ce que dit la documentation aujourd'hui :

Dans Zendesk, la partie « afficher seulement si Oui » est un champ conditionnel. L'éditeur de conditions permet aussi de rendre les champs dépendants obligatoires selon le statut, de sorte que le Type d'exception ne devient obligatoire qu'une fois le ticket résolu :

Gorgias fait la même chose avec des conditions de champ, sur toutes les formules Helpdesk :

Quatre pièges dans les petites lignes

Ce sont les détails qui cassent discrètement un registre d'exceptions six semaines après sa mise en place :

1. Le champ obligatoire de Zendesk a des trous. Le réglage est présent sur chaque champ, mais la documentation de Zendesk dit que les champs obligatoires "peuvent être contournés par les déclencheurs et les automatisations" et sont "aussi contournés lorsqu'un agent fusionne un ticket" (Zendesk). Leur contournement suggéré est une étiquette okay_to_close que votre automatisation de clôture attend.
2. Gorgias ne produit des rapports que sur les listes déroulantes. Son rapport sur les champs de ticket "ne suit que les champs de ticket personnalisés de type liste déroulante", donc les champs Nombre, Texte et Oui/Non n'apparaissent pas (Gorgias). Faites d'Exception accordée une liste déroulante, pas un champ Oui/Non. Gorgias note aussi que son AI Agent "peut clôturer un ticket sans avoir rempli un champ de ticket obligatoire" (Gorgias).
3. Help Scout vérifie à la réponse, pas à la clôture. Les champs personnalisés obligatoires doivent être remplis "lors de l'envoi d'une réponse", et les données du champ ne suivent pas si la conversation passe dans une autre boîte de réception (Help Scout).
4. Supprimer un champ supprime votre historique. Freshdesk indique que retirer un champ "le masque dans Analytics", et Help Scout indique que supprimer un champ efface ses données "pour toujours". Archivez les anciens types d'exception au lieu de les supprimer.

Un bonus pour les équipes Zendesk en Suite Professional ou supérieur : le jeu de données Updates history d'Explore peut suivre l'évolution des valeurs de champs dans le temps (Zendesk), ce qui répond à « qui a passé ceci sur Oui, et quand ». Ma recette Explore pour les champs personnalisés détaille le rapport.

Étape 3 : Utilisez les outils qui gèrent déjà les exceptions ponctuelles

Votre helpdesk consigne l'exception. Mais l'action elle-même se passe souvent dans un autre outil : l'application de retours, l'administration de la boutique, le système de facturation. Plusieurs d'entre eux ont un vrai mécanisme d'exception intégré, et l'utiliser vaut mieux qu'un agent qui contourne les règles.

Loop est le modèle le plus clair. Sa fonction Listings existe "pour gérer les exceptions et restrictions de retour", et autoriser une commande "passe outre toute entrée de la liste de blocage, les produits étiquetés Final Sale ou le délai de retour de la commande" (Loop). J'aime encore plus la bonne pratique de Loop elle-même : autoriser la commande, soumettre le retour pour le client, puis retirer aussitôt l'entrée de la liste. Une exception temporaire qui se nettoie toute seule, c'est exactement ce qu'on veut. Loop invite aussi les acheteurs hors délai à "contact your support team directly for any exceptions" (Loop) : ces tickets arriveront donc dans votre file, que vous l'ayez prévu ou non.

Loop Workflows transforme les exceptions répétées en règles. Quand la revue de l'étape 4 indique qu'une exception doit devenir politique, Workflows peut l'appliquer automatiquement, avec des actions comme Bypass final sale, Set return window et Set handling fee pour "remplacer, compléter ou supprimer les frais existants" (Loop Workflows). J'en ai dit plus dans mon guide sur l'automatisation des retours.

Les règles de Shopify peuvent porter les exceptions que vous connaissez déjà. Les remplacements de délai de retour permettent d'accorder 14 jours aux articles soldés et 90 aux meubles, et les articles en vente finale sont décrits comme des "exceptions à vos règles de retour par défaut" (Shopify). Ce que je n'ai pas trouvé dans la documentation de Shopify, c'est un interrupteur pour rendre une commande éligible quand les règles disent non. La voie documentée est un retour créé par le personnel dans l'administration, où les frais peuvent être modifiés par retour.

Le solde créditeur de Stripe est un avoir commercial avec une piste d'audit intégrée. Chaque solde client est "calculé à partir d'un registre, une liste immuable de transactions de débit et de crédit" (Stripe). Chaque ajustement peut porter une note interne que le client ne voit jamais, et les entrées ne peuvent pas être supprimées, seulement annulées. Si les avoirs commerciaux de votre produit SaaS vivent ailleurs, ils sont plus difficiles à auditer qu'ils ne devraient l'être.

Étape 4 : Revoyez le registre et promouvez les exceptions répétées

C'est là que la gestion des exceptions devient rentable. Une fois par mois, extrayez tous les tickets avec Exception accordée sur Oui et regroupez-les par type et par motif. Pour chaque groupe, vous vous posez une seule question : est-ce une vraie exception ou une règle non écrite ?

Du côté du client, les exceptions non revues paraissent aléatoires. Un commentateur, après avoir obtenu un geste d'un superviseur, a écrit : "There's no particular rhyme or reason for why extraordinary relief is sometimes granted though, it seems completely random!" (gnicholas, Hacker News). Du côté de l'équipe, c'est pire : vous dépensez du temps d'approbateur sur des décisions que vous prenez toujours de la même façon.

Choisissez un type d'exception du mois dernier et saisissez ses chiffres ici :

Les seuils du widget (10 demandes par mois, 80 % accordées) sont mon point de départ, pas une norme du secteur. Ajustez-les à votre volume. L'essentiel est que la revue aboutisse à l'une de quatre décisions, et que chaque décision change quelque chose :

• En faire la politique. Mettez à jour la politique écrite et le centre d'aide, mettez à jour vos macros et prévenez les agents et votre agent IA le jour même. Mon guide sur la gestion des changements de politique de support couvre le déploiement.
• La garder à la discrétion de l'agent. Laissez-la dans le budget, mais continuez à la consigner.
• L'envoyer à un approbateur désigné. Coût élevé, ou un schéma pour lequel vous voulez un second regard.
• Scénariser le non. Si vous refusez une demande 80 % du temps, les 20 % de oui apprennent aux clients à continuer à demander. Comme l'a dit un employé de magasin, "They are getting something out of it, so it continues" (Cheshire1871, Reddit).

La revue alimente aussi deux autres boucles. Les agents dont le taux d'exceptions s'écarte fortement de la moyenne de l'équipe relèvent d'une discussion de coaching, et c'est là qu'interviennent la calibration QA du support et le feedback aux agents. Et un pic sur un motif, comme les retards de transporteur, est un problème d'exploitation que le support paie discrètement. Signalez-le avec le reste de votre analyse des tickets de support.

Étape 5 : Donnez à votre agent IA des règles d'exception écrites

Les agents IA rendent la gestion des exceptions plus urgente, pas moins. Une personne peut sentir la situation et assouplir discrètement une règle. Un agent IA soit suivra les règles que vous avez écrites, soit improvisera, et les deux défaillances se voient en public.

La première crainte est que les clients convainquent l'IA de faire des exceptions :

"People will find out how to convince the LLM you do meet the requirements for a refund.

And if you check the requirements using something deterministic (last order was within last 2 weeks, customer has a high loyalty points score, they're subscribed to some premium service) then why do you need an agent at all?"

graypegg, Hacker News

L'échec inverse est tout aussi grave : un bot qui ne peut pas accorder d'exception et ne laisse pas le client joindre quelqu'un qui le peut. Un client a décrit un chat de support IA qui proposait sans cesse de résilier à la fin de la période de facturation : "I ask for human. It repeats. I ask for human again. It repeats. I disconnect" (kldg, Hacker News).

La réponse aux deux est la même que pour les personnes. Écrivez les exceptions que l'IA peut appliquer sous forme de règles simples, donnez-lui une limite ferme sur tout ce qui engage de l'argent et assurez-vous que toute autre demande d'exception parvienne à un humain avec du contexte. Ce sont des garde-fous IA appliqués à la politique, et le parcours d'escalade IA en est la moitié.

Les principaux outils d'IA de helpdesk prennent désormais en charge cette approche :

Le constructeur de procédures de Zendesk donne une bonne image de ce qu'est « écrire l'exception » pour une IA. Vous décrivez la politique en langage courant, et il construit une carte arborescente avec une vérification avant toute action irréversible (Zendesk) :

La documentation de Zendesk est aussi honnête sur la limite : le contexte d'une procédure ne peut pas "garantir le comportement exact de l'IA", et tout ce qui doit bifurquer devrait utiliser un bloc Check condition (Zendesk). C'est le bon instinct. La formulation guide l'IA, mais les limites fermes sur l'argent relèvent des réglages d'actions.

Comment j'écrirais des règles d'exception avec eesel

Dans eesel, les exceptions vont dans les instructions de l'agent en langage courant, comme vous briefiez une nouvelle recrue. La documentation propose un modèle « Cover exceptions and edge cases » avec des lignes comme « Réclamations pour dommages sous 50 $ : sauter la demande de photo, approuver le remboursement » et « Commandes passées depuis moins d'une heure : les annulations n'ont pas besoin d'approbation », plus une règle selon laquelle les clients étiquetés VIP sont toujours escaladés (documentation eesel). Le modèle d'escalade couvre l'autre moitié : laisser une note interne qui dit « ce que veut le client, ce que vous avez trouvé et ce que vous auriez répondu », puis l'assigner à une personne.

Vous pouvez aussi corriger l'agent comme vous corrigeriez une personne. Un administrateur de support avec qui j'ai travaillé a appris à son agent une règle qui est en réalité une politique d'exception : une demande d'annulation ou de remboursement accompagnée d'un problème non résolu reçoit d'abord un dépannage :

"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."

Un administrateur de support qui intègre à l'agent une politique « dépannez avant d'annuler »

Pour tout ce qui coûte de l'argent, ce sont les réglages d'actions qui font respecter la règle. Chaque action a l'un de trois réglages par agent : Auto, Needs approval ou Disabled (documentation eesel). Vous pouvez laisser une action sur Auto et dire quand même à l'agent de demander d'abord dans des situations précises, ce qui fait d'une politique d'exception écrite une vraie barrière. Quand une approbation est nécessaire, l'approbateur voit l'action exacte et le montant, et les approbations ne s'exécutent jamais d'elles-mêmes après un délai.

La page Activity enregistre qui a approuvé quoi et quand, ce qui sert de registre d'exceptions pour tout ce que l'IA a touché.

Erreurs courantes de gestion des exceptions

Voici celles que je corrigerais en premier, à peu près dans l'ordre de ce qu'elles coûtent :

1. Consigner les exceptions dans des notes. On ne peut pas compter des notes. Utilisez une liste déroulante obligatoire et, dans Gorgias, assurez-vous que c'est une liste déroulante et non un champ Oui/Non.
2. Pas de budget de discrétion. Sans budget, chaque agent invente le sien, et les clients apprennent à demander à un second agent. Écrivez ce que chaque rôle peut accorder.
3. Traiter les exceptions dues à notre faute comme des faveurs. Un avoir pour livraison tardive que vous accordez à chaque fois devrait être une règle. Faire demander les clients ne fait qu'ajouter des tickets et nuit au CSAT.
4. Ne jamais boucler la boucle. Si la revue mensuelle ne change ni la politique, ni le centre d'aide, ni les macros, ce n'est qu'un rapport. Chaque type d'exception devrait sortir de la revue avec une décision.
5. Laisser l'IA improviser. Un agent IA sans règles d'exception écrites dit non à tout ou oui aux mauvaises choses. Donnez-lui des règles, une limite d'argent et un parcours d'escalade propre.
6. Supprimer d'anciens champs. Archivez les types d'exception retirés pour que les données de l'an dernier apparaissent toujours dans les rapports.

Gérez les exceptions au support avec eesel

Si votre équipe tourne sur Zendesk, Gorgias ou Freshdesk, le coéquipier IA de helpdesk d'eesel est le moyen le plus direct de faire tenir vos règles d'exception. Il rejoint votre file existante, apprend de vos anciens tickets, de votre centre d'aide et de vos macros, et suit les exceptions que vous écrivez en langage courant. Tout ce qui coûte de l'argent attend l'approbation de la bonne personne, dans le tableau de bord ou dans Slack, et tout ce qui sort de vos règles va à votre équipe avec une note expliquant ce que veut le client et ce qu'il a trouvé.

Avant qu'il ne traite une vraie exception, vous pouvez lancer une simulation sur vos tickets passés et comparer ses réponses avec ce que votre équipe a réellement envoyé. La tarification est au ticket avec des places illimitées, donc chaque approbateur peut avoir accès, et vous pouvez commencer avec 100 crédits gratuits et sans carte. Essayez eesel.