Regrouper les retours des utilisateurs sans perdre les demandes d’origine

Les retours sont dispersés entre les fils d’assistance, les canaux d’équipe et les tickets. Un même problème est décrit de différentes façons, un message peut contenir plusieurs demandes et un long fil peut donner l’impression qu’il y a de nombreuses plaintes distinctes.

Choisissez la boîte de réception d’assistance, le canal ou le projet que l’agent doit consulter, puis indiquez la période et les filtres. Demandez-lui d’enregistrer les identifiants des messages récupérés, les liens vers les sources et l’heure de récupération avant de regrouper les signalements. L’analyse repose ainsi sur un ensemble fixe de données, même si de nouvelles réponses arrivent ensuite.

Read last month’s conversations in the connected support inbox about booking times.
Follow the replies in each matching thread. Save the source IDs and links.
Propose groups, distinguish feature requests from reported bugs, and count distinct accounts where IDs are available.
Compare the groups with issues in the connected project tracker.
Show likely existing matches and draft new issues for review. Do not send customer replies.

Les résultats de recherche ne sont qu’un point de départ. La lecture du reste de la conversation peut révéler qu’un bug signalé a été résolu, qu’un client a modifié sa demande ou que deux signalements apparemment distincts concernent le même incident. Conservez les extraits pertinents dans le fichier de travail, sans y copier les coordonnées dont l’analyse n’a pas besoin.

Trois messages, deux problèmes différents

Prenons ces exemples fictifs tirés d’un produit de réservation :

Le groupe sur le fuseau horaire compte trois messages source. Celui sur l’e-mail en compte un. Les deux groupes totalisent quatre mentions, mais seulement trois messages, car F02 contient deux problèmes. Si le rapport parle de « demandes », précisez si ce terme désigne les messages, les mentions ou les comptes distincts.

Ajoutez un court extrait à chaque classification. « L’écran de réservation n’affiche que l’heure du bureau » peut signaler des libellés confus ou l’absence d’une fonction de conversion. Notez cette ambiguïté dans une colonne de révision au lieu de choisir discrètement une interprétation.

Comptez aussi les clients concernés, pas seulement les messages

Supposons que F01 et F02 proviennent du même compte, et F03 d’un autre. Le groupe sur le fuseau horaire compte toujours trois messages, mais ceux-ci représentent deux comptes connus. Si les données récupérées ne comportent pas d’identifiants de compte, le nombre de comptes est inconnu. La similitude des formulations ne permet pas de conclure que deux messages viennent de la même personne.

Un ensemble de tickets d’assistance indique les motifs pour lesquels des personnes ont contacté le support. Il ne vous dit pas quelle proportion de l’ensemble des clients a rencontré le problème. Même « deux comptes sur dix dans cette analyse » ne décrit que les conversations sélectionnées. Indiquez la période de collecte, les filtres et les canaux à côté des décomptes, afin que les lecteurs sachent à quoi correspondent les chiffres.

Vous pouvez demander à Beeuni de comparer les thèmes d’une période à l’autre, mais veillez à comparer des données équivalentes. Si les tickets du mois dernier viennent uniquement du support, tandis que ceux de ce mois comprennent aussi un sondage intégré au produit, une hausse du décompte peut s’expliquer par cette nouvelle source. Conservez les libellés des canaux pour comparer le support au support avant de tirer des conclusions sur une tendance.

Un suivi peut scinder un thème apparemment clair

Poursuivons avec l’exemple fictif du produit de réservation. L’équipe demande aux auteurs de F01 et F03 quel écran ils ont utilisé et quelle heure ils s’attendaient à voir. L’un répond que l’heure affichée était correcte, mais que le libellé du fuseau horaire était masqué sous la ligne de flottaison. L’autre indique que la réservation restait à l’heure du bureau après qu’il a sélectionné un autre fuseau. Ces signalements renvoient maintenant à des travaux différents.

Gardez « fuseaux horaires » comme thème général, puis distinguez la visibilité du libellé d’un éventuel problème de conversion. Associez les réponses aux identifiants des sources d’origine. Le premier problème peut nécessiter une modification de conception. Pour le second, il faut reproduire le problème afin de déterminer si l’erreur concerne le calcul, la préférence enregistrée ou l’affichage. Aucun signalement ne doit disparaître lors du changement de nom des groupes.

Le problème d’e-mail manquant de F02 nécessite un suivi distinct. Demandez si la réservation a bien été effectuée et quelle confirmation était attendue. L’absence de confirmation peut empêcher quelqu’un de retrouver les détails de son rendez-vous, même si le problème ne compte que quelques mentions. Vous pouvez enquêter dessus en premier tout en laissant le fuseau horaire en tête du tableau des fréquences. Indiquez la raison de cet ordre.

Constituer un rapport que l’on peut vérifier

• Un fichier source annoté comprenant des étiquettes de groupe et un indicateur de révision.
• Un récapitulatif des groupes indiquant le nombre de messages, le nombre de comptes distincts lorsqu’il est disponible et des exemples d’identifiants de source.
• Une liste de points non résolus pour les commentaires vagues, les signalements contradictoires et les doublons possibles.

Distinguez les comportements demandés des défaillances signalées. « Ajouter un autre format d’exportation » et « l’exportation actuelle ne fonctionne pas » peuvent relever du même domaine, mais nécessitent des suites différentes. Conservez les deux étiquettes si un message contient ces deux éléments.

Avant de créer un ticket, demandez à l’agent de rechercher dans l’outil de suivi connecté si le même comportement fait déjà l’objet d’un ticket. Il peut être préférable de l’ajouter à un ticket existant en y joignant les nouveaux liens vers les sources. Examinez les correspondances et le texte proposé pour le ticket, puis précisez les mises à jour souhaitées. Conservez le fichier source récupéré avec le rapport annoté, afin qu’un examen ultérieur permette de distinguer les nouveaux retours d’un changement de regroupement.