Eine Claude Skill, die drei Feedback-Streams, die CS- und Product-Teams ohnehin getrennt sammeln —Feature Requests aus Canny, In-Product-Survey-Antworten aus Sprig und einen Support-Ticket-Export— zu einem einzigen priorisierten Voice-of-the-Customer-Report zusammenführt. Das Output ist eine gerankte Themenliste, in der jedes Thema einen gewichteten Demand-Score, die anfragenden Segmente, repräsentative Verbatims mit ihrer Quelle und eine einzeilige Produktimplikation trägt. Statt dass drei Personen drei Tools lesen und darüber streiten, was Kunden „wirklich” wollen, führt CS Ops einen einzigen Befehl aus und erhält ein synthetisiertes Doc, auf dem ein Product Review handeln kann. Das Bundle des Artifacts enthält das SKILL.md, drei Reference-Dateien, die das Team einmal anpasst, und ein Beispiel-Output.

Wann Sie sie einsetzen

Sie sind ein CS-Ops-Lead oder Product Manager, der eine wiederkehrende VoC-Zusammenfassung produzieren muss —monatliches Product Council, vierteljährlicher Roadmap-Input oder ein jährliches Planungs-Artifact— und das Rohsignal lebt in mindestens zwei von Canny, Sprig und dem Ticket-Export eines Support-Tools. Die Skill ist für den Fall gebaut, in dem das Feedback-Volumen den Punkt überschritten hat, an dem ein Mensch alles lesen kann (ungefähr 150+ Items pro Zyklus), das Team aber weiterhin Nachvollziehbarkeit zurück zu spezifischen Verbatims will statt eines Blackbox-Scores.

Sie funktioniert am besten, wenn die drei Quellen jeweils mit einem stabilen Schema exportiert werden können —Canny-Posts mit Vote-Counts und Board, Sprig-Antworten mit der Survey-Frage und einem Segment-Attribut, Support-Tickets mit einer Kategorie und einem Account-Tier. Die Skill clustert über alle drei hinweg, dedupliziert dieselbe Anfrage in fünf verschiedenen Formulierungen und gewichtet jedes Thema mit einer Formel, die Sie kontrollieren. Sie produziert das verteidigungsfähigste Output, wenn Sie jedem Item ein Account-Value- oder Segment-Feld anhängen können, weil das es ist, was dem Report erlaubt, nach Revenue-gewichteter Demand statt nach roher Erwähnungszahl zu ranken.

Wann Sie sie NICHT einsetzen

Setzen Sie diese Skill nicht als einzigen Input einer Roadmap-Entscheidung ein. Sie synthetisiert geäußerte Demand; sie misst weder Zahlungsbereitschaft noch technische Kosten noch strategischen Fit. Ein Thema an der Spitze der gerankten Liste bedeutet, dass viele wertvolle Accounts es laut gefordert haben, nicht dass es das Richtige zum Bauen ist. Die Zeile zur Produktimplikation ist ein Anstoß zur Diskussion, kein Urteil.

Richten Sie sie nicht auf weniger als ~50 Items in einem Zyklus. Darunter kann ein PM jedes Item direkt in weniger Zeit lesen, als es braucht, die Reference-Dateien anzupassen, und das Clustering macht Overfitting —Sie erhalten „Themen” aus je zwei Items, die in Wirklichkeit nur zwei Formulierungen einer Anfrage sind.

Setzen Sie sie nicht ein, wenn Ihre Quellen überhaupt kein Segment- oder Account-Value-Attribut haben. Ohne das gewichtet sich jedes Thema nach roher Zahl, was das lauteste Segment überindexiert (meist Low-ARR-Self-serve-User, die Canny-Posts füllen) und die Enterprise-Accounts unterzählt, die ihrem CSM eine E-Mail schreiben, statt ein Ticket zu öffnen. Ein reiner Count-VoC-Report führt die Roadmap-Priorisierung aktiv in die Irre.

Behandeln Sie die Verbatims nicht als anonymisiert für externes Teilen. Die Skill bewahrt genug Quellkontext (Account-Tier, manchmal eine zitierte Phrase), dass ein Report durchsickern lassen kann, wer was gesagt hat. Halten Sie das Output intern, sofern Sie nicht einen separaten Redaktionsdurchlauf fahren.

Setup

