Pourquoi les clients SaaS annulent vraiment (et comment le découvrir)

Voici une phrase qu'un véritable testeur a prononcée dans un processus d'annulation.

"le prix est honnêtement tout le problème pour nous, nous sommes une équipe de trois et le niveau supérieur coûte plus que tout notre budget d'outillage pour le trimestre."

Voici maintenant ce qu'un menu déroulant aurait enregistré de la même personne. Trop cher. Deux mots, une ligne dans une feuille de calcul, et tous les détails exploitables disparus.

La phrase n'est pas une plainte sur votre prix. C'est une plainte sur l'ampleur du saut entre deux de vos niveaux, de la part de quelqu'un qui est trois personnes et ne correspond pas au niveau supérieur. C'est un problème de page de tarification. La réponse du menu déroulant, "trop cher", vous dirige plutôt vers une remise, ce qui est la mauvaise solution et une solution coûteuse. Même client, même code de raison, conclusions opposées.

Cet article est organisé autour des sept catégories de raisons que Outro classe dans les annulations. La taxonomie est délibérément petite et fixe, car un ensemble petit et fixe est ce qui rend le comptage possible. L'argument est que les catégories ne deviennent utiles que lorsque quelque chose en dessous d'elles préserve la phrase que le client a réellement dite.

Les sept raisons, et ce que chacune cache réellement

Outro classe chaque annulation dans l'une des sept raisons. L'ensemble ne change pas et vous ne le configurez pas.

• Trop cher : le client vous dit quelque chose sur le prix, mais presque jamais sur le chiffre absolu. C'est généralement l'écart entre les niveaux, un budget qui a été réduit, ou un prix qui semblait correct jusqu'à ce que l'utilisation diminue. Enregistré comme une catégorie, cela ressemble à un problème. Enregistré comme une phrase, cela se divise en trois, avec trois responsables différents.
• Fonctionnalités manquantes : le mot porteur est lesquelles. Une intégration manquante qui a bloqué tout un flux de travail est une décision de feuille de route. Un élément agréable à avoir qui est apparu une fois est du bruit. La catégorie les traite de manière identique.
• Ne l'utilise pas : personne n'a été lésé par votre produit, ils ne l'ont simplement jamais intégré dans leur semaine. C'est la raison pour laquelle un client a le moins d'incitation à se porter volontaire et le plus d'incitation à signaler comme "trop cher", car payer pour quelque chose que vous n'ouvrez jamais semble vraiment trop cher.
• Trop difficile à utiliser : friction qui a arrêté le client avant que la valeur ne le fasse. Configuration, un concept dans votre interface utilisateur qui ne correspond pas au concept dans leur tête. Distinct de "ne l'utilise pas" car ici ils ont essayé.
• Problèmes techniques : bugs, pannes, choses qui ont brisé la confiance. La catégorie la plus réparable et celle qui vaut le plus la peine d'être lue textuellement, car vous avez besoin du chemin de reproduction et non du nombre.
• Changement : ils sont allés ailleurs. La catégorie est presque inutile en elle-même. Où ils sont allés et ce qui les a attirés est tout le signal.
• Autre : aucune raison claire liée au produit, y compris une réponse inintelligible ou quelque chose de réellement en dehors des six autres, comme la fermeture de l'entreprise. Une taxonomie sans ce compartiment est pire qu'une avec, car un classificateur forcé de choisir classera le bruit sous la raison réelle qui convient le moins mal.

Les valeurs sous-jacentes sont stockées comme des identifiants plutôt que les étiquettes affichées ci-dessus, et elles ne lisent pas toujours comme le fait l'étiquette. L'ensemble complet est too_expensive, missing_features, not_using, too_complex, technical_issues, switching et other, donc "Trop difficile à utiliser" arrive comme too_complex et "Ne l'utilise pas" comme not_using. Bon à savoir avant de construire un rapport sur une exportation CSV.

Remarquez que quatre des six raisons réelles peuvent plausiblement être signalées par le client comme la première. Cette asymétrie est tout le problème avec les menus déroulants, et elle prédit qu'une enquête à cases à cocher penchera vers le prix pour des raisons qui ont très peu à voir avec votre prix.

Pourquoi "trop cher" absorbe tout le reste

Un menu déroulant demande au client de faire un travail de traduction pour vous. Ils ont une situation spécifique, et vous leur proposez cinq catégories prédéfinies et leur demandez de choisir celle qui s'en rapproche le plus. C'est une étape de compression avec perte, et le client n'est pas motivé à le faire soigneusement, car il s'en va.

