Utiliser le CSAT Zendesk pour repérer les clients sur le point de partir

Le CSAT de Zendesk se lit généralement comme un indicateur d’équipe : la part des tickets résolus notés positivement ce mois-ci. Lu client par client, il devient autre chose : une liste de personnes qui viennent de vous dire, en un clic, que quelque chose s’est mal passé. Certaines sont sur le point de partir.

Ce guide explique ce que contiennent les données de satisfaction de Zendesk, comment les sortir, comment donner suite rapidement aux mauvaises notes, et comment tester si les notes prédisent le churn dans votre activité. Il s’appuie sur la documentation de Zendesk sur l’expérience CSAT, l’envoi d’une enquête CSAT, les raisons de satisfaction, les mauvaises notes inattendues, et les références API Satisfaction Ratings et CSAT Survey Responses (toutes consultées en novembre 2026).

Comment Zendesk recueille le CSAT

L’enquête est liée aux tickets résolus. Pour les canaux de messagerie, Zendesk crée un trigger système qui affiche l’enquête juste après la résolution d’un ticket. Pour l’email, une automatisation par défaut envoie la demande 24 heures après le passage du ticket en résolu, d’après l’article de Zendesk sur l’expérience CSAT.

Avec l’expérience d’enquête actuelle décrite dans Sending a CSAT survey, les admins choisissent l’échelle de notation (deux, trois ou cinq points) et peuvent ajouter une question ouverte. Zendesk prend aussi en charge les raisons de satisfaction : une liste déroulante de raisons affichée quand un client donne une note négative. Les raisons sont facultatives pour le client.

Les enquêtes sur messagerie n’affichent l’invite de commentaire qu’après que le client a cliqué sur une note.

À quoi ressemblent les données

Il existe deux représentations dans l’API, et il est utile de connaître les deux.

Satisfaction ratings. L’ancien endpoint Satisfaction Ratings (GET /api/v2/satisfaction_ratings) renvoie des notes avec un score offered, unoffered, good ou bad. Vous pouvez filtrer par score, y compris les variantes avec et sans commentaires, et par start_time. « Offered » veut dire que le client a reçu une enquête et n’a pas répondu ; « unoffered » veut dire qu’aucune enquête n’a été envoyée.

CSAT survey responses. L’API CSAT Survey Responses couvre la nouvelle enquête, avec des notes regroupées en mauvaises, neutres ou bonnes. Le guide de Zendesk sur la récupération des réponses CSAT recommande ces données pour un retour plus précis quand vous utilisez la nouvelle enquête.

Dans les deux cas, chaque note renvoie à un ticket, et le ticket à un demandeur et, souvent, à une organisation. C’est le chemin vers un client.

Un problème de qualité des données à régler d’abord

Zendesk documente une cause connue de mauvaises notes inattendues : les scanners de sécurité email qui suivent chaque lien d’un message. Comme la note enregistre le dernier lien cliqué, un scanner qui clique sur « good » puis sur « bad » enregistre une mauvaise note que le client n’a jamais donnée. La correction recommandée par Zendesk consiste à remplacer les liens directs good et bad de l’email CSAT par un lien vers la page d’atterrissage de l’enquête.

Si vous comptez utiliser les mauvaises notes comme signal de churn, corrigez cela d’abord. Sinon, certains de vos « clients mécontents » sont le filtre de messagerie d’une grande entreprise.

Donner suite aux mauvaises notes

Le gain le plus rapide ne demande aucune analyse : quelqu’un lit chaque mauvaise note dans la journée et agit.

1. Construisez une vue. Zendesk documente une vue pour les notes avec commentaires, avec des conditions comme « Satisfaction Is Bad with comment ». Créez-en une pour les mauvaises notes avec et sans commentaires.
2. Désignez un responsable. Un chef d’équipe ou un customer success manager, pas l’agent qui a traité le ticket.
3. Lisez le commentaire et la raison, puis regardez le compte : offre, ancienneté, événements de facturation récents, autres tickets ouverts.
4. Répondez personnellement à ce que le client a dit. Un court message d’une personne nommée qui corrige ou explique quelque chose fait plus que des excuses génériques.
5. Taguez l’issue (csat-followup-done, csat-followup-churned) pour pouvoir la mesurer plus tard.

