Tickets support vs. demandes : qui croire ?
6 min de lecture
Un tableau de demandes de fonctionnalités capture ce que les utilisatrices demandent quand elles ont le temps de s’asseoir et de décrire ce qu’elles veulent. Un ticket support capture ce sur quoi les utilisatrices sont bloquées maintenant, souvent agacées, souvent sans le vocabulaire pour décrire proprement la demande sous-jacente. Les deux sont un signal réel, et les équipes qui ne regardent que l’un des deux finissent par résoudre le mauvais problème avec assurance, parce que chaque canal surreprésente systématiquement un type différent d’utilisatrice et un type différent de besoin. Prioriser les demandes de fonctionnalités couvre le classement de ce qui est déjà sur le tableau ; ceci concerne l’écart entre ce qui arrive sur le tableau et ce qui n’apparaît jamais que comme ticket support.
Pourquoi le même problème sous-jacent apparaîtrait-il dans un canal et pas dans l’autre ?
Parce que les deux canaux ont des coûts d’activation différents, et la taille de ce coût détermine qui le franchit. Déposer une demande de fonctionnalité demande de l’initiative : une utilisatrice doit croire que la demande vaut la peine d’être articulée, trouver le tableau, et écrire quelque chose de cohérent, ce qui sélectionne des utilisatrices engagées et patientes déjà investies dans le produit. Déposer un ticket support demande presque aucune initiative en comparaison, souvent juste un clic sur “aide” en plein milieu d’une tâche, ce qui signifie qu’il capture des utilisatrices frustrées sur le moment, y compris celles qui ne se seraient jamais donné la peine avec un tableau de demandes. Un vrai manque dans le produit peut être invisible sur le tableau de fonctionnalités et bruyant dans le support simplement parce que les utilisatrices qui y sont confrontées sont celles les moins susceptibles de déposer une demande formelle.
Le volume de tickets pour une fonctionnalité manquante signifie-t-il la même chose que le nombre de votes pour elle ?
Non, parce qu’ils mesurent des populations différentes dans des conditions différentes. Une demande de fonctionnalité avec cent votes représente cent personnes qui ont pris le temps de trouver et soutenir une demande existante, ce qui est un signal fort de demande durable et réfléchie. Cent tickets support sur le même manque sous-jacent, déposés sur la même période, représentent probablement des utilisatrices qui se heurtent à un mur sur le moment, dont certaines oublieraient complètement une fois la friction immédiate passée. Traiter les deux comme un signal équivalent de “cent personnes veulent ça” surpondère le volume de tickets, parce que les tickets sont bon marché à générer et les votes non.
| Tableau de demandes | Tickets support |
|---|---|
| Demande de l’initiative pour déposer | En demande presque aucune |
| Capture une demande réfléchie et durable | Capture une frustration sur le moment |
| Penche vers des utilisatrices engagées et patientes | Capture des utilisatrices qui n’utiliseraient jamais le tableau |
| Un compte de votes est un vrai signal d’engagement | Un compte de tickets reflète la friction, pas toujours le désir |
Que signifie-t-il quand une fonctionnalité a des tickets support mais presque aucun vote sur le tableau ?
Souvent, que la demande existe mais que les utilisatrices qui y sont confrontées ne savent pas que le tableau existe, ne croient pas que voter changerait quoi que ce soit, ou rencontrent le problème trop rarement pour se donner la peine de changer de canal pour l’enregistrer formellement. C’est exactement la population qu’un tableau de demandes rate structurellement, et un faible compte de votes ici n’est pas une preuve de faible demande, c’est une preuve d’un écart de mesure. La solution n’est pas de se méfier des tickets, c’est de traiter un groupe de tickets support autour d’une fonctionnalité manquante comme son propre signal, à enregistrer vous-même sur le tableau, au nom des utilisatrices, pour qu’il ne reste pas invisible à qui priorise seulement à partir des comptes de votes.
Le tableau lit comme priorité basse :
"Export to CSV" : 4 votes sur 6 mois
Le support raconte une autre histoire :
"Export to CSV" : 31 tickets sur la même période, chacun
d'un compte différent, chacun fermé avec "pas
actuellement supporté, nous transmettrons le retour"Un pic de tickets support signifie-t-il toujours que le problème sous-jacent est une fonctionnalité manquante ?
Non, et c’est là que les deux canaux peuvent induire en erreur dans la direction opposée. Un pic de tickets est tout aussi souvent causé par une interface confuse autour d’une fonctionnalité qui existe déjà, un bug, ou un changement sorti sans explication adéquate, rien de tout cela ne se résolvant en construisant quelque chose de nouveau. Lire chaque pic de tickets comme “les utilisatrices veulent une fonctionnalité que nous n’avons pas” produit une roadmap remplie de choses qui étaient en réalité des manques de documentation ou des problèmes d’utilisabilité déguisés. Le ticket support vous dit où est la friction ; il ne vous dit pas à lui seul si la solution est une nouvelle fonctionnalité, un changement d’interface, ou un meilleur article d’aide, et confondre cela gaspille du temps d’ingénierie sur la mauvaise solution.
Comment les deux signaux devraient-ils vraiment être combinés pour décider quoi construire ?
Utilisez les tickets pour trouver où est la friction, et utilisez le tableau de demandes, plus un contact direct là où le tableau est maigre, pour confirmer à quoi ressemble vraiment le résultat souhaité. Un groupe de tickets identifie un problème réel et ressenti ; il spécifie rarement la solution avec assez de précision pour construire dessus, parce qu’une utilisatrice frustrée dans une conversation de support décrit des symptômes, pas des spécifications. Le tableau de demandes, quand il a assez de votes sur le même problème sous-jacent, tend à porter plus du détail de “qu’est-ce qui satisferait vraiment ça”, parce qu’écrire une demande est déjà un acte de spécifier ce qu’on veut, pas juste de rapporter ce qui ne va pas.
Les agentes support devraient-elles enregistrer elles-mêmes les tickets comme demandes de fonctionnalités ?
Oui, et c’est le correctif à plus fort levier pour l’écart entre les deux canaux. Une agente qui reconnaît un ticket comme une demande de fonctionnalité déguisée, plutôt que de simplement le résoudre et passer à autre chose, peut l’enregistrer sur le tableau au nom de la cliente, ce qui comble directement l’écart de mesure plutôt que d’exiger que la cliente découvre et utilise un second canal. Cela ne fonctionne que si l’enregistrement prend des secondes, pas des minutes, pour l’agente, pour que la friction de le faire soit inférieure à la friction de simplement fermer le ticket et passer au suivant.
FAQ
Les votes de demandes de fonctionnalités devraient-ils jamais être décomptés s’ils viennent tous d’un seul compte ou d’une seule équipe ? Oui, pondérez par comptes ou organisations distincts plutôt que par compte brut de votes, parce que cinq votes de cinq personnes de la même entreprise représentent les priorités d’une cliente, pas cinq confirmations indépendantes de demande.
Vaut-il la peine de construire une fonctionnalité qui apparaît beaucoup dans les tickets mais a presque aucun vote ? Souvent oui, à condition que le volume de tickets vienne vraiment de comptes distincts et que le besoin sous-jacent soit confirmé plutôt que supposé ; traitez le faible compte de votes comme un artefact de mesure du coût d’activation du tableau, pas comme une preuve que la demande n’est pas réelle.
Comment distinguer d’un coup d’œil un ticket de confusion d’interface d’un vrai ticket de fonctionnalité manquante ? Regardez si la résolution consiste à expliquer une capacité existante ou à s’excuser pour une manquante. Un motif de résolutions “oh, c’est en fait juste là” pointe vers un problème d’interface ou de découvrabilité ; un motif de “on ne supporte pas encore ça” pointe vers un vrai manque.
Cette distinction compte-t-elle autant avec un très petit volume de support ? Moins mécaniquement, puisqu’une poignée de tickets est facile à lire individuellement sans avoir besoin d’analyse agrégée, mais le biais sous-jacent, les tickets surreprésentent les utilisatrices frustrées et sous-représentent les patientes, est présent à toute échelle et vaut la peine d’être gardé à l’esprit même quand vous lisez chaque ticket vous-même.
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.