La catégorie qu'ils choisissent est celle socialement acceptable. Dire "trop cher" ne coûte rien au client, car cela n'implique aucune critique du produit, aucune admission qu'ils n'ont jamais pris le temps de le configurer, et aucune obligation d'expliquer. Comparez cela avec cliquer sur "trop difficile à utiliser", qui ressemble à une accusation, ou "ne l'utilise pas", qui ressemble à un aveu. Lorsqu'on leur laisse le choix, les gens contournent les options gênantes.

Ainsi, "trop cher" absorbe discrètement au moins trois cas non liés, y compris "je ne l'ai jamais configuré", "la fonctionnalité dont j'avais besoin manquait", et "mon budget a été réduit". Ces trois cas nécessitent des réponses complètement différentes de votre part. Regroupés dans une seule catégorie, ils se traduisent en une recommandation de baisser votre prix, ce qui est la seule action qui ne les aide pas.

La page d'annulation d'Outro conserve les boutons radio et ajoute l'option vocale à côté, ce qui est un compromis délibéré plutôt qu'une position puriste. Les boutons vous donnent une catégorie pour chaque annulation, y compris pour les clients qui ne parleront pas. La réponse vocale vous donne la phrase derrière la catégorie pour ceux qui le feront.

Mécaniquement, c'est une courte question orale à la place du bouton d'annulation. La réponse est transcrite et classifiée à son arrivée, et une offre correspondante apparaît avant que l'annulation ne soit complétée. L'enregistrement est transcrit à la volée plutôt que conservé sous forme de fichier audio lisible, bien que la transcription et l'analyse qui en est dérivée soient stockées comme n'importe quel autre enregistrement client, et la page affiche la ligne "Votre voix sera transcrite par l'IA" avant l'enregistrement. Cette ligne de consentement est fixe et non configurable, ce qui est le bon choix par défaut pour quelque chose qui capture la voix d'un client au moment le moins généreux de la relation. Pour un aperçu plus large du format, voir Entretiens de sortie IA.

À quoi ressemblent les raisons en sortie réelle

Ci-dessous se trouve le panneau "Nécessite une attention" d'une exécution en direct. Chaque résumé a été généré à partir d'une réponse orale réelle.

Lisez les trois résumés comme des instances de la taxonomie plutôt que comme du texte.

"L'utilisateur exprime une préoccupation concernant le prix, qui est un problème important pour leur petite équipe" est le résumé généré à partir de la phrase orale en haut de cet article. Il se classe dans la catégorie prix et porte le qualificatif important, qui est pour leur petite équipe. Un menu déroulant vous aurait donné la catégorie avec le qualificatif supprimé.

"L'utilisateur a rencontré un bug avec le tableau de bord qui ne se charge pas et une réponse lente du support, impactant leur confiance" est un cas de technical issues nommant deux échecs distincts. L'un est un bug, l'autre est un problème de latence du support, et ils appartiennent à différentes personnes de votre équipe. Un seul code de raison aurait forcé le client à en abandonner un.

"L'utilisateur a éprouvé de la confusion lors de l'installation et a eu des difficultés avec l'intégration des widgets et la configuration des offres" est un cas de too-hard-to-use lié à une étape spécifique. Pas "le produit est déroutant" mais confusion lors de l'installation, spécifiquement autour de l'intégration et de la configuration des offres. C'est un ticket que vous pouvez ouvrir cet après-midi.

Aucun des trois n'aurait pu être reconstruit à partir d'une case à cocher, et tous les trois font la différence entre connaître votre taux de désabonnement et savoir quoi changer.

La classification des raisons et la classification des retours sont deux choses différentes

Cela peut prêter à confusion, alors gardez-les séparées. Outro exécute deux systèmes de classification indépendants pour chaque réponse.

Le premier est la taxonomie de résiliation en sept valeurs ci-dessus, qui répond à la question de savoir pourquoi l'abonnement a pris fin. Le second est une classification des retours, couvrant Rapport de bug, Demande de fonctionnalité, Éloge, Question et Autre, qui répond à la question de savoir quel type de message c'est. En plus de cela, chaque réponse porte un sentiment de Positif, Neutre ou Négatif.

