PM Copilot : recouper tickets et demandes avant de décider quoi faire

Pour qui

Si vous êtes chef de produit et voulez aligner tickets de support, demandes de fonctionnalité et conversations d’assistance IA avant de décider la suite, ce service correspond. Le texte officiel en fait un serveur MCP de triangulation.

Il convient à qui peut cloner le dépôt en local, exécuter l’artefact de build avec node, et détient déjà des identifiants HelpScout. HelpScout est obligatoire. ProductLift et Chatbase sont tous deux optionnels : n’en configurer qu’un, les deux, ou aucun, l’analyse change avec. Sans HelpScout, le texte officiel ne donne aucun chemin utilisable.

L’analyse touche le texte client d’origine. Le texte officiel dit que SSN, numéros de carte qui passent un contrôle Luhn, e-mails et téléphones sont masqués avant l’analyse, et que les réponses d’agents sont filtrées des citations. Ce n’est pas un risque nul : les sujets de tickets entrent quand même dans l’analyse.

Réussir le premier essai en 3 minutes

Le chemin officiel recommandé est de cloner et construire en local. Prérequis : avoir les identifiants HelpScout prêts.

Suivre les étapes officielles :

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

Après copie du modèle de variables d’environnement, remplir vos vrais identifiants. Le texte officiel n’écrit que Edit with your credentials et n’énumère pas les noms de variables ; n’inventez pas de noms de clés, ne changez que les postes déjà dans le modèle. Après le build, dans le client MCP mettez command à node et orientez args vers dist/index.js du dépôt local. L’exemple officiel utilise un espace réservé en chemin absolu ; remplacez-le par le vrai chemin après le clone, ne copiez pas le répertoire fictif. Enregistrez, rechargez, confirmez que le service est connecté.

Puis un appel : appelez synthesize_feedback. Le texte officiel dit qu’il recoupe tickets HelpScout, demandes ProductLift et conversations Chatbase, et renvoie une analyse appariée par thème avec des scores de priorité. Les champs de paramètres ne sont pas écrits ; appelez selon la définition affichée par le client. La première fois, vous pouvez ne configurer que HelpScout et laisser les deux autres non configurés.

Signal de succès : une analyse avec thèmes et scores de priorité revient. En cas d’erreur d’identifiants, vérifiez d’abord que .env a été rempli pour HelpScout d’après le modèle, pas laissé vide.

Cas d’usage

Cas 1 : analyse thématique avec HelpScout seulement. Appelez synthesize_feedback. Le texte officiel dit que les deux autres sources sont optionnelles et que l’analyse s’adapte. La plage temporelle des tickets et le filtre e-mail ne sont pas écrits. En cas de succès vous devez voir appariements de thèmes et scores de priorité. Ne lisez pas les scores comme une feuille de route déjà classée.

Cas 2 : HelpScout déjà en place, ajoutez ProductLift ou Chatbase, ou les deux, et rappelez synthesize_feedback. Le texte officiel dit qu’il recoupe ces trois types de sources. Les poids entre sources ne sont pas écrits. En cas de succès, une analyse thématique qui compte aussi demandes ou conversations. Les citations ne devraient pas contenir le texte agent non filtré, mais ne supposez pas que toutes les PII ont été retirées.

Limites

HelpScout est obligatoire ; ProductLift et Chatbase sont optionnels. Les données client entrent dans l’analyse ; seules les PII nommées officiellement sont d’abord masquées. Les requêtes sortent vers ces services.

Le texte officiel n’écrit ni limite de débit ni annulation. Les résultats d’analyse ne sont pas une décision de mise en production. Cette page ne nomme que synthesize_feedback ; n’inventez pas d’autres noms d’outils de planification. dist/index.js dans la configuration doit pointer vers l’artefact construit en local.