Ce qu'est une matrice d'approbation des remboursements au support (et pourquoi un seul plafond ne suffit pas)
La plupart des équipes commencent par une seule règle : « les agents peuvent rembourser jusqu'à X $, au-delà cela va à un responsable ». Ça marche jusqu'au premier remboursement de 20 $ pour un client qui a déjà demandé six remboursements ce trimestre, ou jusqu'au premier remboursement de 400 $ qui est manifestement la faute de l'entrepôt et devrait passer en une minute.
Une matrice règle cela en ajoutant un deuxième axe. Le montant fixe l'approbateur de départ, et les signaux de risque le font monter ou descendre. Voici les dimensions que j'y mettrais, dans l'ordre où elles comptent :
| Dimension | Pourquoi c'est important | Déplace l'approbateur |
|---|---|---|
| Montant du remboursement | Le coût d'un mauvais oui | Fixe la tranche de départ |
| Dans ou hors politique | Délai de retour, vente finale, preuve de dommage | Hors politique monte d'un niveau |
| Historique de remboursements du client | Les clients qui remboursent souvent sont là où se cache l'abus | Un client qui rembourse souvent monte d'un niveau |
| Mode de remboursement | Le crédit en boutique et les remplacements gardent l'argent dans l'entreprise | Un crédit ou un remplacement peut descendre d'un niveau |
| Litige ou rétrofacturation ouvert | Rembourser maintenant peut payer deux fois | Va toujours au responsable des litiges |
Cette dernière ligne n'a rien de théorique. Stripe facture des frais de litige de 15,00 $ pour chaque litige reçu, plus 15,00 $ de plus si vous le contestez, et les frais de rétrofacturation de PayPal sont de 20,00 $ aux États-Unis. Aucun des deux prestataires ne rend non plus les frais de la transaction d'origine lorsque vous remboursez : Stripe indique que les « frais de traitement de la transaction d'origine ne sont pas restitués » dans sa documentation sur les remboursements.
Les propriétaires de boutiques Shopify apprennent la règle de la rétrofacturation à leurs dépens :
« Je connais aussi des propriétaires de boutiques qui se sont brûlés en remboursant puis en recevant une rétrofacturation. Ils perdent 3 fois (la commande, le remboursement et la rétrofacturation). Un remboursement ne garantit pas de clore ou d'empêcher une rétrofacturation. Si une rétrofacturation est en cours, ne remboursez absolument pas. »
Voici à quoi ressemble une matrice remplie avec des seuils d'exemple. Les chiffres sont un point de départ, pas une recommandation pour toutes les entreprises ; une marque de bijoux et une boutique de coques de téléphone à 12 $ ont besoin de tranches très différentes.
Construisez votre propre matrice d'approbation des remboursements
Saisissez vos propres plafonds et testez un remboursement que vous avez traité cette semaine. La matrice se redessine pendant que vous tapez, et le panneau de droite indique qui devrait approuver le cas de test et pourquoi.
Comment fixer les seuils en dollars
Le but d'un seuil n'est pas d'arrêter les mauvais remboursements. C'est de s'assurer que le coût de la vérification est inférieur au coût de l'erreur. Quand un responsable passe dix minutes sur un remboursement de 12 $, cette vérification coûte plus cher que le remboursement, et le client a attendu en ligne pour cela.
Les clients le remarquent. Un commentateur de Hacker News a décrit une entreprise où les représentants ne pouvaient autoriser que de minuscules montants :
« Les représentants du service client me disaient littéralement qu'ils ne pouvaient autoriser qu'un remboursement de 1 $. 2 $ était "trop" et exigeait toutes sortes d'approbations de responsable, et il n'y avait jamais de responsable disponible... »
À l'autre extrémité se trouve la règle d'autonomie la plus citée en support, qui revient chaque fois que ce débat surgit :
« [...] Ritz Carlton donne, c'est bien connu, à chaque employé 2 000 $ de dépenses discrétionnaires pour réparer les choses auprès d'un client sans bureaucratie. Embauchez de bonnes personnes, faites confiance aux bonnes personnes, donnez de l'autonomie aux bonnes personnes. »
La plupart des équipes se situent entre les deux, et les grands centres de contact ont tendance à empiler les niveaux. Un commentateur de r/verizon a décrit leurs plafonds ainsi : « Les superviseurs peuvent approuver jusqu'à environ 300 $ de crédits, puis ce qui reste est remonté à leurs responsables » (Reddit).
Une fois écrite, une matrice peut être étonnamment courte. Un commentateur de Hacker News a esquissé toute une politique de remboursement en trois conditions :
« Par exemple, tout client a droit à ses 2 premiers retours sans poser de questions tant que la valeur est inférieure à 200 $, 1 remboursement intégral si la valeur est inférieure à 50 $, et tous les retours inférieurs à 200 $ sont acceptés tant que le taux de retour global sur son compte est inférieur à 15 %. Si aucune de ces conditions n'est remplie, alors escalader. »
Voici comment je choisirais les chiffres de chaque tranche :
- Tranche automatique. Commencez au montant de remboursement où vous approuvez presque tout de toute façon. Sortez les remboursements du dernier trimestre, trouvez le montant en dessous duquel les responsables ont dit oui plus de 95 % du temps, et placez la ligne automatique juste en dessous. Gardez cette tranche strictement dans la politique.
- Tranche de l'agent. Une à trois commandes moyennes est un point d'arrivée courant. Les agents devraient pouvoir régler une commande normale qui s'est mal passée sans mettre personne en attente.
- Tranche du chef d'équipe. C'est ici que vivent les décisions « hors politique mais raisonnables ». Les chefs d'équipe connaissent assez bien la politique de retour pour l'assouplir une fois.
- Tranches du responsable et de la finance. Gros remboursements, crédits B2B et tout ce qui touche un contrat. Nommez une personne par tranche, pas un groupe, pour que rien ne reste coincé à « quelqu'un s'en occupera ».
Une vérification de plus : assurez-vous que vos seuils survivent à une semaine chargée. Si votre chef d'équipe est le seul approbateur de 250 à 1 000 $ et qu'il est absent, tous ces remboursements restent bloqués. Ajoutez un suppléant nommé pour chaque tranche, comme vous planifieriez le débordement du support.
Où votre helpdesk peut (et ne peut pas) appliquer la matrice
C'est là que s'arrêtent la plupart des modèles de matrice de remboursements, et là que le vrai travail commence. J'ai parcouru la documentation sur les remboursements et les autorisations des helpdesks que je vois le plus souvent dans la file d'eesel. Aucun ne documente de plafond en dollars par agent. Ce qu'ils offrent, c'est un interrupteur :
| Helpdesk | Remboursement depuis le ticket | Qui peut rembourser | Plafond en dollars par agent | Étape d'approbation |
|---|---|---|---|---|
| Zendesk | Total ou partiel via l'application Shopify (tous les plans Suite) | Non défini par agent dans la documentation | Non documenté | Demandes d'approbation à partir de Suite Professional |
| Freshdesk | Total ou partiel depuis le widget Shopify (Growth et supérieur) | Un réglage d'administrateur pour tous les agents | Non documenté | Le workflow d'approbation ne concerne que les articles de la base de connaissances |
| Gorgias | Remboursements et annulations Shopify depuis les macros et la barre latérale | Rôles Basic, Lead et Admin ; Observer et Lite ne peuvent pas | Non documenté | Aucune pour les humains |
| Gladly | Action de remboursement sur la fiche de commande, montant total uniquement | « All Agents can perform all Actions » | Non | Aucune pour les humains |
| Kustomer | Montant total, partiel ou manuel | Actions Shopify dans le jeu d'autorisations | Non documenté | L'IA transmet les remboursements de forte valeur à un humain |
| eDesk | Remboursements par article, sans dépasser le montant d'origine | Autorisation de rôle « Shopify Refunds » | Non documenté | Les procédures IA escaladent par défaut |
Quelques détails de ce tableau comptent plus qu'il n'y paraît.
L'autorisation Shopify ne suit pas les remboursements jusque dans votre helpdesk. Shopify sépare les remboursements en autorisations de personnel distinctes pour le moyen de paiement d'origine et pour le crédit en boutique, ce qui est excellent. Mais son journal des modifications indique que l'autorisation de remboursement « s'applique dans l'administration Shopify et l'application mobile, mais pas dans les autres applications Shopify ou tierces qui permettent aux utilisateurs de rembourser des commandes ». Si un agent peut rembourser depuis Gorgias ou Zendesk, le réglage de rôle du helpdesk lui-même est le seul verrou.
Gladly donne le bouton à chaque agent. Sa documentation sur les actions Shopify dit « All Agents can perform all Actions » et le remboursement depuis la fiche de commande rembourse toujours le montant total, frais de port compris (Gladly). Si vous utilisez Gladly, votre matrice vit dans la formation et le contrôle qualité, pas dans les paramètres.
eDesk ajoute un frein utile. Les remboursements « ne peuvent pas dépasser le montant d'origine », et si le montant diffère de l'original, l'agent doit choisir un motif d'écart (Discrepancy Reason) (eDesk). Ce champ de motif est le genre de piste d'audit que je voudrais partout.
Zendesk est ce qui se rapproche le plus d'un véritable objet d'approbation. Sur Customer Service Suite Professional et supérieur, un agent peut déposer une demande d'approbation sur un ticket, et l'exemple de Zendesk lui-même est un remboursement qui va au chef d'équipe de l'agent. Les détails sont intéressants pour une matrice de remboursements : jusqu'à 5 approbateurs par demande, l'approbateur ne peut être ni le demandeur ni la personne assignée, et une approbation en attente empêche la clôture du ticket (Zendesk). Ce qu'il ne fait pas, c'est choisir l'approbateur pour vous en fonction du montant. L'agent lit toujours la matrice et choisit.
En pratique, la partie helpdesk de la matrice se résume donc à trois réglages : qui a l'autorisation de rembourser (voir mes notes sur le contrôle d'accès des agents de support), une macro ou un formulaire qui oblige les agents à consigner le motif, et une étiquette de ticket sur laquelle vous pouvez produire des rapports.
Zendesk ajoute automatiquement une étiquette shopify_refund lorsqu'un agent rembourse depuis l'application Shopify (Zendesk), ce qui facilite la revue trimestrielle.
Appliquez la limite en dollars dans la couche de paiement
Si vous avez besoin d'une limite stricte qu'une personne ne peut pas franchir d'un clic, elle doit vivre là où l'argent circule. Voici ce que chaque outil de paiement ou de commerce peut réellement appliquer :
| Outil | Qui peut rembourser | Seuil de montant appliqué ? | Approbation intégrée | Délai de remboursement |
|---|---|---|---|---|
| Stripe | Rôles tels que Refund Analyst, Support Associate, Support Specialist | Oui, une condition de montant sur « Refund is created » (préversion publique) | Exiger une approbation ou bloquer ; les demandes expirent après 14 jours | Limite de carte non indiquée dans la documentation sur les remboursements |
| PayPal | Jusqu'à 200 utilisateurs secondaires avec des autorisations définies par le propriétaire | Non documenté | Non documenté | 180 jours, total ou partiel |
| Administration Shopify | Autorisations distinctes pour le paiement d'origine et le crédit en boutique | Non, activé ou désactivé uniquement | Le personnel approuve ou refuse les demandes de retour ; POS Pro peut exiger un code PIN de responsable | Le marchand définit 14, 30, 90 jours ou une durée personnalisée |
| Loop Returns | Équipe du marchand | Oui, règles selon la valeur du retour ou de la commande | Action Manual Review | Défini par le marchand |
Stripe se démarque. Ses approbations à deux personnes permettent à un administrateur d'ajouter une règle sur « Refund is created » avec une condition de montant, de sorte que l'approbation se déclenche « uniquement si le montant dépasse un seuil ». Le contrôle est soit Require approval, qui met le remboursement en pause jusqu'à ce qu'un réviseur l'approuve, soit Block. « A user can't approve their own request », les demandes restées 14 jours expirent, et une seule règle active peut s'appliquer à une action donnée, donc vous exprimez les niveaux par des conditions combinées plutôt que par une échelle de règles. Stripe fournit aussi des règles d'approbation par défaut sur les remboursements créés par des clés d'API marquées comme agent, ce qui en dit long sur la façon dont les entreprises de paiement pensent l'IA et l'argent.
Shopify est un interrupteur, pas un cadran. Les autorisations de la boutique listent « Refund to original payment method » et « Refund to store credit » comme des autorisations distinctes, sans limite de montant dans l'une ou l'autre description. Cette séparation reste utile : vous pouvez laisser les nouveaux agents rembourser uniquement en crédit en boutique. Notez aussi que « you can't cancel or reverse a refund after you initiate a refund » dans Shopify (Shopify), donc un mauvais oui est définitif.
Les applications de retours peuvent gérer l'acheminement par valeur. Les workflows de Loop peuvent acheminer selon le total du retour, le total de la commande, l'étiquette du client ou le motif du retour, et envoyer une demande en Manual Review. L'exemple de Loop lui-même envoie les retours de plus de 300 $ en révision manuelle pour que l'entrepôt inspecte d'abord les articles de forte valeur.
Si les retours génèrent la plupart de vos remboursements, c'est ici que le haut de votre matrice doit se trouver, et cela se combine bien avec les outils de retours dont j'ai déjà parlé. Mon guide d'automatisation des retours couvre le reste de ce flux.
Empêchez les approbations de devenir le goulot d'étranglement
Une matrice d'approbation échoue en silence quand les approbations traînent. Le client ne voit pas votre organigramme, il voit une mise en attente :
« J'ai dû vérifier avec mon superviseur pour obtenir l'approbation du remboursement, parce que leur commande complète dépassait un peu ce que je peux approuver moi-même. J'ai dit que je les mettrais brièvement en attente. Le superviseur a eu besoin d'une minute, donc j'ai attendu. »
Et quand le seuil est fixé trop bas, les approbateurs s'en agacent aussi :
« [...] il ne devrait pas être nécessaire d'attendre 15 minutes l'approbation du directeur du magasin pour un remboursement de 37 centimes, et il ne devrait même pas avoir à s'en occuper, c'est une perte de son temps et de son salaire de s'occuper de quelque chose d'aussi mineur. »
Voici ce qui garde la matrice rapide :
- Placez l'approbation là où l'approbateur travaille déjà. Zendesk a ajouté les approbations dans Slack en mai 2026, et les approbateurs peuvent désormais y laisser des commentaires aussi. Une approbation qui vit dans une boîte de réception que personne n'ouvre est un remboursement qui ne part jamais.
- Donnez à chaque tranche un objectif de délai d'approbation. Zendesk ne documente aucun rappel natif pour les demandes d'approbation, donc créez une vue ou une automatisation qui signale les approbations en attente après quelques heures.
- Rédigez le contexte une seule fois. L'approbateur doit voir la commande, le montant, la ligne de politique enfreinte et la recommandation de l'agent. Zendesk limite la description de la demande à 2 500 caractères, ce qui est largement suffisant avec un modèle.
- Ne laissez jamais le demandeur approuver. Zendesk empêche la personne assignée d'approuver, Stripe empêche l'auto-approbation, et HubSpot fait de même pour les devis. Si votre outil ne le fait pas, faites-en une règle.
- Décidez ce que signifie l'expiration. Stripe fait expirer les demandes après 14 jours. Décidez à l'avance si une approbation expirée vaut un non ou monte d'un niveau, et dites au client lequel des deux c'était.
Donnez à votre agent IA une ligne dans la matrice
C'est la partie que la plupart des politiques de remboursement n'ont pas encore rattrapée, même dans les équipes qui utilisent déjà l'IA pour les demandes de remboursement. Si un agent IA peut toucher aux commandes, il lui faut sa propre tranche dans la matrice, et cette tranche doit être plus étroite que celle d'une nouvelle recrue.
Le meilleur cadrage que j'aie lu à ce sujet vient d'un fil sur ce que les gens laissent faire aux agents IA sans approbation :
« la ligne que j'ai fini par tracer n'était pas le niveau de risque de l'action, mais la possibilité de l'annuler. l'argent s'est avéré facile, on rembourse. [...] un mauvais remboursement, c'est un mauvais après-midi. un mauvais message reste dans la boîte de quelqu'un pour toujours et il n'y a pas de bouton annuler pour ça. »
Je suis d'accord avec le test de réversibilité, avec une réserve : dans Shopify et PayPal, un remboursement envoyé ne peut pas être annulé. Donc pour les remboursements, « annuler » veut dire « absorber le coût », et c'est exactement à cela que servent les tranches en dollars. Un autre commentateur de Hacker News a décrit la configuration que la plupart des équipes finissent par vouloir : une IA qui « prépare une recommandation et un humain passe l'approuver ou la refuser » (lubujackson, Hacker News).
Chaque décision de remboursement de l'IA doit aboutir à l'un de trois endroits. C'est une conception human-in-the-loop appliquée à l'argent, et c'est le garde-fou IA que je mettrais en place avant tout autre :
Les éditeurs ont convergé vers ce schéma, avec des leviers différents :
| Outil IA | Comment les remboursements s'exécutent | Où se trouve le garde-fou |
|---|---|---|
| Zendesk Copilot auto assist | Annule et rembourse les commandes Shopify après acceptation par un agent | Zendesk indique que les actions de remboursement « should be marked as agent-approved » |
| Gorgias AI Agent | Remboursements dans le cadre d'une annulation, d'un retrait d'article ou d'un remplacement d'article | Conditions d'action sur le total de la commande ; confirmation du client activée par défaut pour les actions irréversibles |
| Richpanel | Un outil Refund Order | « Require approval » par outil ; remboursements bornés par le total de la commande et la politique |
| Kustomer AI Agent | Remboursements et retours | Au-delà d'une valeur définie, un humain approuve, puis l'IA termine la conversation |
| Gladly AI | Remboursements totaux ou partiels | Montant présenté puis confirmé au préalable avec le client |
| eDesk AI Agent | Résultat « Approve Refund » dans les procédures | Le résultat par défaut est d'escalader à un humain |
Deux d'entre eux méritent un examen plus attentif. La documentation sur les actions de Zendesk avertit que les actions préapprouvées « may be executed in a different order than specified », ce qui est la raison documentée de ne pas préapprouver les remboursements. Et la confirmation du client chez Gorgias est une confirmation de l'acheteur, pas d'un responsable. Elle évite les annulations accidentelles, mais ce n'est pas une approbation interne. Les actions de Gorgias AI Agent ne sont pas non plus incluses dans le plan Starter, d'après la page de tarifs de Gorgias, et chaque interaction automatisée coûte de 0,85 $ à 1,00 $ selon le plan. Mon détail des tarifs de Gorgias AI Agent contient le tableau complet.
La version de Kustomer est celle que je copierais pour le retour vers l'IA : l'humain approuve le remboursement, laisse une note à l'IA, et l'IA informe le client et clôt la conversation.
Comment j'écrirais la tranche IA avec eesel
Dans eesel, chaque action que le coéquipier IA peut effectuer a l'un de trois réglages par agent : Auto, Needs approval ou Disabled (documentation eesel). La connexion Shopify inclut Refund Order et Cancel Order comme actions d'écriture, et rien ne change dans une boutique tant que vous ne créez pas une automatisation et ne les activez pas (intégration Shopify).
La matrice elle-même va dans les instructions de l'agent, en langage courant. La documentation fournit un modèle d'escalade qui inclut « The conversation involves a refund over $100 », et un modèle d'exceptions avec des lignes comme « Damage claims under $50: skip the photo request, approve the refund » (documentation des instructions). Un administrateur de support avec qui j'ai travaillé a appris à son agent une règle qui passe avant toute tranche en dollars :
« J'ai une règle au CS selon laquelle nous ne traitons pas une demande d'annulation ou de remboursement lorsqu'un problème y est associé. »
Un administrateur de support qui encode dans l'agent une politique « dépannez avant d'annuler »
Quand un remboursement a besoin d'un oui, l'approbateur reçoit une carte montrant l'action exacte et le montant, avec Approve, Always allow ou Deny. Les approbations ne s'exécutent jamais d'elles-mêmes après un délai, et la page Activity enregistre qui a décidé et quand.
Si vous préférez approuver depuis Slack, la même demande apparaît dans le fil avec les boutons Approve, Deny et Review, ce qui garde l'approbation dans la journée de l'approbateur. Plus de détails dans mon guide de l'escalade par IA.
Erreurs courantes dans une matrice de remboursements
Ce sont celles que je vois le plus souvent dans la file, à peu près par ordre de coût :
- Une seule ligne en dollars, pas de colonne de risque. Un plafond unique approuve le remboursement de 20 $ de votre client le plus fréquent et bloque celui de 300 $ qui est manifestement de votre faute. Les deux font mal : l'un fait fuir l'argent, l'autre pousse un bon client vers le désabonnement. Ajoutez au moins les colonnes hors politique et client qui rembourse souvent.
- Supposer que le helpdesk l'applique. À moins d'avoir configuré les approbations Stripe ou un réglage d'action de l'IA, vos plafonds sont une politique, pas un contrôle. Auditez les remboursements par agent chaque mois à l'aide de l'étiquette ou du rapport de remboursements.
- Des approbateurs qui sont des groupes. « Le canal des chefs d'équipe » n'est pas un approbateur. Nommez une personne et un suppléant pour chaque tranche, et inscrivez-le dans votre processus d'escalade.
- Traiter le crédit en boutique comme de l'argent. Le crédit en boutique garde l'argent dans l'entreprise. Donnez-lui une tranche plus souple et les agents l'offriront davantage, ce qui est souvent ce que le client voulait de toute façon. Mes macros de remboursement montrent comment formuler cette offre.
- Aucun responsable des rétrofacturations. Un remboursement émis après l'ouverture d'un litige peut payer deux fois et coûte quand même les frais de litige. Acheminez les rétrofacturations vers une seule personne, à chaque fois.
- Ne jamais revoir les tranches. Si votre chef d'équipe a approuvé 98 % de sa tranche le trimestre dernier, la tranche est trop basse. Traitez la matrice comme une politique de support vivante et mettez à jour les agents et l'IA le même jour.
Faites tourner votre matrice de remboursements avec eesel
Si vos remboursements arrivent par Zendesk, Freshdesk ou Gorgias avec une boutique Shopify derrière, le coéquipier IA helpdesk d'eesel est le moyen le plus simple de rendre la matrice réelle. Il rejoint votre file existante, apprend de vos anciens tickets, de votre centre d'aide et de vos macros, et exécute les remboursements de votre tranche automatique. Tout ce qui dépasse un seuil que vous écrivez en langage courant attend l'approbation de la bonne personne, dans le tableau de bord ou dans Slack, et tout ce qui sort de la politique va à votre équipe avec une note expliquant ce qu'il a trouvé.
Avant qu'il ne touche un vrai remboursement, vous pouvez lancer une simulation sur vos anciens tickets et voir comment il aurait traité vos demandes de remboursement par rapport à ce que votre équipe a réellement fait. La tarification se fait par ticket traité avec des postes illimités, donc chaque approbateur de votre matrice peut avoir accès sans coût supplémentaire.
Commencez avec 100 crédits gratuits, connectez votre boutique Shopify et votre helpdesk, et réglez Refund Order sur Needs approval dès le premier jour. Essayez eesel.