Utiliser les tickets Zendesk comme preuves dans un chargeback

Quand un abonné conteste un prélèvement, votre historique de support est souvent la preuve la plus solide dont vous disposez. Un ticket où le client a posé une question sur le produit après le renouvellement, ou un ticket où vous avez confirmé sa résiliation et l’avez remboursé, peut trancher le dossier. Un ticket reformulé, mal caviardé ou exporté sans dates vaut beaucoup moins.

Ce guide explique ce qui rend un ticket Zendesk utile comme preuve, comment configurer champs et macros pour que les bons faits soient enregistrés sur le moment, et comment sortir les tickets de Zendesk sous une forme lisible par un examinateur du réseau de cartes. Les fonctions de Zendesk viennent de sa propre documentation : imprimer des tickets, exporter des données, champs de ticket personnalisés, actions de macro, caviardage et les API Ticket Audits et Ticket Comments. Les champs de litige viennent des catégories de litiges et des bonnes pratiques sur les preuves de Stripe (tous consultés en novembre 2026).

Ce que cherche un examinateur

Un litige est tranché par quelqu’un chez la banque émettrice qui n’a jamais entendu parler de votre produit et a quelques minutes pour lire votre dossier. Pour les litiges d’abonnement, les questions sont généralement simples :

• Le client savait-il qu’il serait prélevé ?
• A-t-il essayé de résilier, et si oui, quand, et que s’est-il passé ?
• A-t-il continué à utiliser le service après le prélèvement ?

Pour la catégorie « subscription canceled », la page des catégories de litiges de Stripe vous oriente vers le champ cancellation_rebuttal (pourquoi l’abonnement n’a pas été résilié, ou pourquoi le prélèvement reste valable) et customer_communication (les échanges montrant que le client a continué à utiliser le service ou était au courant du renouvellement). Les bonnes pratiques de Stripe recommandent de regrouper plusieurs communications, comme des emails et des transcriptions de chat, dans un seul fichier pour ce champ.

Un ticket Zendesk peut répondre aux trois questions, s’il a trois choses.

Les trois choses qui font d’un ticket une preuve

1. Des horodatages fiables

Chaque commentaire dans Zendesk porte sa propre heure de création, et Zendesk garde une piste d’audit. L’API Ticket Audits décrit les audits comme un historique en lecture seule de toutes les mises à jour d’un ticket, chacune avec son propre created_at. Cela compte : un litige se joue souvent sur la question de savoir si le client a écrit avant ou après une date de renouvellement.

Quand vous présentez un ticket, montrez la date et l’heure de chaque message et indiquez le fuseau horaire. La page d’export de données de Zendesk précise que les horodatages CSV utilisent le fuseau par défaut du compte ; votre prestataire de facturation utilise peut-être l’UTC. Mettez les deux sur la même base avant de construire une chronologie.

2. Les mots du client lui-même

Citez, ne reformulez pas. « Le client a confirmé qu’il utilisait la fonction de rapports », c’est votre opinion. Un message daté depuis l’adresse email du client disant « l’export dans les rapports est encore cassé, pouvez-vous le corriger avant notre conseil d’administration », c’est une preuve.

Tenez-vous à ces règles :

• Citez le message entier, ou un extrait clairement signalé avec « […] » là où vous coupez.
• Ne corrigez, ne résumez ni ne traduisez jamais à l’intérieur de la citation. Si vous traduisez, donnez l’original à côté.
• Incluez les messages qui desservent votre dossier s’ils sont pertinents. Un examinateur qui découvre une demande de résiliation omise ne fera pas confiance au reste du dossier, et envoyer un dossier trompeur n’est de toute façon pas quelque chose à faire.

3. Une résolution claire

Le ticket doit montrer comment il s’est terminé : résilié à une date donnée, remboursé, avoir émis, question traitée. Si un agent a résilié un abonnement, le ticket doit le dire dans une réponse publique au client, pas seulement dans une note interne.

Configurer Zendesk pour l’enregistrer sur le moment

Les preuves sont bien plus faciles à retrouver quand elles ont été étiquetées le jour de leur création.

Champs personnalisés

Le guide des champs de ticket personnalisés de Zendesk explique que les admins ajoutent des champs dans l’Admin Center sous Objects and rules > Tickets > Fields. Chaque option d’une liste déroulante a son propre tag. Des champs utiles pour les litiges :

Champ	Type	Valeurs
Demande de facturation	Liste déroulante	Demande de résiliation, Demande de remboursement, Question sur un prélèvement, Descente en gamme, Aucune
Issue de la résiliation	Liste déroulante	Résilié immédiatement, Résilié en fin de période, Demande retirée par le client, Sans objet
Remboursement effectué	Case à cocher	Oui / Non
ID client de facturation	Texte	L’ID issu de votre système de facturation

