Se você quer rodar dois WhatsApps (um para vendas e outro para pós-venda/suporte) dentro do Kommo CRM sem duplicar lead, sem perder histórico e sem brigar por “dono do contato”, a solução é simples: um contato único + múltiplos pipelines (funis) + regras de entrada + governança de propriedade. O erro é tentar “separar” criando dois CRMs, duas bases ou dois contatos. Isso mata ROI, mata rastreio e vira guerra interna.
Eu sou o Luiz Otávio Gonçalves (engenheiro mecânico que virou engenheiro digital) e, na prática, esse desenho é um dos que mais destravam escala de atendimento com WhatsApp no Brasil — principalmente quando a empresa cresce e percebe que “vender” e “reter/atender” são operações diferentes, com SLA e métricas diferentes.
O problema real: 2 WhatsApps sem arquitetura viram 4 dores
Quando você coloca um WhatsApp para vender e outro para atender, sem método, aparecem quatro problemas previsíveis:
- Contato duplicado: o mesmo cliente entra em vendas e depois chama o pós-venda; alguém cria outro contato e você perde o histórico.
- Conversa fragmentada: o time não sabe o que foi prometido, o que foi negociado e o que já foi resolvido.
- Disputa de dono: vendedor “segura” o contato, pós-venda não consegue agir (ou vice-versa).
- Relatório lixo: você não sabe CAC real, taxa de recompra, tempo de resposta e nem gargalo do funil.
O antídoto é arquitetura operacional: um CRM, uma base, dois funis, duas linhas de comunicação e regras de roteamento. E sim: dá para fazer no Kommo de forma limpa.
Para quem isso serve (e para quem não serve)
Serve para empresas que:
- Vendam por WhatsApp e tenham volume suficiente para justificar pós-venda separado (ex.: clínicas com recorrência, imobiliárias, cursos, indústria com pós-venda técnico, assistência, contratos).
- Precisem de SLA (tempo de 1ª resposta, tempo de resolução) e rastreio de promessa comercial.
- Queiram reter e aumentar LTV sem inflar time (automação + processo).
Não serve (ainda) para quem:
- Tem baixo volume e só um operador: separar WhatsApps só vai adicionar fricção e custo.
- Não tem disciplina mínima de CRM (cadastro, etapas, atividades). Se o time “odeia CRM”, primeiro arruma o básico.
- Quer “automação mágica” para compensar produto ruim ou atendimento ruim. CRM não salva operação quebrada.
A regra de ouro: 1 contato, 1 histórico, N jornadas
O cliente é um. O que muda são as jornadas (venda, onboarding, suporte, renovação, indicação). No Kommo, isso significa:
- Um contato único (com telefone normalizado e campos padronizados).
- Dois pipelines (ex.: “Vendas” e “Pós-venda/Retenção”).
- Dois números de WhatsApp conectados ao Kommo (via API oficial do WhatsApp/Cloud API com BSP — isso é o que evita ban e permite escala).
- Uma política de propriedade: quem é dono do contato e quem é dono do deal em cada funil.
Se você quer aprofundar o que muda quando você escala WhatsApp (custo e operação), eu recomendo ler também: Kommo + WhatsApp API: o custo real (em R$) e o que trava ROI quando você escala atendimento.
Arquitetura recomendada (o desenho que eu implemento)
Vou te passar um modelo prático que funciona em 80% dos cenários. Ajusta depois por nicho.
1) Dois funis (pipelines) com objetivos e métricas diferentes
Pipeline 1: Vendas (objetivo: fechar e receber)
- Novo lead
- Qualificado
- Proposta enviada
- Negociação
- Ganho / Perdido
Pipeline 2: Pós-venda / Retenção (objetivo: ativar, resolver, reter, expandir)
- Boas-vindas / Onboarding
- Em andamento (solicitação)
- Pendente cliente
- Resolvido
- Recompra / Upsell
Vendas mede taxa de conversão e ciclo. Pós-venda mede SLA e retenção. Misturar tudo em um funil só é a forma mais rápida de destruir visibilidade.
2) Uma política de “dono” (sem briga e sem travar atendimento)
Eu separo assim:
- Dono do contato: geralmente fica com um papel de “Conta” (ex.: gerente de contas) ou pode ficar com o vendedor original. O importante é ser regra, não discussão.
- Dono do deal: muda por pipeline. No funil de vendas, é o vendedor/SDR. No funil de pós-venda, é o time de CS/suporte.
Isso evita o clássico: “não mexe nesse cliente que é meu”. Cliente não é de ninguém. Cliente é da empresa.
3) Dois WhatsApps conectados: o que é fato e o que é ilusão
Fato: dá para operar 2 números dentro do Kommo e organizar por fila/time.
Ilusão: achar que dois números, sozinhos, resolvem processo. Sem regras, vira barulho dobrado.
Dado real: o Kommo tem plano pago por usuário e costuma ser cobrado em US$ por usuário/mês (com variação por plano e cobrança mensal/anual). Para conferir os valores atualizados e qual licença faz sentido pro seu cenário, eu detalhei aqui: Quanto custa o Kommo CRM? Preços e planos em 2026. E se sua dor é escolher licença sem cair em cilada, aqui: Licenças do Kommo CRM: Qual é a melhor para sua empresa?.
Agora, a parte sensível: WhatsApp API (oficial) tem custos próprios (conversa/mensagem conforme regra vigente da Meta e do seu BSP). Eu não vou inventar número aqui porque isso muda por categoria e país e sofre atualização. O que eu faço é: eu coloco na planilha de ROI o custo por conversa + custo por usuário + custo de automação e deixo isso explícito no projeto.
4) Roteamento: como evitar duplicação quando o cliente troca de WhatsApp
O que impede duplicação não é “boa vontade”. É regra de sistema + padrão de cadastro.
Checklist prático que eu implemento:
- Normalizar telefone (DDI + DDD + número) e bloquear criação sem padrão.
- Regra de busca por telefone: ao entrar mensagem nova, o Kommo precisa identificar contato existente antes de criar outro.
- Criação de deal por canal/pipeline: se mensagem veio do WhatsApp de pós-venda, cria/ativa deal no pipeline de pós-venda (não no de vendas).
- Se já existe deal aberto no mesmo pipeline, não cria outro; apenas reabre, move etapa ou cria atividade.
Isso exige configurar automações com cuidado para não gerar “deal spam”. Se você quer automação e follow-up sem irritar lead, veja também: Follow-up de vendas automático: o que é, por que quase todo mundo faz errado e como montar.
5) Automação mínima que dá ROI (sem overengineering)
Quando eu falo de ROI, eu não estou falando de “ficar bonito”. Estou falando de reduzir tempo e aumentar receita com controle.
No funil de Vendas, automações que quase sempre valem:
- SLA de 1ª resposta: se entrou lead e ninguém respondeu em X minutos, alerta + redistribuição.
- Follow-up por etapa: proposta enviada sem resposta em 24h/48h? cria tarefa e sugere mensagem.
- Higiene de funil: lead parado X dias volta etapa ou cai numa fila de reativação.
No funil de Pós-venda, automações que quase sempre valem:
- Boas-vindas + onboarding (com checklists e coleta de dados).
- Lembrete de pendência do cliente (sem depender do operador lembrar).
- NPS/CSAT e disparo de pedido de indicação quando resolve.
- Recompra: gatilhos por data (D+30, D+60, D+90) com base no tipo de compra/contrato.
Recompra e retenção são onde o caixa aparece. Eu detalho essa estratégia aqui: Kommo CRM para retenção e recompra: como transformar pós-venda em receita (sem inflar o time).
6) Tabela de decisão: 1 funil vs 2 funis (critérios objetivos)
| Critério | 1 funil só | 2 funis (vendas + pós) |
|---|---|---|
| Volume de atendimentos | Baixo, time pequeno | Médio/alto, precisa fila e SLA |
| Recompra/recorrência | Quase inexistente | Importante para LTV e margem |
| Complexidade do suporte | Simples, poucas dúvidas | Técnico, prazos, pendências, tickets |
| Risco de promessas comerciais | Baixo | Alto (contratos, entrega, SLA) |
| Métricas exigidas | Conversão e ciclo já bastam | Precisa SLA + resolução + churn + upsell |
7) O “pulo do gato”: quando o pós-venda deve enxergar o funil de vendas (e quando não)
Transparência total parece bonito, mas às vezes é ruído. Minha regra prática:
- Pós-venda deve enxergar o que foi vendido, prazo, condições e mensagens-chave (para não prometer diferente).
- Pós-venda não precisa operar o funil de vendas. Cada time no seu funil, com suas metas.
- Vendas deve enxergar status de onboarding e satisfação, porque isso vira prova social e upsell.
Isso é governança: quem pode ver, quem pode editar, quem pode mover etapa. Sem isso, o CRM vira “terra de ninguém”.
8) Como medir ROI desse desenho (sem achismo)
Se você rodar 2 WhatsApps e 2 funis, você passa a medir o que antes era invisível:
- Tempo de 1ª resposta por canal (vendas vs pós-venda).
- Taxa de resolução e tempo médio de resolução.
- Receita de recompra/upsell originada pelo pós-venda (sem depender do vendedor).
- Queda de retrabalho (menos “me manda de novo”, menos “qual foi o combinado?”).
ROI de automação e CRM tem que ser conta fechada: tempo economizado + receita incremental – custos. Se você quer o método para medir isso direito, sem autoengano, aqui: Como medir o ROI de automações empresariais.
Erros que eu vejo travando 2 WhatsApps no Kommo (e como corrigir)
- Erro 1: criar “Contato Vendas” e “Contato Pós-venda”. Correção: contato é único; use tags/campos e deals separados.
- Erro 2: pipeline de pós-venda com etapas de vendas. Correção: etapas precisam refletir operação real (SLA, pendência, resolução).
- Erro 3: automação que cria deal toda vez que chega mensagem. Correção: valida se já existe deal aberto; se existir, só atualiza/reativa.
- Erro 4: sem política de propriedade. Correção: defina dono do contato e dono do deal por pipeline.
- Erro 5: querer “IA” antes de processo. Correção: primeiro padroniza etapas, SLA e campos; depois você aplica IA onde dá ganho.
Conclusão: dois WhatsApps não é “mais ferramenta”, é mais processo
Quando você implementa dois WhatsApps no Kommo do jeito certo, você constrói uma esteira: vendas fecha, pós-venda ativa e retém, e o histórico fica inteiro. Isso reduz atrito interno, aumenta satisfação e abre espaço para recompra com método. Sem arquitetura, você só dobra o barulho.
Se você quer que eu desenhe e implemente isso na sua operação (do funil aos roteamentos, automações e métricas), o próximo passo é direto: solicitar um projeto.
FAQ
1) Dá para usar dois números de WhatsApp no Kommo ao mesmo tempo?
Sim, dá. O ponto crítico não é “conectar”, é rotear cada conversa para o pipeline certo e impedir duplicação de contato/deal.
2) Como evitar contato duplicado quando o cliente chama no WhatsApp de vendas e depois no WhatsApp do suporte?
Padronize telefone (DDI+DDD+número), force esse padrão no cadastro e configure regras para o sistema procurar contato existente antes de criar um novo. O desenho correto é um contato, múltiplos deals por jornada.
3) É melhor ter um funil só com etapas de pós-venda depois do “Ganho”?
Quase nunca. Misturar vendas e pós-venda em um funil só destrói leitura de conversão e não cria métricas de SLA. O mais eficiente é dois pipelines com metas e relatórios separados.
4) Quem deve ser o dono do contato: vendas ou pós-venda?
Depende do seu modelo, mas precisa ser regra. Eu costumo separar: contato com um responsável de “conta” (ou vendedor) e deal com o responsável do pipeline (vendas no pipeline de vendas; CS/suporte no pipeline de pós).
5) Isso funciona para clínica, imobiliária e indústria B2B?
Funciona, desde que haja volume e necessidade real de pós-venda/retensão. Em operações pequenas, separar WhatsApps pode ser overkill e reduzir produtividade em vez de aumentar.