Comment l'IA révèle des demandes de fonctionnalités cachées dans vos verbatims

Toutes les demandes de fonctionnalité n'arrivent pas sous la forme d'une phrase claire et directe comme "ajoutez X s'il vous plaît". La plupart du temps, elles sont enfouies dans une plainte, la description d'une solution de contournement, ou une question frustrée à laquelle votre agent n'a pas pu répondre. Cet article couvre comment utiliser Screeb AI pour faire remonter ces demandes cachées plutôt que de les manquer.

Pourquoi les demandes de fonctionnalité sont souvent invisibles

Un utilisateur dépose rarement une demande formelle. Le plus souvent, il décrit juste le problème qu'il rencontre :

"Pouvez-vous me dire si mon virement est déjà passé ?" (une fonctionnalité de suivi de statut, pas un rapport de bug)
Poser de façon répétée une question que votre agent marque comme Unsupported Request
Une plainte vague qui, lue attentivement, est en réalité quelqu'un demandant une capacité qui n'existe pas encore

Lues individuellement, aucune de ces choses ne ressemble à un item de roadmap. Lues en agrégat, à travers des centaines de conversations similaires, elles constituent un dossier clair et chiffré de ce qu'il faut construire.

Où chercher

Unsupported Requests est la source la plus directe. Chaque question à laquelle votre agent n'a pas pu répondre est déjà regroupée et classée par volume, avec l'impact sur la rétention et la conversion attaché. Une demande apparaissant dans des dizaines ou centaines de conversations, avec un coût de rétention mesurable, est une demande de fonctionnalité pour laquelle vos données ont déjà construit le dossier business.
Dissatisfaction Topics est la seconde source, et la moins évidente. Certains de ces sujets ne sont pas des plaintes sur quelque chose de cassé, ce sont des utilisateurs décrivant une solution de contournement pour quelque chose qui devrait juste être une fonctionnalité. Un sujet comme "les clients demandent à l'agent de comparer les taux hypothécaires entre banques avant de s'engager" n'est pas un bug. C'est une capacité manquante, formulée comme une question.

Comment distinguer un bug d'une demande de fonctionnalité cachée

Tout ce qui se trouve dans Issues ou Unsupported Requests n'est pas un manque de fonctionnalité. Quelques signaux rapides pour les distinguer :

Bug : l'agent aurait dû pouvoir le faire, et a échoué (un crash, une mauvaise réponse à quelque chose qu'il est censé gérer).
Demande de fonctionnalité cachée : l'agent dit correctement qu'il ne peut pas aider, parce que la capacité n'existe réellement pas encore, et les utilisateurs continuent quand même à demander.

Si la même demande non résolue continue de revenir vague après vague, c'est un signal fort qu'elle appartient à la roadmap, pas juste à un backlog de bugs.

Du signal à l'item de roadmap

Une fois qu'une demande de fonctionnalité cachée probable a été identifiée :

Récupérez une poignée de verbatims bruts derrière elle, la formulation exacte utilisée par les utilisateurs.
Vérifiez la tendance de volume : est-ce en croissance, ou était-ce un pic ponctuel ?
Vérifiez le coût de rétention/conversion attaché dans Unsupported Requests.
Apportez les verbatims, pas juste le comptage agrégé, dans votre revue produit. Voir notre guide sur transformer les Topics en roadmap pour plus de détails sur cette étape spécifiquement.

Checklist rapide

Ai-je vérifié Unsupported Requests pour des entrées récurrentes et à fort volume ?
Ai-je lu Dissatisfaction Topics pour des plaintes de type "solution de contournement", pas juste des rapports de bug directs ?
Puis-je dire, pour chaque candidat, s'il s'agit d'un bug ou d'une capacité réellement manquante ?
Ai-je de vrais verbatims prêts pour soutenir cela comme item de roadmap ?

Comment l'IA révèle des demandes de fonctionnalités cachées dans vos verbatims