Pour le reporting, Zendesk publie une recette Explore pour les mauvaises notes avec commentaires.

Lire les raisons et les commentaires

Les scores vous disent que quelque chose s’est mal passé ; les raisons de satisfaction et les commentaires vous disent quoi. Avant toute statistique, lisez un mois de mauvaises notes avec commentaires et classez-les en quelques thèmes :

• Expérience support : réponse lente, réponse floue, ticket clos trop tôt.
• Problème produit : un bug, une fonctionnalité manquante, quelque chose qui ne marche pas comme annoncé.
• Problème de facturation : un prélèvement inattendu, un renouvellement oublié par le client, un remboursement refusé.
• Rien à voir avec vous : une note cliquée par erreur, ou une plainte sur quelque chose hors de votre contrôle.

Les deuxième et troisième groupes sont ceux qui valent le plus d’être comparés au churn. Un client fâché par une réponse lente peut rester une fois le problème réglé ; un client fâché par un prélèvement est aussi un risque de litige, vérifiez donc sa facturation en même temps.

Tester si les notes prédisent le churn

Une mauvaise note ressemble à un signal de churn. Vérifiez-le.

Construire le jeu de données

1. Exportez les notes d’une période, avec l’une ou l’autre API ci-dessus, avec ID de ticket, demandeur, organisation, score, raison, commentaire et date.
2. Exportez les clients de facturation avec date de début, date de résiliation et type de churn (volontaire ou paiement échoué).
3. Rapprochez demandeurs et clients par email. Les utilisateurs Zendesk peuvent avoir plusieurs identités email ; utilisez-les toutes. En B2B, décidez si une note d’un utilisateur quelconque compte pour l’organisation.
4. Fixez une fenêtre. Notes dans les 90 jours avant une date de référence ; churn dans les 90 jours après.

Comparer des groupes

Groupe	Définition
Au moins une mauvaise	Une ou plusieurs mauvaises notes dans la fenêtre
Bonnes seulement	Uniquement des bonnes notes
Proposée, jamais répondue	Enquêtes envoyées, pas de réponse
Aucun ticket résolu	Aucune enquête proposée dans la fenêtre

Calculez le churn volontaire de chaque groupe, avec le nombre de clients à côté de chaque taux. Laissez de côté le churn par paiement échoué ; voir le churn involontaire pour comprendre pourquoi il se comporte différemment. Les formules de churn sont dans comment calculer le taux de churn.

Lire avec prudence

• Les taux de réponse façonnent tout. Si peu de clients répondent, le groupe « mauvaise » est petit et auto-sélectionné. Le groupe « proposée, jamais répondue » peut être aussi instructif que les mauvaises notes.
• Les raisons comptent plus que les scores. Une mauvaise note avec la raison « problème non résolu » est un signal différent de « l’agent a été lent ». Ventilez la comparaison par raison quand vous avez assez de données.
• Le suivi change le résultat. Si vous commencez à donner suite aux mauvaises notes, leur lien avec le churn devrait s’affaiblir. C’est le but, pas une analyse cassée.
• Corrélation, pas causalité. Une mauvaise note peut être le symptôme d’une décision déjà prise. Elle vous dit quand même à qui parler.

Si le CSAT ne sépare pas ceux qui partent de ceux qui restent dans vos données, regardez d’autres signaux du support ; voir repérer les signaux de churn dans les tickets Zendesk.

Faire tout cela avec NoChurn

Le connecteur Zendesk de NoChurn est en lecture seule : il n’envoie pas d’enquêtes, ne change pas vos réglages CSAT et n’écrit pas dans les tickets. Il lit les tickets et leurs notes de satisfaction, rapproche les demandeurs des clients de facturation par email (les rapprochements douteux vous sont suggérés pour confirmation, jamais fusionnés automatiquement), et s’en sert comme données d’entrée du score de churn de 0 à 100 et des facteurs de churn, qui classent les attributs les plus corrélés au churn (corrélation, pas causalité). Vous pouvez envoyer d’autres attributs par API, comme l’usage du produit, pour voir comment se comparent les signaux du support. Voir NoChurn + Zendesk.