Ungefähr 45 bis 90 Minuten beim ersten Mal, fast vollständig damit verbracht, die drei Reference-Dateien an Ihre eigenen Export-Schemas und Ihre Gewichtungs-Policy anzupassen.

Installieren Sie die Skill. Legen Sie das Bundle aus apps/web/public/artifacts/voice-of-customer-synthesis-skill/ in ~/.claude/skills/voc-synthesis/ ab. Die Skill definiert einen Einstiegsbefehl, synthesize_voc(period, sources), plus interne Helper zum Normalisieren jeder Quelle, zum Clustern und für die Zwei-Pass-Pipeline von Claude.
Exportieren Sie die drei Quellen. Ziehen Sie die Canny-Posts der Periode über die Canny API (oder einen CSV-Export) mit title, details, score (Vote-Count), board und jedem verknüpften Company-Feld. Ziehen Sie die Sprig-Antworten mit der Survey-Frage, der Freitext-Antwort und mindestens einem Segment-Attribut. Ziehen Sie den Support-Ticket-Export (Zendesk, Freshdesk, Front, Help Scout —jedes Tool, das CSV exportiert) mit subject, description, category und account_tier. Legen Sie alle drei als CSV oder JSON in inputs/ ab.
Passen Sie die Schema-Map an. Öffnen Sie references/1-source-schema-map.md und mappen Sie die echten Spaltennamen jeder Quelle auf die internen Felder der Skill (text, weight_signal, segment, source_label). Das ist die Datei, die beim ersten Run am häufigsten bricht, weil sich die Canny-Board-Namen und Sprig-Survey-IDs jedes Teams unterscheiden. Die Skill weigert sich zu laufen, wenn ein erforderliches Feld nicht gemappt ist, statt still auf Teildaten zu scoren.
Setzen Sie die Gewichtungs-Policy. Öffnen Sie references/2-weighting-policy.md und setzen Sie die Formel. Der Default ist theme_score = Summe über Items von (segment_weight * recency_factor), wobei segment_weight 3 für Enterprise, 2 für Mid-Market, 1 für Self-serve ist und recency_factor linear von 1.0 an Tag 0 auf 0.5 an der Periodengrenze abfällt. Ersetzen Sie diese durch Ihre eigenen Bänder. Die Policy in einer Datei statt hartkodiert zu haben, ist das, was einem Product Council erlaubt, die Gewichtungen anzufechten, und Ihnen, in zwei Minuten neu zu laufen, statt Code zu editieren.
Passen Sie das Output-Template an. Öffnen Sie references/3-report-template.md und richten Sie die Abschnittsreihenfolge und das Verbatim-Zitierformat an dem aus, was Ihr Product Review erwartet. Führen Sie dann synthesize_voc(period="2026-Q2", sources=["canny", "sprig", "support"]) aus. Die Skill schreibt einen Markdown-Report plus ein CSV jedes Items mit seinem zugewiesenen Thema, damit ein Skeptiker das Clustering auditieren kann.

Was die Skill tatsächlich tut

Die Skill läuft in zwei Pässen, und die Aufteilung ist bewusst. Pass eins ist Extrahieren-und-Clustern; Pass zwei ist Ranken-und-Erklären. Beides in einem einzigen Pass zu tun produziert ein Clustering, das zu dem driftet, was das Modell zuletzt rationalisiert, weil es gleichzeitig entscheidet, was die Themen sind, und für ihre Priorität argumentiert —die Prioritätsargumentation kontaminiert das Clustering.

Pass eins normalisiert die drei Quellen über die Schema-Map zu einer gemeinsamen Record-Form, dann bittet er Claude, die Items in Kandidaten-Themen zu clustern. Der Prompt zwingt das Modell, jedes Item genau einem Thema oder einem expliziten unclustered-Bucket zuzuweisen und den Text-Span zu zitieren, der jede Zuweisung rechtfertigt. Der unclustered-Bucket ist eine Guard, kein Versagen: Ein gesunder Run lässt 5 bis 15 Prozent ungeclustert (echt einmalige Anfragen), und eine Unclustered-Rate über 30 Prozent ist ein Signal, dass die Quellen zu heterogen sind, um diesen Zyklus zusammenzuführen, was die Skill an die Oberfläche bringt, statt eine Zusammenführung zu erzwingen.

