Boucle de feedback

Comment demander un feedback client dans un produit logiciel

8 min de lecture

Pour demander un feedback client dans un produit logiciel, posez une question précise sur quelque chose que l’utilisateur vient de faire, à l’endroit où il l’a fait. “Comment s’est passé l’export de ce rapport ?” juste après un export obtient une réponse. “Dites-nous ce que vous pensez de notre produit” dans un pied de page obtient le silence. Le reste de cette page, ce sont les moments, les canaux et les formulations exactes.

La plupart des conseils sur ce sujet sont écrits pour des boutiques et des services clients. Une équipe logicielle sait exactement ce que l’utilisateur a fait il y a une seconde, donc la question peut porter là-dessus.

MomentOù demanderQuestion prête à l’emploi
Juste après la fin d’une tâcheDans l’app, à côté du résultat“Cet export a-t-il fait ce qu’il vous fallait ?”
Après le premier usage d’une nouvelle fonctionnalitéDans l’app, une seule fois“Qu’essayiez-vous de faire avec la modification groupée ?”
Après la résolution d’un ticket de supportDans le fil du support“Est-ce que ça a réglé le problème, ou y a-t-il encore un souci ?”
Quand un utilisateur bloque ou abandonne un parcoursE-mail, un jour plus tard“Vous vous êtes arrêté à l’étape 3 de la configuration. Qu’est-ce qui vous a freiné ?”
Après 30 jours d’usage régulierE-mail d’une personne identifiée“Quelle est la seule chose que vous changeriez ?”
Quand un utilisateur résilieDans le parcours de résiliation“Qu’est-ce qui vous a fait décider de partir aujourd’hui ?”
Après la livraison de ce qu’il avait demandéLà où il l’avait demandé“Vous aviez demandé l’import CSV. C’est en ligne. Cela couvre-t-il votre cas ?”

Quel est le bon moment pour demander un feedback ?

Le bon moment est juste après que l’utilisateur a terminé quelque chose, tant que le détail est encore frais dans sa tête. Une question qui suit une action obtient une réponse sur cette action. Une question qui arrive de nulle part obtient une réponse sur l’humeur du moment, ou aucune réponse.

Ne demandez pas à l’inscription, car personne n’a rien utilisé. Ne demandez pas au milieu d’une tâche, car vous interrompez ce que vous voulez comprendre. Quand une personne a répondu, laissez-la tranquille jusqu’à ce que vous ayez quelque chose à lui annoncer en retour.

Où demander un feedback client ?

Demandez à l’endroit où l’expérience a eu lieu. Une invite dans l’app convient à une question sur un écran. Le fil du support convient à une question sur un correctif. L’e-mail convient à une question sur une semaine d’usage, ou sur un parcours que la personne a abandonné. Un appel convient aux questions qu’on ne peut pas prévoir.

Chaque canal donne un type de réponse différent :

  • Dans l’app : court, immédiat et précis, mais seulement de la part des personnes présentes. Vous n’entendez rien des utilisateurs partis.
  • Fil du support : de la part de gens déjà assez frustrés pour écrire. Utile pour trouver ce qui est cassé, peu pour juger le reste du produit.
  • E-mail : réponses plus longues de moins de monde, et seul moyen de joindre les utilisateurs devenus silencieux. Écrivez-le comme un court message d’une personne identifiée, avec une seule question dedans.
  • Entretien : la façon de comprendre pourquoi les gens font ce qu’ils font. Demandez-leur de vous montrer comment ils travaillent, et taisez-vous pendant qu’ils le font.

La qualité du signal de feedback explique comment pondérer ce que chaque canal vous apprend.

Comment demander un feedback de façon professionnelle ?

Soyez précis sur l’objet, dites pourquoi vous demandez, et faites en sorte que la réponse prenne moins d’une minute. Une demande professionnelle nomme le moment, fait comprendre qu’une personne lira la réponse, et ne s’excuse pas de déranger.

Nommez l’action exacte (“l’export que vous venez de lancer”), demandez une seule chose, utilisez une zone de texte libre sans champ obligatoire, et signez d’un prénom.

Quelle bonne phrase pour demander un feedback ?

Une bonne phrase est une question sur un moment précis, à laquelle on peut répondre en quelques mots. Comparez les deux colonnes ci-dessous. Celles de gauche appellent un haussement d’épaules. Celles de droite obligent la personne à se rappeler quelque chose de réel.

Demande faibleDemande plus forte
“Un avis ?”“Quelle a été la partie la plus difficile de cette configuration ?”
“Comment trouvez-vous notre produit ?”“À quoi l’avez-vous utilisé la semaine dernière ?”
“Notez votre expérience de 1 à 10.”“Avez-vous fait aujourd’hui ce que vous veniez faire ?”
“Dites-nous comment nous améliorer.”“Qu’est-ce qui vous a ralenti cette semaine ?”
“Nous recommanderiez-vous ?”“À qui l’avez-vous montré en dernier, et qu’avez-vous dit ?”

Une autre qui marche presque partout : “Que faites-vous à la place quand ça ne vous convient pas ?” Elle fait remonter le vrai concurrent, qui est souvent un tableur.

Quelles sont les pires façons de demander un feedback ?

