hatjicon/agent-skills

Analyseur de Points de Douleur Clients

Objectif

Analyser une transcription d'appel client (Markdown ou texte brut) et identifier jusqu'à cinq points de douleur clients validés. Se concentrer sur les besoins opérationnels sous-jacents, pas sur les solutions demandées.

Entrées

• Requis : transcription de l'appel client.
• Optionnel : nom du client, noms des intervieweurs, noms des intervenants clients, stack technique, destination de ticketing, et liste de tickets existants.
• Si les rôles des intervenants ne sont pas clairs, demander des précisions ou marquer l'attribution comme incertaine. Ne pas traiter tout intervenant non identifié comme un client.

Attribution des intervenants

Extraire les points de douleur uniquement à partir de déclarations attribuables aux clients. Les questions, interprétations et solutions proposées par les intervieweurs ne sont pas des preuves client, sauf confirmation explicite du client. Ne pas inférer les rôles clients à partir des seuls noms.

Contexte client

Identifier le rôle/persona et l'environnement technique du client uniquement lorsque la transcription les soutient. Sinon, indiquer Non établi dans la transcription.

Critères de validation

Un point de douleur valide reflète une difficulté opérationnelle concrète, telle que :

• Frustration, inefficacité ou travail manuel répétitif
• Retards, risques, faible visibilité ou problèmes de fiabilité
• Contraintes de passage à l'échelle ou lacunes d'observabilité

Des déclarations comme « nous devons », « on finit par faire manuellement », « nous n'avons pas de visibilité » ou « cela prend trop de temps » peuvent être des signaux utiles, mais la formulation seule n'est pas une validation. Les demandes comme « je veux » ou « ce serait génial si » nécessitent une preuve d'un problème sous-jacent.

Exclure les demandes de fonctionnalités non étayées, les déclarations uniquement centrées sur la solution, et les opinions générales. Ne pas inventer de détails.

Processus d'analyse

1. Identifier les intervenants clients et les distinguer des intervieweurs.
2. Extraire les preuves de comportement actuel, contournements, conséquences et résultats souhaités.
3. Regrouper les déclarations connexes en problèmes sous-jacents distincts ; éviter les points de douleur en double.
4. Classer les points de douleur validés par fréquence, intensité et impact métier. Ne pas assimiler les relances répétées de l'intervieweur à une fréquence client.
5. Retourner au maximum cinq points. Si moins sont validés, en retourner moins. Si aucun n'est validé, indiquer : Point de douleur non clairement validé dans cet appel.
6. Pour chaque point, rédiger une user story orientée résultats : En tant que [type d'utilisateur], quand [contexte], j'ai besoin de [capacité], afin de [résultat métier].
7. Inclure une courte citation textuelle de preuve client ou une référence précise à la transcription, lorsque disponible. Ne pas fabriquer de citations.
8. Distinguer l'impact métier confirmé des implications plausibles mais non confirmées.

Éviter le biais de solution. Ne pas prescrire d'éléments d'interface utilisateur ou de mises en œuvre techniques, sauf s'ils sont explicitement indiqués comme contraintes et pertinents pour le problème.

Workflow de tickets (optionnel)

Par défaut : analyse uniquement. Ne pas créer ou modifier de tickets sauf demande explicite et autorisation.

Si l'accès aux tickets et une destination sont disponibles :

1. Récupérer les tickets existants dans le groupe ou le tableau cible.
2. Comparer le problème sous-jacent, pas seulement le titre, avec les tickets existants.
3. Si substantiellement similaire, proposer d'ajouter la nouvelle user story avec Validation supplémentaire de [Nom du client] (lorsque connu).
4. Sinon, proposer un nouveau titre court, orienté problème et résultats.
5. Présenter les actions proposées pour confirmation avant toute écriture, sauf si l'utilisateur a explicitement approuvé la création/mise à jour automatique des tickets.
6. Après exécution, rapporter les liens réels des tickets et les résultats. Ne jamais prétendre qu'une action a réussi sans confirmation de l'outil.

Si le système de tickets n'est pas connecté, afficher Proposé : Créer un nouveau ticket, Proposé : Ajouter au ticket existant ou Déduplication non vérifiée selon le cas ; ne jamais sous-entendre qu'un ticket a été créé.

Résultat attendu

Répéter cette structure pour chaque point de douleur validé :

Point de Douleur N – [Titre court orienté problème]

Source de l'appel client : [Nom du client ou inconnu] Stack technique et persona du client : [Contexte établi ou non établi]

User Story : En tant que [type d'utilisateur], quand [contexte], j'ai besoin de [capacité], afin de [résultat métier].

Comportement actuel : [Description fondée sur des preuves]

Comportement souhaité : [Résultat souhaité, pas une fonctionnalité supposée]

Problème racine : [Besoin non satisfait principal]

Impact métier : [Impact confirmé ; étiqueter toute inference]

Preuve client : [Citation courte ou référence de transcription]

Action sur le ticket : [Action proposée, action complétée vérifiée, ou Déduplication non vérifiée]

Vérifications qualité

• Aucune déclaration exclusive à l'intervieweur considérée comme une validation client.
• Pas plus de cinq points de douleur ; moins lorsque les preuves sont faibles.
• Aucun persona, stack, impact, citation ou statut de ticket fabriqué.
• Les titres des points de douleur décrivent des problèmes, pas des fonctionnalités.
• Les écritures de tickets nécessitent une autorisation et un accès réel à l'outil.