Une Claude Skill qui fusionne trois streams de feedback que les équipes CS et Product collectent déjà séparément —les feature requests de Canny, les réponses aux surveys in-product de Sprig et un export de tickets de support— en un seul rapport priorisé de Voice of the Customer. L’output est une liste de thèmes classée où chaque thème porte un score de demande pondéré, les segments qui le réclament, des verbatims représentatifs avec leur source et une implication produit d’une ligne. Au lieu de trois personnes lisant trois outils et débattant de ce que les clients veulent « vraiment », CS Ops lance une seule commande et obtient un doc synthétisé sur lequel un product review peut agir. Le bundle de l’artifact inclut le SKILL.md, trois fichiers de référence que l’équipe adapte une fois et un output d’exemple.

Quand l’utiliser

Vous êtes un lead CS Ops ou un Product Manager qui doit produire un résumé récurrent de VoC —product council mensuel, input de roadmap trimestriel ou un artifact de planification annuelle— et le signal brut vit dans au moins deux parmi Canny, Sprig et l’export de tickets d’un outil de support. La Skill est conçue pour le cas où le volume de feedback a dépassé le point où un humain peut tout lire (environ 150+ items par cycle) mais où l’équipe veut toujours une traçabilité vers des verbatims spécifiques plutôt qu’un score boîte noire.

Elle fonctionne le mieux quand les trois sources peuvent chacune être exportées avec un schema stable —posts Canny avec compteurs de votes et board, réponses Sprig avec la question du survey et un attribut de segment, tickets de support avec une catégorie et un tier de compte. La Skill clusterise à travers les trois, déduplique la même demande formulée de cinq façons différentes et pondère chaque thème avec une formule que vous contrôlez. Elle produit l’output le plus défendable quand vous pouvez attacher un champ de valeur-de-compte ou de segment à chaque item, parce que c’est ce qui permet au rapport de classer par demande pondérée par le revenue plutôt que par le compte brut de mentions.

Quand NE PAS l’utiliser

N’utilisez pas cette Skill comme seul input d’une décision de roadmap. Elle synthétise la demande déclarée ; elle ne mesure ni la disposition à payer, ni le coût technique, ni le fit stratégique. Un thème en tête de la liste classée signifie que beaucoup de comptes de valeur l’ont réclamé fort, pas que c’est la bonne chose à construire. La ligne d’implication produit est une amorce de discussion, pas un verdict.

Ne la pointez pas vers moins de ~50 items dans un cycle. En dessous, un PM peut lire chaque item directement en moins de temps qu’il n’en faut pour adapter les fichiers de référence, et le clustering fait du overfitting —vous obtenez des « thèmes » de deux items chacun qui ne sont en réalité que deux formulations d’une demande.

Ne l’utilisez pas quand vos sources n’ont aucun attribut de segment ou de valeur-de-compte. Sans cela, chaque thème se pondère par compte brut, ce qui sur-indexe le segment le plus bruyant (généralement des utilisateurs self-serve à faible ARR remplissant des posts Canny) et sous-compte les comptes enterprise qui envoient un email à leur CSM au lieu d’ouvrir un ticket. Un rapport de VoC fondé uniquement sur le compte induit activement en erreur la priorisation de roadmap.

Ne traitez pas les verbatims comme anonymisés pour un partage externe. La Skill préserve assez de contexte de source (tier de compte, parfois une phrase citée) pour qu’un rapport puisse divulguer qui a dit quoi. Gardez l’output interne sauf si vous lancez une passe de rédaction séparée.

Setup

Environ 45 à 90 minutes la première fois, presque entièrement passées à adapter les trois fichiers de référence à vos propres schemas d’export et à votre politique de pondération.

