Pourquoi personne n'utilise la nouvelle fonctionnalité que j'ai développée ?
Le plus souvent parce que les gens ne sont jamais arrivés jusqu'à elle, et non parce qu'ils l'ont regardée avant de dire non. Une nouvelle fonctionnalité doit battre le chemin que les utilisateurs empruntent déjà pour la même tâche, or l'ancien chemin continue de fonctionner, continue d'être documenté et reste celui vers lequel l'habitude se tourne. Avant de lire un usage nul comme une demande nulle, vérifiez quatre choses dans l'ordre : les gens l'ont-ils vue, les moments où ils en avaient besoin les y ont-ils conduits, la première tentative a-t-elle fonctionné, et sont-ils revenus. Un zéro à l'une des deux premières étapes est un problème d'aiguillage que vous pouvez corriger dès cette semaine.
Un usage nul parle d'aiguillage avant de parler de demande
Quand une fonctionnalité livrée reste inutilisée, la lecture tentante est que vous avez construit la mauvaise chose. Cette conclusion réclame des preuves que vous n'avez probablement pas encore. L'usage n'a lieu que lorsqu'une personne qui a la tâche à accomplir arrive sur la fonctionnalité au moment où elle en a besoin, et dans la plupart des produits ce moment survient ailleurs : dans un menu qu'elle connaît déjà, un modèle copié le mois dernier, un article d'aide rédigé avant que la fonctionnalité n'existe, ou un e-mail d'onboarding qui décrit encore l'ancienne façon de faire.
L'ancienne façon de faire est le vrai concurrent, et elle possède un avantage que votre annonce de lancement ne peut pas lui retirer — elle fonctionne toujours. Rien ne plante quand quelqu'un prend le long chemin, donc rien ne vous signale que c'est arrivé. Une fonctionnalité que les gens ont rejetée et une fonctionnalité que personne n'a su trouver produisent le même chiffre dans votre outil d'analyse, et c'est pourquoi le diagnostic doit les distinguer avant que quiconque ne débatte de la feuille de route. Pour les tout nouveaux inscrits, la question équivalente est celle de la première réussite, traitée dans comment améliorer l'onboarding utilisateur de mon SaaS ? ; cette page-ci concerne les utilisateurs que vous avez déjà.
Lisez le zéro une étape à la fois
L'adoption par un utilisateur existant fonctionne comme l'activation pour un nouveau : une courte suite d'étapes, dont chacune doit se produire avant que la suivante puisse avoir lieu. Trouvez la première étape où le compte s'effondre. Chacune a un responsable différent et un correctif différent, et les correctifs bon marché se trouvent tous vers le haut.
| Étape | Ce que signifie un zéro ici | Comment vérifier |
|---|---|---|
| Vue | Les personnes qui en avaient besoin n'ont jamais appris qu'elle existait | Comptez les vues du point d'entrée, et non les utilisations de la fonctionnalité, parmi les utilisateurs qui avaient la tâche à accomplir cette semaine-là |
| Aiguillée | Les endroits où les gens agissent pointent encore vers l'ancien chemin | Parcourez la tâche du début à la fin comme le ferait un utilisateur : le menu, vos modèles, votre documentation d'aide, vos e-mails, toute consigne enregistrée |
| Essayée | Ils y sont arrivés et la première tentative a échoué ou les a déroutés | Regardez trois personnes s'attaquer à la tâche d'une seule traite et notez chaque erreur, chaque écran vide et chaque formulaire abandonné |
| Répétée | Elle a fonctionné une fois mais n'a pas battu l'ancienne habitude | Comparez la deuxième utilisation à la première, utilisateur par utilisateur ; une première utilisation saine suivie d'une deuxième faible signifie que la fonctionnalité perd sur la valeur |
Seule la dernière ligne apporte une preuve sur la demande. Un effondrement à l'étape « vue » ou « aiguillée » ne dit rien de l'intérêt que les gens portent à la fonctionnalité, et la retirer sur cette base revient à jeter un travail que le marché n'a jamais eu l'occasion de juger.
La fonctionnalité que nous avons construite et qui n'a jamais servi une seule fois
Nous avons intégré un calendrier de contenu à AgentCeres — l'AI Growth Officer sur agentceres.com — pour qu'une publication sur les réseaux sociaux puisse être approuvée une fois puis publiée à l'heure prévue, sans que personne ait besoin d'être là au moment où elle part. Quand nous avons vérifié en production, il n'avait pas servi une seule fois. Pas rarement : zéro publication programmée, sur l'ensemble des comptes.
Les utilisateurs, dans ce cas, étaient nos propres agents et non des personnes cliquant dans une interface, ce qui rendait la cause facile à lire, et cette cause était l'aiguillage. Les instructions écrites que suivent nos agents quand on leur demande de programmer une publication dataient d'avant le calendrier et listaient toutes les autres façons de le faire. Alors quand un client payant a demandé exactement ce pour quoi le calendrier existe — garder cette publication approuvée et la publier demain matin — l'agent a fait ce que disaient ses instructions : il s'est programmé un rappel pour revenir le lendemain et redemander l'approbation. Le client aurait dû être présent une seconde fois pour une publication qu'il avait déjà approuvée.
La demande était là, au moment précis pour lequel la fonctionnalité avait été construite, et le chemin l'a envoyée ailleurs. Rien n'a échoué, donc rien n'a alerté personne. Le correctif n'a pas été une annonce : nous avons fait du calendrier la première réponse dans ces instructions, signalé l'ancienne voie comme un dernier recours en précisant ce que coûte ce choix, et remplacé un exemple commenté qui enseignait discrètement l'ancienne habitude. Jugée sur son seul usage, elle aurait eu tout l'air d'une fonctionnalité dont personne ne voulait.
Les correctifs, dans l'ordre où ils rapportent
Descendez le tableau depuis le haut, et laissez à chaque changement une fenêtre raisonnable avant de lire le chiffre suivant.
- Trouvez chaque endroit qui décrit la tâche — documentation d'aide, modèles, e-mails d'onboarding, prompts enregistrés, scripts de vente — et faites de la nouvelle fonctionnalité la première réponse dans chacun.
- Placez le point d'entrée là où la tâche commence, pas là où la fonctionnalité se trouve par hasard dans votre navigation.
- Prévenez les utilisateurs qui ont accompli la tâche à l'ancienne ce mois-ci, un par un, en une phrase sur ce qu'ils n'ont plus à faire.
- Regardez trois personnes l'essayer avant de construire quoi que ce soit d'autre par-dessus.
- Alors seulement, lisez la deuxième utilisation. C'est ce chiffre-là qui dit si la fonctionnalité est vraiment voulue.
FAQ
- Combien de temps attendre avant de conclure qu'une fonctionnalité a échoué ?
- Assez longtemps pour que la tâche qu'elle sert se présente plusieurs fois chez les personnes concernées. Une tâche hebdomadaire exige des semaines de données, une tâche mensuelle des mois, et un pic la semaine du lancement renseigne sur la curiosité plutôt que sur l'adoption. Fixez la fenêtre avant de regarder, en fonction de la fréquence de la tâche, pour que le chiffre ne puisse pas vous convaincre de la réponse vers laquelle vous penchiez déjà.
- Faut-il annoncer la fonctionnalité une nouvelle fois ?
- Une annonce corrige l'étape « vue » et rien en dessous. Si les gens ont vu la première et prennent toujours l'ancien chemin, une seconde touchera les mêmes personnes avec le même résultat. Changez plutôt ce qui se passe au moment du besoin — le point d'entrée, le modèle, le réglage par défaut — et ne l'annoncez qu'aux utilisateurs à qui vous pouvez montrer qu'elle fait gagner du temps.
- Faut-il supprimer l'ancienne façon de faire ?
- Rarement, et jamais en premier. Supprimer un chemin qui fonctionne force l'adoption et empêche de savoir si la nouvelle fonctionnalité est réellement meilleure, et les utilisateurs que cela agace le plus sont ceux qui dépendaient le plus de l'ancien chemin. Faites de la nouvelle voie le choix par défaut et laissez l'ancienne accessible ; si la deuxième utilisation de la nouvelle fonctionnalité tient, l'ancien chemin se videra de lui-même.
- Une faible adoption d'une fonctionnalité est-elle un signe de désabonnement ?
- Elle peut en être un signe précoce, mais seulement pour les fonctionnalités liées à la raison pour laquelle les gens paient. Une fonctionnalité qui sert une tâche occasionnelle peut rester peu utilisée dans un compte en parfaite santé. Surveillez l'adoption des fonctionnalités qui portent votre valeur centrale, et traitez les autres comme des questions de feuille de route plutôt que comme des alarmes de rétention. Comment réduire le taux de désabonnement de mon SaaS ? couvre le versant rétention.
Want this done for you?
AgentCeres is a managed AI marketing team — specialists draft the work, you approve what ships. 14-day free trial, from $39/month.