Traiter les demandes de remboursement dans Zendesk avant qu’elles deviennent des chargebacks

Un chargeback, c’est souvent une demande de remboursement à laquelle personne n’a répondu à temps. Le client écrit au support, attend, reçoit une réponse floue ou rien du tout, puis appelle sa banque. À partir de là, un simple remboursement devient un litige avec des frais, une date limite, une marque sur votre taux de litiges et une issue que vous ne contrôlez plus.

Ce guide montre comment configurer Zendesk pour que les demandes de remboursement soient repérées, traitées vite et tranchées de façon cohérente, et comment garder la trace dont vous aurez besoin si un litige arrive quand même. Il s’appuie sur la documentation de Zendesk sur la condition Comment text, les macros, l’intelligent triage et l’impression des tickets, et sur les pages de Stripe How disputes work, les bonnes pratiques de prévention de la fraude et les bonnes pratiques sur les preuves de litige (toutes consultées en novembre 2026). Côté paiement, Stripe sert d’exemple ; vérifiez les règles de votre propre processeur si vous en utilisez un autre.

Pourquoi la rapidité compte plus que la décision

Deux faits tirés de la documentation de Stripe expliquent pourquoi les demandes de remboursement méritent la priorité :

• Une fois un litige ouvert, la porte du remboursement se ferme. La page How disputes work de Stripe indique que vous ne pouvez pas émettre de remboursement en dehors de la procédure de litige tant qu’un litige est ouvert. Le seul moyen de le renverser est d’envoyer des preuves.
• Un remboursement total évite un litige ; un remboursement partiel, non. D’après la même page, les clients ne peuvent pas contester les paiements entièrement remboursés, mais ils peuvent contester ceux partiellement remboursés.

La question n’est donc pas seulement « faut-il rembourser ? » mais « pouvons-nous décider avant que le client aille voir sa banque ? »

Repérer les demandes de remboursement dans Zendesk

Trigger sur mots-clés

Un trigger de ticket utilisant la condition Comment text attrape la plupart des demandes. La condition regarde l’objet à la création et le dernier commentaire lors des mises à jour. Sous « Meet ANY of the following conditions », ajoutez une condition par expression :

• « remboursement », « rembourser », « prélevé deux fois », « double prélèvement »
• « pas autorisé », « je n’ai pas autorisé », « non autorisé », « je ne reconnais pas ce prélèvement »
• « litige », « chargeback », « ma banque »

Actions : ajouter le tag refund-request, passer la priorité à High, assigner au groupe facturation.

Donnez au deuxième groupe d’expressions son propre tag (charge-not-recognized). Un client qui ne reconnaît pas un prélèvement est celui qui a le plus de chances d’aller directement voir sa banque, et le plus de chances d’être un cas de fraude plutôt qu’un cas de remboursement.

Intelligent triage

Si vous avez l’intelligent triage, l’intention et le sentiment prédits peuvent router les tickets de remboursement sans listes de mots-clés. Le guide des cas d’usage de Zendesk suggère par exemple de relever la priorité des tickets très négatifs ou de les envoyer à un groupe senior. Utiliser ces prédictions dans des triggers demande l’add-on Copilot ; les classifications elles-mêmes sont disponibles sur les offres Suite et Support Professional et au-delà.

Un formulaire ou un champ facturation

Un formulaire de ticket « Facturation » avec un champ « Type de demande » (Remboursement, Prélèvement non reconnu, Question sur une facture, Résiliation) donne des données plus propres que n’importe quel mot-clé. Il ne marche que pour les tickets créés via votre centre d’aide ou votre widget : gardez donc le trigger pour l’email.

Répondre vite

Fixez pour les tickets refund-request et charge-not-recognized un objectif de délai de première réponse plus court que l’habituel, et gardez une vue de ces tickets triés par ancienneté pour que rien n’attende sans être vu. La réponse n’a pas besoin de contenir la décision. Elle doit dire au client qu’une personne s’en occupe et quand il aura des nouvelles.

Une macro de première réponse :

Bonjour {{ticket.requester.first_name}}, merci de nous avoir écrit au sujet de ce prélèvement. Je m’en occupe maintenant et je reviens vers vous d’ici [heure] avec une réponse. Inutile de contacter votre banque : nous allons régler cela directement.

