MCP

PM Copilot: cruzar tickets y peticiones antes de decidir qué hacer

Para product managers que quieren cruzar tickets de HelpScout con peticiones y chats opcionales antes de decidir el siguiente paso; construye en local, llama synthesize_feedback y configura HelpScout primero.

Official source · PM Copilot

Install

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

Para quién

Si eres product manager y quieres alinear tickets de soporte, peticiones de función y chats de atención con IA antes de decidir el siguiente paso, este servicio encaja. El texto oficial lo describe como un servidor MCP de triangulación.

Encaja si ya puedes clonar el repositorio en local, ejecutar el artefacto de build con node y tienes credenciales de HelpScout. HelpScout es obligatorio. ProductLift y Chatbase son ambos opcionales: configura uno, ambos o ninguno, y el análisis cambia con ello. Sin HelpScout, el texto oficial no da un camino usable.

El análisis toca el texto original del cliente. El texto oficial dice que SSN, números de tarjeta que pasan una comprobación Luhn, correos y teléfonos se ocultan antes del análisis, y las respuestas de agentes se filtran de las citas. No es riesgo cero: los asuntos de los tickets siguen entrando en el análisis.

Completar el primer intento en 3 minutos

La vía oficial recomendada es clonar y construir en local. Requisitos: ten listas las credenciales de HelpScout.

Sigue los pasos oficiales:

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

Tras copiar la plantilla de variables de entorno, rellena tus credenciales reales. El texto oficial solo escribe Edit with your credentials y no enumera nombres de variables; no inventes nombres de clave, solo cambia lo que ya está en la plantilla. Tras el build, en el cliente MCP pon command en node y apunta args a dist/index.js del repositorio local. El ejemplo oficial usa un marcador de ruta absoluta; cámbialo a la ruta real tras clonar y no copies el directorio de relleno. Guarda, recarga y confirma que el servicio está conectado.

Luego haz una llamada: llama synthesize_feedback. El texto oficial dice que cruza tickets de HelpScout, peticiones de ProductLift y conversaciones de Chatbase, y devuelve un análisis emparejado por tema con puntuaciones de prioridad. No escribe campos de parámetros; llama según la definición que muestre el cliente. La primera vez puedes configurar solo HelpScout y dejar los otros dos sin configurar.

Señal de éxito: vuelve un análisis con temas y puntuaciones de prioridad. Si hay error de credenciales, comprueba primero que .env se rellenó para HelpScout según la plantilla, no se dejó vacío.

Casos de uso

Caso 1: análisis temático solo con HelpScout. Llama synthesize_feedback. El texto oficial dice que las otras dos fuentes son opcionales y el análisis se adapta. No escribe rango temporal de tickets ni filtro de correo. Si acierta deberías ver emparejamientos de tema y puntuaciones de prioridad. No trates las puntuaciones como una hoja de ruta ya ordenada.

Caso 2: con HelpScout ya puesto, añade ProductLift o Chatbase, o ambos, y vuelve a llamar synthesize_feedback. El texto oficial dice que cruza estos tres tipos de fuente. No escribe pesos entre fuentes. Si acierta deberías ver un análisis temático que también cuenta peticiones o conversaciones. En las citas no debería aparecer texto de agente sin filtrar, pero no asumas que se ha quitado todo el PII.

Límites

HelpScout es obligatorio; ProductLift y Chatbase son opcionales. Los datos del cliente entran en el análisis; solo los tipos de PII que nombra el texto oficial se ocultan primero. Las consultas salen a esos servicios.

El texto oficial no escribe límite de ritmo ni deshacer. Los resultados del análisis no son una decisión de lanzamiento. Esta página solo nombra synthesize_feedback; no inventes otros nombres de herramientas de planificación. dist/index.js en la configuración debe apuntar al artefacto que construiste en local.