Zwischen den Pässen ist das Scoring deterministisches Python, nicht Claude. Die Gewichtungsformel aus references/2-weighting-policy.md läuft im Code über die geclusterten Items, sodass dieselben Inputs immer dasselbe Ranking produzieren und ein Reviewer den Score jedes Themas von Hand nachrechnen kann. Claude die Themen „gewichten” zu lassen würde das Ranking nicht-auditierbar und nicht-reproduzierbar machen; das Modell clustert und erklärt, der Code scort.

Pass zwei nimmt die gerankten Themen und wählt für jedes zwei bis drei repräsentative Verbatims (eines pro Quelle, wo möglich, damit ein Thema nicht vollständig von der lauten Minderheit aus Canny getragen wird), schreibt die einzeilige Produktimplikation und nennt die Segmente, die den Score treiben. Das Output ist ein gerankter Report plus das CSV pro Item. Der Report eröffnet mit den Top-Themen; das CSV ist der Audit-Trail.

Kostenrealität

Ein vollständiger Run auf Claude Sonnet kostet je nach Item-Zahl und Textlänge ungefähr 30.000 bis 90.000 Input-Tokens und 5.000 bis 10.000 Output-Tokens —nennen Sie es 12 bis 30 Cent pro VoC-Zyklus. Die dominierende Input-Variable ist die Beschreibungslänge der Support-Tickets; den Text jedes Items in der Schema-Map auf 600 Zeichen zu cappen hält einen 400-Item-Zyklus nahe am unteren Ende, ohne das Clustering-Signal zu verlieren. Die Uhrzeit beträgt zwei bis fünf Minuten, fast vollständig die zwei Claude-Pässe, da Export und Scoring lokal sind.

Gegen die Alternative —ein PM, der jeden Zyklus einen fokussierten Tag damit verbringt, 300 Items von Hand zu lesen und zu taggen— bringt die Skill das auf ungefähr 90 Minuten (nach dem ersten Run nichts anzupassen, dann den Report reviewen und das CSV stichprobenartig auditieren). Für ein Team, das VoC monatlich fährt, ist das ungefähr ein Tag PM-Zeit pro Monat zurückgewonnen, und der Tausch liegt mit deutlich unter einem Dollar pro Monat an Tokens gut im Budget.

Wie Erfolg aussieht

Verfolgen Sie drei Zahlen. Erstens, Clustering-Übereinstimmung: Sampeln Sie 30 Items aus dem CSV pro Item und lassen Sie einen PM beurteilen, ob jedes im richtigen Thema ist. Zielen Sie auf 85 Prozent oder höher bis zum zweiten Zyklus; unter 70 Prozent bedeutet, dass die Schema-Map dem Modell verrauschten Text zuführt (meist nicht entferntes HTML oder Signaturen in Ticket-Bodies). Zweitens, Roadmap-Nachvollziehbarkeit: der Anteil der Roadmap-Entscheidungen in den nächsten zwei Quartalen, die ein VoC-Thema namentlich zitieren. Bleibt er bei null, wird der Report produziert, aber nicht konsumiert, und das Format muss zum tatsächlichen Ritual des Product Review passen. Drittens, die Unclustered-Rate pro Zyklus —stabil im Band von 5 bis 15 Prozent zu tendieren ist gesund; ein plötzlicher Spike bedeutet, dass sich ein Quell-Schema upstream geändert hat.

Gegen die Alternativen

Gegen eine native Roadmap-Ansicht von Productboard oder Canny. Sowohl Productboard als auch Canny aggregieren Feedback innerhalb ihrer eigenen Mauern und ranken nach Votes oder Insights, und wenn Ihr gesamtes Signal bereits in einem davon lebt, ist deren native Ansicht weniger Arbeit. Die Lücke: Keines führt über alle drei von Canny plus Sprig plus Support-Tickets hinweg zusammen, und beide ranken nach ihrem eigenen Engagement-Signal statt nach einer Revenue-gewichteten Formel, die Sie kontrollieren. Nutzen Sie die native Ansicht, wenn ein Tool 80 Prozent Ihres Signals hält; nutzen Sie diese Skill, wenn das Signal echt über drei Systeme verteilt ist und Sie die Segment-Gewichtung brauchen.

