Integração ChatGuru + Pipedrive: como conectei os dois em 1 tarde

Quando o lead passa pelas 4 perguntas do Super SDR e confirma que quer reunião, alguém precisava copiar nome, telefone e contexto pro Pipedrive. Por semanas esse “alguém” fui eu, manualmente. Resolvi isso em 1 tarde: webhook do ChatGuru, 3 módulos no Make, Pipedrive com pessoa, deal e atividade criados automaticamente. Aqui está o passo a passo exato.

Por que a integração manual falha?

Não é problema de disciplina. É problema de latência e volume.

O lead qualificado no WhatsApp às 22h não entra no CRM naquela hora. Entra no dia seguinte, quando alguém lembra, se lembrar. Estudo da Harvard Business Review mostra que responder a um lead em até 1 hora aumenta em 7x a chance de qualificação. Depois de 24 horas, essa chance cai 60 vezes. O CRM preenchido na manhã seguinte não é dado útil, é registro histórico.

Além da latência, tem o erro de transcrição. Nome escrito errado, telefone sem DDD, origem não preenchida. Dados sujos que contaminam o funil e tornam impossível rastrear de onde vêm os negócios fechados.

A integração resolve os dois problemas na mesma tacada: o dado entra no CRM no segundo em que o lead qualifica, completo e padronizado, sem intervenção humana.

Qual é o stack da integração? (ChatGuru + Make + Pipedrive)

Três ferramentas. Nenhuma delas cara isolada, e a combinação roda no free tier do Make pra volumes baixos.

ChatGuru é o sistema de atendimento via WhatsApp que usamos. Ele gerencia os fluxos de conversa do Super SDR — as 4 perguntas de qualificação, as respostas condicionais, o momento de escalonamento. A funcionalidade crítica pra essa integração é o webhook de saída: toda vez que uma tag é aplicada a um contato, o ChatGuru pode enviar um payload HTTP pra qualquer URL.

Make (antes Integromat) é a plataforma de automação intermediária. Recebe o webhook do ChatGuru, formata os dados e chama a API do Pipedrive. Poderia usar n8n (open source, mais controle) ou Zapier (mais simples, menos flexível). Ficou com Make porque o editor visual facilita debugar o payload em tempo real.

Pipedrive é o CRM. A API dele é direta: endpoints separados pra persons, deals e activities, autenticação por API token, resposta JSON previsível.

O fluxo é: ChatGuru detecta qualificação → dispara webhook → Make recebe, processa e chama Pipedrive → três registros criados em sequência.

O que o webhook do ChatGuru manda?

Quando configuro uma ação de webhook no ChatGuru, escolho o gatilho (no caso: tag “qualificado” aplicada ao contato) e a URL de destino. O payload padrão inclui:

{
  "contact": {
    "name": "Nome do Lead",
    "phone": "5511999998888",
    "tags": ["qualificado"],
    "customFields": {
      "empresa": "Nome da Empresa",
      "cargo": "Cargo Informado",
      "origem": "instagram"
    }
  },
  "conversation": {
    "id": "conv_abc123",
    "startedAt": "2026-09-16T14:32:00Z"
  }
}

O phone já vem no formato internacional (55 + DDD + número), que é exatamente o que o Pipedrive espera. O conversation.id é o campo que vou usar pra garantir idempotência — mais sobre isso no final.

Os campos em customFields dependem do que coletei nas perguntas do Super SDR. No meu caso: empresa, cargo e como o lead chegou até mim. Esses três campos alimentam os campos personalizados do Pipedrive.

Como fica o Make flow em 3 módulos?

Módulo 1 — Webhook (receptor): Crio um webhook no Make, copio a URL e colo no ChatGuru. É o ponto de entrada. O Make já mostra a estrutura do payload após o primeiro disparo de teste, o que facilita mapear os campos nos módulos seguintes.

Módulo 2 — Search + Create Person no Pipedrive: Antes de criar a pessoa, busco pelo telefone pra verificar se ela já existe. Isso evita duplicatas. Se existir: uso o ID existente. Se não existir: POST /persons com name, phone e os campos customizados de empresa e cargo.

Mapeamento direto:

• name ← contact.name
• phone[0].value ← contact.phone
• [campo_empresa] ← contact.customFields.empresa

Módulo 3 — Create Deal + Create Activity: Com o person_id retornado pelo módulo 2, crio o deal:

• title = {nome} | {empresa} (padrão do nosso CRM)
• pipeline_id = ID do pipeline Educacional (ou SaaS, dependendo do lead)
• stage_id = primeira etapa do pipeline
• [origem] ← contact.customFields.origem

Imediatamente depois, crio a atividade:

• type = diagnostico (tipo customizado que criamos no Pipedrive)
• subject = "Diagnóstico — {nome}"
• due_date = data atual + 2 dias úteis (calculado no Make com função de data)
• deal_id ← retorno do create deal

Tempo total de execução do cenário Make: entre 2 e 4 segundos do disparo até os três registros no Pipedrive.

O que cai no Pipedrive depois da integração?

Três registros criados automaticamente, todos linkados entre si:

Pessoa com nome, telefone formatado, empresa, cargo e campo “Origem do Contato” preenchido. Sem dados sujos, sem DDD faltando.

Deal no pipeline e etapa corretos, com título padronizado Nome | Empresa, origem da oportunidade preenchida e data de criação igual ao momento da qualificação no WhatsApp.

Atividade do tipo “Diagnóstico” vinculada ao deal, com data sugerida 2 dias úteis à frente, já aparecendo na agenda do responsável.

O time comercial abre o Pipedrive na manhã seguinte e encontra o lead organizado, contexto preservado e próxima ação já agendada. Zero digitação manual.

O bug da idempotência (e como evitar)

Aprendi esse conceito da forma mais cara possível: 346 grupos duplicados no Pipedrive num único final de semana. O post completo está aqui, mas o resumo técnico que aplica diretamente a essa integração:

Webhooks têm retry automático. O ChatGuru, por padrão, reenvia o payload se não receber confirmação HTTP 200 em tempo hábil. O Make pode demorar a responder em horários de pico. Resultado: o mesmo lead dispara o webhook 2 ou 3 vezes. Sem proteção, você cria 2 ou 3 pessoas, 2 ou 3 deals e 6 ou 9 atividades para o mesmo contato.

A proteção é feita em dois pontos:

No Make, antes do create person: busco pelo conversation.id do ChatGuru num campo customizado do Pipedrive que criei chamado external_conversation_id. Se já existe um deal com esse ID, encerro o cenário sem criar nada. É uma busca de 1 chamada de API que evita triplicar os dados.

No Pipedrive, configuro o campo external_conversation_id como campo obrigatório na criação do deal, e no Pipedrive existe um campo nativo de deduplicação por e-mail e telefone pra pessoas. Ativo as duas proteções.

Com as duas travas no lugar, o Make pode receber o mesmo webhook 10 vezes que vai criar exatamente 1 pessoa, 1 deal e 1 atividade. Não 10.

Idempotência não é paranoia. É o que separa uma integração que funciona em teste de uma que funciona em produção.

Quanto tempo levou de verdade?

4 horas, distribuídas assim:

• 1h — configurar o webhook no ChatGuru, criar o cenário no Make, mapear os campos do payload
• 1h — criar os campos customizados no Pipedrive, testar os 3 módulos separadamente
• 1h — testar o fluxo completo de ponta a ponta com leads reais (modo de teste do ChatGuru)
• 1h — calibrar a lógica de idempotência, testar reenvio de webhook, confirmar que não duplica

O Make free tier suporta até 1.000 operações por mês. Cada lead qualificado gera ~5 operações (busca + create person + create deal + create activity + log). Pra volumes até 200 leads/mês, é de graça. Acima disso, o plano Core do Make custa $9/mês.

---

Perguntas frequentes

Dá pra fazer essa integração sem o Make, direto entre ChatGuru e Pipedrive? O ChatGuru tem integração nativa com Pipedrive, mas ela é limitada: cria contato, não cria deal e não cria atividade na mesma automação. Pra fazer os três registros em sequência com lógica condicional (verificar duplicata, calcular data da atividade, mapear pipeline correto), você precisa de uma camada intermediária. Make, n8n ou Zapier — qualquer um resolve. O Make tem a melhor relação custo-benefício pra esse caso.

Por que não usar n8n no lugar do Make? n8n é open source e dá mais controle, especialmente em ambientes com dados sensíveis. A desvantagem é que você precisa hospedar (VPS ~$5-10/mês) e manter. Pra quem não tem time técnico, o Make gerenciado é mais simples. Usei Make porque já tinha conta e o editor visual é mais rápido pra iterar. A lógica dos módulos é idêntica nos dois.

O que acontece se o lead qualificar mas não confirmar a reunião? A integração só dispara quando a tag “qualificado” é aplicada no ChatGuru. Você decide quando aplicar essa tag — pode ser ao confirmar reunião, pode ser ao demonstrar interesse qualificado sem confirmação ainda. No meu fluxo, a tag só vai quando o lead responde “sim” pra agendar. Lead que para no meio do fluxo não entra no Pipedrive, entra numa fila de retomada dentro do próprio ChatGuru.

Como tratar leads que já existem no Pipedrive? O módulo 2 do Make faz search por telefone antes de criar. Se o contato já existe, usa o ID existente e cria um novo deal linkado à pessoa já cadastrada. O que não faço é sobrescrever campos que já têm valor — o Pipedrive tem a regra de não sobrescrever campo preenchido, exceto quando é pedido explícito. Isso evita que uma qualificação nova apague histórico anterior.

Dá pra replicar isso com Z-API direto, sem ChatGuru? Sim, mas o esforço aumenta. Com Z-API puro você precisa construir a lógica de fluxo de conversa (as 4 perguntas, os condicionais, o gatilho de qualificação) por conta própria. O ChatGuru já tem isso pronto. A integração com Pipedrive via Make é idêntica — muda só de onde vem o webhook. Se você já tem a lógica conversacional construída em outro lugar, o passo do Make pra frente é igual.

Bora testar?