PM Copilot: cruzar tickets e pedidos antes de decidir o que fazer

Para quem

Se você é gerente de produto e quer alinhar tickets de suporte, pedidos de funcionalidade e conversas de atendimento com IA antes de decidir o próximo passo, este serviço combina. O texto oficial o descreve como um servidor MCP de triangulação.

Combina com quem já consegue clonar o repositório localmente, executar o artefato de build com node e tem credenciais do HelpScout. HelpScout é obrigatório. ProductLift e Chatbase são ambos opcionais: configure um, os dois ou nenhum, e a análise muda com isso. Sem HelpScout, o texto oficial não dá um caminho utilizável.

A análise toca o texto original do cliente. O texto oficial diz que SSN, números de cartão que passam na verificação Luhn, e-mails e telefones são mascarados antes da análise, e respostas de agentes são filtradas das citações. Não é risco zero: os assuntos dos tickets ainda entram na análise.

Concluir a primeira tentativa em 3 minutos

O caminho oficial recomendado é clonar e construir localmente. Pré-requisito: ter as credenciais do HelpScout prontas.

Siga os passos oficiais:

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

Depois de copiar o modelo de variáveis de ambiente, preencha suas credenciais reais. O texto oficial só escreve Edit with your credentials e não lista nomes de variáveis; não invente nomes de chave, mude só o que já está no modelo. Após o build, no cliente MCP defina command como node e aponte args para dist/index.js do repositório local. O exemplo oficial usa um placeholder de caminho absoluto; troque pelo caminho real após o clone e não copie o diretório fictício. Salve, recarregue e confirme que o serviço está conectado.

Depois faça uma chamada: chame synthesize_feedback. O texto oficial diz que ele cruza tickets do HelpScout, pedidos do ProductLift e conversas do Chatbase e devolve análise casada por tema com pontuações de prioridade. Campos de parâmetros não estão escritos; chame conforme a definição que o cliente mostra. Na primeira vez você pode configurar só o HelpScout e deixar os outros dois sem configurar.

Sinal de sucesso: volta uma análise com temas e pontuações de prioridade. Se der erro de credencial, primeiro confira se o .env foi preenchido para HelpScout a partir do modelo, não deixado vazio.

Casos de uso

Caso 1: análise temática só com HelpScout. Chame synthesize_feedback. O texto oficial diz que as outras duas fontes são opcionais e a análise se adapta. Intervalo de tempo dos tickets e filtro de e-mail não estão escritos. Em sucesso você deve ver casamentos de tema e pontuações de prioridade. Não trate as pontuações como um roadmap já ordenado.

Caso 2: com HelpScout já no lugar, acrescente ProductLift ou Chatbase, ou os dois, e chame synthesize_feedback de novo. O texto oficial diz que cruza esses três tipos de fonte. Pesos entre fontes não estão escritos. Em sucesso você deve ver análise temática que também conta pedidos ou conversas. Nas citações não deve aparecer fala de agente sem filtro, mas não presuma que todo PII foi removido.

Limites

HelpScout é obrigatório; ProductLift e Chatbase são opcionais. Dados do cliente entram na análise; só os tipos de PII que o texto oficial nomeia são mascarados primeiro. As consultas saem para esses serviços.

O texto oficial não escreve limite de taxa nem desfazer. Resultados de análise não são decisão de lançamento. Esta página só nomeia synthesize_feedback; não invente outros nomes de ferramentas de planejamento. dist/index.js na configuração deve apontar para o artefato que você construiu localmente.