Gegen einen manuellen Tagging-Durchlauf in einer Tabelle. Ein PM, der jedes Item liest und taggt, produziert das Clustering höchster Güte, weil der Mensch die Nuance fängt, die das Modell verpasst. Der Tausch ist der fokussierte Tag pro Zyklus und die Tatsache, dass es nicht über ein paar hundert Items hinaus skaliert und den Jobwechsel des PM nicht überlebt. Nutzen Sie manuelles Tagging für den ersten Zyklus oder zwei, um Ihre Gewichtungsbänder gegen die Realität zu kalibrieren, lassen Sie dann die Skill das wiederkehrende Volumen tragen und reservieren Sie das menschliche Lesen für den unclustered-Bucket.

Gegen einen generischen LLM-Dump („fass dieses Feedback zusammen”). Alle drei Exporte in ein Chat-Fenster zu kleben und eine Zusammenfassung zu verlangen ist schneller zu starten und produziert einen selbstsicheren, nicht-auditierbaren Klumpen ohne Scores, ohne Quell-Nachvollziehbarkeit und mit stiller Deduplizierung, die Sie nicht inspizieren können. Die Zwei-Pass-Aufteilung mit deterministischem Scoring existiert genau dafür, das Output in einem Roadmap-Streit verteidigungsfähig zu machen, was der generische Dump nie ist.

Worauf zu achten ist

Bias des lautesten Segments. Self-serve-User füllen Canny-Posts; Enterprise-Champions schreiben ihrem CSM eine E-Mail. Eine Count-basierte Ansicht übergewichtet systematisch das Segment, das zufällig den öffentlichen Kanal nutzt. Guard: Das Scoring multipliziert jedes Item mit segment_weight aus references/2-weighting-policy.md, sodass ein einzelnes Enterprise-Ticket mehrere Self-serve-Votes überwiegen kann —und der Report nennt die treibenden Segmente pro Thema, damit ein Reviewer die Gewichtung am Werk sieht, statt einer nackten Zahl zu vertrauen.
Clustering-Halluzination über Quellen hinweg. Aufgefordert, drei Vokabulare zusammenzuführen, kann das Modell ein Thema erfinden, das eine echte Unterscheidung verwischt (behandelt „langsamer Export” und „Export mit fehlenden Spalten” als eines). Guard: Pass eins zitiert den rechtfertigenden Span jeder Zuweisung und schreibt das CSV pro Item, sodass ein Reviewer eine schlechte Zusammenführung im Audit-Trail erkennen kann; der unclustered-Bucket gibt dem Modell einen expliziten Ausweg, statt eine Streckung zu erzwingen.
Veraltetes oder verschobenes Quell-Schema. Ein umbenanntes Canny-Board oder eine neue Sprig-Survey-ID ändert still, was der Export enthält, und der Report scort dann gegen Teildaten. Guard: Die Validierung der Schema-Map weigert sich, auf einem nicht gemappten erforderlichen Feld zu laufen, und meldet, welche Quelle und Spalte fehlgeschlagen ist, statt auf dem zu scoren, was geladen wurde.
Demand als Priorität zu lesen. Die gerankte Liste misst geäußerte Demand gewichtet nach Segment-Value —nicht Zahlungsbereitschaft, Build-Kosten oder Strategie-Fit. Guard: Die Zeile zur Produktimplikation ist als Frage für das Review formuliert, nicht als Empfehlung, und der Report trägt einen stehenden Header, der notiert, dass er ein Input unter mehreren ist, sodass ein Leser den Rang nicht mit einer Build-Entscheidung verwechseln kann.
Verbatim-Leck. Der bewahrte Quellkontext kann identifizieren, wer was gesagt hat, wenn der Report extern geteilt wird. Guard: Der Report ist im Template-Header als nur-intern markiert, und das Bundle bringt ein redact-Flag mit, das Account-Identifikatoren und zitierte Phrasen für jede Version entfernt, die das Gebäude verlässt.

Stack

Canny —Feature-Request-Posts mit Vote-Counts und Board (Canny API oder CSV-Export)
Sprig —Freitext-Antworten aus In-Product-Surveys mit einem Segment-Attribut
Support-Tool —Ticket-Export (Zendesk, Freshdesk, Front oder Help Scout) mit Kategorie und Account-Tier
Claude —Zwei-Pass-Pipeline: Extrahieren-und-Clustern, dann Ranken-und-Erklären (Sonnet aus Kostengründen empfohlen)
Lokales Scoring —deterministisches Python wendet die Gewichtungs-Policy zwischen den Pässen an, damit das Ranking reproduzierbar und auditierbar ist

Diese Seite auf GitHub bearbeiten