Ne créez pas de champ pour les numéros de carte ou les données de paiement complètes. Vous n’en avez jamais besoin comme preuves, et Zendesk documente le caviardage automatique des numéros de carte bancaire (offres Professional et au-delà) pour les cas où des clients les collent quand même. D’après Zendesk, il garde les six premiers et les quatre derniers chiffres et ne s’applique pas aux numéros déjà dans le système ; les anciens doivent être caviardés à la main, ce qui est irréversible.

Des macros pour les demandes de remboursement et de résiliation

Les actions de macro de Zendesk peuvent régler les champs à liste déroulante, à choix multiples et à case à cocher, et régler, ajouter ou retirer des tags. Une macro « Demande de résiliation traitée » pourrait :

1. Publier une réponse publique qui confirme la résiliation et sa date d’effet.
2. Régler Demande de facturation sur Demande de résiliation.
3. Régler Issue de la résiliation sur la valeur correspondante.
4. Ajouter un tag comme cancel_confirmed.

La réponse de confirmation est la partie importante. Elle transforme « nous l’avons résilié » en un message daté dans la boîte de réception du client et sur le ticket. Restez factuel : ce qui a été résilié, à partir de quand, et si un remboursement s’applique.

La liste des actions de macro de Zendesk couvre les champs qui posent des tags (liste déroulante, choix multiples, case à cocher) : prévoyez donc que l’ID client de facturation vienne d’une intégration ou soit saisi par l’agent.

Sortir les tickets

Un ticket à la fois : l’impression

L’article de Zendesk sur l’impression des tickets explique comment ouvrir le ticket, cliquer sur le menu Ticket options et choisir Print ticket. Vous pouvez choisir d’inclure ou non les notes internes et les conversations annexes (Suite Professional et au-delà). Pour des preuves, laissez les notes internes de côté sauf si elles comptent : elles sont écrites pour des collègues et peuvent mal se lire hors contexte. Imprimez en PDF et vérifiez que chaque message affiche sa date.

Beaucoup de tickets : export ou API

Méthode	Inclut les commentaires ?	Notes tirées de la doc Zendesk
Export de données de l’Admin Center, JSON	Oui	Désactivé par défaut ; le propriétaire du compte demande au support Zendesk de l’activer ; les commentaires sont omis pour les tickets de plus de 1 Mo
Export de données de l’Admin Center, CSV	Non	Champs de ticket seulement ; ni commentaires ni descriptions
Export d’une vue en CSV	Non	Champs des tickets d’une vue
API Ticket Comments	Oui	Peut être trié par created_at
API Ticket Audits	Oui, avec chaque modification	Historique en lecture seule de toutes les mises à jour

Sources : export de données, export de vue, Ticket Comments, Ticket Audits.

Les exports CSV servent à trouver les bons tickets (filtrez sur votre champ Demande de facturation) mais pas comme preuves en eux-mêmes, car ils laissent de côté ce que le client a écrit.

Monter le dossier de preuves, étape par étape

1. Trouvez tous les tickets venant de l’adresse email du client qui conteste, et de toute autre adresse de son compte.
2. Triez tous les messages par heure et placez-les sur une même chronologie avec les événements de facturation : inscription, avis de renouvellement, prélèvements, résiliation.
3. Choisissez les messages qui répondent aux questions de l’examinateur. Citez-les en entier avec la date, le fuseau horaire et l’expéditeur.
4. Rédigez une courte note d’accompagnement en langage simple : « Le client a contacté le support le [date] au sujet de [fonctionnalité], [N] jours après le prélèvement contesté. Message complet ci-dessous. »
5. Regroupez les transcriptions dans un seul fichier pour customer_communication, comme le recommande Stripe.
6. Vérifiez que rien dans le fichier ne contient de numéro de carte ou de données personnelles sans rapport.
7. Envoyez avant la date limite affichée sur le litige.

Faire tout cela avec NoChurn

Le connecteur Zendesk de NoChurn est en lecture seule : il lit les tickets et ne répond, ne tague ni ne modifie jamais rien dans Zendesk. Les tickets sont rapprochés de vos clients par email ; les rapprochements douteux vous sont suggérés pour confirmation et ne sont jamais fusionnés automatiquement. Quand un litige s’ouvre sur Stripe ou Braintree, NoChurn réunit les preuves automatiquement (réponses du parcours d’annulation, emails envoyés, usage, et les messages Zendesk rapprochés, cités mot pour mot avec leurs dates), rédige une réponse avec l’IA, et ne l’envoie qu’après votre relecture. Le traitement des tickets, les macros et le caviardage restent dans Zendesk, et la décision sur le litige revient à la banque émettrice. Voir NoChurn + Zendesk.