中文（繁體）

登入發布專案

Report PRONIX

Create sales conversation reports and handoff PDFs for leads

翻譯準備中

AI 摘要 · 網站內容

商業JavaScript · HTMLGitHub @caua-lima上線中營運者未確認

前往專案 GitHub

試用過了嗎？ 點一下就好，不需要登入。

運作狀態: 上線中; 30 天上線率 100%
最近程式碼更新: 11月6日; 活躍儲存庫
最新版本: 無
貢獻者: 1 人; 分支 0
nomorevibe 收錄: 11月8日; 儲存庫建立於 2026年10月

語言組成

JavaScript 84.1%
HTML 15.8%
Python 0.1%

更新0 筆更新

全部

尚未偵測到更新。GitHub 發布版本後會顯示在這裡。

留言

Report PRONIX

Create sales conversation reports and handoff PDFs for leads

翻譯準備中

AI 摘要 · 網站內容

商業JavaScript · HTMLGitHub @caua-lima上線中營運者未確認

前往專案 GitHub

試用過了嗎？ 點一下就好，不需要登入。

運作狀態: 上線中; 30 天上線率 100%
最近程式碼更新: 11月6日; 活躍儲存庫
最新版本: 無
貢獻者: 1 人; 分支 0
nomorevibe 收錄: 11月8日; 儲存庫建立於 2026年10月

語言組成

JavaScript 84.1%
HTML 15.8%
Python 0.1%

更新0 筆更新

全部

尚未偵測到更新。GitHub 發布版本後會顯示在這裡。

留言

介紹

製作者的介紹僅有上面的一句話。更多詳情請閱讀儲存庫 README。儲存庫 README ↗

README

Report PRONIX

Extensão do Chrome + servidor que transformam a conversa de prospecção em um relatório de handoff em PDF para o closer — com um clique, direto do WhatsApp Web ou do Instagram Direct, lendo o histórico inteiro e transcrevendo os áudios.

Em volta do report, a ferramenta virou a mesa de trabalho do pré-vendedor: mostra a ficha do lead no RD Station ao lado da conversa, resume onde a conversa parou, abre um painel lateral com o lead e as negociações (um clique leva ao card no CRM), move o card no CRM quando o lead responde e acumula dados para responder, com número, qual closer fecha com qual tipo de lead e o que funciona na prospecção.

Sem bot, sem QR code e sem biblioteca não oficial: a extensão só lê a página que o SDR já tem aberta e logada.

Sumário

O que a ferramenta entrega

Para quem	O quê
Pré-vendedor (SDR)	Report em PDF com um clique; ficha do lead do RD ao abrir a conversa; resumo rápido para retomar um lead; painel lateral com as negociações do lead, cada uma com link para o card no CRM; .zip com os reports do dia.
Closer	Handoff de até 2 páginas: resumo, perfil do lead e como conduzir, nível de consciência, sinais de compra, como foi a conversa e a fala pronta para abrir a reunião.
Gestão	Custo por report e por SDR, PDFs de toda a equipe, resultado de cada reunião, matriz closer × perfil de lead, padrões da prospecção que fecha e insights escritos por IA gratuita.

Custo: só a geração do report (Anthropic) é paga. Transcrição de áudio, leitura de print, insights, ficha do CRM e a automação do cartão não têm custo por uso.

Como funciona

WhatsApp Web / Instagram Direct
   │  extensão (content script): lê o DOM, rola o histórico, captura os áudios no mudo
   ▼
service worker da extensão ── x-cr-key ──▶ servidor (Express, na Vercel)
                                             │
                                             ├─ transcreve os áudios ........ Groq (Whisper)
                                             ├─ normaliza a conversa ........ src/conversation-normalizer.js
                                             ├─ gera o report ............... Anthropic (prompt em cache, saída estruturada)
                                             ├─ confere as citações sem IA .. src/citacoes.js
                                             ├─ monta o PDF ................. pdfkit, até 2 páginas
                                             └─ registra custo e leitura .... src/stats.js
   ▼
PDF em base64 ──▶ a extensão oferece o download (e o painel guarda uma cópia)