Les deux systèmes ne se confondent pas. Un Rapport de bug s'associe naturellement à des problèmes techniques, mais il peut tout aussi bien être classé sous "not_using" lorsque le bug est la raison pour laquelle ils ont cessé d'ouvrir le produit il y a deux mois. Une Demande de fonctionnalité peut être liée à une raison de prix, puisque "le niveau qui a ce dont j'ai besoin coûte trop cher" est véritablement les deux.

Le tableau des Réponses Récentes est l'endroit où les deux systèmes se trouvent côte à côte. Analysez les étiquettes de sentiment et de classification ensemble plutôt qu'une à la fois, car les combinaisons sont plus informatives que chaque colonne seule. Une Demande de fonctionnalité avec un sentiment Neutre est une entrée pour la feuille de route. La même demande avec un sentiment Négatif est un client qui s'est senti ignoré, ce qui est une conversation différente et souvent récupérable.

Les thèmes transforment les catégories en liste de priorités

Les catégories vous indiquent comment le churn se répartit. Les thèmes vous disent quoi faire lundi. Outro extrait les thèmes à partir des réponses et les compte.

Ce sont les vrais comptes de cette exécution, avec l'annulation à 7, le prix à 6, le coût à 3, le budget à 2, la taille de l'équipe à 2, la qualité du produit à 2, les fonctionnalités manquantes à 2, et les retours utilisateurs à 2.

Soyez clair sur ce que c'est et ce que ce n'est pas. Il s'agit de seize réponses sur un compte de test, neuf parlées et sept tapées. Les comptes sont réels et l'extraction des thèmes est réelle, mais seize réponses ne peuvent pas vous dire si les plaintes concernant les prix augmentent, et un graphique tracera volontiers une pente d'apparence confiante à travers elles de toute façon. Le dire clairement est plus utile que la pente, et si vous évaluez un outil de churn, la taille de l'échantillon est l'élément sur lequel insister le plus.

Ce que les comptes démontrent, c'est le mécanisme. Le prix, le coût, le budget et la taille de l'équipe apparaissent comme quatre thèmes distincts plutôt qu'un seul. Un menu déroulant aurait fusionné les quatre en "too expensive". Séparés, ils se lisent comme une histoire cohérente sur les petites équipes confrontées à un saut de palier abrupt, ce qui est exactement ce que la phrase parlée originale disait. Les thèmes ont récupéré la structure que la catégorie avait détruite. Une fois que vous avez cela, réduire le churn devient une liste classée de solutions plutôt qu'une supposition, et vous pouvez chiffrer ce que chaque solution vaut avec le calculateur de churn.

Adapter l'offre à la raison plutôt qu'au clic

Connaître la raison lors de l'annulation, plutôt qu'une semaine plus tard dans un rapport, signifie que l'offre peut y répondre. Dans l'exemple ci-dessus, l'offre proposée après l'objection sur le prix était "50% de réduction pendant 3 mois".

Deux choses à remarquer sur cet écran. L'offre apparaît avant que l'annulation ne soit complétée, alors que l'intention de partir est encore faible. Et "Non merci, annuler quand même" reste visible et simple. Tout gain que vous obtenez en cachant la sortie revient sous forme de rétrofacturations, de charge de support, et de plaintes publiques. Exemples de flux d'annulation couvre où cette ligne se situe en pratique.

La récupération est comptée de manière conservatrice. Un sauvetage n'est compté qu'après qu'une période de grâce de 14 jours soit passée et seulement si l'abonnement est toujours actif à ce moment-là. Un client qui accepte une réduction et annule une semaine plus tard n'est pas un sauvetage, et le chiffre ne prétend pas le contraire. L'alternative, compter le clic sur l'offre, produit un taux de sauvetage qui semble impressionnant mais ne prédit rien.

La catégorie de churn qu'aucun flux d'annulation ne peut voir

Il existe une septième raison, et elle se situe entièrement en dehors de la taxonomie car elle n'atteint jamais le flux. Le churn involontaire est l'abonnement qui se termine parce qu'une carte a expiré, qu'un paiement a échoué ou qu'une banque a refusé une charge. Le client n'a pas décidé de partir. Il n'a jamais cliqué sur annuler, donc il n'a jamais vu une page d'annulation, n'a jamais répondu à une question, et n'est jamais apparu dans aucune des captures d'écran ci-dessus.

