Priorise les tickets de support selon ce qui revient vraiment
5 min de lecture
La plupart des priorisations commencent par les tickets qu’un PM a lus récemment, ou ceux qui ont été escaladés bruyamment. Ce n’est pas la même chose que de savoir ce qui est réellement le plus courant, et cela veut dire qu’un problème discret mais fréquent peut perdre à chaque fois face à un problème rare mais bruyant. Un PM qui ouvre la file de support un lundi matin a bien plus de chances d’agir sur le ticket escaladé par un responsable de compte pendant le week-end que sur le fait que trente autres utilisateurs ont discrètement signalé, ce mois-ci, une version plus petite de la même friction de fond.
Attention
Un ticket dont tu te souviens et un ticket qui revient sont des signaux différents. Celui dont tu te souviens est peut-être juste celui qui a été escaladé, pas celui qui touche le plus d’utilisateurs.
Le ticket dont tu te souviens n’est pas toujours celui à corriger en premier. Celui qui revient sans cesse, si.
Pourquoi lire les tickets dans l’ordre ne fait pas ressortir la vraie fréquence
Parcourir une file de support donne des impressions, pas des chiffres. Un problème signalé par quinze utilisateurs différents de quinze façons n’a pas l’air d’un schéma quand on lit un ticket à la fois, il ressemble à quinze plaintes distinctes. L’effort mental de tenir un décompte à travers des dizaines de tickets, chacun formulé différemment, est exactement le type de comptage où un relecteur humain est mauvais et tend à sous-estimer.
Prends la file de support d’un parcours d’accueil où un utilisateur, un compte entreprise, escalade bruyamment une étape de configuration déroutante. Ce ticket reçoit vite de l’attention. Pendant ce temps, la même semaine, trente utilisateurs de l’offre gratuite soumettent discrètement des tickets sur la même étape, formulés de trente façons, aucun escaladé, aucun alarmant isolément. Lus dans l’ordre d’arrivée, le ticket bruyant de l’entreprise domine le modèle mental du PM sur ce qui est cassé, tandis que le problème réellement le plus fréquent, qui touche bien plus d’utilisateurs, reste méconnu comme schéma à travers trente tickets séparés.
Avant : survoler les tickets récents, prioriser ceux qui paraissent les plus urgents ou ont été escaladés, passer à autre chose.
Après : coller un lot de tickets dans Claude, lui demander de les regrouper en thèmes classés selon le nombre de tickets dans chacun et prioriser d’après la fréquence réelle.
Une méthode pour transformer des tickets en thèmes classés
- 1
Rassemble un vrai lot, pas une poignée
Prends des tickets sur une fenêtre définie, une semaine ou un mois entiers, plutôt que ce qui traîne dans ta boîte de réception. Un échantillon partiel penche vers ce qui est arrivé le plus récemment.
- 2
Demande des thèmes regroupés par fréquence, pas un résumé
Un résumé comprime ce qui a été dit. Demande précisément des tickets regroupés en thèmes récurrents, avec le nombre de tickets dans chaque groupe.
- 3
Demande un ticket représentatif par thème
Un exemple réel ancre chaque thème dans du concret, et il sert plus tard quand tu dois justifier une priorité avec un cas réel, pas seulement un chiffre.
- 4
Priorise par nombre, puis vérifie avec la gravité
La fréquence te dit ce qui est courant, pas forcément ce qui coûte le plus. Une fois la liste classée, vérifie si un thème moins fréquent mérite de remonter à cause de sa gravité.
Voici 30 tickets de support sur notre parcours d’accueil. Regroupe-les en trois plaintes les plus courantes et dis-moi combien de tickets tombent dans chaque groupe.
”Une fois les thèmes classés, il vaut la peine de vérifier s’ils ont grossi ou diminué par rapport à une période précédente, car un thème en forte hausse semaine après semaine est une autre sorte d’urgence qu’un bourdonnement régulier de faible niveau depuis des mois.
Voici la même répartition par thèmes du mois dernier. Compare les deux et dis-moi quels thèmes progressent en part du total des tickets, et pas seulement lesquels ont le plus grand nombre brut ce mois-ci.
”
Dans Claude Tutorial
Classer selon la fréquence réelle plutôt que la récence est transposable.
Regrouper des signalements épars en thèmes chiffrés, au lieu de prioriser ce que tu as vu le plus récemment, vaut bien au-delà des tickets de support. L’appli propose une leçon complète à ce sujet, avec une pratique qui s’applique à tout retour sur lequel tu dois agir.
Quand fréquence et gravité pointent dans des directions différentes
Parfois le thème le plus courant n’est pas le plus dommageable. Une gêne mineure signalée souvent et un bug rare qui bloque un compte méritent tous deux une place dans la liste, mais pas forcément dans l’ordre de fréquence. Traiter la fréquence comme seule donnée risque de sous-prioriser systématiquement les problèmes rares mais graves qui génèrent peu de tickets simplement parce que les utilisateurs touchés ne vont pas assez loin dans le produit pour en déposer un.
Astuce
Demande à Claude de signaler quels thèmes impliquent des utilisateurs totalement bloqués et lesquels de simples gênés. Un problème bloquant avec moins de signalements peut quand même passer devant un thème plus gros mais de faible gravité.
Parmi les trois thèmes que tu as trouvés, lesquels impliquent des utilisateurs complètement empêchés de terminer l’accueil, et lesquels simplement agacés par la friction ? Je veux peser la gravité en plus de la fréquence avant de finaliser la priorité.
”Il vaut aussi la peine de vérifier si un thème rare mais grave pourrait être sous-déclaré précisément parce qu’il est grave, car un utilisateur qui rencontre un blocage sérieux tôt dans l’accueil peut abandonner le produit plutôt que de prendre le temps de déposer un ticket.
Ce problème bloquant n’a généré que 3 tickets, ce qui paraît peu pour quelque chose d’aussi grave. Y a-t-il une raison pour qu’un problème bloquant comme celui-ci soit sous-déclaré par rapport à un autre plus léger qui laisse les utilisateurs continuer ?
”Pour aller plus loin
- Rédiger un document de feuille de route qui explique les arbitrages : transformer une liste classée de thèmes en décision de feuille de route que les parties prenantes peuvent suivre.
- Rédiger un PRD à partir d’une demande de fonctionnalité d’une ligne : que faire une fois qu’un thème fait apparaître une fonctionnalité à spécifier.
- Affûter un PRD avant de l’envoyer en relecture : repérer avant la relecture les cas limites vers lesquels un thème comme celui-ci peut pointer.