Produção (Vercel): o mesmo server.js, exposto por api/index.js. Dados no Vercel KV / Upstash Redis (o disco da Vercel não persiste). Áudio sempre pelo Groq.
Local (npm start): dados em data/*.json; áudio pelo Groq se houver GROQ_API_KEY, senão pelo faster-whisper em Python.

src/db.js escolhe o modo sozinho, olhando se KV_REST_API_URL e KV_REST_API_TOKEN existem.

Começando

Servidor local

npm install
cp .env.example .env      # preencha pelo menos ANTHROPIC_API_KEY e ADMIN_PASSWORD
npm start                 # http://localhost:3000

Abra http://localhost:3000, entre com a ADMIN_PASSWORD e crie o primeiro acesso na aba Acessos (papel Master). Cada acesso é um nome + uma chave pnx_… — não há e-mail nem senha.

Extensão

Equipe: instala pela Chrome Web Store (atualiza sozinha). Passo a passo em GUIA-SDR.md.
Desenvolvimento: chrome://extensions → Modo do desenvolvedor → Carregar sem compactação → pasta extension/. No popup, cole a chave; para apontar para o servidor local, troque o endereço para http://localhost:3000.

Para usar: abra a conversa do lead, clique no ícone da extensão e em Gerar Report da conversa aberta. Um aviso no canto acompanha a leitura e, no fim, oferece o PDF. Dá para responder outros leads enquanto a IA escreve — só não troque de conversa durante a leitura.

Papéis e permissões

	Usuário (SDR)	Gestor	Master
Gerar report (extensão e painel)	✓	✓	✓
Reports do dia — os próprios (.zip)	✓	✓	✓
Reports do dia — equipe inteira (.zip com uma pasta por SDR)		✓	✓
Reports gerados (números, custo, closer e resultado)		✓	✓
Arquivos (PDFs guardados, download em massa)		✓	✓
Base de conhecimento		✓	✓
Aba Extensão (download, teste do RD)		✓	✓
Acessos (criar, editar, remover chaves e permissões)			✓
Resultados da reunião e inteligência			✓
Closers (adicionar e remover)			✓
Escolher o closer no aviso "Report pronto!"			✓

O papel é só o ponto de partida. Na aba Acessos o master marca, pessoa por pessoa, quais abas do painel ela abre (Reports gerados, Resultados da reunião, Closers, Arquivos, Base, Extensão e os reports do dia da equipe) — a aba Acessos é sempre só do master. Quem recebe a aba Resultados sem ser gestor vê e edita apenas os próprios reports. O servidor confere a mesma permissão em cada rota.

Além do papel, o master liga quatro recursos por pessoa na aba Acessos:

Recurso	Padrão	O que libera
Popup do lead	ligado para todos	Ficha do CRM, painel lateral e resumo rápido no WhatsApp.
Automação RD	só o master	Etiqueta "Qualificado" e agendamento. O "Respondeu" automático vale para todos com a ficha do lead (desde 27/10/2026).
Etiquetas	só o master	No cartão, o investimento do formulário ("R$ 3 a 5k", "R$ 5k+") e se o lead já vende.
Cor na agenda	master: Banana; demais: nenhuma	A cor com que as reuniões dos leads da pessoa são pintadas no Google Agenda. O master já começa na Banana sem configurar; "Não pintar" escolhido à mão é respeitado.

Regras do cadastro (src/usuarios.js): o único master não pode ser rebaixado nem removido; enquanto não houver nenhum, o usuário cujo nome é MASTER_NOME é promovido uma vez. A ADMIN_PASSWORD é o acesso reserva (cria o primeiro master).

O report

O que vem no PDF

Resumo em linhas (nível, investimento, motivação, decisor, perfil…). Investimento, Motivação e Decisor(es) nunca ficam em branco: a IA extrai o sinal que já está na conversa ("tenho uma distribuidora há 12 anos" já responde investimento).
Perfil do lead — dominante, analítico, cético, relacional, cauteloso ou entusiasta — com a evidência e uma frase de como conduzir a reunião (src/perfil.js).
Termômetro de dores: até 3 dores que o lead demonstrou, cada uma com a intensidade de 1 a 5 (cinco degraus, mais quentes quanto mais dói) e a prova do que ele disse. É o motivo da compra, então abre o cartão do topo. Só entra dor de fato (3 ou mais): a citada de passagem fica fora, e na dúvida a IA dá a intensidade menor (src/dores.js).
Temperatura do lead: nível de consciência (inconsciente → problema → solução → nossa entrega → pronto para decidir) com o porquê, e os sinais de compra com a prova da conversa. O selo só aparece de "consciente da solução" para cima (src/consciencia.js) e cada nível exige prova: sem ela, a IA desce um degrau.
Como foi a conversa: 4 a 6 frases em ordem cronológica, com os nomes de quem falou.
Seções de análise, nas palavras do lead (0 a 2 falas, só as muito boas) e a frase de impacto.
Como iniciar a reunião: fala pronta para o closer, junto dos 3 pontos-chave do resumo.

Tom só positivo. O report existe para "vender" o lead ao closer: nenhum ponto real é omitido (objeção, decisor ausente, orçamento apertado), mas tudo é escrito como próximo passo, nunca como alerta. Fala do lead que desanima fica fora das citações — pelo prompt e por um filtro sem IA (citacaoDesanimadora).

Editável e de graça. Qualquer campo pode ser corrigido no popup da extensão ou no painel; o PDF é refeito sem chamar a IA (POST /api/pdf).

Qualidade

Conversa é dado, não instrução. O texto vai entre <conversa> e </conversa>; marcas parecidas escritas por alguém na conversa são neutralizadas.
Regras de leitura: só é afirmação do lead o que o lead disse; correção posterior prevalece; faturamento não é lucro nem verba; números e nomes exatamente como ditos; nome de pessoa nunca é inventado.
Citações conferidas sem IA (verificarCitacoes): a fala precisa estar na conversa, ou ter ≥ 80% das palavras na mesma ordem e todos os números iguais. A que não passa sai do report.
Captura parcial à vista. A extensão informa quantos áudios achou e quantos transcreveu; o painel marca captura parcial.
Remetente conferido. O aviso final mostra "N mensagens · X suas · Y do lead" e alerta quando um lado vem zerado. Se o site some com os sinais de remetente, vale a posição da bolha.
Trava de conversa. Trocou de conversa durante a leitura? A extensão aborta em vez de misturar duas conversas.

Custo

Cache do prompt. Instruções, exemplos e a base de conhecimento ficam num prefixo em cache (1 h): a partir do segundo report, essa parte custa cerca de 0,1x. Quando o cache vence, o próximo report paga a reescrita (2x) — é a maior parte do custo de um report.
- Dois blocos. Regras + playbook formam o 1º ponto de cache; calibragem do gestor + exemplos, o 2º. O texto emendado é o mesmo de antes, mas corrigir o nível ou o perfil de um report só reescreve o bloco pequeno.
- Aquecimento (src/aquecimento.js, POST /api/cache/aquecer). ~55 min depois de um report, a extensão bate no servidor; se o cache está para vencer e houve report nas últimas 2 h, o servidor manda o mesmo prefixo com 1 token de saída (paga só a leitura, ~20x menos que a reescrita) e o cache fica valendo até ~2h50 depois do último report. Nunca bate com o cache já vencido. AQUECER_CACHE=nao desliga; AQUECER_JANELA_MIN (120) muda a janela. O gasto das batidas e quantos reports acharam o cache quente aparecem nos números do painel.
Conversa compacta. Cada mensagem vai com a hora local ([10:05]) e um cabeçalho por dia com o dia da semana, em vez do carimbo ISO em UTC — menos tokens e a hora certa do WhatsApp.
Idempotência. A reportKey é o hash da conversa normalizada + versão do prompt + modo de qualidade (src/idempotencia.js). Conversa igual não chama a IA de novo: a extensão pergunta entre Abrir o existente e Gerar de novo. Uma trava por chave impede duas gerações simultâneas da mesma conversa.
Normalização (src/conversation-normalizer.js): remove vazios e ecos longos, agrupa falas seguidas e, só acima de MAX_CONVERSATION_CHARS, corta preservando o mais recente e todo trecho com sinal comercial. Quando corta, o report avisa.
Modo de qualidade. qualidade: "eco" | "standard" | "premium" troca só o modelo; nunca é automático. POST /api/estimar-custo mostra a estimativa no painel sem chamar a IA.
Custo registrado. src/precos.js calcula o custo real de cada report (com cache) e src/stats.js guarda o número da época — recalcular depois daria outro valor.

Versão do prompt: PROMPT_VERSAO = 'v6' em src/report.js. Subir a versão permite gerar de novo uma conversa já feita.

Meus closers (com quem o SDR se dá melhor)

Aba Meus closers (só o master): para o mês escolhido (padrão: o atual) e o SDR (você, alguém do time do Match ou o time todo), por closer: reuniões realizadas no mês, vendas no mês, ticket médio, conversão (vendas ÷ reuniões) e no-show, com o total e o destaque "você converte mais com …" (entre os closers com 3+ reuniões). Clique num closer para ver os leads. Lê do CRM os cards em que o SDR é o SDR e que mudaram no mês, nos funis que têm reunião realizada e nos dos closers, e fica com os que foram para um closer (o dono do card). As regras de "a reunião aconteceu", da data da reunião e da venda são as do Match (src/painelClosers.js usa src/matchCloser.js). Só o CRM conta (como a coluna "Vendido" do CRM): report que o CRM não traz não entra — as duas abas mostram os mesmos números para o mesmo closer. Lê em partes (continua sozinha) e guarda o resultado por 20 min (GET /api/master/closers-do-sdr?sdr=&mes=).

Match com PH (meta do mês com o closer)

Aba do master (src/matchCloser.js, GET /api/master/match, PUT /api/master/match/meta). Mostra, desde 01/07/2026 (MATCH_DESDE) e com o closer Paulo Henrique (MATCH_CLOSER; dá para trocar na tela), as reuniões realizadas e as vendas em que você foi o SDR — mês a mês, com o mês atual.

De onde vem. Só leitura no RD: os cards do closer (responsável) com o campo SDR do card com o seu nome. Reunião realizada = card ganho, perdido por outro motivo que não no-show, ou numa etapa do funil dos closers que só existe depois da reunião (Reunião realizada, FUP agendado, Em contato, Fluxo de FUP, Negociação avançada, Não compraram, Vendido). "Reunião agendada" e no-show não contam. Só o CRM conta (desde 29/10/2026): report com resultado de reunião que o CRM não traz não entra — os números batem com o CRM (card sem você no campo SDR se acerta no CRM).
Datas. Dia da reunião = um campo de data do card com "reunião"/"call" no nome; sem ele, a criação do card. Venda = o dia em que o card foi ganho, com o valor do card.
Mês a mês. Reuniões realizadas, vendas, conversão (vendas ÷ reuniões do mês), faturamento e ticket médio, com a variação sobre o mês anterior; e o mês atual contra o mesmo período do mês passado (do dia 1 até hoje), como no dashboard-pessoal.
Meta. Meta 1, 2 e 3 em reais e a conversão alvo (%), por mês, num formulário sempre à vista que mostra, enquanto você digita, quanto cada meta pede por dia útil e quantas vendas e reuniões. Salvar devolve o painel já refeito (a tela redesenha com a resposta). Medidor (até 59% vermelho, até 89% ouro, 90%+ verde) e barras como no zxp-market, inclusive a meta diária acumulada (onde deveria estar hoje). O plano diz quanto falta, quanto por dia útil, quantas vendas (pelo ticket médio do período) e quantas reuniões isso pede (pela conversão alvo; sem ela, pela do período) e a projeção.
Dias úteis. Segunda a sexta e o último sábado de cada mês (os outros sábados não contam).
Visual. Cada meta tem a marca de onde deveria estar hoje e a cor do ritmo (verde no ritmo, ouro até 10% abaixo, vermelho atrás), com quanto falta e por dia útil; o medidor segue a mesma regra. A conversão do mês tem a própria régua, com a marca do alvo, a média do período tracejada e quantas vendas faltam para o alvo. Atalhos no topo levam a cada parte da aba; closer e "desde" ficam lembrados no navegador.
Com quem o closer fecha mais (src/matchAnalises.js). Conversão (vendas ÷ reuniões realizadas daquele tipo de lead), vendas e faturamento por: profissão, quanto disse que pode investir (até R$ 3 mil, R$ 3 a 5 mil, mais de R$ 5 mil), faturamento, se já vende, o que busca, perfil e nível de consciência do report, dia da semana e origem do card; e, das vendas, o produto, quanto tempo levou para fechar e os motivos de quem não comprou. Os destaques apontam o tipo que mais converte contra a média (só com 3+ reuniões). Os campos vêm do card; sem eles, da anotação do formulário no RD, lida uma vez por card (até 60 por atualização) e guardada por 60 dias.

O cartão do lead no WhatsApp

Ao abrir uma conversa no WhatsApp Web, um cartão aparece encostado na borda direita da conversa e, na borda direita da tela, o painel lateral do CRM. O cartão flutuante some quando a opção "Mostrar o cartão flutuante" está desmarcada no menu da extensão — só ele: a ficha no painel lateral, o "Respondeu" automático, as etiquetas e a contagem de recontatos continuam. – minimiza e × fecha o cartão só naquela conversa.

Áudios abertos com a conversa. O WhatsApp novo baixa os áudios assim que a conversa é clicada na lista, antes de o nome dela aparecer no topo. Cada arquivo de áudio fica com a conversa da "rodada" do clique (o nome que aparece no topo em seguida), e o report usa os da sua conversa — áudio ouvido em outra conversa continua de fora.

Painel lateral do CRM

↻ Atualizar (no topo do painel, desde a 1.6.17) faz a aba ler de novo a conversa aberta e buscar o lead no CRM; sem resposta da aba, o painel pede para recarregar o WhatsApp (F5). Cada aba do WhatsApp guarda o seu lead (painelLead:<aba> no chrome.storage.session): outra aba ou janela sem conversa aberta não apaga mais o lead do painel.

É o painel lateral do próprio Chrome (chrome.sidePanel), como o da extensão do RD Station: abre pelo botão ▤ no cartão do lead ou por Abrir painel lateral do CRM no popup da extensão, e mostra o lead da conversa aberta no WhatsApp Web:

nome, telefones e e-mails, o botão Abrir o card no Pronix CRM ↗, que vai direto para a negociação, e o link do card com Copiar link (para colar no Pronix Calendar ao criar a reunião);
a reunião agendada, quando a agenda do Google já tem;
Negociações (N): cada card do lead com status (em andamento, ganha, perdida e o motivo), funil › etapa, responsável e valor. Clicou, abre aquele card no CRM numa aba nova;
O que respondeu (formulário e campos do card) e as últimas anotações.

Fecha pelo × do próprio Chrome. Lead não achado: o painel tem a mesma busca do cartão, que roda na aba do WhatsApp. Só link do próprio CRM vira link, e nada do CRM vira HTML (extension/sidepanel.html, sidepanel.js e painel.js; o cartão publica o estado pelo service worker em chrome.storage.session). Sem a ficha do CRM liberada, o painel não aparece.

Mais rápido. A extensão percebe a troca de conversa em até 0,4 s (antes 1,5 s), espera 0,25 s antes de buscar (antes 0,7 s) e guarda na aba a última ficha de cada conversa por 10 minutos: voltar a uma conversa mostra o lead na hora, e a busca nova só redesenha se algo mudou. No servidor, contato, negociações, anotações, campos e usuários do CRM são pedidos em paralelo, e a automação do cartão, a agenda e o pintar a reunião no Google Agenda também correm juntos.

Complementar um report do WhatsApp com a ligação (site)

Na aba Gerar report, o bloco "Complementar um report do WhatsApp com a ligação": qualificou pelo WhatsApp e depois ligou? Escolha um report seu (o texto vem sozinho — guardado 60 dias desde a geração; report mais antigo, cole o texto do PDF), escreva o que veio da ligação e clique em Gerar report completo. A IA recebe os dois, marcados, e vale a ligação quando divergir. O report novo fica preso ao mesmo lead (card, contato e telefone do report de origem) e passa a ser o handoff do "Reunião realizada" (GET /api/report-base, POST /api/report-texto com baseId).

Sugestão de motivo no Desqualificar

No cartão, ✨ Sugerir motivo e anotação lê as mensagens da tela. Lead sem resposta há 3 ou mais tentativas suas (em dias diferentes) depois da última mensagem dele: escolhe o motivo de "não respondeu" e escreve a anotação com as datas, sem IA. Nos outros casos, a IA gratuita (Groq, a do resumo rápido) escolhe um dos motivos do CRM e escreve a anotação (src/sugestaoDesq.js, POST /api/crm/sugestao-desqualificacao). Sem custo por uso; o SDR confere e confirma.

Botões que escrevem no CRM (painel lateral)

Para quem tem o acesso do Desqualificar, o painel ganha três botões. Nada muda no CRM sem confirmar no painel.

Perder como duplicado — aparece no card mais antigo quando o lead tem dois ou mais em aberto (o mais novo é o que fica), mesmo que o card antigo seja de outra pessoa. Marca a perda com o motivo de duplicidade cadastrado no CRM (um motivo com "duplic" no nome) e a nota diz em qual card o lead segue.
Qualificado ✓ — no card que fica, para o lead que qualificou e confirmou a reunião (que ainda não aconteceu). Vai para a etapa "Qualificado" do funil (o nome, nunca "Desqualificado" nem "Em qualificação"); funil sem ela, para a etapa de reunião agendada (o "Agendou"); funil sem nenhuma das duas (ex.: Aplicação Direta), para o funil e a etapa em que os cards dele entraram. Closer e handoff só são pedidos se a etapa exigir o closer. A etiqueta "Qualificado" do cartão acompanha. Com os qualificados numa coluna própria, o CRM mostra quem qualificou e não chegou na reunião.
Reunião realizada → — no card que fica. Mostra o caminho que o card vai fazer até a etapa de reunião realizada, o closer (já escolhido quando a agenda do Google tem a reunião) e de onde vem o handoff; confirmado, move passo a passo, conferindo cada passagem, e para no primeiro erro dizendo o que já foi feito.
- As etapas são reconhecidas pela categoria que o CRM dá a cada uma (resposta, reunião agendada, reunião realizada…), igual em todos os funis, qualquer que seja o nome. O caminho passa por "Qualificado", pelas etapas de resposta e de reunião agendada e pelas etapas de trabalho por onde a maioria dos cards passou.
- Funil sem etapa de reunião realizada (ex.: Aplicação Direta): o sistema aprende para qual funil e em qual etapa os cards dele foram, pelo histórico dos cards que já chegaram na reunião nos últimos 120 dias (cache de 12 h). Sem esse histórico e com mais de um funil possível, ele não adivinha: pede para fazer pela tela uma vez.
- O closer vira o responsável do card, na etapa que o exige (ou no fim, se nenhuma exigir). A lista é a dos closers cadastrados na aba Closers, achados no CRM pelo e-mail ou pelo nome.
- O handoff é o texto do último report do lead (guardado 60 dias quando o report é gerado). Sem report, o painel pede o texto. O texto aparece para editar, e o campo Informações da ligação complementa (começou no WhatsApp e terminou na ligação): os dois vão juntos; se o card já tinha handoff, o complemento vira anotação no card. A API do CRM não aceita anexo de PDF: o report vai como o handoff, que é o campo do CRM para isso.
- O token do CRM precisa das permissões trocar_responsavel e, para trocar de funil, mover_de_funil; sem elas o painel avisa antes de mexer em qualquer coisa.

Ficha do RD Station

Etapa e funil, responsável, as respostas do formulário (a anotação com linhas "Campo: valor"), campos personalizados, outras anotações e o link Abrir no RD Station.

Como acha o lead. Pelo telefone: o cabeçalho (contato não salvo), o link de WhatsApp do card no RD (send?phone=…) ou o painel "Dados do contato". O servidor tenta os formatos em que o número pode estar no RD e só aceita contato cujos 8 últimos dígitos batem.
Contato salvo com nome. O nome é limpo das etiquetas do time ("Armando PRONIX Moretti" → "Armando Moretti") e buscado do mais específico para o mais amplo. Só escolhe sozinho quando não há dúvida; senão mostra a lista. Não achou? O cartão tem busca.
Lead com vários cards. O servidor junta todos os contatos com o mesmo telefone e abre o card que o SDR já escolheu; senão, o em aberto com atividade mais recente. O seletor "Este lead tem N cards" lembra a escolha no servidor.
Limpeza. Acentos quebrados por integrações ("EmpresÃ¡rio") são consertados, campos repetidos aparecem uma vez e campos de anúncio/origem ficam de fora.

Resumo rápido

Botão no cartão: lê a conversa e os áudios e devolve o cenário, onde parou, a última pergunta e o próximo passo. Mesma conversa = resumo do cache por 7 dias, sem custo.

Mapa da conversa e perguntas (depois do resumo rápido)

Conversa com áudios longos não se reouve. Depois do Resumo rápido, o cartão ganha:

Mapear a conversa — um checklist do que você já perguntou e do que o lead respondeu: investimento, decisor, momento do negócio, objetivo, prazo, forma de pagamento e reunião. Cada item mostra ✓ (respondeu), ◐ (respondeu em parte), ? (você perguntou e ele não respondeu) ou – (ainda não perguntado), com o trecho que o lead escreveu ou disse e quando. No topo: Qualificado financeiramente: Sim / Em parte / Não (só é "Sim" se o lead disse que tem ou consegue investir; você ter perguntado não basta).
Pergunte sobre a conversa — perguntas prontas ("Já está qualificado financeiramente?", "Já perguntei do decisor?", "Já falei de prazo e pagamento?", "O que ele quer com o projeto?") e uma caixa para escrever qualquer outra. A resposta vem como Sim / Não / Em parte (ou texto, nas perguntas abertas), com quem disse o quê e quando.

Usa a conversa que o resumo já leu (com os áudios transcritos), sem reler nem retranscrever; é IA gratuita (Groq) e nada fica guardado (src/perguntasDaConversa.js, POST /api/conversa/mapa e POST /api/conversa/perguntar, mesma permissão do resumo rápido). O trecho citado só aparece se está de fato numa mensagem: o que a IA inventasse sai. Conversa muito longa é enxugada (as mensagens mais recentes e as com sinal comercial ficam), e chegou mensagem nova depois do resumo, use Atualizar.

Automação do cartão

Três coisas, sem IA e sem custo, para quem o master ligou:

Mover para "Respondeu" no RD. Com a conversa aberta, se há mensagem do lead depois de uma mensagem sua — as duas depois do início da tentativa de contato atual do card — e o card está em aberto e antes de "Respondeu" no mesmo funil, o servidor avança o card. O início da tentativa (contatoDesde na ficha, inicioDaTentativa em src/crm.js) vem do histórico de etapas do card: a entrada na sequência de etapas antes de "Respondeu" no funil atual, nunca antes da criação. Assim, num card de recuperação (card antigo que voltou ao contato, ou que veio de outro funil), a resposta antiga do lead que está no histórico da conversa não conta. A extensão manda a data da resposta (respostaEm) e o servidor confere de novo: sem a data (extensão antiga), com data de antes da tentativa ou no futuro, não move. A automação também espera 1,5 s depois de trocar de conversa e confere que o contato no topo é o da ficha. É a única escrita automática que o sistema faz no RD (a outra é a limpeza do funil, pedida pelo master): nunca volta um card, não mexe em card fechado nem em funil sem essa etapa, confere tudo de novo no RD na hora e registra cada movimento. O RD só aceita se o dono do token for o responsável pelo card ou do mesmo time; se recusar, o cartão mostra o motivo.
Etiqueta "Qualificado". Serve para saber, sem reouvir a conversa, que aquele lead já foi qualificado. Só entra por três caminhos: o card está na etapa "Qualificado" do RD, um report foi gerado para o lead, ou você marcou à mão. Lead que apenas respondeu não ganha etiqueta, e ter agendamento também não qualifica ninguém. Uma vez colocada, fica lembrada mesmo que o card mude de etapa (remarcou, sumiu); passar o mouse mostra de onde ela veio. Marcar ou tirar à mão vale sobre a leitura automática.
Dia e horário agendados. extension/agenda.js lê, no navegador, a última mensagem sua que confirma um compromisso com dia e hora ("reunião agendada para quinta às 15h", "remarquei para 10/10 às 16h", "ficou para amanhã às 9h") — ou o lead escolhendo um horário que você ofereceu, seguido do seu "Agendado!". Citar reunião, horário ou diagnóstico não basta, e proposta ("posso agendar para amanhã às 15h?"), oferta de opções e duração ("2h por dia") não contam. Agendamento dito em áudio entra quando o resumo ou o report leem a conversa inteira. Depois do horário, vira "Estava agendado".

O texto da conversa não vai ao servidor para isso — só o pedido de mover, a etiqueta e a data.

Etiqueta de perda. Se o card do lead foi dado como perdido no RD, o cartão mostra, em vermelho, DESQUALIFICADO · motivo (card na etapa de desqualificados) ou PERDIDO · motivo (perdido em outra etapa), com a anotação da perda ao passar o mouse. Vem da própria ficha do RD, então aparece para quem vê o cartão, sem depender da automação; cobre tanto a perda dada à mão quanto a da Limpeza do RD. Lead com outro card em aberto não ganha a etiqueta: a ficha mostra o card aberto.

Reunião pelo Google Agenda. Quando o master conecta a conta dele (aba Extensão → Google Agenda), o servidor lê as agendas que essa conta enxerga — as dos closers, compartilhadas com ela — e procura o evento em que o e-mail do lead é convidado (sem e-mail no RD, o nome inteiro no título). O cartão mostra "Agendado: hoje às 14:00 · Vitor", e isso vale mais que o lido na conversa. Remarcou pelo link? Vale a próxima reunião. Cache de 10 min por lead, e uma falha do Google nunca derruba a ficha (src/agendaGoogle.js).

Cor do pré-vendedor na agenda. O time marca de quem é cada lead pela cor do evento. Em Acessos, cada pessoa pode ter uma cor: ao abrir a conversa do lead, a reunião futura dele é pintada com ela, se o evento ainda não tiver cor (lead já marcado por outro não é trocado). É a única alteração que o sistema faz na agenda, e exige que a conta conectada possa editar os eventos dos closers.

Inteligência comercial

O objetivo é decidir por dado, não por achismo: que closer pega que lead e que prospecção funciona.

Cada report guarda uma leitura (fora do PDF): perfil do lead, nível de consciência e a análise da prospecção — BANT, SPIN, as perguntas-chave do pré-vendedor e a abordagem.
O closer é escolhido na extensão, no aviso "Report pronto!". Havendo histórico, o closer indicado para aquele perfil vem marcado "(indicado)" com o motivo. Nada é salvo sozinho.
O resultado é marcado na aba Resultados da reunião: venda em call, venda em follow-up, pix de compromisso, não fechou, no-show ou em follow-up, com anotação e a correção do perfil e do nível de consciência quando a IA errou.
A conta é feita sem IA (src/inteligencia.js): matriz closer × perfil, conversão por perfil e por nível, e o que difere na prospecção das reuniões que fecharam.
Insights escritos pelo Groq gratuito, só em cima dos números e das perguntas do SDR (a fala dos leads não é enviada). Exige 5 reuniões com resultado.

Onde cada closer vai melhor, e por quê. A aba mostra, sem IA, frases como "Paulo vai melhor com lead cauteloso: fechou 3 de 4 (75%), contra 0 de 2 com os outros perfis", seguidas das anotações de "o que deu a reunião" — é delas que sai o porquê. Os insights da IA recebem os mesmos dados e não podem inventar motivo: sem anotação, dizem que falta anotar.
Closer preenchido sozinho. Ao abrir a conversa do lead, se o card no RD já está em "Reunião Realizada" (ou no funil dos closers) com o closer como responsável, ou se a reunião está na agenda de um closer, os handoffs daquele lead que estão sem closer são preenchidos (src/closerAuto.js). Só vale closer cadastrado na aba Closers, e closer já marcado nunca é trocado.
Desfecho puxado do RD. O closer registra o fim no RD: vendido (com o produto e o valor), ou perdido / etapa "Não compraram" com o motivo. O servidor lê isso (src/vendasRd.js) e preenche a linha sozinho:
- vendido vira Venda em call — ou Venda em follow-up, se o card já tinha passado pelo follow-up ou fechou depois do dia da reunião —, com o produto e o ticket do card. Você só completa a forma de pagamento. Tipo, produto e ticket preenchidos à mão nunca são trocados;
- não comprou vira "Não fechou" com o motivo em "o que deu a reunião" e sai da lista.
Só vale desfecho registrado depois de o report existir.
O resultado acompanha o estado do card. O que o RD deu (e não o que foi marcado à mão) muda junto com o card: "Não compraram" vira "Não fechou"; perda com motivo de falta ("no-show", "não compareceu") vira No-show; o lead que "não comprou" e voltou a negociar volta para Em follow-up; e se ele comprar depois, vira Venda em follow-up. Resultado escolhido à mão nunca é trocado (o report guarda de onde o resultado veio: resultadoOrigem).
Puxar do RD é retroativo. O botão confere todo o período escolhido em Resultados — um lote por vez, até acabar (?varredura=) —, inclusive os reports com resultado à mão que estão sem closer (ganham o closer; o resultado fica). Para preencher o mês, escolha o período e clique uma vez.
Trazer do Report Closer. Report gerado só no Report Closer (o sistema da empresa) fica só no banco de lá. Lá, em Resultados → Levar para o Report PRONIX (período, closer, só vendas), sai um .json com cada report e o PDF; aqui, em Resultados → , ele é importado (, ): só os reports do próprio usuário, o closer achado pelo nome no cadastro daqui, sem duplicar (mesmo report, ou o mesmo lead com até 3 dias de diferença).

Vendas de um closer direto do RD

Em Resultados, Trazer as vendas de um closer direto do RD (POST /api/master/trazer-vendas-rd, src/vendasDoRd.js): lê os cards ganhos do closer desde a data escolhida em que o campo SDR é o seu nome. Quem já tem report aqui é completado (closer, ticket, produto, data) sem trocar o que foi marcado à mão; quem não tem ganha um report com a venda (origem "rd", sem PDF). Card sem o campo SDR preenchido fica de fora (e a tela diz quantos). Só leitura no RD.

Report automático do dia

Na aba Reports do dia, o cartão Report automático monta o fechamento do dia no formato que se manda à liderança (src/reportDoDia.js):

Leads novos contatados / Respostas / Recontatos — a extensão (com a automação do cartão ligada) olha as conversas que passam pela tela e avisa, por conversa e por dia, três sinais: você escreveu hoje, já havia mensagens de antes, o lead escreveu hoje (e se já tinha escrito em outro dia). Novo = escreveu hoje e não havia nada antes; recontato = escreveu hoje e já havia histórico (lead que parou ou nunca respondeu e você chama de novo); resposta = a primeira vez que o lead responde, que é quando o card vai para Respondeu no RD — quem já tinha escrito em outro dia não conta. Cada contato conta uma vez. Do contato fica só uma impressão (hash), nunca telefone nem nome. Conversa que não passou pela tela não é vista, e mensagem de áudio ou foto (sem hora) vale a hora da mensagem de antes.
Desqualificados — as perdas do dia por motivo: os cards seus que o RD mostra como perdidos hoje, juntos com o registro do sistema (botão Desqualificar e limpeza do funil), sem contar duas vezes e sem as desfeitas. Se o RD não responder, vale o registro do sistema e o cartão avisa.
Digitado — automáticas, realizadas, agendas que caíram, no-show e observações dos desqualificados ficam salvos por dia (não há como contar isso sozinho).

O texto sai pronto, editável, com o botão Copiar o report (GET/PUT /api/report-dia, POST /api/atividade).

Linha do tempo do contato no report

Das datas das mensagens (sem IA), o resumo do report ganha, quando faz sentido:

Contato: "Conversando com o lead desde 23/09 (24 dias)" — quando o primeiro contato tem mais de 7 dias;
Confirmação: "Confirmado desde quarta-feira (14/10)" — quando o lead confirmou a reunião num dia anterior ao do report (inclusive 1 ou 2 dias antes), e "· reconfirmado no dia (sábado, 17/10)" quando ele confirmou de novo no dia. Conta como confirmação o lead escrever que confirma ("confirmado", "confirmo", "estarei lá") ou responder que sim logo depois de você pedir a confirmação; se a reunião foi remarcada, vale a confirmação de depois (src/linhaDoTempo.js).

Conversa colada como texto, sem datas, não ganha essas linhas.

As duas extensões no mesmo Chrome

O Report PRONIX e o PRONIX Closer Report desenham o mesmo cartão e o mesmo painel lateral no WhatsApp Web. Com as duas ligadas, o cartão pulava de lugar e desligar a "Popup do lead" de uma sumia com a do outro. O Report PRONIX (1.5.3+) avisa na página (data-report-dono="pronix") que é ele quem desenha; o Closer Report (1.13.2+), vendo o aviso, não consulta o RD nem desenha nada. Sem o Report PRONIX, o Closer Report volta a funcionar sozinho.

Desqualificar pelo WhatsApp

No cartão do lead, o botão Desqualificar (para quem tem a automação do cartão) mostra os motivos de perda cadastrados no RD; escolhido o motivo e confirmado, o card do lead vira perda com esse motivo, vai para "Desqualificados" (se o funil dele tiver essa etapa) e o campo SDR recebe o seu nome — sem abrir o card no RD. Só vale o card em aberto do lead da conversa (o servidor confere na ficha), e a mudança entra no registro da limpeza: aparece no relatório por motivo e dá para desfazer pelo painel (GET /api/crm/motivos-perda, POST /api/crm/desqualificar, desqualificarCard em src/limpezaRd.js).

Limpeza do funil no RD

Card parado no começo do funil vira perda em "Desqualificados", com o motivo certo:

Onde o card está	Parado há mais de	Motivo de perda
Contato iniciado	15 dias (ajustável)	Nunca respondeu
Respondeu	15 dias (ajustável)	Parou de responder

O campo SDR do card recebe o nome de quem pediu a limpeza. Fica na aba Limpeza do RD do menu (Gestão comercial), só para o master, e nada acontece sozinho:

Funil — você escolhe em qual funil rodar (ex.: só o de SMQLs automáticas). A lista traz os funis que têm as três etapas; com mais de um, a limpeza nunca escolhe sozinha.
Prévia — lista o que seria mexido e de onde, sem alterar nada.
Testar com 5 cards — para conferir no RD antes do resto. A tela lista os cards movidos com o e-mail do lead e o link "Abrir no RD".
Executar todos — em lotes de 15. Cada card é lido de novo antes de mudar: se saiu da etapa, teve movimento, foi fechado ou é de outro responsável (em "só os meus"), é pulado.
Relatório — quantos cards por motivo ("• Nunca respondeu - 110"), com botão de copiar. Cada execução vira um relatório salvo (dia, funil e contagem), que fica no histórico da aba.
Desfazer o último lote — volta para a etapa de onde saiu e reabre o card.

"Parado" conta do movimento mais recente entre a última atividade, a última atualização e a criação do card. É uma leitura conservadora do "esfriando" da tela do RD: na dúvida, não mexe. Os outros campos personalizados do card são reenviados como estavam (src/limpezaRd.js). CRM_MOVER_ETAPA=0 desliga também esta escrita.

Cadastros duplicados. Na mesma aba, Procurar duplicados olha os cards em aberto do funil em que você é o responsável e acha o mesmo lead em mais de um card: e-mail igual ou telefone igual (DDD + 8 últimos dígitos, então "+55 71 99999-8888" e "(71) 9999-8888" são o mesmo). Um card fica e os outros vão para "Desqualificados" com a perda "Duplicado" e o campo SDR preenchido.

Quem fica: o card na etapa mais adiantada; no empate, o de movimento mais recente.
O que não é duplicado: lead que já foi perdido e se inscreveu de novo (card fechado não entra na conta), card de outro responsável e card de outro funil.
Dado genérico: e-mail ou telefone repetido em mais de 6 cards (teste, número de preenchimento) fica de fora, e a tela avisa.
Antes de fechar, cada par é lido de novo: só fecha se o card que fica continua em aberto no funil, com o mesmo responsável e contato em comum. Nunca se fecha o último card vivo de um lead.
A prévia mostra, por lead, o que fica e o que sai, e avisa quando o lead cadastrou de novo (o card que sai é mais novo que o que fica). Tem o mesmo "Testar com 5", os lotes, o relatório (linha "Duplicado") e o desfazer. O nome do motivo no RD pode ser trocado em CRM_LIMPEZA_MOTIVO_DUPLICADO (padrão: qualquer motivo que contenha "duplic").

Afinidade com o closer ("Analisar Match com PH")

Para cada closer com inteligência cadastrada (aba Closers → Inteligência), o popup da extensão ganha um botão "Analisar Match com {apelido}". Clicar gera só a análise — não gera report (não usa a IA paga nem cria report novo). Se o lead já tem report seu dos últimos 30 dias, o servidor aproveita o perfil e o nível de consciência dele, e a nota fica naquele report. O aviso traz a análise:

nota de 0 a 10 da combinação lead × closer (não é "o lead é bom?", é "é bom para ele?");
no aviso: o veredito, até três motivos, um ponto de atenção e a base da nota;
um segundo PDF, de uso do pré-vendedor, com o relatório completo:
- pontos que dão match — cada um com a prova do lead (a fala ou o fato) e o que as calls do closer mostram, com o número;
- pontos de atenção — de onde vêm e como contornar antes ou durante a call;
- casos parecidos nas calls do closer — as contas dos recortes em que o lead se encaixa (quem decide, momento, presença) e exemplos reais do que fechou e do que não, sem nome de lead;
- plano da call em oito fases: abertura, quem decide e quem paga, perguntas de diagnóstico, devolver a dor, prova, proposta, pagamento e fechamento;
- objeções prováveis (o sinal na conversa e a resposta), o que não fazer, falas do lead para usar (só as que ele disse de fato) e o que confirmar antes.

A análise são dois pedidos à IA gratuita — a avaliação e o plano da call —, porque cada pedido tem tamanho limitado. Se o plano falhar, o relatório sai com a avaliação e os passos curtos, e a próxima tentativa refaz o plano.

A nota cruza três coisas: a inteligência do closer (o que as calls dele ensinaram: com que tipo de lead fecha — sozinho, casal, com sócio; perfil —, como conduz, onde trava), o histórico dele em Resultados (vendas e reuniões por perfil de lead) e o que o report levantou do lead, mais o fim da conversa. A inteligência é texto destilado, sem nome nem dado de lead; o material bruto (transcrições) fica na pasta privado/, fora do Git.

Custo zero: a análise roda no Groq e o PDF é montado no servidor. Se a análise falhar, o report continua pronto e o aviso oferece tentar de novo. A nota fica guardada no report, para comparar depois com o que a reunião deu.

Casos das calls e padrão. Além do texto, a análise usa números medidos: cada negociação do closer vira um caso com quem decidia (sozinho, casal, sócios, família), se todos os decisores estavam na call, o momento do lead (loja física, já vende online, do zero), quantas reuniões e como terminou. Os casos vêm de dois lugares (src/casos.js):

do pacote do closer (aba Closers → Importar pacote): um .json com o cadastro, o apelido, a inteligência e os casos classificados das transcrições. Cria o closer se ele não existe; importar de novo troca os casos das transcrições, sem duplicar. Os casos não levam nome nem contato de lead, e o pacote, como as transcrições, fica em privado/, fora do Git;
dos reports: lead analisado para aquele closer que teve o resultado da reunião marcado (venda ou não comprou) entra na conta sozinho, com o que a análise leu dele.

O padrão ("casal com os dois na call: 9 de 17") vai dentro do histórico no pedido à IA e aparece no painel, em Closers → Inteligência.

Conversa por ligação. Sem conversa escrita, a extensão não tem o que ler. No painel, aba Gerar report, o cartão Match com o closer recebe o PDF do handoff (o que o próprio sistema gera) ou o texto do report colado, e devolve o PDF do match (POST /api/afinidade/handoff, src/textoDoPdf.js). Report gerado ali mesmo nem precisa do PDF: é só clicar. O PDF enviado não fica guardado; "falas do lead" no plano só as que estão entre aspas no report.

Transcrições novas, direto do Drive. Em Closers → Inteligência, cole o link da pasta do Google Drive onde caem as transcrições das calls do closer (as anotações do Google Meet) e a data a partir da qual ler. Todo documento novo vira um caso dele, e o padrão se atualiza (src/transcricoes.js, src/driveGoogle.js):

a pasta pode ter uma subpasta por call (com a gravação e o documento dentro), como o Meet costuma ficar organizado: a busca desce até dois níveis, descarta as subpastas com data no nome anterior à data de corte e pergunta pelos documentos de várias pastas por consulta. Com a pasta em dia, cada leitura olha só as duas últimas semanas; mudar a pasta ou a data recomeça da data escolhida;
a leitura acontece sozinha de hora em hora (junto da batida da extensão; no máximo uma rodada a cada 45 min, dois documentos por closer) e no botão Ler agora (três por clique). A tela diz o que foi olhado — quantas subpastas, a data da mais nova e, se há call nova sem texto para ler, que tipos de arquivo ela tem —, sem nome de ninguém; se a conta conectada não enxerga a pasta, avisa;
lê Documento Google, Word (.docx), .txt e atalho para um deles; vídeo e o resto ficam de fora;
reunião sem conversa (não compareceu, caiu) não vira caso; duas reuniões do mesmo lead em até 15 dias viram um caso, com o melhor desfecho; o que chega pelo Drive e por um report com resultado conta uma vez só;
a classificação é da IA gratuita, a partir das anotações. É automática e pode errar: a tela lista cada call lida, com "quem decide" e "como terminou" editáveis e o botão de apagar. Caso corrigido não é mais mexido. Tarefa para a pessoa do onboarding nas "Próximas etapas" vale como prova de venda (TRANSCRICAO_ONBOARDING, padrão Carlos);
privacidade: só leitura no Drive; a transcrição não fica guardada no servidor; antes de ir para a IA os nomes, e-mails e telefones são mascarados; o caso guarda o nome da call (o do documento no Drive, que costuma ter o do lead) só para o master achar e corrigir na tela — esse nome nunca vai para a IA nem para o PDF do match —, e uma impressão do primeiro nome para juntar as reuniões. Um documento que o Google não deixa ler é pulado, com o aviso de qual, e vai para o fim da fila.

Para funcionar: ative a Google Drive API no projeto do Google Cloud do aplicativo e conecte o Google de novo no painel (a permissão drive.readonly é nova). A conta conectada precisa ter acesso à pasta.

Ligar e desligar. Na aba Closers, cada closer com inteligência tem o botão Desligar análise (e depois Ligar análise). Desligada, o botão some do popup de todo mundo e POST /api/afinidade responde 403, sem chamar a IA; o texto da inteligência continua guardado, é só ligar de novo.

Base de conhecimento

Seis campos na aba Base: empresa, oferta e valores, perfil de cliente, roteiro, régua de qualificação (SPIN e BANT) e objeções. Entram no prefixo em cache de todo report. Campo nunca escrito vem com o texto recomendado (src/baseInicial.js, versão 3), montado com os scripts, apresentações, contratos e a análise de 12 reuniões que viraram venda (docs/analise-calls-vendas.md). Uma versão nova só substitui o campo que ninguém editou; Voltar aos textos anteriores desfaz a migração.

O painel

Em SUA_URL/. As abas aparecem conforme o papel.

Aba	Para	O que faz
Gerar report	todos	Report sem a extensão, em formato de chat (abaixo).
Reports do dia	todos	Lista do dia e .zip para o líder; gestor e master veem a equipe.
Acessos	master	Chaves da equipe, papel e os três recursos por pessoa.
Reports gerados	gestor, master	Números, custo por SDR, closer e resultado de cada report.
Resultados da reunião	master	Resultado por reunião, inteligência e insights.
Closers	master	Lista de closers.
Arquivos	gestor, master	PDFs guardados; download individual, por SDR ou tudo em .zip.
Base	gestor, master	Base de conhecimento.
Extensão	gestor, master	Download do .zip e teste da ficha do RD.

Report em formato de chat. Escreva fala por fala (Lead ou Eu), cole a conversa inteira ou anexe e arraste áudios (transcritos), prints (lidos como conversa) e arquivos de texto. Cada fala vira uma bolha removível; o texto final continua editável. PDF e Word ainda não são lidos.

Print e celular. O print é lido pelo modelo de visão do Groq (custo zero); o painel reduz a imagem antes de enviar e o servidor confere o tipo pelos magic bytes. É o caminho para quem atende pelo telefone, onde a extensão não roda: tira o print e abre o painel no navegador do celular. Sem print, o Exportar conversa do WhatsApp gera um .txt para colar.

Reports do dia. Quando o SDR refaz o report de um lead, vale o último (src/diario.js agrupa por SDR + dia + contato). Dá para marcar outra versão antes de baixar. O mesmo .zip sai pelo botão Baixar meus reports de hoje do popup.

API

Autenticação por cabeçalho x-cr-key (a chave do usuário). gestor+ = master, gestor ou a ADMIN_PASSWORD em x-admin-pass.

Report e mídia

Rota	Acesso	Para quê
`POST /api/report-direto`	chave	Report a partir das mensagens lidas pela extensão.
`POST /api/report-texto`	chave	Report a partir de texto (painel).
`POST /api/pdf`	chave	Refaz o PDF de um report editado — sem IA.
`POST /api/transcrever`	chave	Transcreve um áudio (cache pelo hash dos bytes).
`POST /api/ler-imagem`	chave	Lê um print de conversa.
`POST /api/estimar-custo`	chave	Estimativa de custo, sem IA.
`GET /api/reports/:id/pdf`	chave	Reabre o PDF (o dono; gestor e master, qualquer um).
`POST /api/reports/:id/closer`	chave	Define o closer do próprio report (gestor e master, de qualquer um).
`GET /api/closers`	chave	Closers (id e nome) e a indicação para um perfil.

Cartão do lead

Rota	Acesso	Para quê
`POST /api/crm/lead`	chave + popup do lead	Ficha do RD do lead da conversa.
`POST /api/crm/respondeu`	chave + ficha do lead	Avança o card para "Respondeu" (todos os usuários; confere a data da resposta).
`GET /api/master/diagnostico`	master	Confere, sem alterar nada, se a automação do "Respondeu" e a cor da agenda têm tudo no lugar, e mostra a última vez que cada uma funcionou.
`POST /api/master/trazer-vendas-rd`	master	Traz as vendas de um closer direto do RD (cards ganhos em que o usuário é o SDR).
`GET /api/report-dia` · `PUT /api/report-dia`	chave	Report automático do dia: contagem, desqualificados, o que foi digitado e o texto pronto.
`POST /api/conversa/mapa` · `POST /api/conversa/perguntar`	chave com o popup do lead	Mapa da conversa e perguntas sobre ela, depois do resumo rápido (IA gratuita; a conversa vem do cartão).
`POST /api/atividade`	chave com a automação do cartão	A extensão avisa o que viu numa conversa hoje (escrevi / havia histórico / o lead escreveu).
`GET /api/crm/motivos-perda` · `POST /api/crm/desqualificar`	chave com a automação do cartão	Botão Desqualificar: os motivos de perda do RD e a perda no card do lead da conversa.
`GET /api/master/limpeza-rd/funis` · `GET …/previa` · `POST …/executar` · `POST …/desfazer` · `GET …/relatorio`	master	Limpeza do funil no RD: prévia, lotes, desfazer e relatório por motivo.
`GET/POST /api/master/limpeza-rd/duplicados`	master	Cadastros duplicados no funil: a busca (sem alterar nada) e o fechamento em lotes como "Duplicado".
`POST /api/rd/atualizar`	chave	Batida de hora em hora da extensão: põe venda, follow-up, perda e closer dos reports em dia com o RD (no máximo a cada 30 min).
`POST /api/lead/marca`	chave + automação	Etiqueta "Qualificado" e agendamento.

Dia a dia e gestão

Rota	Acesso	Para quê
`GET /api/eu`	chave	Nome, papel e recursos liberados.
`GET /api/meus-reports` · `POST /api/meus-reports/zip`	chave	Reports do dia do próprio usuário.
`GET /api/equipe-reports` · `POST /api/equipe-reports/zip`	gestor+	Reports do dia da equipe.
`GET /api/admin/stats`	gestor+	Números e custo.
`PATCH /api/admin/reports/:id/resultado`	gestor+	Closer, resultado, datas e correções.
`DELETE /api/admin/reports/:id`	gestor+	Remove o report e o PDF.
`GET /api/admin/reports/:id/pdf` · `GET /api/admin/reports/pdf-zip`	gestor+	PDFs guardados.
`GET/POST /api/admin/base` · `…/recomendada` · `…/restaurar`	gestor+	Base de conhecimento.
`GET /api/admin/closers`	gestor+	Lista completa de closers.
`POST /api/admin/crm/teste`	gestor+	Busca no RD sem cache, com o passo a passo.
`POST/DELETE /api/admin/closers`	master	Adiciona e remove closers.
`PATCH /api/admin/closers/:id`	master	Apelido e inteligência do closer (alimenta a afinidade); `analiseAtiva` liga e desliga a análise.
`POST /api/admin/closers/importar`	master	Pacote do closer: cadastro, apelido, inteligência e casos das calls.
`GET /api/admin/closers/:id/padrao`	master	As contas dos casos do closer (transcrições + reuniões com resultado).
`POST /api/admin/closers/:id/drive/ler` · `GET …/drive`	master	Lê os documentos novos da pasta do Drive do closer; lista os casos lidos e a última leitura.
`PATCH/DELETE /api/admin/closers/:id/casos/:caso`	master

Do RD Station CRM (API v1) o servidor lê /contacts, /deals/{id}, /activities, /users, /custom_fields e /deal_pipelines, e escreve só PUT /deals/{id} com deal_stage_id.

Variáveis de ambiente

Tudo tem padrão seguro no código; o .env.example traz a lista comentada.

Essenciais

Variável	Quando	Descrição
`ANTHROPIC_API_KEY`	sempre	Gera os reports.
`ADMIN_PASSWORD`	sempre	Acesso reserva do painel; cria o primeiro master.
`GROQ_API_KEY`	produção	Áudio, print e insights. Local sem ela: `faster-whisper`.
`KV_REST_API_URL` · `KV_REST_API_TOKEN`	produção	Banco (Vercel KV / Upstash; também aceita `UPSTASH_REDIS_REST_URL` e `UPSTASH_REDIS_REST_TOKEN`). Vazias: `data/*.json`.
`CRM_API_TOKEN`	ficha do lead	Token do CRM. Um token `pcrm_…` liga o PronixCRM (crm.pronixhub.com.br); outro valor, o RD Station. Tem prioridade sobre `RDSTATION_CRM_TOKEN`.
`RDSTATION_CRM_TOKEN`	ficha do lead	Token do RD Station CRM (ou `pcrm_…`, do PronixCRM). Vazio, junto com `CRM_API_TOKEN`: ficha desligada.
`CRM_API_URL`	ficha do lead	Força a base da API do CRM (padrão: pelo token).

Modelos

Variável	Padrão	Descrição
`LLM_PROVIDER`	`anthropic`	`anthropic` ou `ollama` (local, custo zero).
`ANTHROPIC_MODEL`	`claude-sonnet-5`	Modelo dos reports; precisa de preço em `src/precos.js`.
`ANTHROPIC_MODEL_ECO` · `ANTHROPIC_MODEL_PREMIUM`	`claude-haiku-4-5` · `claude-opus-4-8`	Só com `qualidade` explícita no pedido.
`ANTHROPIC_MODEL_RESUMO`	o dos reports	Modelo do resumo rápido.
`GROQ_MODEL`	`whisper-large-v3-turbo`	Transcrição.
`GROQ_VISION_MODEL`	`qwen/qwen3.6-27b`	Leitura de print (reserva: `qwen/qwen3.8-27b`).
`GROQ_COACH_MODEL`	fila padrão	Modelo a tentar primeiro nas análises gratuitas (insights e afins). O nome ficou do antigo coach.
`OLLAMA_MODEL` · `OLLAMA_URL`	`llama3.1` · `localhost:11434`	Só com `LLM_PROVIDER=ollama`.

RD Station

Variável	Padrão	Descrição
`CRM_CACHE_TTL_SEG` · `CRM_TIMEOUT_MS`	`300` · `8000`	Cache da ficha e tempo máximo por chamada.
`CRM_PALAVRAS_IGNORADAS`	—	Etiquetas extras a tirar do nome salvo (separadas por vírgula).
`CRM_MOVER_ETAPA`	ligado	`0` desliga a escrita no RD; as etiquetas continuam.
`CRM_ETAPA_RESPONDEU` · `CRM_ETAPA_QUALIFICADO`	`Respondeu` · `Qualificado`	Nome das etapas, se o time renomear.
`CRM_ETAPA_NAO_COMPROU`	`Não compraram`	Etapa dos closers que encerra o report como "não fechou".
`CRM_ETAPA_VENDIDO` · `CRM_ETAPA_FUP`	`Vendido` · `Fluxo de FUP`	Etapas dos closers que viram "Vendido no RD" e "Em follow-up".
`CRON_SECRET`	—	Segredo do agendador diário da Vercel que confere vendas e perdas no RD.

Google Agenda

Variável	Padrão	Descrição
`GOOGLE_CLIENT_ID` · `GOOGLE_CLIENT_SECRET`	—	Cliente OAuth do Google Cloud. Vazias: recurso desligado.
`GOOGLE_REFRESH_TOKEN`	—	Opcional: a autorização da conta, em vez de conectar pelo painel.
`GOOGLE_TIMEOUT_MS`	`8000`	Tempo máximo de cada chamada ao Google.

Limites e ajustes

Variável	Padrão	Descrição
`MAX_CONVERSATION_CHARS`	`24000`	Teto da conversa antes do prompt.
`MAX_REPORT_OUTPUT_TOKENS`	`4000`	Teto de saída pedido à Anthropic.
`MAX_AUDIO_BYTES` · `MAX_AUDIO_TRANSCRIPTION_CHARS`	`20971520` · `6000`	Tamanho do áudio e da transcrição.
`MAX_IMAGEM_BYTES`	`4194304`	Tamanho do print.
`MAX_RESUMO_CHARS`	`16000`	Conversa enviada ao resumo.
`TRANSCRIPTION_CACHE_TTL_SEG`	`86400`	Cache da transcrição; `0` desliga.
`ANTHROPIC_TIMEOUT_MS` · `GROQ_TIMEOUT_MS`	`50000`	A Vercel corta a função em 60 s.
`USD_BRL_RATE`	`5.3`	Câmbio fixo, só para exibir a estimativa em reais.
`TZ_RELATORIO`	`America/Sao_Paulo`	Fuso que define o "dia" de cada report.
`COMPANY_NAME` · `SDR_NAME`	`PRONIX` · —	Nome no PDF; `SDR_NAME` é só reserva para uso sem chave.
`MASTER_NOME`	`Cauã Lima`	Quem é promovido enquanto não houver master.
`PORT` · `CR_DATA_DIR`	`3000` · `data/`	Servidor local.
`PYTHON_BIN` · `WHISPER_MODEL_SIZE`	`python` · `small`	Transcrição local, sem Groq.

Dados guardados

Tudo em src/db.js (Redis em produção, data/*.json local). A conversa não é guardada.

Chave	Conteúdo
`usuarios`	Acessos: nome, chave, papel e recursos.
`reports`	Histórico (até 5.000): lead, contato, SDR, custo, leitura da IA, closer e resultado.
`consumo`	Custo por geração — continua valendo se o report for removido.
`pdf_<id>`	O PDF de cada report.
`base`	Base de conhecimento (com os textos anteriores, para restaurar).
`closers`	Lista de closers, com o apelido e a inteligência de cada um.
`crm_cards`	Card escolhido para cada lead com mais de um.
`google_agenda`	Autorização da conta conectada ao Google Agenda (só no servidor).
`lead_marcas`	Etiqueta "Qualificado" e agendamento por lead (até 4.000).
`crm_movimentos`	Registro de cada card movido para "Respondeu" (últimos 500).
`crm_transcricoes`	Registro de cada transcrição mandada ao CRM (últimos 500: card, ok/erro — sem o texto da conversa).
`rd_limpeza_relatorios`	Um relatório por execução da limpeza: quando, funil e quantos cards por motivo (últimos 400).
`rd_limpeza_log`	Cada card desqualificado pela limpeza do funil: de que etapa saiu, o motivo e quando (últimos 8.000). É o que permite desfazer.
`aprendizado_consciencia`	Correções do nível de consciência (até 200).
`insights_ultimo`	Últimos insights gerados.
`cache:*`	Temporários: transcrições, ficha do RD (5 min), funis (1 h), resumos (7 dias).

Copiar os dados de um banco para outro

scripts/migrar-dados.js copia todas as chaves permanentes de um banco Upstash/KV para outro (usuários, reports, resultados, base de aprendizado...). As credenciais ficam só em variáveis de ambiente da janela do terminal: ORIGEM_URL, ORIGEM_TOKEN, DESTINO_URL e DESTINO_TOKEN.

node scripts/migrar-dados.js            # só lista o que seria copiado
node scripts/migrar-dados.js --copiar   # copia de fato

Não apaga nada na origem; no destino, substitui a chave de mesmo nome. Chaves temporárias (cache e travas) ficam de fora.

Testes

npm test

393 testes, sem rede, sem chave real, sem custo e sem tocar em data/ (o banco é uma pasta temporária). O jsdom roda os scripts reais da extensão e do painel.

Arquivo	O que cobre
`servidor.test.js`	A API com IA e Groq simulados: acessos, geração, duplicado, PDFs, resultado, áudio.
`qualidade.test.js`	Conferência de citações e normalização da conversa, em casos sintéticos.
`report-rico.test.js`	Nível de consciência, "Como foi a conversa", sinais de compra e o limite de 2 páginas.
`extensao-dom.test.js`	Leitura da conversa no WhatsApp e no Instagram: ordem, remetente, áudios, troca de conversa.
`ficha-crm.test.js`	O cartão no WhatsApp: ficha, busca, vários cards, resumo, painel lateral e a ficha guardada na aba.
`automacao-dom.test.js`	Mover para "Respondeu", etiqueta e agendamento no cartão.
`automacao.test.js`	A escrita no RD e as marcas do lead, com RD simulado.
`agenda.test.js`	Leitura de dia e horário nas mensagens.
`crm.test.js`	Busca do lead no RD: telefone, nome, duplicados, cache.
`resumo.test.js`	Resumo rápido no servidor, com IA simulada.
`inteligencia.test.js`	Perfil, closer × perfil, resultados, calibragem e base recomendada.
`diario.test.js`	Regra do .zip do dia (vale o último report de cada lead).
`painel.test.js`	O painel inteiro com API falsa.
`popup.test.js`	Popup da extensão.
`audio-cliente.test.js` · `auditoria.test.js`	Validador de áudio e correções da auditoria.

Os testes não substituem o uso real: WhatsApp e Instagram mudam de layout sem avisar, e a qualidade do texto gerado pela IA só se confere em reports de verdade.

Deploy e publicação

Servidor (Vercel)

Conecte o repositório e adicione um Vercel KV (ou Upstash Redis).
Preencha as variáveis do projeto (as essenciais, no mínimo).
git push origin main — a Vercel publica sozinha (vercel.json manda tudo para api/index.js, com limite de 60 s por função).

Mudança só no servidor ou no painel: basta o push.

Extensão (Chrome Web Store)

Qualquer mudança em extension/ exige versão nova:

Suba a version em extension/manifest.json.
npm run empacotar — gera public/PRONIX-extensao.zip.
Envie o .zip no painel da Chrome Web Store e aguarde a revisão.

Não é preciso sincronizar as duas publicações: recurso que o outro lado ainda não conhece fica desligado até ele ser atualizado.

Segurança e privacidade

Segredos só no servidor. Chaves da Anthropic e do Groq e o token do RD ficam em variáveis de ambiente; nunca vão para a extensão, para o navegador nem para log.
O servidor é fixo na extensão. O service worker só fala com o endereço salvo no popup (https, ou localhost em desenvolvimento) e ignora endereço vindo da página.
Nada de fora vira HTML. Nome do contato, dados do CRM e erros entram na tela como texto.
Cada um vê o seu. O SDR só reabre e baixa os próprios reports; a chave é mascarada no painel.
Telefone e nome do lead vão por POST, fora de URL e de log de acesso.
Leitura sob clique. O conteúdo das mensagens só vai ao servidor quando o SDR clica (report ou resumo). A automação do cartão lê no navegador e envia apenas o resultado.
Tipo conferido pelos bytes em áudio e imagem, não pela extensão do arquivo.

A política completa, exigida pela Chrome Web Store, está em /privacidade (public/privacidade.html).

Limites e riscos

Risco de ban: baixo. A extensão só lê a página aberta; não abre conexão própria com o WhatsApp nem com o Instagram.
Layout dos sites. A leitura depende do HTML de cada site. extension/content.js e extension/content-instagram.js são os arquivos mais sensíveis do projeto.
Instagram. O Direct usa classes trocadas a cada build e destrói do DOM as mensagens fora da tela, além de ignorar scrollTop. Por isso a leitura navega com scrollIntoView, costura cada janela na anterior pela maior sobreposição de sequência e captura o áudio no momento em que a bolha aparece.
Áudio. Transcrever exige tocar o áudio no mudo; no Instagram isso pode marcá-lo como ouvido. Áudio antigo, que o WhatsApp não entrega mais, entra como [áudio].
Automação do RD. Montada pela documentação da API e testada com RD simulado; depende de o token ter permissão sobre os cards. A leitura de agendamento é por regra de texto e pode errar em frases fora do padrão — o × no cartão corrige.
Amostra pequena. A inteligência só vale com resultados marcados na rotina.
Ainda não existe: leitura de PDF e Word no chat manual, status por campo (confirmado/inferido) no report e expurgo automático dos PDFs antigos.

Estrutura do projeto

server.js                     Rotas: páginas, report, cartão do lead, gestão
api/index.js · vercel.json    Entrada e configuração da Vercel

src/
  report.js                   Prompt do report, chamada à IA, validação da resposta
  conversation-normalizer.js  Limpa, agrupa e corta a conversa antes do prompt
  citacoes.js                 Conferência das citações e filtro de falas, sem IA
  consciencia.js · perfil.js  Nível de consciência e perfil do lead (a mesma régua em tudo)
  generatePdf.js              PDF com a marca PRONIX, até 2 páginas
  idempotencia.js             Hash da conversa (reportKey)
  precos.js · stats.js        Preço por modelo; histórico, custo e resultados
  pdfStorage.js · diario.js   PDFs guardados; regra do .zip do dia
  transcribe.js · groq.js     Transcrição, visão e chat gratuito (com fila de modelos)
  resumoRapido.js             Resumo rápido da conversa
  crm.js · leads.js           RD Station (ficha e mover etapa); etiqueta e agendamento por lead
  inteligencia.js             Closer × perfil, padrões da prospecção, insights
  aprendizado.js              Correções que calibram o nível de consciência
  base.js · baseInicial.js    Base de conhecimento e o texto recomendado
  usuarios.js · closers.js    Acessos, papéis e recursos; lista de closers
  db.js                       Redis em produção, arquivos localmente; cache e trava

extension/                    Extensão MV3
  content.js                  WhatsApp: leitura da conversa, áudios e cartão do lead
  sidepanel.html · painel.js  Painel lateral do Chrome: lead e negociações, cada uma com link para o card
  agenda.js                   Leitura de agendamento e de "lead respondeu" (sem rede)
  content-instagram.js        Instagram Direct: leitura da conversa e dos áudios
  inject.js                   Gancho de áudio no contexto da página
  background.js               Service worker: fala com o servidor
  popup.html · popup.js       Gerar, editar e baixar o report; chave e servidor

public/
  dashboard.html              O painel
  dia.html                    Resumo do dia
  privacidade.html            Política de privacidade
  PRONIX-extensao.zip         Gerado por `npm run empacotar`

tests/                        22 arquivos; helpers/dom.js simula WhatsApp e Instagram
docs/                         Sistema visual, auditoria, plano, checklist e análise das calls
scripts/transcribe.py         faster-whisper local (só sem GROQ_API_KEY)

Documentação relacionada

GUIA-SDR.md — instalação e uso para quem só gera reports.
docs/design.md — o sistema visual (papel, tinta e marca-texto): tokens, regras e onde vale.
docs/analise-calls-vendas.md — o que 12 reuniões que viraram venda ensinam (sem dados de clientes).
docs/checklist-pendencias.md — o que entrou em cada versão e o que falta conferir.
docs/auditoria-pronix.md — status de cada achado da auditoria.
docs/plano-implementacao.md — o que falta, em etapas.

CRM: RD Station ou PronixCRM

O PronixCRM (crm.pronixhub.com.br/api/v1) é uma cópia da API v1 do RD, e o mesmo código (src/crm.js) fala com os dois: o token pcrm_… decide. O que muda no PronixCRM, e já é tratado:

o token vai no cabeçalho Authorization: Bearer (nunca na URL);
a lista de contatos vem sem as negociações, os telefones e os e-mails: a ficha busca /deals?contact_id e o detalhe do contato (os e-mails são o que acha a reunião no Google Agenda, para pintar);
mover para "Respondeu" é POST /deals/:id/stage com a versao lida; perder/desqualificar é POST /deals/:id/lost (a etapa "Desqualificado" vai junto quando é etapa de perda do funil);
o SDR é uma coluna do CRM, gravada por ele: o campo "SDR" não é mais escrito;
reabrir uma negociação perdida não existe na API: o "desfazer" da limpeza manda fazer pela tela do CRM;
a lista de /deals ignora win, user_id e closed_at_period: quem lista (Match, vendas do closer, report do dia) usa sdr_id, o funil dos closers e a janela updated_at_period, e confere o resto aqui;
o detalhe de cada negociação é lido no ritmo do limite (600 consultas por minuto por token), com prazo por rodada e guardado por id + updated_at (só a que mudou é relida). O token age em nome de quem o gerou.

Antes de chamar: o lead já passou pelos closers?

A ficha olha todos os cards do lead (os cadastros repetidos também) e o histórico de etapas de cada um (historicoComercial em src/crm.js): JÁ COMPROU (card ganho), JÁ FEZ REUNIÃO (passou por reunião realizada, FUP, negociação ou venda), JÁ TEVE REUNIÃO MARCADA e JÁ PASSOU PELOS CLOSERS (funil com "closer" no nome) — com a data, o closer (dono do card) e o card. Aparece em destaque no topo do painel lateral e no cartão, para todos. Do card da conversa só contam fatos passados (a reunião marcada dele já está na ficha).

Mudar etapa à mão (painel lateral)

No card da conversa, Mudar etapa à mão: para quando a automação falha (ex.: não foi para "Respondeu"). Lista as etapas do funil do card, sugere "Respondeu" quando o card está antes dela e move só ao confirmar. Para todos com a ficha do lead. O servidor confere de novo que o card é do lead da conversa, está em aberto e a etapa é do mesmo funil; reunião, FUP, negociação, venda, perda e etapas que pedem closer ficam de fora (têm botão próprio). Registra em crm_movimentos com manual: true (POST /api/crm/etapas, POST /api/crm/etapa).

Transcrição da conversa no CRM

A cada report do WhatsApp, a conversa inteira (com os áudios já transcritos) vai para o card do lead no PronixCRM: POST /deals/:id/whatsapp_transcripts com transcript ("[21/10/2026 10:05] Nome: …", hora de Brasília), started_at, ended_at, phone e external_id (a impressão digital do texto: a mesma conversa mandada de novo não duplica). Vai também como anotação no card (é o que aparece no Histórico do card; uma vez por conversa, em partes de 20 mil caracteres se o CRM recusar uma só). Roda em paralelo com o report, sem custo de IA (src/transcricaoCrm.js). Vai também quando o report já existia — é assim que um lead de antes chega ao CRM: gerar o report de novo. A conversa não fica guardada no servidor, então reports antigos só vão quando forem gerados de novo. Instagram não vai; sem card, CRM recusando ou CRM_TRANSCRICAO=0, o report sai igual.

檢視完整 README ↗

README

Report PRONIX

Sem bot, sem QR code e sem biblioteca não oficial: a extensão só lê a página que o SDR já tem aberta e logada.

Sumário

O que a ferramenta entrega

Para quem	O quê
Pré-vendedor (SDR)	Report em PDF com um clique; ficha do lead do RD ao abrir a conversa; resumo rápido para retomar um lead; painel lateral com as negociações do lead, cada uma com link para o card no CRM; .zip com os reports do dia.
Closer	Handoff de até 2 páginas: resumo, perfil do lead e como conduzir, nível de consciência, sinais de compra, como foi a conversa e a fala pronta para abrir a reunião.
Gestão	Custo por report e por SDR, PDFs de toda a equipe, resultado de cada reunião, matriz closer × perfil de lead, padrões da prospecção que fecha e insights escritos por IA gratuita.

Custo: só a geração do report (Anthropic) é paga. Transcrição de áudio, leitura de print, insights, ficha do CRM e a automação do cartão não têm custo por uso.

Como funciona

WhatsApp Web / Instagram Direct
   │  extensão (content script): lê o DOM, rola o histórico, captura os áudios no mudo
   ▼
service worker da extensão ── x-cr-key ──▶ servidor (Express, na Vercel)
                                             │
                                             ├─ transcreve os áudios ........ Groq (Whisper)
                                             ├─ normaliza a conversa ........ src/conversation-normalizer.js
                                             ├─ gera o report ............... Anthropic (prompt em cache, saída estruturada)
                                             ├─ confere as citações sem IA .. src/citacoes.js
                                             ├─ monta o PDF ................. pdfkit, até 2 páginas
                                             └─ registra custo e leitura .... src/stats.js
   ▼
PDF em base64 ──▶ a extensão oferece o download (e o painel guarda uma cópia)

Produção (Vercel): o mesmo server.js, exposto por api/index.js. Dados no Vercel KV / Upstash Redis (o disco da Vercel não persiste). Áudio sempre pelo Groq.
Local (npm start): dados em data/*.json; áudio pelo Groq se houver GROQ_API_KEY, senão pelo faster-whisper em Python.

src/db.js escolhe o modo sozinho, olhando se KV_REST_API_URL e KV_REST_API_TOKEN existem.

Começando

Servidor local

npm install
cp .env.example .env      # preencha pelo menos ANTHROPIC_API_KEY e ADMIN_PASSWORD
npm start                 # http://localhost:3000

Abra http://localhost:3000, entre com a ADMIN_PASSWORD e crie o primeiro acesso na aba Acessos (papel Master). Cada acesso é um nome + uma chave pnx_… — não há e-mail nem senha.

Extensão

Equipe: instala pela Chrome Web Store (atualiza sozinha). Passo a passo em GUIA-SDR.md.
Desenvolvimento: chrome://extensions → Modo do desenvolvedor → Carregar sem compactação → pasta extension/. No popup, cole a chave; para apontar para o servidor local, troque o endereço para http://localhost:3000.

Papéis e permissões

	Usuário (SDR)	Gestor	Master
Gerar report (extensão e painel)	✓	✓	✓
Reports do dia — os próprios (.zip)	✓	✓	✓
Reports do dia — equipe inteira (.zip com uma pasta por SDR)		✓	✓
Reports gerados (números, custo, closer e resultado)		✓	✓
Arquivos (PDFs guardados, download em massa)		✓	✓
Base de conhecimento		✓	✓
Aba Extensão (download, teste do RD)		✓	✓
Acessos (criar, editar, remover chaves e permissões)			✓
Resultados da reunião e inteligência			✓
Closers (adicionar e remover)			✓
Escolher o closer no aviso "Report pronto!"			✓

Além do papel, o master liga quatro recursos por pessoa na aba Acessos:

Recurso	Padrão	O que libera
Popup do lead	ligado para todos	Ficha do CRM, painel lateral e resumo rápido no WhatsApp.
Automação RD	só o master	Etiqueta "Qualificado" e agendamento. O "Respondeu" automático vale para todos com a ficha do lead (desde 27/10/2026).
Etiquetas	só o master	No cartão, o investimento do formulário ("R$ 3 a 5k", "R$ 5k+") e se o lead já vende.
Cor na agenda	master: Banana; demais: nenhuma	A cor com que as reuniões dos leads da pessoa são pintadas no Google Agenda. O master já começa na Banana sem configurar; "Não pintar" escolhido à mão é respeitado.

O report

O que vem no PDF

Resumo em linhas (nível, investimento, motivação, decisor, perfil…). Investimento, Motivação e Decisor(es) nunca ficam em branco: a IA extrai o sinal que já está na conversa ("tenho uma distribuidora há 12 anos" já responde investimento).
Perfil do lead — dominante, analítico, cético, relacional, cauteloso ou entusiasta — com a evidência e uma frase de como conduzir a reunião (src/perfil.js).
Termômetro de dores: até 3 dores que o lead demonstrou, cada uma com a intensidade de 1 a 5 (cinco degraus, mais quentes quanto mais dói) e a prova do que ele disse. É o motivo da compra, então abre o cartão do topo. Só entra dor de fato (3 ou mais): a citada de passagem fica fora, e na dúvida a IA dá a intensidade menor (src/dores.js).
Temperatura do lead: nível de consciência (inconsciente → problema → solução → nossa entrega → pronto para decidir) com o porquê, e os sinais de compra com a prova da conversa. O selo só aparece de "consciente da solução" para cima (src/consciencia.js) e cada nível exige prova: sem ela, a IA desce um degrau.
Como foi a conversa: 4 a 6 frases em ordem cronológica, com os nomes de quem falou.
Seções de análise, nas palavras do lead (0 a 2 falas, só as muito boas) e a frase de impacto.
Como iniciar a reunião: fala pronta para o closer, junto dos 3 pontos-chave do resumo.

Editável e de graça. Qualquer campo pode ser corrigido no popup da extensão ou no painel; o PDF é refeito sem chamar a IA (POST /api/pdf).

Qualidade

Conversa é dado, não instrução. O texto vai entre <conversa> e </conversa>; marcas parecidas escritas por alguém na conversa são neutralizadas.
Regras de leitura: só é afirmação do lead o que o lead disse; correção posterior prevalece; faturamento não é lucro nem verba; números e nomes exatamente como ditos; nome de pessoa nunca é inventado.
Citações conferidas sem IA (verificarCitacoes): a fala precisa estar na conversa, ou ter ≥ 80% das palavras na mesma ordem e todos os números iguais. A que não passa sai do report.
Captura parcial à vista. A extensão informa quantos áudios achou e quantos transcreveu; o painel marca captura parcial.
Remetente conferido. O aviso final mostra "N mensagens · X suas · Y do lead" e alerta quando um lado vem zerado. Se o site some com os sinais de remetente, vale a posição da bolha.
Trava de conversa. Trocou de conversa durante a leitura? A extensão aborta em vez de misturar duas conversas.

Custo

Cache do prompt. Instruções, exemplos e a base de conhecimento ficam num prefixo em cache (1 h): a partir do segundo report, essa parte custa cerca de 0,1x. Quando o cache vence, o próximo report paga a reescrita (2x) — é a maior parte do custo de um report.
- Dois blocos. Regras + playbook formam o 1º ponto de cache; calibragem do gestor + exemplos, o 2º. O texto emendado é o mesmo de antes, mas corrigir o nível ou o perfil de um report só reescreve o bloco pequeno.
- Aquecimento (src/aquecimento.js, POST /api/cache/aquecer). ~55 min depois de um report, a extensão bate no servidor; se o cache está para vencer e houve report nas últimas 2 h, o servidor manda o mesmo prefixo com 1 token de saída (paga só a leitura, ~20x menos que a reescrita) e o cache fica valendo até ~2h50 depois do último report. Nunca bate com o cache já vencido. AQUECER_CACHE=nao desliga; AQUECER_JANELA_MIN (120) muda a janela. O gasto das batidas e quantos reports acharam o cache quente aparecem nos números do painel.
Conversa compacta. Cada mensagem vai com a hora local ([10:05]) e um cabeçalho por dia com o dia da semana, em vez do carimbo ISO em UTC — menos tokens e a hora certa do WhatsApp.
Idempotência. A reportKey é o hash da conversa normalizada + versão do prompt + modo de qualidade (src/idempotencia.js). Conversa igual não chama a IA de novo: a extensão pergunta entre Abrir o existente e Gerar de novo. Uma trava por chave impede duas gerações simultâneas da mesma conversa.
Normalização (src/conversation-normalizer.js): remove vazios e ecos longos, agrupa falas seguidas e, só acima de MAX_CONVERSATION_CHARS, corta preservando o mais recente e todo trecho com sinal comercial. Quando corta, o report avisa.
Modo de qualidade. qualidade: "eco" | "standard" | "premium" troca só o modelo; nunca é automático. POST /api/estimar-custo mostra a estimativa no painel sem chamar a IA.
Custo registrado. src/precos.js calcula o custo real de cada report (com cache) e src/stats.js guarda o número da época — recalcular depois daria outro valor.

Versão do prompt: PROMPT_VERSAO = 'v6' em src/report.js. Subir a versão permite gerar de novo uma conversa já feita.

Meus closers (com quem o SDR se dá melhor)

Match com PH (meta do mês com o closer)

De onde vem. Só leitura no RD: os cards do closer (responsável) com o campo SDR do card com o seu nome. Reunião realizada = card ganho, perdido por outro motivo que não no-show, ou numa etapa do funil dos closers que só existe depois da reunião (Reunião realizada, FUP agendado, Em contato, Fluxo de FUP, Negociação avançada, Não compraram, Vendido). "Reunião agendada" e no-show não contam. Só o CRM conta (desde 29/10/2026): report com resultado de reunião que o CRM não traz não entra — os números batem com o CRM (card sem você no campo SDR se acerta no CRM).
Datas. Dia da reunião = um campo de data do card com "reunião"/"call" no nome; sem ele, a criação do card. Venda = o dia em que o card foi ganho, com o valor do card.
Mês a mês. Reuniões realizadas, vendas, conversão (vendas ÷ reuniões do mês), faturamento e ticket médio, com a variação sobre o mês anterior; e o mês atual contra o mesmo período do mês passado (do dia 1 até hoje), como no dashboard-pessoal.
Meta. Meta 1, 2 e 3 em reais e a conversão alvo (%), por mês, num formulário sempre à vista que mostra, enquanto você digita, quanto cada meta pede por dia útil e quantas vendas e reuniões. Salvar devolve o painel já refeito (a tela redesenha com a resposta). Medidor (até 59% vermelho, até 89% ouro, 90%+ verde) e barras como no zxp-market, inclusive a meta diária acumulada (onde deveria estar hoje). O plano diz quanto falta, quanto por dia útil, quantas vendas (pelo ticket médio do período) e quantas reuniões isso pede (pela conversão alvo; sem ela, pela do período) e a projeção.
Dias úteis. Segunda a sexta e o último sábado de cada mês (os outros sábados não contam).
Visual. Cada meta tem a marca de onde deveria estar hoje e a cor do ritmo (verde no ritmo, ouro até 10% abaixo, vermelho atrás), com quanto falta e por dia útil; o medidor segue a mesma regra. A conversão do mês tem a própria régua, com a marca do alvo, a média do período tracejada e quantas vendas faltam para o alvo. Atalhos no topo levam a cada parte da aba; closer e "desde" ficam lembrados no navegador.
Com quem o closer fecha mais (src/matchAnalises.js). Conversão (vendas ÷ reuniões realizadas daquele tipo de lead), vendas e faturamento por: profissão, quanto disse que pode investir (até R$ 3 mil, R$ 3 a 5 mil, mais de R$ 5 mil), faturamento, se já vende, o que busca, perfil e nível de consciência do report, dia da semana e origem do card; e, das vendas, o produto, quanto tempo levou para fechar e os motivos de quem não comprou. Os destaques apontam o tipo que mais converte contra a média (só com 3+ reuniões). Os campos vêm do card; sem eles, da anotação do formulário no RD, lida uma vez por card (até 60 por atualização) e guardada por 60 dias.

O cartão do lead no WhatsApp

Painel lateral do CRM

nome, telefones e e-mails, o botão Abrir o card no Pronix CRM ↗, que vai direto para a negociação, e o link do card com Copiar link (para colar no Pronix Calendar ao criar a reunião);
a reunião agendada, quando a agenda do Google já tem;
Negociações (N): cada card do lead com status (em andamento, ganha, perdida e o motivo), funil › etapa, responsável e valor. Clicou, abre aquele card no CRM numa aba nova;
O que respondeu (formulário e campos do card) e as últimas anotações.

Complementar um report do WhatsApp com a ligação (site)

Sugestão de motivo no Desqualificar

Botões que escrevem no CRM (painel lateral)

Para quem tem o acesso do Desqualificar, o painel ganha três botões. Nada muda no CRM sem confirmar no painel.

Perder como duplicado — aparece no card mais antigo quando o lead tem dois ou mais em aberto (o mais novo é o que fica), mesmo que o card antigo seja de outra pessoa. Marca a perda com o motivo de duplicidade cadastrado no CRM (um motivo com "duplic" no nome) e a nota diz em qual card o lead segue.
Qualificado ✓ — no card que fica, para o lead que qualificou e confirmou a reunião (que ainda não aconteceu). Vai para a etapa "Qualificado" do funil (o nome, nunca "Desqualificado" nem "Em qualificação"); funil sem ela, para a etapa de reunião agendada (o "Agendou"); funil sem nenhuma das duas (ex.: Aplicação Direta), para o funil e a etapa em que os cards dele entraram. Closer e handoff só são pedidos se a etapa exigir o closer. A etiqueta "Qualificado" do cartão acompanha. Com os qualificados numa coluna própria, o CRM mostra quem qualificou e não chegou na reunião.
Reunião realizada → — no card que fica. Mostra o caminho que o card vai fazer até a etapa de reunião realizada, o closer (já escolhido quando a agenda do Google tem a reunião) e de onde vem o handoff; confirmado, move passo a passo, conferindo cada passagem, e para no primeiro erro dizendo o que já foi feito.
- As etapas são reconhecidas pela categoria que o CRM dá a cada uma (resposta, reunião agendada, reunião realizada…), igual em todos os funis, qualquer que seja o nome. O caminho passa por "Qualificado", pelas etapas de resposta e de reunião agendada e pelas etapas de trabalho por onde a maioria dos cards passou.
- Funil sem etapa de reunião realizada (ex.: Aplicação Direta): o sistema aprende para qual funil e em qual etapa os cards dele foram, pelo histórico dos cards que já chegaram na reunião nos últimos 120 dias (cache de 12 h). Sem esse histórico e com mais de um funil possível, ele não adivinha: pede para fazer pela tela uma vez.
- O closer vira o responsável do card, na etapa que o exige (ou no fim, se nenhuma exigir). A lista é a dos closers cadastrados na aba Closers, achados no CRM pelo e-mail ou pelo nome.
- O handoff é o texto do último report do lead (guardado 60 dias quando o report é gerado). Sem report, o painel pede o texto. O texto aparece para editar, e o campo Informações da ligação complementa (começou no WhatsApp e terminou na ligação): os dois vão juntos; se o card já tinha handoff, o complemento vira anotação no card. A API do CRM não aceita anexo de PDF: o report vai como o handoff, que é o campo do CRM para isso.
- O token do CRM precisa das permissões trocar_responsavel e, para trocar de funil, mover_de_funil; sem elas o painel avisa antes de mexer em qualquer coisa.

Ficha do RD Station

Etapa e funil, responsável, as respostas do formulário (a anotação com linhas "Campo: valor"), campos personalizados, outras anotações e o link Abrir no RD Station.

Como acha o lead. Pelo telefone: o cabeçalho (contato não salvo), o link de WhatsApp do card no RD (send?phone=…) ou o painel "Dados do contato". O servidor tenta os formatos em que o número pode estar no RD e só aceita contato cujos 8 últimos dígitos batem.
Contato salvo com nome. O nome é limpo das etiquetas do time ("Armando PRONIX Moretti" → "Armando Moretti") e buscado do mais específico para o mais amplo. Só escolhe sozinho quando não há dúvida; senão mostra a lista. Não achou? O cartão tem busca.
Lead com vários cards. O servidor junta todos os contatos com o mesmo telefone e abre o card que o SDR já escolheu; senão, o em aberto com atividade mais recente. O seletor "Este lead tem N cards" lembra a escolha no servidor.
Limpeza. Acentos quebrados por integrações ("EmpresÃ¡rio") são consertados, campos repetidos aparecem uma vez e campos de anúncio/origem ficam de fora.

Resumo rápido

Botão no cartão: lê a conversa e os áudios e devolve o cenário, onde parou, a última pergunta e o próximo passo. Mesma conversa = resumo do cache por 7 dias, sem custo.

Mapa da conversa e perguntas (depois do resumo rápido)

Conversa com áudios longos não se reouve. Depois do Resumo rápido, o cartão ganha:

Mapear a conversa — um checklist do que você já perguntou e do que o lead respondeu: investimento, decisor, momento do negócio, objetivo, prazo, forma de pagamento e reunião. Cada item mostra ✓ (respondeu), ◐ (respondeu em parte), ? (você perguntou e ele não respondeu) ou – (ainda não perguntado), com o trecho que o lead escreveu ou disse e quando. No topo: Qualificado financeiramente: Sim / Em parte / Não (só é "Sim" se o lead disse que tem ou consegue investir; você ter perguntado não basta).
Pergunte sobre a conversa — perguntas prontas ("Já está qualificado financeiramente?", "Já perguntei do decisor?", "Já falei de prazo e pagamento?", "O que ele quer com o projeto?") e uma caixa para escrever qualquer outra. A resposta vem como Sim / Não / Em parte (ou texto, nas perguntas abertas), com quem disse o quê e quando.

Automação do cartão

Três coisas, sem IA e sem custo, para quem o master ligou:

Mover para "Respondeu" no RD. Com a conversa aberta, se há mensagem do lead depois de uma mensagem sua — as duas depois do início da tentativa de contato atual do card — e o card está em aberto e antes de "Respondeu" no mesmo funil, o servidor avança o card. O início da tentativa (contatoDesde na ficha, inicioDaTentativa em src/crm.js) vem do histórico de etapas do card: a entrada na sequência de etapas antes de "Respondeu" no funil atual, nunca antes da criação. Assim, num card de recuperação (card antigo que voltou ao contato, ou que veio de outro funil), a resposta antiga do lead que está no histórico da conversa não conta. A extensão manda a data da resposta (respostaEm) e o servidor confere de novo: sem a data (extensão antiga), com data de antes da tentativa ou no futuro, não move. A automação também espera 1,5 s depois de trocar de conversa e confere que o contato no topo é o da ficha. É a única escrita automática que o sistema faz no RD (a outra é a limpeza do funil, pedida pelo master): nunca volta um card, não mexe em card fechado nem em funil sem essa etapa, confere tudo de novo no RD na hora e registra cada movimento. O RD só aceita se o dono do token for o responsável pelo card ou do mesmo time; se recusar, o cartão mostra o motivo.
Etiqueta "Qualificado". Serve para saber, sem reouvir a conversa, que aquele lead já foi qualificado. Só entra por três caminhos: o card está na etapa "Qualificado" do RD, um report foi gerado para o lead, ou você marcou à mão. Lead que apenas respondeu não ganha etiqueta, e ter agendamento também não qualifica ninguém. Uma vez colocada, fica lembrada mesmo que o card mude de etapa (remarcou, sumiu); passar o mouse mostra de onde ela veio. Marcar ou tirar à mão vale sobre a leitura automática.
Dia e horário agendados. extension/agenda.js lê, no navegador, a última mensagem sua que confirma um compromisso com dia e hora ("reunião agendada para quinta às 15h", "remarquei para 10/10 às 16h", "ficou para amanhã às 9h") — ou o lead escolhendo um horário que você ofereceu, seguido do seu "Agendado!". Citar reunião, horário ou diagnóstico não basta, e proposta ("posso agendar para amanhã às 15h?"), oferta de opções e duração ("2h por dia") não contam. Agendamento dito em áudio entra quando o resumo ou o report leem a conversa inteira. Depois do horário, vira "Estava agendado".

O texto da conversa não vai ao servidor para isso — só o pedido de mover, a etiqueta e a data.

Inteligência comercial

O objetivo é decidir por dado, não por achismo: que closer pega que lead e que prospecção funciona.

Cada report guarda uma leitura (fora do PDF): perfil do lead, nível de consciência e a análise da prospecção — BANT, SPIN, as perguntas-chave do pré-vendedor e a abordagem.
O closer é escolhido na extensão, no aviso "Report pronto!". Havendo histórico, o closer indicado para aquele perfil vem marcado "(indicado)" com o motivo. Nada é salvo sozinho.
O resultado é marcado na aba Resultados da reunião: venda em call, venda em follow-up, pix de compromisso, não fechou, no-show ou em follow-up, com anotação e a correção do perfil e do nível de consciência quando a IA errou.
A conta é feita sem IA (src/inteligencia.js): matriz closer × perfil, conversão por perfil e por nível, e o que difere na prospecção das reuniões que fecharam.
Insights escritos pelo Groq gratuito, só em cima dos números e das perguntas do SDR (a fala dos leads não é enviada). Exige 5 reuniões com resultado.

Onde cada closer vai melhor, e por quê. A aba mostra, sem IA, frases como "Paulo vai melhor com lead cauteloso: fechou 3 de 4 (75%), contra 0 de 2 com os outros perfis", seguidas das anotações de "o que deu a reunião" — é delas que sai o porquê. Os insights da IA recebem os mesmos dados e não podem inventar motivo: sem anotação, dizem que falta anotar.
Closer preenchido sozinho. Ao abrir a conversa do lead, se o card no RD já está em "Reunião Realizada" (ou no funil dos closers) com o closer como responsável, ou se a reunião está na agenda de um closer, os handoffs daquele lead que estão sem closer são preenchidos (src/closerAuto.js). Só vale closer cadastrado na aba Closers, e closer já marcado nunca é trocado.
Desfecho puxado do RD. O closer registra o fim no RD: vendido (com o produto e o valor), ou perdido / etapa "Não compraram" com o motivo. O servidor lê isso (src/vendasRd.js) e preenche a linha sozinho:
- vendido vira Venda em call — ou Venda em follow-up, se o card já tinha passado pelo follow-up ou fechou depois do dia da reunião —, com o produto e o ticket do card. Você só completa a forma de pagamento. Tipo, produto e ticket preenchidos à mão nunca são trocados;
- não comprou vira "Não fechou" com o motivo em "o que deu a reunião" e sai da lista.
Só vale desfecho registrado depois de o report existir.
O resultado acompanha o estado do card. O que o RD deu (e não o que foi marcado à mão) muda junto com o card: "Não compraram" vira "Não fechou"; perda com motivo de falta ("no-show", "não compareceu") vira No-show; o lead que "não comprou" e voltou a negociar volta para Em follow-up; e se ele comprar depois, vira Venda em follow-up. Resultado escolhido à mão nunca é trocado (o report guarda de onde o resultado veio: resultadoOrigem).
Puxar do RD é retroativo. O botão confere todo o período escolhido em Resultados — um lote por vez, até acabar (?varredura=) —, inclusive os reports com resultado à mão que estão sem closer (ganham o closer; o resultado fica). Para preencher o mês, escolha o período e clique uma vez.
Trazer do Report Closer. Report gerado só no Report Closer (o sistema da empresa) fica só no banco de lá. Lá, em Resultados → Levar para o Report PRONIX (período, closer, só vendas), sai um .json com cada report e o PDF; aqui, em Resultados → , ele é importado (, ): só os reports do próprio usuário, o closer achado pelo nome no cadastro daqui, sem duplicar (mesmo report, ou o mesmo lead com até 3 dias de diferença).

Vendas de um closer direto do RD

Report automático do dia

Na aba Reports do dia, o cartão Report automático monta o fechamento do dia no formato que se manda à liderança (src/reportDoDia.js):

Leads novos contatados / Respostas / Recontatos — a extensão (com a automação do cartão ligada) olha as conversas que passam pela tela e avisa, por conversa e por dia, três sinais: você escreveu hoje, já havia mensagens de antes, o lead escreveu hoje (e se já tinha escrito em outro dia). Novo = escreveu hoje e não havia nada antes; recontato = escreveu hoje e já havia histórico (lead que parou ou nunca respondeu e você chama de novo); resposta = a primeira vez que o lead responde, que é quando o card vai para Respondeu no RD — quem já tinha escrito em outro dia não conta. Cada contato conta uma vez. Do contato fica só uma impressão (hash), nunca telefone nem nome. Conversa que não passou pela tela não é vista, e mensagem de áudio ou foto (sem hora) vale a hora da mensagem de antes.
Desqualificados — as perdas do dia por motivo: os cards seus que o RD mostra como perdidos hoje, juntos com o registro do sistema (botão Desqualificar e limpeza do funil), sem contar duas vezes e sem as desfeitas. Se o RD não responder, vale o registro do sistema e o cartão avisa.
Digitado — automáticas, realizadas, agendas que caíram, no-show e observações dos desqualificados ficam salvos por dia (não há como contar isso sozinho).

O texto sai pronto, editável, com o botão Copiar o report (GET/PUT /api/report-dia, POST /api/atividade).

Linha do tempo do contato no report

Das datas das mensagens (sem IA), o resumo do report ganha, quando faz sentido:

Contato: "Conversando com o lead desde 23/09 (24 dias)" — quando o primeiro contato tem mais de 7 dias;
Confirmação: "Confirmado desde quarta-feira (14/10)" — quando o lead confirmou a reunião num dia anterior ao do report (inclusive 1 ou 2 dias antes), e "· reconfirmado no dia (sábado, 17/10)" quando ele confirmou de novo no dia. Conta como confirmação o lead escrever que confirma ("confirmado", "confirmo", "estarei lá") ou responder que sim logo depois de você pedir a confirmação; se a reunião foi remarcada, vale a confirmação de depois (src/linhaDoTempo.js).

Conversa colada como texto, sem datas, não ganha essas linhas.

As duas extensões no mesmo Chrome

Desqualificar pelo WhatsApp

Limpeza do funil no RD

Card parado no começo do funil vira perda em "Desqualificados", com o motivo certo:

Onde o card está	Parado há mais de	Motivo de perda
Contato iniciado	15 dias (ajustável)	Nunca respondeu
Respondeu	15 dias (ajustável)	Parou de responder

O campo SDR do card recebe o nome de quem pediu a limpeza. Fica na aba Limpeza do RD do menu (Gestão comercial), só para o master, e nada acontece sozinho:

Funil — você escolhe em qual funil rodar (ex.: só o de SMQLs automáticas). A lista traz os funis que têm as três etapas; com mais de um, a limpeza nunca escolhe sozinha.
Prévia — lista o que seria mexido e de onde, sem alterar nada.
Testar com 5 cards — para conferir no RD antes do resto. A tela lista os cards movidos com o e-mail do lead e o link "Abrir no RD".
Executar todos — em lotes de 15. Cada card é lido de novo antes de mudar: se saiu da etapa, teve movimento, foi fechado ou é de outro responsável (em "só os meus"), é pulado.
Relatório — quantos cards por motivo ("• Nunca respondeu - 110"), com botão de copiar. Cada execução vira um relatório salvo (dia, funil e contagem), que fica no histórico da aba.
Desfazer o último lote — volta para a etapa de onde saiu e reabre o card.

Quem fica: o card na etapa mais adiantada; no empate, o de movimento mais recente.
O que não é duplicado: lead que já foi perdido e se inscreveu de novo (card fechado não entra na conta), card de outro responsável e card de outro funil.
Dado genérico: e-mail ou telefone repetido em mais de 6 cards (teste, número de preenchimento) fica de fora, e a tela avisa.
Antes de fechar, cada par é lido de novo: só fecha se o card que fica continua em aberto no funil, com o mesmo responsável e contato em comum. Nunca se fecha o último card vivo de um lead.
A prévia mostra, por lead, o que fica e o que sai, e avisa quando o lead cadastrou de novo (o card que sai é mais novo que o que fica). Tem o mesmo "Testar com 5", os lotes, o relatório (linha "Duplicado") e o desfazer. O nome do motivo no RD pode ser trocado em CRM_LIMPEZA_MOTIVO_DUPLICADO (padrão: qualquer motivo que contenha "duplic").

Afinidade com o closer ("Analisar Match com PH")

nota de 0 a 10 da combinação lead × closer (não é "o lead é bom?", é "é bom para ele?");
no aviso: o veredito, até três motivos, um ponto de atenção e a base da nota;
um segundo PDF, de uso do pré-vendedor, com o relatório completo:
- pontos que dão match — cada um com a prova do lead (a fala ou o fato) e o que as calls do closer mostram, com o número;
- pontos de atenção — de onde vêm e como contornar antes ou durante a call;
- casos parecidos nas calls do closer — as contas dos recortes em que o lead se encaixa (quem decide, momento, presença) e exemplos reais do que fechou e do que não, sem nome de lead;
- plano da call em oito fases: abertura, quem decide e quem paga, perguntas de diagnóstico, devolver a dor, prova, proposta, pagamento e fechamento;
- objeções prováveis (o sinal na conversa e a resposta), o que não fazer, falas do lead para usar (só as que ele disse de fato) e o que confirmar antes.

do pacote do closer (aba Closers → Importar pacote): um .json com o cadastro, o apelido, a inteligência e os casos classificados das transcrições. Cria o closer se ele não existe; importar de novo troca os casos das transcrições, sem duplicar. Os casos não levam nome nem contato de lead, e o pacote, como as transcrições, fica em privado/, fora do Git;
dos reports: lead analisado para aquele closer que teve o resultado da reunião marcado (venda ou não comprou) entra na conta sozinho, com o que a análise leu dele.

O padrão ("casal com os dois na call: 9 de 17") vai dentro do histórico no pedido à IA e aparece no painel, em Closers → Inteligência.

a pasta pode ter uma subpasta por call (com a gravação e o documento dentro), como o Meet costuma ficar organizado: a busca desce até dois níveis, descarta as subpastas com data no nome anterior à data de corte e pergunta pelos documentos de várias pastas por consulta. Com a pasta em dia, cada leitura olha só as duas últimas semanas; mudar a pasta ou a data recomeça da data escolhida;
a leitura acontece sozinha de hora em hora (junto da batida da extensão; no máximo uma rodada a cada 45 min, dois documentos por closer) e no botão Ler agora (três por clique). A tela diz o que foi olhado — quantas subpastas, a data da mais nova e, se há call nova sem texto para ler, que tipos de arquivo ela tem —, sem nome de ninguém; se a conta conectada não enxerga a pasta, avisa;
lê Documento Google, Word (.docx), .txt e atalho para um deles; vídeo e o resto ficam de fora;
reunião sem conversa (não compareceu, caiu) não vira caso; duas reuniões do mesmo lead em até 15 dias viram um caso, com o melhor desfecho; o que chega pelo Drive e por um report com resultado conta uma vez só;
a classificação é da IA gratuita, a partir das anotações. É automática e pode errar: a tela lista cada call lida, com "quem decide" e "como terminou" editáveis e o botão de apagar. Caso corrigido não é mais mexido. Tarefa para a pessoa do onboarding nas "Próximas etapas" vale como prova de venda (TRANSCRICAO_ONBOARDING, padrão Carlos);
privacidade: só leitura no Drive; a transcrição não fica guardada no servidor; antes de ir para a IA os nomes, e-mails e telefones são mascarados; o caso guarda o nome da call (o do documento no Drive, que costuma ter o do lead) só para o master achar e corrigir na tela — esse nome nunca vai para a IA nem para o PDF do match —, e uma impressão do primeiro nome para juntar as reuniões. Um documento que o Google não deixa ler é pulado, com o aviso de qual, e vai para o fim da fila.

Base de conhecimento

O painel

Em SUA_URL/. As abas aparecem conforme o papel.

Aba	Para	O que faz
Gerar report	todos	Report sem a extensão, em formato de chat (abaixo).
Reports do dia	todos	Lista do dia e .zip para o líder; gestor e master veem a equipe.
Acessos	master	Chaves da equipe, papel e os três recursos por pessoa.
Reports gerados	gestor, master	Números, custo por SDR, closer e resultado de cada report.
Resultados da reunião	master	Resultado por reunião, inteligência e insights.
Closers	master	Lista de closers.
Arquivos	gestor, master	PDFs guardados; download individual, por SDR ou tudo em .zip.
Base	gestor, master	Base de conhecimento.
Extensão	gestor, master	Download do .zip e teste da ficha do RD.

API

Autenticação por cabeçalho x-cr-key (a chave do usuário). gestor+ = master, gestor ou a ADMIN_PASSWORD em x-admin-pass.

Report e mídia

Rota	Acesso	Para quê
`POST /api/report-direto`	chave	Report a partir das mensagens lidas pela extensão.
`POST /api/report-texto`	chave	Report a partir de texto (painel).
`POST /api/pdf`	chave	Refaz o PDF de um report editado — sem IA.
`POST /api/transcrever`	chave	Transcreve um áudio (cache pelo hash dos bytes).
`POST /api/ler-imagem`	chave	Lê um print de conversa.
`POST /api/estimar-custo`	chave	Estimativa de custo, sem IA.
`GET /api/reports/:id/pdf`	chave	Reabre o PDF (o dono; gestor e master, qualquer um).
`POST /api/reports/:id/closer`	chave	Define o closer do próprio report (gestor e master, de qualquer um).
`GET /api/closers`	chave	Closers (id e nome) e a indicação para um perfil.

Cartão do lead

Rota	Acesso	Para quê
`POST /api/crm/lead`	chave + popup do lead	Ficha do RD do lead da conversa.
`POST /api/crm/respondeu`	chave + ficha do lead	Avança o card para "Respondeu" (todos os usuários; confere a data da resposta).
`GET /api/master/diagnostico`	master	Confere, sem alterar nada, se a automação do "Respondeu" e a cor da agenda têm tudo no lugar, e mostra a última vez que cada uma funcionou.
`POST /api/master/trazer-vendas-rd`	master	Traz as vendas de um closer direto do RD (cards ganhos em que o usuário é o SDR).
`GET /api/report-dia` · `PUT /api/report-dia`	chave	Report automático do dia: contagem, desqualificados, o que foi digitado e o texto pronto.
`POST /api/conversa/mapa` · `POST /api/conversa/perguntar`	chave com o popup do lead	Mapa da conversa e perguntas sobre ela, depois do resumo rápido (IA gratuita; a conversa vem do cartão).
`POST /api/atividade`	chave com a automação do cartão	A extensão avisa o que viu numa conversa hoje (escrevi / havia histórico / o lead escreveu).
`GET /api/crm/motivos-perda` · `POST /api/crm/desqualificar`	chave com a automação do cartão	Botão Desqualificar: os motivos de perda do RD e a perda no card do lead da conversa.
`GET /api/master/limpeza-rd/funis` · `GET …/previa` · `POST …/executar` · `POST …/desfazer` · `GET …/relatorio`	master	Limpeza do funil no RD: prévia, lotes, desfazer e relatório por motivo.
`GET/POST /api/master/limpeza-rd/duplicados`	master	Cadastros duplicados no funil: a busca (sem alterar nada) e o fechamento em lotes como "Duplicado".
`POST /api/rd/atualizar`	chave	Batida de hora em hora da extensão: põe venda, follow-up, perda e closer dos reports em dia com o RD (no máximo a cada 30 min).
`POST /api/lead/marca`	chave + automação	Etiqueta "Qualificado" e agendamento.

Dia a dia e gestão

Rota	Acesso	Para quê
`GET /api/eu`	chave	Nome, papel e recursos liberados.
`GET /api/meus-reports` · `POST /api/meus-reports/zip`	chave	Reports do dia do próprio usuário.
`GET /api/equipe-reports` · `POST /api/equipe-reports/zip`	gestor+	Reports do dia da equipe.
`GET /api/admin/stats`	gestor+	Números e custo.
`PATCH /api/admin/reports/:id/resultado`	gestor+	Closer, resultado, datas e correções.
`DELETE /api/admin/reports/:id`	gestor+	Remove o report e o PDF.
`GET /api/admin/reports/:id/pdf` · `GET /api/admin/reports/pdf-zip`	gestor+	PDFs guardados.
`GET/POST /api/admin/base` · `…/recomendada` · `…/restaurar`	gestor+	Base de conhecimento.
`GET /api/admin/closers`	gestor+	Lista completa de closers.
`POST /api/admin/crm/teste`	gestor+	Busca no RD sem cache, com o passo a passo.
`POST/DELETE /api/admin/closers`	master	Adiciona e remove closers.
`PATCH /api/admin/closers/:id`	master	Apelido e inteligência do closer (alimenta a afinidade); `analiseAtiva` liga e desliga a análise.
`POST /api/admin/closers/importar`	master	Pacote do closer: cadastro, apelido, inteligência e casos das calls.
`GET /api/admin/closers/:id/padrao`	master	As contas dos casos do closer (transcrições + reuniões com resultado).
`POST /api/admin/closers/:id/drive/ler` · `GET …/drive`	master	Lê os documentos novos da pasta do Drive do closer; lista os casos lidos e a última leitura.
`PATCH/DELETE /api/admin/closers/:id/casos/:caso`	master

Do RD Station CRM (API v1) o servidor lê /contacts, /deals/{id}, /activities, /users, /custom_fields e /deal_pipelines, e escreve só PUT /deals/{id} com deal_stage_id.

Variáveis de ambiente

Tudo tem padrão seguro no código; o .env.example traz a lista comentada.

Essenciais

Variável	Quando	Descrição
`ANTHROPIC_API_KEY`	sempre	Gera os reports.
`ADMIN_PASSWORD`	sempre	Acesso reserva do painel; cria o primeiro master.
`GROQ_API_KEY`	produção	Áudio, print e insights. Local sem ela: `faster-whisper`.
`KV_REST_API_URL` · `KV_REST_API_TOKEN`	produção	Banco (Vercel KV / Upstash; também aceita `UPSTASH_REDIS_REST_URL` e `UPSTASH_REDIS_REST_TOKEN`). Vazias: `data/*.json`.
`CRM_API_TOKEN`	ficha do lead	Token do CRM. Um token `pcrm_…` liga o PronixCRM (crm.pronixhub.com.br); outro valor, o RD Station. Tem prioridade sobre `RDSTATION_CRM_TOKEN`.
`RDSTATION_CRM_TOKEN`	ficha do lead	Token do RD Station CRM (ou `pcrm_…`, do PronixCRM). Vazio, junto com `CRM_API_TOKEN`: ficha desligada.
`CRM_API_URL`	ficha do lead	Força a base da API do CRM (padrão: pelo token).

Modelos

Variável	Padrão	Descrição
`LLM_PROVIDER`	`anthropic`	`anthropic` ou `ollama` (local, custo zero).
`ANTHROPIC_MODEL`	`claude-sonnet-5`	Modelo dos reports; precisa de preço em `src/precos.js`.
`ANTHROPIC_MODEL_ECO` · `ANTHROPIC_MODEL_PREMIUM`	`claude-haiku-4-5` · `claude-opus-4-8`	Só com `qualidade` explícita no pedido.
`ANTHROPIC_MODEL_RESUMO`	o dos reports	Modelo do resumo rápido.
`GROQ_MODEL`	`whisper-large-v3-turbo`	Transcrição.
`GROQ_VISION_MODEL`	`qwen/qwen3.6-27b`	Leitura de print (reserva: `qwen/qwen3.8-27b`).
`GROQ_COACH_MODEL`	fila padrão	Modelo a tentar primeiro nas análises gratuitas (insights e afins). O nome ficou do antigo coach.
`OLLAMA_MODEL` · `OLLAMA_URL`	`llama3.1` · `localhost:11434`	Só com `LLM_PROVIDER=ollama`.

RD Station

Variável	Padrão	Descrição
`CRM_CACHE_TTL_SEG` · `CRM_TIMEOUT_MS`	`300` · `8000`	Cache da ficha e tempo máximo por chamada.
`CRM_PALAVRAS_IGNORADAS`	—	Etiquetas extras a tirar do nome salvo (separadas por vírgula).
`CRM_MOVER_ETAPA`	ligado	`0` desliga a escrita no RD; as etiquetas continuam.
`CRM_ETAPA_RESPONDEU` · `CRM_ETAPA_QUALIFICADO`	`Respondeu` · `Qualificado`	Nome das etapas, se o time renomear.
`CRM_ETAPA_NAO_COMPROU`	`Não compraram`	Etapa dos closers que encerra o report como "não fechou".
`CRM_ETAPA_VENDIDO` · `CRM_ETAPA_FUP`	`Vendido` · `Fluxo de FUP`	Etapas dos closers que viram "Vendido no RD" e "Em follow-up".
`CRON_SECRET`	—	Segredo do agendador diário da Vercel que confere vendas e perdas no RD.

Google Agenda

Variável	Padrão	Descrição
`GOOGLE_CLIENT_ID` · `GOOGLE_CLIENT_SECRET`	—	Cliente OAuth do Google Cloud. Vazias: recurso desligado.
`GOOGLE_REFRESH_TOKEN`	—	Opcional: a autorização da conta, em vez de conectar pelo painel.
`GOOGLE_TIMEOUT_MS`	`8000`	Tempo máximo de cada chamada ao Google.

Limites e ajustes

Variável	Padrão	Descrição
`MAX_CONVERSATION_CHARS`	`24000`	Teto da conversa antes do prompt.
`MAX_REPORT_OUTPUT_TOKENS`	`4000`	Teto de saída pedido à Anthropic.
`MAX_AUDIO_BYTES` · `MAX_AUDIO_TRANSCRIPTION_CHARS`	`20971520` · `6000`	Tamanho do áudio e da transcrição.
`MAX_IMAGEM_BYTES`	`4194304`	Tamanho do print.
`MAX_RESUMO_CHARS`	`16000`	Conversa enviada ao resumo.
`TRANSCRIPTION_CACHE_TTL_SEG`	`86400`	Cache da transcrição; `0` desliga.
`ANTHROPIC_TIMEOUT_MS` · `GROQ_TIMEOUT_MS`	`50000`	A Vercel corta a função em 60 s.
`USD_BRL_RATE`	`5.3`	Câmbio fixo, só para exibir a estimativa em reais.
`TZ_RELATORIO`	`America/Sao_Paulo`	Fuso que define o "dia" de cada report.
`COMPANY_NAME` · `SDR_NAME`	`PRONIX` · —	Nome no PDF; `SDR_NAME` é só reserva para uso sem chave.
`MASTER_NOME`	`Cauã Lima`	Quem é promovido enquanto não houver master.
`PORT` · `CR_DATA_DIR`	`3000` · `data/`	Servidor local.
`PYTHON_BIN` · `WHISPER_MODEL_SIZE`	`python` · `small`	Transcrição local, sem Groq.

Dados guardados

Tudo em src/db.js (Redis em produção, data/*.json local). A conversa não é guardada.

Chave	Conteúdo
`usuarios`	Acessos: nome, chave, papel e recursos.
`reports`	Histórico (até 5.000): lead, contato, SDR, custo, leitura da IA, closer e resultado.
`consumo`	Custo por geração — continua valendo se o report for removido.
`pdf_<id>`	O PDF de cada report.
`base`	Base de conhecimento (com os textos anteriores, para restaurar).
`closers`	Lista de closers, com o apelido e a inteligência de cada um.
`crm_cards`	Card escolhido para cada lead com mais de um.
`google_agenda`	Autorização da conta conectada ao Google Agenda (só no servidor).
`lead_marcas`	Etiqueta "Qualificado" e agendamento por lead (até 4.000).
`crm_movimentos`	Registro de cada card movido para "Respondeu" (últimos 500).
`crm_transcricoes`	Registro de cada transcrição mandada ao CRM (últimos 500: card, ok/erro — sem o texto da conversa).
`rd_limpeza_relatorios`	Um relatório por execução da limpeza: quando, funil e quantos cards por motivo (últimos 400).
`rd_limpeza_log`	Cada card desqualificado pela limpeza do funil: de que etapa saiu, o motivo e quando (últimos 8.000). É o que permite desfazer.
`aprendizado_consciencia`	Correções do nível de consciência (até 200).
`insights_ultimo`	Últimos insights gerados.
`cache:*`	Temporários: transcrições, ficha do RD (5 min), funis (1 h), resumos (7 dias).

Copiar os dados de um banco para outro

node scripts/migrar-dados.js            # só lista o que seria copiado
node scripts/migrar-dados.js --copiar   # copia de fato

Não apaga nada na origem; no destino, substitui a chave de mesmo nome. Chaves temporárias (cache e travas) ficam de fora.

Testes

npm test

393 testes, sem rede, sem chave real, sem custo e sem tocar em data/ (o banco é uma pasta temporária). O jsdom roda os scripts reais da extensão e do painel.

Arquivo	O que cobre
`servidor.test.js`	A API com IA e Groq simulados: acessos, geração, duplicado, PDFs, resultado, áudio.
`qualidade.test.js`	Conferência de citações e normalização da conversa, em casos sintéticos.
`report-rico.test.js`	Nível de consciência, "Como foi a conversa", sinais de compra e o limite de 2 páginas.
`extensao-dom.test.js`	Leitura da conversa no WhatsApp e no Instagram: ordem, remetente, áudios, troca de conversa.
`ficha-crm.test.js`	O cartão no WhatsApp: ficha, busca, vários cards, resumo, painel lateral e a ficha guardada na aba.
`automacao-dom.test.js`	Mover para "Respondeu", etiqueta e agendamento no cartão.
`automacao.test.js`	A escrita no RD e as marcas do lead, com RD simulado.
`agenda.test.js`	Leitura de dia e horário nas mensagens.
`crm.test.js`	Busca do lead no RD: telefone, nome, duplicados, cache.
`resumo.test.js`	Resumo rápido no servidor, com IA simulada.
`inteligencia.test.js`	Perfil, closer × perfil, resultados, calibragem e base recomendada.
`diario.test.js`	Regra do .zip do dia (vale o último report de cada lead).
`painel.test.js`	O painel inteiro com API falsa.
`popup.test.js`	Popup da extensão.
`audio-cliente.test.js` · `auditoria.test.js`	Validador de áudio e correções da auditoria.

Os testes não substituem o uso real: WhatsApp e Instagram mudam de layout sem avisar, e a qualidade do texto gerado pela IA só se confere em reports de verdade.

Deploy e publicação

Servidor (Vercel)

Conecte o repositório e adicione um Vercel KV (ou Upstash Redis).
Preencha as variáveis do projeto (as essenciais, no mínimo).
git push origin main — a Vercel publica sozinha (vercel.json manda tudo para api/index.js, com limite de 60 s por função).

Mudança só no servidor ou no painel: basta o push.

Extensão (Chrome Web Store)

Qualquer mudança em extension/ exige versão nova:

Suba a version em extension/manifest.json.
npm run empacotar — gera public/PRONIX-extensao.zip.
Envie o .zip no painel da Chrome Web Store e aguarde a revisão.

Não é preciso sincronizar as duas publicações: recurso que o outro lado ainda não conhece fica desligado até ele ser atualizado.

Segurança e privacidade

Segredos só no servidor. Chaves da Anthropic e do Groq e o token do RD ficam em variáveis de ambiente; nunca vão para a extensão, para o navegador nem para log.
O servidor é fixo na extensão. O service worker só fala com o endereço salvo no popup (https, ou localhost em desenvolvimento) e ignora endereço vindo da página.
Nada de fora vira HTML. Nome do contato, dados do CRM e erros entram na tela como texto.
Cada um vê o seu. O SDR só reabre e baixa os próprios reports; a chave é mascarada no painel.
Telefone e nome do lead vão por POST, fora de URL e de log de acesso.
Leitura sob clique. O conteúdo das mensagens só vai ao servidor quando o SDR clica (report ou resumo). A automação do cartão lê no navegador e envia apenas o resultado.
Tipo conferido pelos bytes em áudio e imagem, não pela extensão do arquivo.

A política completa, exigida pela Chrome Web Store, está em /privacidade (public/privacidade.html).

Limites e riscos

Risco de ban: baixo. A extensão só lê a página aberta; não abre conexão própria com o WhatsApp nem com o Instagram.
Layout dos sites. A leitura depende do HTML de cada site. extension/content.js e extension/content-instagram.js são os arquivos mais sensíveis do projeto.
Instagram. O Direct usa classes trocadas a cada build e destrói do DOM as mensagens fora da tela, além de ignorar scrollTop. Por isso a leitura navega com scrollIntoView, costura cada janela na anterior pela maior sobreposição de sequência e captura o áudio no momento em que a bolha aparece.
Áudio. Transcrever exige tocar o áudio no mudo; no Instagram isso pode marcá-lo como ouvido. Áudio antigo, que o WhatsApp não entrega mais, entra como [áudio].
Automação do RD. Montada pela documentação da API e testada com RD simulado; depende de o token ter permissão sobre os cards. A leitura de agendamento é por regra de texto e pode errar em frases fora do padrão — o × no cartão corrige.
Amostra pequena. A inteligência só vale com resultados marcados na rotina.
Ainda não existe: leitura de PDF e Word no chat manual, status por campo (confirmado/inferido) no report e expurgo automático dos PDFs antigos.

Estrutura do projeto

server.js                     Rotas: páginas, report, cartão do lead, gestão
api/index.js · vercel.json    Entrada e configuração da Vercel

src/
  report.js                   Prompt do report, chamada à IA, validação da resposta
  conversation-normalizer.js  Limpa, agrupa e corta a conversa antes do prompt
  citacoes.js                 Conferência das citações e filtro de falas, sem IA
  consciencia.js · perfil.js  Nível de consciência e perfil do lead (a mesma régua em tudo)
  generatePdf.js              PDF com a marca PRONIX, até 2 páginas
  idempotencia.js             Hash da conversa (reportKey)
  precos.js · stats.js        Preço por modelo; histórico, custo e resultados
  pdfStorage.js · diario.js   PDFs guardados; regra do .zip do dia
  transcribe.js · groq.js     Transcrição, visão e chat gratuito (com fila de modelos)
  resumoRapido.js             Resumo rápido da conversa
  crm.js · leads.js           RD Station (ficha e mover etapa); etiqueta e agendamento por lead
  inteligencia.js             Closer × perfil, padrões da prospecção, insights
  aprendizado.js              Correções que calibram o nível de consciência
  base.js · baseInicial.js    Base de conhecimento e o texto recomendado
  usuarios.js · closers.js    Acessos, papéis e recursos; lista de closers
  db.js                       Redis em produção, arquivos localmente; cache e trava

extension/                    Extensão MV3
  content.js                  WhatsApp: leitura da conversa, áudios e cartão do lead
  sidepanel.html · painel.js  Painel lateral do Chrome: lead e negociações, cada uma com link para o card
  agenda.js                   Leitura de agendamento e de "lead respondeu" (sem rede)
  content-instagram.js        Instagram Direct: leitura da conversa e dos áudios
  inject.js                   Gancho de áudio no contexto da página
  background.js               Service worker: fala com o servidor
  popup.html · popup.js       Gerar, editar e baixar o report; chave e servidor

public/
  dashboard.html              O painel
  dia.html                    Resumo do dia
  privacidade.html            Política de privacidade
  PRONIX-extensao.zip         Gerado por `npm run empacotar`

tests/                        22 arquivos; helpers/dom.js simula WhatsApp e Instagram
docs/                         Sistema visual, auditoria, plano, checklist e análise das calls
scripts/transcribe.py         faster-whisper local (só sem GROQ_API_KEY)

Documentação relacionada

GUIA-SDR.md — instalação e uso para quem só gera reports.
docs/design.md — o sistema visual (papel, tinta e marca-texto): tokens, regras e onde vale.
docs/analise-calls-vendas.md — o que 12 reuniões que viraram venda ensinam (sem dados de clientes).
docs/checklist-pendencias.md — o que entrou em cada versão e o que falta conferir.
docs/auditoria-pronix.md — status de cada achado da auditoria.
docs/plano-implementacao.md — o que falta, em etapas.

CRM: RD Station ou PronixCRM

O PronixCRM (crm.pronixhub.com.br/api/v1) é uma cópia da API v1 do RD, e o mesmo código (src/crm.js) fala com os dois: o token pcrm_… decide. O que muda no PronixCRM, e já é tratado:

o token vai no cabeçalho Authorization: Bearer (nunca na URL);
a lista de contatos vem sem as negociações, os telefones e os e-mails: a ficha busca /deals?contact_id e o detalhe do contato (os e-mails são o que acha a reunião no Google Agenda, para pintar);
mover para "Respondeu" é POST /deals/:id/stage com a versao lida; perder/desqualificar é POST /deals/:id/lost (a etapa "Desqualificado" vai junto quando é etapa de perda do funil);
o SDR é uma coluna do CRM, gravada por ele: o campo "SDR" não é mais escrito;
reabrir uma negociação perdida não existe na API: o "desfazer" da limpeza manda fazer pela tela do CRM;
a lista de /deals ignora win, user_id e closed_at_period: quem lista (Match, vendas do closer, report do dia) usa sdr_id, o funil dos closers e a janela updated_at_period, e confere o resto aqui;
o detalhe de cada negociação é lido no ritmo do limite (600 consultas por minuto por token), com prazo por rodada e guardado por id + updated_at (só a que mudou é relida). O token age em nome de quem o gerou.

Antes de chamar: o lead já passou pelos closers?

Mudar etapa à mão (painel lateral)

Transcrição da conversa no CRM

檢視完整 README ↗

POST /api/master/importar-reports

src/importarReports.js

Report PRONIX

語言組成

更新0 筆更新

留言

商業 分類的熱門專案

Report PRONIX

語言組成

更新0 筆更新

留言

商業 分類的熱門專案

你是此專案的營運者嗎？

介紹

README

Report PRONIX

Sumário

O que a ferramenta entrega

Como funciona

Começando

Servidor local

Extensão

Papéis e permissões

O report

O que vem no PDF

Qualidade

Custo

Meus closers (com quem o SDR se dá melhor)

Match com PH (meta do mês com o closer)

O cartão do lead no WhatsApp

Painel lateral do CRM

Complementar um report do WhatsApp com a ligação (site)

Sugestão de motivo no Desqualificar

Botões que escrevem no CRM (painel lateral)

Ficha do RD Station

Resumo rápido

Mapa da conversa e perguntas (depois do resumo rápido)

Automação do cartão

Inteligência comercial

Vendas de um closer direto do RD

Report automático do dia

Linha do tempo do contato no report

As duas extensões no mesmo Chrome

Desqualificar pelo WhatsApp

Limpeza do funil no RD

Afinidade com o closer ("Analisar Match com PH")

Base de conhecimento

O painel

API

Report e mídia

Cartão do lead

Dia a dia e gestão

Variáveis de ambiente

Essenciais

Modelos

RD Station

Google Agenda

Limites e ajustes

Dados guardados

Copiar os dados de um banco para outro

Testes

Deploy e publicação

Servidor (Vercel)

Extensão (Chrome Web Store)

Segurança e privacidade

Limites e riscos

Estrutura do projeto

Documentação relacionada

CRM: RD Station ou PronixCRM

Antes de chamar: o lead já passou pelos closers?

Mudar etapa à mão (painel lateral)

Transcrição da conversa no CRM

README

README

Report PRONIX

Sumário

O que a ferramenta entrega

Como funciona

Começando

Servidor local

Extensão

Papéis e permissões

商業分類的熱門專案

商業分類的熱門專案