Outro ne traite pas cela. Il ne gère pas la récupération des paiements échoués et ne fait pas de relance. C'est une limite stricte, pas un élément de feuille de route à lire entre les lignes. Si le churn involontaire est votre problème, la solution appartient à la couche de facturation, et les outils de récupération de revenus de Stripe sont le bon endroit pour chercher. Résolvez-le séparément, et ne laissez pas un outil de churn volontaire vous convaincre que votre churn est compris alors qu'une partie de celui-ci n'est jamais entrée dans le flux.

Erreurs courantes

• Lire la distribution des raisons comme la vérité : si la distribution provient d'un menu déroulant, le prix est surestimé par construction. Considérez-le comme une mesure de l'étiquette la moins gênante à cliquer, et non de la raison pour laquelle les gens sont partis.
• Appliquer une remise en réponse à une catégorie de prix : la phrase prononcée dans cet article ressemble à un cas de remise et est en réalité un cas de structure de niveaux. Lisez quelques réponses verbatim avant de modifier un prix.
• Confondre la raison du churn avec le type de retour : Un rapport de bug n'est pas la même chose que des problèmes techniques, et les deux systèmes répondent à des questions différentes, donc les fusionner en une seule élimine des signaux.
• Tirer des tendances à partir de données minces : seize réponses constituent une démonstration de mécanisme, pas une tendance. Attendez un vrai volume avant d'agir sur la forme d'un graphique, y compris les graphiques ci-dessus.
• Compter le clic sur l'offre comme une sauvegarde : sans une fenêtre de grâce et une vérification d'abonnement en direct, un taux de sauvegarde mesure les clics sur les boutons plutôt que le revenu retenu.
• Cacher le lien d'annulation pour augmenter le taux de sauvegarde : cela convertit une annulation en rétrofacturation et en plainte, et c'est le moyen le plus rapide de transformer votre flux d'annulation en un passif.
• S'attendre à ce qu'un flux d'annulation couvre le churn involontaire : les paiements échoués nécessitent des nouvelles tentatives côté facturation, et aucun entretien de sortie ne les verra jamais.
• Écrire un sondage avec plus de quelques options : chaque option supplémentaire ajoute une étape de traduction pour le client et un compartiment sur lequel vous n'agirez jamais. Les modèles de questions d'enquête de sortie sont plus courts que ce que la plupart des équipes attendent pour cette raison.

Obtenir les réponses du tableau de bord

Une contrainte pratique à prendre en compte. L'egress d'Outro aujourd'hui est un email récapitulatif hebdomadaire qui arrive le lundi, plus une exportation CSV. Il n'y a pas d'API REST publique, pas de webhooks, pas de package npm, pas de connecteur Zapier, n8n, ou Make, et pas d'intégration Slack.

Cela façonne le flux de travail. Vous ne pouvez pas diriger une annulation vers votre propre système d'alerte ou diffuser des réponses dans un canal Slack automatiquement. Ce que vous pouvez faire, c'est lire le récapitulatif du lundi comme un point fixe de l'ordre du jour et récupérer le CSV lorsque vous souhaitez croiser les réponses avec vos propres données de facturation. Pour une petite équipe, cela suffit généralement. Si votre processus dépend de l'automatisation pilotée par les événements, sachez-le maintenant plutôt qu'après avoir conçu autour de cela.

Où cela vous laisse-t-il

Les catégories ne sont pas l'insight, elles sont l'index. Leur rôle est de rendre les annulations quantifiables, et compter est vraiment utile, car vous ne pouvez pas prioriser ce que vous ne pouvez pas comparer. Mais chacune des six est un conteneur pour plusieurs situations différentes, et "trop cher" est la plus grande et la plus trompeuse d'entre elles. Le travail consiste à garder la phrase attachée à la catégorie, afin que lorsque le compartiment de prix se remplit, vous puissiez déterminer si vous faites face à un problème de remise, un problème de structure de niveaux, un problème d'intégration, ou un client dont le budget a été réduit par quelqu'un qui n'a jamais utilisé votre produit.

Outro est un logiciel de gestion des flux d'annulation avec des entretiens de sortie vocaux, conçu pour la facturation SaaS en libre-service sur Stripe ou Lemon Squeezy. Il remplace le bouton d'annulation par une courte question orale, transcrit et classe la raison, et affiche une offre de sauvegarde correspondante avant que l'annulation ne soit effectuée. Il existe un niveau gratuit à 0 $, puis Starter à 29 $ par mois, Pro à 79 $, et Scale à 199 $. Chaque capture d'écran de cet article est un véritable résultat du produit plutôt qu'une maquette, y compris les comptes de thèmes et l'avertissement d'une seule journée qui les accompagne.