Du chat client au ticket Jira, et retour : un processus d'escalade des bugs auquel le support et l'équipe technique font confiance
Le support escalade un bug, l'équipe technique reçoit un rapport flou, et le client n'entend plus parler de rien jusqu'à ce qu'il réessaie. Ce processus en 4 étapes règle chaque passage de relais, avec un modèle de rapport de bug, des règles de statut et un message pour le jour où la correction sort.
Sommaire
- Comment un bug se perd entre le support et l'équipe technique
- Étape 1 : prouver que c'est un défaut avant que l'équipe technique le voie
- Étape 2 : un seul ticket Jira par bug, avec chaque ticket concerné lié
- Étape 3 : faire remonter le statut Jira jusqu'au support
- Étape 4 : prévenir chaque client concerné dès que la correction est disponible
- Appliquer le processus dans Deskwoot
- Combien ça coûte et par où commencer
Vous escaladez un bug et personne ne vous répond. L'équipe technique se plaint que le support lui envoie des questions qui n'ont jamais été des bugs. Puis 3 tickets Jira s'empilent pour un seul défaut, et personne ne peut dire au client quand la correction arrive.
Ce guide vous donne un processus en 4 étapes, avec un passage de relais clair à chaque étape, plus 5 questions de tri, un modèle de rapport de bug et un message pour le jour où la correction sort.
Comment un bug se perd entre le support et l'équipe technique
Une cliente écrit dans le chat de votre site web : le PDF de facture qu'elle exporte depuis votre app iPad s'arrête avant la dernière page. Votre agent essaie, constate la même chose et poste dans le canal de l'équipe technique : « Export PDF cassé sur iPad ? » Quelqu'un réagit avec un emoji.
Pendant les 2 semaines suivantes, 4 autres clients le signalent, 2 agents ouvrent 3 tickets Jira à eux deux, et personne au support ne sait dire si une correction arrive. Quand elle sort enfin, les clients s'en rendent compte en réessayant.
Tray.ai, qui vend un logiciel d'automatisation, décrit cette fin dans son guide sur l'escalade vers l'équipe technique : « le client l'apprend quand même par les notes de version, ou en posant la question », parce que « personne n'était chargé de le prévenir ».
L'équipe technique a la plainte inverse. Zenatta, un cabinet de conseil qui met en place des services d'assistance sur Zoho, écrit dans une étude de cas sur son site web qu'un « backlog Jira rempli de questions du support qui n'ont jamais été des défauts devient un bruit que l'équipe technique apprend à ignorer ».
Chacune des 4 étapes ci-dessous se termine par un passage de relais clair, et elles fonctionnent avec n'importe quel logiciel de support relié à Jira.
Étape 1 : prouver que c'est un défaut avant que l'équipe technique le voie
Beaucoup d'escalades qui agacent les développeurs dérapent ici : le client n'a pas trouvé un réglage, ou veut quelque chose que le produit n'a jamais fait.
L'équipe support d'Atlassian elle-même suit une règle simple dans sa politique de correction des bugs Cloud : « Nous essaierons de reproduire le bug pour le vérifier et, si nous y arrivons, nous enregistrerons le rapport pour vous. » Copiez-la. Si personne au support ne peut reproduire le problème, il n'est pas prêt pour Jira.
5 questions avant toute escalade
Avant d'escalader, l'agent répond à 5 questions dans le ticket :
- Puis-je le reproduire, et sur quel appareil, navigateur, version de l'app ou compte ?
- Est-ce un comportement documenté, d'après le centre d'aide ou les notes de version ?
- Est-ce déjà dans Jira ? Cherchez le texte de l'erreur et le nom de la fonctionnalité.
- Qui est touché ? Un compte, un forfait, tous les utilisateurs Android ?
- Qu'est-ce que cela bloque, et existe-t-il une solution de contournement ?
Où va chaque signalement
Ensuite, triez le signalement selon ce qu'il est vraiment :
| Il s'agit en fait de | Exemple | Où il va |
|---|---|---|
| Une question sur l'utilisation du produit | « Où est-ce que je change le pied de page de la facture ? » | Y répondre et donner le lien de l'article d'aide |
| Un problème de réglage ou de données dans un compte | Mauvais taux de TVA sur les factures d'un client | Le support le corrige |
| Une demande de fonctionnalité | « Le PDF peut-il afficher notre logo sur chaque page ? » | Votre liste de retours sur le produit, jamais le backlog des bugs |
| Un défaut que vous pouvez reproduire | Le PDF s'arrête avant la dernière page sur iPad | Étape 2 |
| Une panne que beaucoup de clients remarquent en même temps | Personne ne peut se connecter | Étape 2 tout de suite ; rassemblez les clients concernés dès le premier signalement |
La priorité dans les termes de l'équipe technique
Pour la priorité, utilisez l'échelle de l'équipe technique. S'il n'y en a pas, empruntez celle d'Atlassian :
- Priorité 1 quand « les utilisateurs ne peuvent pas faire leur travail et qu'aucune solution de contournement n'existe ».
- Priorité 3 quand une fonctionnalité « ne fonctionne pas comme prévu, mais qu'une solution de contournement existe ».
Le support décrit l'impact dans ces termes, et l'équipe technique fixe l'ordre du travail à partir de là.
Étape 2 : un seul ticket Jira par bug, avec chaque ticket concerné lié
Cherchez dans Jira avant de créer quoi que ce soit. Un deuxième ticket Jira pour le même défaut répartit les commentaires et le nombre de clients sur 2 endroits, et quelqu'un doit en fermer un comme doublon.
Le guide de Tray.ai résume l'objectif ainsi : « Un seul ticket par bug, avec chaque ticket concerné lié à celui-ci. » Ces liens sont aussi votre argument : selon le guide, le nombre de clients et le chiffre d'affaires qu'ils représentent « sont ce qui fait passer un bug en priorité ».
Un rapport de bug exploitable par les développeurs
Une étude utile à connaître ici est « What Makes a Good Bug Report? » de Zimmermann et ses collègues (IEEE Transactions on Software Engineering, 2010). Elle repose sur 466 réponses à une enquête menée auprès de développeurs et de personnes qui signalent des bugs chez Apache, Eclipse et Mozilla.
- Parmi les développeurs qui avaient utilisé des étapes de reproduction, 83% les ont placées parmi les 3 éléments qui les avaient le plus aidés.
- Parmi ceux qui étaient tombés sur des rapports incomplets, 74% ont cité ce problème parmi les 3 qui retardaient le plus les corrections.
Les éléments que les développeurs appréciaient le plus étaient aussi les plus difficiles à fournir pour ceux qui signalent. Le support peut combler cet écart, car l'agent peut encore poser la question au client tant que le chat est ouvert.
Utilisez toujours les mêmes rubriques :
| Rubrique | Ce qu'on y met | Exemple |
|---|---|---|
| Titre | Le défaut en une ligne, sans nom de client | Le PDF de facture s'arrête avant la dernière page dans l'app iPad |
| Problème | Ce qui ne va pas, en 1 ou 2 phrases | Les factures de plus de 1 page perdent leur dernière page à l'export |
| Étapes pour reproduire | Numérotées, en partant de zéro | 1. Ouvrir une facture avec 12 lignes. 2. Appuyer sur Exporter en PDF. 3. Ouvrir le fichier. |
| Attendu | Ce qui devrait se passer | Les 12 lignes sur 2 pages |
| Constaté | Ce qui se passe, avec le texte de l'erreur copié mot pour mot | Le PDF s'arrête après la ligne 9 |
| Environnement | Appareil, système, version de l'app, navigateur | iPad Air, iPadOS 18, app 4.2.1 |
| Impact | Combien de clients, ce que cela bloque, la solution de contournement | 5 comptes pour l'instant ; ils exportent depuis l'app web à la place |
| Déjà essayé | Ce que le support a écarté | App réinstallée ; même résultat sur 2 comptes de test |
Gardez les données des clients hors de Jira
N'indiquez ni le nom, ni l'adresse e-mail, ni le numéro de téléphone, ni le numéro de commande du client, sauf si un développeur en a besoin pour reproduire le bug. Si votre logiciel de support ajoute dans Jira un lien vers le ticket avec le titre du ticket, nommez les tickets d'après le problème, jamais d'après le client.
Jira est souvent lu par plus de monde que votre outil de support. Et la copie qui s'y trouve est en dehors de l'endroit où vous traitez les demandes de suppression et d'accès.
Si le RGPD s'applique à vous, c'est aussi son principe de minimisation des données, à l'article 5(1)(c). Le résumé de la Commission européenne indique que les données personnelles doivent être « adéquates, pertinentes et limitées à ce qui est nécessaire au regard de la finalité ». Il s'agit d'informations générales, pas d'un conseil juridique.
Étape 3 : faire remonter le statut Jira jusqu'au support
Une fois le ticket Jira créé, le support ne devrait jamais avoir besoin de demander « du nouveau là-dessus ? » dans un chat d'équipe. Le statut doit arriver tout seul dans le ticket.
Dans Zendesk, il faut pour cela ajouter une post function au workflow Jira. L'article d'aide de Zendesk décrit le résultat : « Jira peut ajouter automatiquement une note interne au ticket Zendesk lié pour prévenir l'agent. L'agent peut alors prévenir le client. »
Quel que soit votre outil, testez-le une fois avec un ticket Jira factice.
Done ne veut pas toujours dire livré
Mettez-vous d'accord avec l'équipe technique sur le statut Jira qui signifie que les clients ont la correction. Dans beaucoup d'équipes, Done veut dire fusionné ou testé, et la version sort quelques jours plus tard.
Si votre workflow a un statut Released ou Deployed, c'est votre déclencheur pour l'étape 4, et le support a besoin de son nom exact. Done et Released se trouvent en général tous les deux dans la catégorie Done de Jira, donc une règle qui ne regarde que la catégorie rate le passage de Done à Released.
Apportez le chiffre à la planification
Une fois par semaine, le responsable du support devrait donner à l'équipe technique le nombre de tickets ouverts en attente de chaque ticket Jira. En planification, « 14 comptes ont signalé APP-482 » va plus loin que « les clients n'arrêtent pas de poser la question ».
Étape 4 : prévenir chaque client concerné dès que la correction est disponible
Attendez que la correction soit entre les mains des clients, puis vérifiez-la vous-même avec la configuration de l'étape 1.
Écrivez à tous ceux qui ont signalé le bug, y compris les clients qui ont seulement dit « pareil pour moi ». Décrivez le problème avec leurs mots et dites-leur quoi faire maintenant :
Bonjour, petite mise à jour sur les PDF de facture de l'app iPad qui s'arrêtaient avant la dernière page. Nous l'avons corrigé dans la version 4.2.2, disponible dès maintenant sur l'App Store.
Après la mise à jour, exportez à nouveau la facture : toutes les pages y sont. Si quelque chose ne va toujours pas, répondez ici avec une capture d'écran.
La fenêtre de 24 heures sur WhatsApp
Meta n'autorise le texte libre que dans les 24 heures qui suivent le dernier message du client (la fenêtre de service client). Ensuite, une entreprise ne peut envoyer que des messages basés sur des modèles approuvés.
La plupart des corrections prennent plus d'une journée, alors faites approuver un modèle pour annoncer les corrections avant d'en avoir besoin.
Appliquer le processus dans Deskwoot
Deskwoot est notre logiciel de support, et il gère les étapes 2 à 4 depuis le ticket : la tâche interne que votre équipe détache d'un chat client (voir comment créer un ticket depuis un chat). Le client ne voit jamais ni le ticket ni le ticket Jira.
Un rapport de bug rédigé à partir du chat
Rédiger le rapport de bug avec Copilot écrit le titre et la description à partir du ticket, de son chat et des commentaires de votre équipe. Copilot lit le chat avec « nom masqué » à la place du nom du client, et a pour consigne de laisser de côté les coordonnées et les numéros de commande, sauf si un développeur en a besoin.
Rien ne part vers Jira tant que l'agent n'a pas vérifié le brouillon et cliqué sur Créer le ticket Jira, et le ticket Jira est créé avec son propre compte Atlassian. Chaque brouillon compte dans vos conversations IA.
Des lignes de statut et 2 règles prêtes à l'emploi
Chaque changement de statut dans Jira écrit une ligne dans chaque ticket lié, par exemple « Le ticket Jira APP-482 est passé à In Progress. » Une recherche de APP-482 dans la liste des tickets trouve chaque ticket lié pour votre décompte de la semaine.
La page des paramètres Jira propose 2 règles prêtes à l'emploi, à vérifier puis à enregistrer :
| Règle | S'exécute quand | Effet |
|---|---|---|
| Ticket Jira créé ou lié | Un ticket Jira est créé depuis le ticket ou lié à celui-ci, et n'est pas encore terminé | Applique le statut de ticket que vous choisissez, par exemple votre propre statut En attente de l'équipe technique |
| Ticket Jira terminé | Le ticket Jira passe dans la catégorie Done depuis une autre catégorie | Applique un statut de ticket, rend le ticket à la personne qui a lié le ticket Jira et ajoute une note privée : « Le ticket Jira lié est terminé. Vérifiez la correction et prévenez le client. » |
Si, dans votre Jira, Done arrive avant la livraison, remplacez les conditions de catégorie de la deuxième règle par le nom du statut, par exemple Le statut du ticket Jira est Released. L'article d'aide sur Jira donne les détails.
Une seule mise à jour pour tous les clients concernés
Avec 2 ou 3 clients concernés, utilisez Répondre au client sur chaque ticket. Au-delà, utilisez un ticket groupé, un ticket sans client pour un problème que partagent beaucoup de clients, et liez-y les chats concernés, les tickets et le ticket Jira.
Quand la correction est disponible, Mettre à jour les clients liés envoie votre texte à chaque client dans son propre chat, jusqu'à 500 clients à la fois. La même étape peut aussi résoudre les chats et les tickets liés.
Les mises à jour d'un ticket groupé ne sont jamais envoyées sous forme de modèles WhatsApp. Sur une boîte de réception WhatsApp Cloud API, ouvrez les chats qui sont hors de la fenêtre de 24 heures et envoyez un modèle approuvé depuis la zone de réponse.
Combien ça coûte et par où commencer
Les tickets, les tickets groupés et l'intégration Jira sont inclus dans le forfait Enterprise : $12 par agent et par mois, ou $9.60 avec un paiement annuel (tarifs).
Commencez petit :
- Connectez Jira.
- Créez un statut de ticket pour le travail qui attend l'équipe technique.
- Enregistrez les 2 règles prêtes à l'emploi.
Le prochain bug qui arrive par le chat sera votre test. Créez un compte et votre nouvel espace de travail profite de 7 jours d'Enterprise sans carte bancaire, pour 30 sièges maximum, le vôtre compris.
À la fin des 7 jours, vous choisissez un forfait ou vous continuez avec le forfait gratuit Hacker pour 1 agent.
Également disponible en:EnglishDeutschEspañolPortuguês (Brasil)