Installez la Skill. Déposez le bundle de apps/web/public/artifacts/voice-of-customer-synthesis-skill/ dans ~/.claude/skills/voc-synthesis/. La Skill définit une commande d’entrée, synthesize_voc(period, sources), plus des helpers internes pour normaliser chaque source, clusteriser et le pipeline à deux passes de Claude.
Exportez les trois sources. Tirez les posts Canny de la période via la Canny API (ou un export CSV) avec title, details, score (compteur de votes), board et tout champ d’entreprise lié. Tirez les réponses Sprig avec la question du survey, la réponse en texte libre et au moins un attribut de segment. Tirez l’export de tickets de support (Zendesk, Freshdesk, Front, Help Scout —tout outil qui exporte du CSV) avec subject, description, category et account_tier. Déposez les trois dans inputs/ en CSV ou JSON.
Adaptez le schema map. Ouvrez references/1-source-schema-map.md et mappez les vrais noms de colonne de chaque source vers les champs internes de la Skill (text, weight_signal, segment, source_label). C’est le fichier qui casse le plus souvent au premier run parce que les noms de board Canny et les IDs de survey Sprig diffèrent d’une équipe à l’autre. La Skill refuse de tourner si un champ requis n’est pas mappé plutôt que de scorer en silence sur des données partielles.
Réglez la politique de pondération. Ouvrez references/2-weighting-policy.md et réglez la formule. Le default est theme_score = somme sur les items de (segment_weight * recency_factor), où segment_weight vaut 3 pour enterprise, 2 pour mid-market, 1 pour self-serve, et recency_factor décroît linéairement de 1.0 au jour 0 à 0.5 à la frontière de la période. Remplacez-les par vos propres bandes. Avoir la politique dans un fichier plutôt qu’en dur est ce qui permet à un product council de contester les pondérations et à vous de relancer en deux minutes au lieu d’éditer du code.
Adaptez le template d’output. Ouvrez references/3-report-template.md et alignez l’ordre des sections et le format de citation des verbatims sur ce que votre product review attend. Puis lancez synthesize_voc(period="2026-Q2", sources=["canny", "sprig", "support"]). La Skill écrit un rapport Markdown plus un CSV de chaque item avec son thème assigné pour qu’un sceptique puisse auditer le clustering.

Ce que la Skill fait réellement

La Skill tourne en deux passes, et la division est délibérée. La passe un est extraire-et-clusteriser ; la passe deux est classer-et-expliquer. Faire les deux en une seule passe produit un clustering qui dérive vers ce que le modèle rationalise en dernier, parce qu’il décide simultanément quels sont les thèmes et argumente pour leur priorité —le raisonnement de priorité contamine le clustering.

La passe un normalise les trois sources à travers le schema map vers une forme d’enregistrement commune, puis demande à Claude de clusteriser les items en thèmes candidats. Le prompt force le modèle à assigner chaque item à exactement un thème ou à un bucket explicite unclustered, et à citer le span de texte qui justifie chaque assignation. Le bucket unclustered est une garde, pas un échec : un run sain laisse 5 à 15 pour cent non clusterisés (demandes véritablement uniques), et un taux d’unclustered au-dessus de 30 pour cent est un signal que les sources sont trop hétérogènes pour fusionner ce cycle, ce que la Skill fait remonter plutôt que de forcer une fusion.

Entre les passes, le scoring est du Python déterministe, pas Claude. La formule de pondération de references/2-weighting-policy.md tourne sur les items clusterisés en code, donc les mêmes inputs produisent toujours le même classement et un relecteur peut recalculer le score de n’importe quel thème à la main. Laisser Claude « pondérer » les thèmes rendrait le classement non-auditable et non-reproductible ; le modèle clusterise et explique, le code score.

La passe deux prend les thèmes classés et, pour chacun, sélectionne deux à trois verbatims représentatifs (un par source quand c’est possible, pour qu’un thème ne soit pas porté entièrement par la minorité bruyante de Canny), écrit l’implication produit d’une ligne et nomme les segments qui pilotent le score. L’output est un rapport classé plus le CSV par item. Le rapport ouvre sur les thèmes du haut ; le CSV est la piste d’audit.

Réalité des coûts

Un run complet sur Claude Sonnet coûte environ 30 000 à 90 000 tokens d’input selon le nombre d’items et la longueur du texte, et 5 000 à 10 000 tokens d’output —disons 12 à 30 centimes par cycle de VoC. La variable d’input qui domine est la longueur de description des tickets de support ; plafonner le texte de chaque item à 600 caractères dans le schema map garde un cycle de 400 items près du bas de la fourchette sans perdre le signal de clustering. Le temps d’horloge est de deux à cinq minutes, presque entièrement les deux passes de Claude puisque l’export et le scoring sont locaux.

Face à l’alternative —un PM passant une journée concentrée à lire et taguer 300 items à la main chaque cycle— la Skill ramène cela à environ 90 minutes (rien à adapter après le premier run, puis revoir le rapport et auditer ponctuellement le CSV). Pour une équipe qui tourne la VoC mensuellement, c’est environ une journée de temps de PM récupérée par mois, et l’échange est largement dans le budget à bien moins d’un dollar par mois en tokens.

À quoi ressemble le succès

Suivez trois nombres. Premièrement, l’accord de clustering : échantillonnez 30 items du CSV par item et faites juger par un PM si chacun est dans le bon thème. Visez 85 pour cent ou plus au deuxième cycle ; en dessous de 70 pour cent signifie que le schema map nourrit le modèle de texte bruyant (généralement du HTML non nettoyé ou des signatures dans les corps de tickets). Deuxièmement, la traçabilité de roadmap : la part des décisions de roadmap des deux prochains trimestres qui citent un thème de VoC par son nom. Si elle reste à zéro, le rapport est produit mais pas consommé, et le format doit correspondre au rituel réel du product review. Troisièmement, le taux d’unclustered par cycle —une tendance stable dans la bande de 5 à 15 pour cent est saine ; un pic soudain signifie qu’un schema de source a changé en amont.