Les pires demandes sont vagues, prématurées, longues ou orientées. Elles ont un défaut commun : la personne ne peut pas répondre sans faire la réflexion que vous auriez dû faire.

  1. “Merci de remplir notre enquête de 20 questions.” Ceux qui vont au bout sont ceux qui ont le plus de temps libre ou les opinions les plus tranchées.
  2. Une pop-up sur la première page après la connexion. L’utilisateur venait faire quelque chose et vous l’avez bloqué. La fermer est la seule réponse raisonnable.
  3. “Nous aimerions avoir votre avis !” sans aucune question. Cela demande à l’utilisateur d’inventer le sujet.
  4. Une question orientée : “À quel point aimez-vous le nouveau tableau de bord ?” Vous obtenez un accord et n’apprenez rien.
  5. Une note sans suite. Un 6 sur 10 vous dit l’humeur. Il ne vous dit pas quoi changer.
  6. Demander, puis se taire. Cela vous coûte le tour suivant, comme on le verra plus bas.

Comment appelle-t-on les retours clients sur un produit ?

Les retours sur un produit s’appellent en général le feedback produit, et ils se rangent en deux sortes. Un rapport de bug dit que quelque chose ne marche pas comme prévu. Une demande de fonctionnalité dit que quelque chose manque. La distinction décide de qui s’en occupe en premier, et demande de fonctionnalité ou bug trace cette ligne. Une troisième sorte, les compliments, vaut la peine d’être gardée et citée avec permission.

Un formulaire de feedback qui propose “Bug” et “Demande de fonctionnalité” comme premier choix fait ce premier tri pour vous.

Que faire des réponses ?

Mettez chaque réponse là où l’équipe travaille déjà, avec les mots de la personne intacts. Une ligne citée vaut mieux que votre résumé. Étiquetez par type et urgence approximative, fusionnez les doublons, puis décidez : le construire, le mettre de côté ou le refuser.

Refuser compte aussi comme une réponse. “Nous n’allons pas construire ça, et voici pourquoi” met fin à l’attente, et refuser une demande de fonctionnalité propose des formulations. Pour la tuyauterie, le suivi des demandes de fonctionnalités décrit comment ramener les demandes de cinq canaux dans une seule liste. Si vous recevez des demandes par écrit, un template de demande de fonctionnalité les garde comparables.

Le widget de Changeloop crée chaque soumission comme une issue GitHub, si bien que le feedback atterrit à côté du code qui le traitera. Avec n’importe quel outil, la règle est la même : une liste, un responsable, aucune réponse oubliée dans la boîte de réception de quelqu’un.

Pourquoi dire ce qui a été livré ?

Cela montre à la personne que répondre valait son temps. Un utilisateur qui vous a dit quelque chose et apprend plus tard “c’est livré, merci” a une raison de répondre à nouveau. Celui qui n’entend rien en conclut que personne ne lit la boîte.

La dernière étape de la demande est donc une réponse. Dites à chaque personne qui a demandé quand sa demande est livrée, dans ses propres termes, sur le canal qu’elle a utilisé. Fermer la boucle de feedback client décrit le mécanisme : l’entrée de changelog publiée déclenche le message, si bien que le demandeur n’est prévenu qu’une fois le changement en ligne. Dans Changeloop, quand un feedback du widget est devenu une issue GitHub et que la pull request fusionnée la ferme, approuver l’entrée poste un commentaire “Shipped” sur cette issue et montre l’entrée à l’auteur de la soumission dans le widget ; les issues créées à la main, et les dépôts GitLab ou Bitbucket, ne reçoivent aucun commentaire. Notre documentation liste la configuration du widget et du flux.

Une réponse peut être courte : “Vous aviez demandé l’import CSV en mars. C’est en ligne aujourd’hui, voici comment ça marche.” Elle vous donne aussi la meilleure question suivante : est-ce que cela couvre ce dont la personne avait besoin ?

Un plan pour démarrer

Choisissez un moment dans le tableau du haut, celui où les utilisateurs réussissent ou abandonnent le plus souvent. Écrivez une question pour lui, placez-la dans un canal, et lisez chaque réponse pendant deux semaines avant d’ajouter une deuxième invite. Répondez à toute personne qui vous a donné quelque chose de concret.

FAQ

À quelle fréquence faut-il demander un feedback aux clients ? Rattachez les demandes à des événements, pas à un calendrier. Un utilisateur ne devrait voir qu’une invite par semaine au plus, et aucune juste après en avoir rempli une. Le message qui suit un feedback doit être une réponse sur ce qu’il est devenu.

Comment demander un feedback sans agacer les utilisateurs ? Demandez après une tâche, jamais au milieu d’une tâche, limitez-vous à une question et facilitez le refus. Respectez un refus pendant quelques semaines.

Faut-il offrir une contrepartie pour un feedback ? En général ce n’est pas nécessaire. Une question précise et une réponse visible pèsent plus qu’une carte cadeau, et les contreparties attirent des gens qui veulent la récompense. Gardez-les pour les entretiens, où vous demandez 20 minutes du temps de quelqu’un.

Que faire si personne ne répond ? Resserrez la question et rapprochez-la du moment, par exemple un seul écran, posée juste après son utilisation. Si le silence persiste, écrivez directement à quelques utilisateurs et servez-vous de ces échanges pour écrire de meilleures invites.


Les affirmations techniques de cet article n'ont pas été vérifiées de façon indépendante. Si quelque chose est faux, dis-le-nous et nous le corrigerons.

À voir sur changeloop : Documentation développeurs

changeloop
L'équipe qui construit un changelog qui boucle la boucle. Tes utilisateurs demandent, ton équipe livre, la personne qui a demandé est prévenue.