La phrase la plus coûteuse du support

« Pourriez-vous nous envoyer une capture d'écran et nous dire quel navigateur vous utilisiez ? » C'est une question polie et raisonnable, et c'est la raison pour laquelle un bug de deux minutes met trois jours à être corrigé. Le client est occupé, donc la réponse arrive le lendemain. La capture montre le message d'erreur mais pas le clic qui l'a déclenché. La version du navigateur est fausse parce qu'il a vérifié sur son téléphone. Quand l'équipe technique voit le ticket, plus personne ne se souvient exactement de ce qui s'est passé, pas même le client.

La solution n'est pas un meilleur formulaire de signalement. C'est d'arrêter de demander au client des preuves que vous auriez pu capturer vous-même, au moment où le problème s'est produit.

Ce que contient vraiment un bon signalement de bug

Pour reproduire un bug, les développeurs ont besoin de cinq choses :

  • Ce que le client a fait : les clics et les saisies, dans l'ordre.
  • Ce qu'il attendait : le résultat qu'il cherchait à obtenir.
  • Ce qui s'est réellement passé : l'erreur, l'écran vide, le bouton qui ne fait rien.
  • L'environnement : page, navigateur, appareil, taille d'écran et provenance.
  • La trace technique : les erreurs de console et les requêtes réseau en échec.

Un client peut vous donner de façon fiable le deuxième élément et une partie du troisième. Les trois autres sont exactement ce qu'enregistre un replay de session : la séquence d'actions, la page et le navigateur, le log de console et les appels réseau. Demander aux gens de reconstituer tout cela de mémoire, c'est leur demander la partie qu'ils sont le moins à même de fournir.

Joignez la session au lieu de la demander

Le point de départ le plus simple, c'est le signalement lui-même. Quand un client envoie un widget de retours ou un formulaire de bug dans l'application, la session est là : la page où il se trouve, les erreurs qui viennent de se déclencher, les requêtes qui ont échoué une seconde plus tôt. Capturez-la avec le signalement, et le ticket arrive déjà avec ce dont l'équipe technique a besoin.

Cela change la première réponse. Au lieu de « pouvez-vous envoyer une capture ? », l'agent ouvre le replay, voit le TypeError dans la console deux secondes avant que le client ne clique à nouveau sur Payer, et peut répondre dans l'heure : « nous voyons ce qui n'a pas fonctionné, voici une solution de contournement ».

L'e-mail est plus difficile, car un e-mail n'a pas de session attachée. Deux habitudes aident. Identifiez les utilisateurs connectés dans vos analytics pour qu'un ticket venant d'une adresse connue puisse être rapproché de leurs sessions récentes, et placez un lien de retour dans le produit pour que le prochain signalement vienne de la page où se trouve le problème, et non d'une boîte mail le lendemain.

Triez par bug, pas par ticket

Dès que les tickets portent l'erreur, vous pouvez les regrouper par erreur. C'est là que la plupart des équipes gagnent le plus. Un bug de paiement ne produit pas un ticket ; il en produit trente, chacun formulé différemment : « paiement échoué », « impossible d'acheter », « bouton cassé ». Lus un par un, ils ressemblent à trente problèmes. Regroupés par le message d'erreur qu'ils partagent, ils forment un seul bug avec trente clients concernés, et c'est ce chiffre qui le fait passer en priorité.

Le regroupement change aussi la façon de boucler la boucle. Escaladez le bug une seule fois, vers un ticket dans Linear, GitHub ou Jira, et rattachez-y chaque ticket correspondant. Quand le correctif est livré, chacun de ces clients peut en être informé, et pas seulement les cinq qui ont pensé à relancer.

Pour que cela fonctionne, le regroupement doit correspondre à ce que voit déjà l'équipe technique. Si le support compte des « problèmes de paiement » et que l'équipe technique compte Cannot read properties of undefined (reading 'total'), les deux listes ne se recoupent jamais. Regroupez les tickets selon le même message d'erreur normalisé que votre suivi des erreurs.

Réglez la confidentialité avant qu'elle ne vous règle

Joindre des sessions aux tickets signifie que les agents voient davantage de ce que les clients ont fait. Fixez donc les règles d'abord :

  • Masquez les champs de formulaire par défaut, et n'enregistrez jamais les mots de passe ni les champs de paiement.
  • Indiquez dans votre politique de confidentialité que le support peut consulter la session liée à une demande.
  • Réservez l'accès aux replays aux personnes qui traitent les tickets, pas à tous ceux qui ont un identifiant.
  • Respectez le consentement : un visiteur qui a refusé l'analytique ne devrait pas avoir de session à joindre.

Fait ainsi, le contexte de session est moins intrusif que l'alternative, qui consiste à demander aux clients de partager leur écran ou d'envoyer des captures de leur compte par e-mail.

Un workflow à lancer dès cette semaine

  1. Ajoutez un widget de retours ou de signalement de bug dans l'application sur les pages où les problèmes surviennent le plus : paiement, onboarding, paramètres.
  2. Capturez la session à chaque envoi, pour que chaque ticket porte le replay, le log de console et les requêtes en échec.
  3. Identifiez les utilisateurs connectés, pour que les tickets e-mail de clients connus puissent être rapprochés de leurs sessions.
  4. Regroupez les tickets par erreur et passez en revue les principaux groupes chaque semaine avec l'équipe technique.
  5. Escaladez chaque bug une seule fois et répondez à chaque client concerné une fois qu'il est corrigé.

Ce qu'il faut mesurer

Quatre chiffres vous disent si cela fonctionne :

  • La part des tickets de bug avec une session jointe. C'est l'indicateur avancé ; faites-le monter en premier.
  • Le délai jusqu'à la première réponse utile, c'est-à-dire une réponse qui ne demande pas plus d'informations.
  • Le nombre de tickets par bug. S'il baisse, vous corrigez les bugs qui génèrent le plus de charge de support.
  • Le taux de réouverture des tickets de bug, qui baisse quand la première réponse est la bonne.

Le help desk de PulsePanda est construit autour de cette boucle : les retours deviennent des tickets avec le replay et les erreurs joints, les tickets sont regroupés selon les mêmes erreurs que la page Erreurs, et l'escalade vers Linear, GitHub ou Jira vous permet de répondre à chaque client concerné quand le ticket est clos.