Ne dites la dernière phrase que si vous la pensez et allez la tenir.

Décider de façon cohérente

Écrivez une politique de remboursement que vos agents peuvent appliquer sans escalader chaque ticket. Un tableau de décision simple :

Situation	Décision type
Prélevé après une résiliation que le client a bien demandée	Remboursement total, confirmer la résiliation
Renouvellement annuel prélevé, client qui ne s’en est pas servi après le renouvellement	Remboursement total ou au prorata, selon votre politique publiée
Prélèvement en double	Rembourser le doublon
Le client ne reconnaît pas le prélèvement, aucun compte correspondant	Escalader comme possible fraude
Le client a utilisé le service et veut être remboursé	Selon votre politique ; expliquez-la clairement si vous refusez

Deux points Stripe à garder en tête :

• Les remboursements partiels peuvent quand même être contestés. Si vous proposez un remboursement partiel, expliquez-le, et sachez que le client peut toujours contester le reste.
• Les alertes de fraude précoces. Si Stripe signale un paiement par une alerte de fraude précoce, ses recommandations de prévention de la fraude indiquent que vous pouvez rembourser de façon proactive pour éviter que le titulaire conteste, mais que rembourser automatiquement chaque alerte n’est pas une bonne stratégie. Un remboursement ne retire pas non plus un signalement de fraude des comptages des réseaux de cartes.

Écrire la décision

Quand vous remboursez :

J’ai remboursé [montant] sur votre carte se terminant par [last4]. Cela peut prendre quelques jours ouvrés pour apparaître, selon votre banque. Votre abonnement est [résilié / toujours actif jusqu’au date]. Dites-moi si quelque chose d’autre vous semble anormal.

Quand vous refusez :

J’ai examiné votre compte. Votre abonnement s’est renouvelé le [date] selon les conditions acceptées à l’inscription, que vous pouvez lire ici : [politique]. Depuis, le compte a été utilisé les [dates]. Je ne peux pas rembourser ce prélèvement, mais j’ai annulé le renouvellement pour que vous ne soyez plus prélevé. Si vous avez des questions, répondez ici et je vous aiderai.

Un refus rédigé ainsi est aussi une bonne preuve : il est factuel, daté et poli, et il montre qu’une solution a été proposée au client.

Garder la trace

Si un litige arrive quand même, le ticket fait partie de votre réponse. Les bonnes pratiques sur les preuves de Stripe vous demandent d’indiquer si le client a tenté de régler le problème avec vous avant de contester, et d’inclure les communications pertinentes sous forme d’extraits dans un seul fichier.

Depuis Zendesk :

• Un ticket : utilisez Print ticket dans le menu d’options du ticket et enregistrez en PDF depuis le navigateur. Vous pouvez choisir d’inclure ou non les notes internes ; pour des preuves, laissez-les de côté. Il n’y a pas d’impression en masse.
• Beaucoup de tickets ou de l’automatisation : Zendesk renvoie vers les API Ticket Comments et Ticket Audits, qui renvoient chaque commentaire avec son auteur et son horodatage.

Gardez les mots du client tels quels, avec les dates. Ne les modifiez pas.

Mesurer

Suivez trois chiffres chaque mois : les demandes de remboursement reçues, le délai médian de première réponse sur ces demandes, et les litiges venant de clients qui avaient un ticket de remboursement ouvert ou récent. Si ce dernier chiffre n’est pas zéro, regardez ces tickets un par un. Ils montrent généralement une réponse arrivée trop tard ou une décision jamais expliquée.

Faire tout cela avec NoChurn

Le connecteur Zendesk de NoChurn est en lecture seule : remboursements, réponses et triggers restent chez votre équipe dans Zendesk et Stripe. NoChurn lit les tickets et les rapproche des clients par email (les rapprochements douteux sont suggérés, jamais fusionnés automatiquement), et s’en sert dans le score de churn. Quand un litige s’ouvre sur Stripe ou Braintree, il réunit les preuves automatiquement, y compris des extraits datés et mot pour mot des tickets Zendesk, les réponses du parcours d’annulation, les emails envoyés et l’usage, et rédige avec l’IA une réponse qui n’est envoyée qu’après relecture par quelqu’un de votre équipe. Voir NoChurn + Zendesk.