Face aux alternatives

Face à une vue de roadmap native de Productboard ou Canny. Productboard comme Canny agrègent le feedback à l’intérieur de leurs propres murs et classent par votes ou insights, et si tout votre signal vit déjà dans l’un d’eux, leur vue native demande moins de travail. L’écart : ni l’un ni l’autre ne fusionne à travers les trois de Canny plus Sprig plus tickets de support, et les deux classent par leur propre signal d’engagement plutôt que par une formule pondérée par le revenue que vous contrôlez. Utilisez la vue native quand un outil détient 80 pour cent de votre signal ; utilisez cette Skill quand le signal est véritablement réparti sur trois systèmes et que vous avez besoin de la pondération par segment.

Face à une passe de tagging manuel dans un tableur. Un PM lisant et taguant chaque item produit le clustering de plus haute fidélité parce que l’humain attrape la nuance que le modèle manque. L’échange est la journée concentrée par cycle et le fait que cela ne scale pas au-delà de quelques centaines d’items ni ne survit au départ du PM. Utilisez le tagging manuel pour le premier cycle ou deux afin de calibrer vos bandes de pondération sur la réalité, puis laissez la Skill porter le volume récurrent et réservez la lecture humaine au bucket unclustered.

Face à un dump générique vers un LLM (« résume ce feedback »). Coller les trois exports dans une fenêtre de chat et demander un résumé est plus rapide à démarrer et produit un bloc confiant et non-auditable sans scores, sans traçabilité de source et avec une déduplication silencieuse que vous ne pouvez pas inspecter. La division à deux passes avec scoring déterministe existe précisément pour rendre l’output défendable dans un débat de roadmap, ce que le dump générique n’est jamais.

À surveiller

Biais du segment le plus bruyant. Les utilisateurs self-serve remplissent des posts Canny ; les champions enterprise envoient un email à leur CSM. Une vue fondée sur le compte sur-pondère systématiquement le segment qui se trouve utiliser le canal public. Garde : le scoring multiplie chaque item par segment_weight de references/2-weighting-policy.md, donc un seul ticket enterprise peut peser plus que plusieurs votes self-serve —et le rapport nomme les segments qui pilotent chaque thème pour qu’un relecteur voie la pondération à l’œuvre plutôt que de faire confiance à un nombre nu.
Hallucination de clustering à travers les sources. Sommé de fusionner trois vocabulaires, le modèle peut inventer un thème qui lisse une vraie distinction (traiter « export lent » et « export avec colonnes manquantes » comme un seul). Garde : la passe un cite le span justificatif de chaque assignation et écrit le CSV par item, donc un relecteur peut repérer une mauvaise fusion dans la piste d’audit ; le bucket unclustered donne au modèle une sortie explicite au lieu de forcer un étirement.
Schema de source périmé ou décalé. Un board Canny renommé ou un nouvel ID de survey Sprig change en silence ce que l’export contient, et le rapport score alors sur des données partielles. Garde : la validation du schema map refuse de tourner sur un champ requis non mappé et signale quelle source et quelle colonne ont échoué, plutôt que de scorer sur ce qui a chargé.
Lire la demande comme une priorité. La liste classée mesure la demande déclarée pondérée par la valeur de segment —pas la disposition à payer, le coût de build ou le fit de stratégie. Garde : la ligne d’implication produit est formulée comme une question pour le review, pas une recommandation, et le rapport porte un header permanent notant qu’il est un input parmi plusieurs, donc un lecteur ne peut pas confondre le rang avec une décision de build.
Fuite de verbatims. Le contexte de source préservé peut identifier qui a dit quoi si le rapport est partagé en externe. Garde : le rapport est marqué interne-seulement dans le header du template, et le bundle embarque un flag redact qui supprime les identifiants de compte et les phrases citées pour toute version qui quitte le bâtiment.

Stack

Canny —posts de feature-request avec compteurs de votes et board (Canny API ou export CSV)
Sprig —réponses en texte libre de surveys in-product avec un attribut de segment
Outil de support —export de tickets (Zendesk, Freshdesk, Front ou Help Scout) avec catégorie et tier de compte
Claude —pipeline à deux passes : extraire-et-clusteriser, puis classer-et-expliquer (Sonnet recommandé pour le coût)
Scoring local —Python déterministe applique la politique de pondération entre les passes pour que le classement soit reproductible et auditable

Modifier cette page sur GitHub