PM Copilot: Tickets und Wünsche gegenchecken, bevor Sie entscheiden

Für wen

Wenn Sie Produktmanager sind und Kundensupport-Tickets, Featurewünsche und KI-Supportchats gegeneinanderlegen wollen, bevor Sie den nächsten Schritt festlegen, passt dieser Dienst. Offiziell ist er ein MCP-Server für Dreiecksprüfung.

Er passt zu allen, die das Repository lokal klonen, das Build-Artefakt mit node ausführen und HelpScout-Zugangsdaten haben. HelpScout ist Pflicht. ProductLift und Chatbase sind beide optional: eines, beide oder keines konfigurieren, die Analyse ändert sich mit. Ohne HelpScout gibt es offiziell keinen nutzbaren Weg.

Die Analyse berührt Kunden-Originaltext. Offiziell werden SSN, Kreditkartennummern mit bestandener Luhn-Prüfung, E-Mails und Telefonnummern vor der Analyse geschwärzt, und Agentenantworten werden aus Zitaten gefiltert. Das ist kein Nullrisiko: Ticketbetreffs gehen trotzdem in die Analyse.

Ersten Versuch in 3 Minuten abschließen

Der offiziell empfohlene Weg ist lokales Klonen und Bauen. Voraussetzung: HelpScout-Zugangsdaten bereithalten.

Die offiziellen Schritte ausführen:

git clone https://github.com/dkships/pm-copilot.git
cd pm-copilot
npm install
cp .env.example .env
npm run build

Nach dem Kopieren der Umgebungsvariablen-Vorlage echte Zugangsdaten eintragen. Offiziell steht nur Edit with your credentials, Variablennamen werden nicht aufgezählt; keine Schlüsselnamen erfinden, nur vorhandene Einträge der Vorlage ändern. Nach dem Build im MCP-Client command auf node setzen und args auf dist/index.js im lokalen Repository zeigen. Das offizielle Beispiel nutzt einen Absolutpfad-Platzhalter; auf den echten Pfad nach dem Klon ändern, das Platzhalterverzeichnis nicht abschreiben. Speichern, neu laden, Verbindung prüfen.

Dann einen Aufruf: synthesize_feedback aufrufen. Offiziell kreuzt es HelpScout-Tickets, ProductLift-Featurewünsche und Chatbase-Gespräche und gibt thematisch zugeordnete Analyse mit Prioritätswerten zurück. Parameterfelder sind nicht geschrieben; gemäß der Definition aufrufen, die der Client zeigt. Beim ersten Mal nur HelpScout konfigurieren und die anderen zwei unkonfiguriert lassen.

Erfolgssignal: Analyse mit Themen und Prioritätswerten kommt zurück. Bei Zugangsdatenfehler zuerst prüfen, dass .env nach der Vorlage für HelpScout gefüllt ist, nicht leer.

Anwendungsfälle

Fall 1: Themenanalyse nur mit HelpScout. synthesize_feedback aufrufen. Offiziell sind die anderen zwei Quellen optional, die Analyse passt sich an. Ticketzeitraum und E-Mail-Filter sind nicht geschrieben. Bei Erfolg sollten Themenzuordnung und Prioritätswerte sichtbar sein. Die Werte nicht als fertige Roadmap lesen.

Fall 2: bei vorhandenem HelpScout ProductLift oder Chatbase oder beides dazu, erneut synthesize_feedback aufrufen. Offiziell kreuzt es diese drei Quelltypen. Gewichte zwischen Quellen sind nicht geschrieben. Bei Erfolg eine Themenanalyse, die auch Wünsche oder Gespräche mitzählt. In Zitaten sollte ungefilterter Agententext nicht erscheinen, aber nicht annehmen, dass alle PII entfernt sind.

Grenzen

HelpScout ist Pflicht; ProductLift und Chatbase sind optional. Kundendaten gehen in die Analyse; nur die offiziell genannten PII-Arten werden zuerst geschwärzt. Abfragen gehen online zu diesen Diensten.

Offiziell gibt es weder Ratengrenze noch Rückgängigmachen. Analyseergebnisse sind keine Versandentscheidung. Diese Seite nennt nur synthesize_feedback; keine anderen Planungswerkzeugnamen erfinden. dist/index.js in der Konfiguration muss auf das lokal gebaute Artefakt zeigen.