Les appels clients deviennent des tickets

Chaque équipe produit a la même fuite. Un client décrit un bug pendant un appel, la personne sur l'appel s'en fait une note mentale, et la note ne survit pas à l'après-midi. La transcription existe, complète et consultable, et personne ne relit une transcription. Le bug est signalé à nouveau par quelqu'un d'autre quatre mois plus tard et traité comme nouveau.

Les deux bouts de la solution existent déjà. Les appels sont transcrits automatiquement, et le tracker est là où le travail se décide. Ce qui manque, c'est le passage sur les transcriptions, réellement fastidieux et réellement mécanique jusqu'au moment où quelqu'un doit décider si une plainte devient un ticket.

Ce que l'IA extrait d'un appel client

L'exécution démarre la nuit, une fois les appels du jour enregistrés et transcrits. Elle récupère chaque appel enregistré dans les vingt-quatre dernières heures depuis Granola, avec sa transcription, ses participants, son compte et sa date. Les appels purement internes sont ignorés sauf demande explicite de l'équipe, car l'essentiel de ce qui fait un bon ticket vient d'un client qui le dit.

Chaque transcription est lue pour trois types d'éléments, rien d'autre :

• Un bug. Quelque chose s'est mal comporté. Il faut un symptôme décrit, pas seulement de l'insatisfaction.
• Une demande de fonctionnalité. Quelque chose qu'ils veulent et qui n'existe pas. Il faut un besoin exprimé, pas une hypothèse.
• Un manque de documentation. Ils n'ont pas réussi à trouver comment faire quelque chose qui fonctionne déjà.

Les compliments, les discussions de prix, la planification et les récriminations générales sont écartés. Chaque élément garde les mots exacts du client comme citation, avec la date de l'appel et qui l'a dit. Un dernier filtre s'applique avant toute création : une personne lisant seulement cet élément saurait-elle quoi faire ensuite ? Sinon, il part dans le récap hebdomadaire comme signal peu clair.

Des retours d'appels aux tickets

Avant de rien créer, l'agent cherche chaque élément dans Linear et compare le fond plutôt que la formulation. Un client qui décrit « ça me déconnecte quand je change d'onglet » et un ticket ouvert titré « session perdue au changement de visibilité » sont le même bug. Quand le ticket existe déjà, la citation et le nom du compte y sont ajoutés en commentaire.

Un nouvel élément devient un ticket sur le board qui possède cette zone, avec un titre décrivant le symptôme plutôt qu'une cause supposée, la citation du client, le compte, la date de l'appel et un lien vers l'enregistrement. La sévérité vient de ce qui a réellement été dit : un client qui décrit un contournement qu'il effectue désormais chaque jour est en sévérité haute, une mention en passant ne l'est pas. Les manques de documentation partent vers Notion sous forme d'ébauche de page à la place, pour ne pas concurrencer le travail d'ingénierie dans la même file et pour atteindre la personne qui peut les résoudre.

Ce qui fait tenir l'automatisation des appels en tickets

Commenter le ticket existant plutôt qu'en créer un nouveau, et voilà ce qui transforme un outil de transcription en outil de priorisation. Classé en doublons, un bug signalé par six clients ressemble à six petits problèmes que personne n'a le temps de traiter. Regroupé sur un seul ticket avec six citations attachées, il ressemble à ce qu'il est réellement. Le compteur de corroboration est ce qui change ce qui se construit, et il n'apparaît que si la déduplication se fait avant la création.

Garder les mots exacts du client n'est pas un détail cosmétique. Un ingénieur qui lit « l'utilisateur signale une instabilité de session » n'a rien appris ; qui lit « ça me déconnecte à chaque fois que je change d'onglet, du coup je garde un second navigateur ouvert juste pour ça » a appris le symptôme, la fréquence et le contournement. C'est dans la paraphrase que les trois disparaissent, et cela arrive par défaut parce que résumer semble être le geste utile.

Le seuil de création est la part la plus importante à défendre. Un passage sur les transcriptions avec un seuil bas génère des tickets plausibles pour la moindre remarque en passant, et le tracker devient un endroit où les vrais problèmes sont enterrés sous des tickets spéculatifs. Envoyer tout ce qui n'atteint pas le seuil vers le récap fait que rien n'est perdu, mais rien de peu clair n'atteint le board non plus.

Le récap du vendredi

Une fois par semaine, un récapitulatif part sur Slack plutôt qu'un flux nocturne : nouveaux tickets par zone, tickets existants ayant gagné en corroboration et nombre de clients les ayant désormais signalés, manques de documentation ouverts, et signaux peu clairs qui n'ont pas atteint le seuil. Le compteur de corroboration est le chiffre le plus utile du récap. Un client qui mentionne quelque chose est une anecdote ; le même problème signalé par six comptes en deux semaines est une priorité, et cela n'est visible que parce que les signalements sont des commentaires sur un seul ticket.