- Kommo ≠ WhatsApp API: Kommo é o CRM (licença por usuário: US$15/US$25/US$45 por usuário/mês). O WhatsApp oficial depende de um BSP (provedor) e das tarifas de conversas do WhatsApp — são centros de custo e contratos diferentes.
- Lock-in mais comum é no BSP, não no CRM: o que prende operação geralmente é template, qualidade do roteamento, relatórios de cobrança e limitações de migração do número/WABA; o Kommo tende a ser “substituível” com exportação de dados, mas o canal WhatsApp tem regras próprias.
- Mudar de BSP pode ser barato ou caro — depende do seu desenho: se você usa Kommo com WhatsApp API de forma “limpa” (um conector, poucos fluxos críticos), a troca é principalmente setup e testes. Se há automações complexas (Salesbot, webhooks, múltiplos números, times e regras), o custo é tempo de CRM Admin + risco de queda de conversão durante a transição.
- Custos que você precisa separar na planilha: licença Kommo (US$/usuário/mês), custos do BSP (quando existir mensalidade/markup), custos do WhatsApp (conversas), e custo interno/consultoria de mudança (horas de configuração, QA e treinamento).
- Checklist de decisão (o que quase ninguém checa): quem é o “dono” do WhatsApp Business Account (WABA), como ficam templates aprovados, como é o processo de migração do número, e qual o plano de contingência se o novo BSP atrasar portabilidade.
O que você realmente está comprando quando “compra Kommo para WhatsApp”
A decisão costuma confundir três coisas: (1) o CRM (Kommo), (2) o provedor do WhatsApp API (BSP) e (3) a própria tarifa do WhatsApp (cobrança por conversas, com regras do WhatsApp/Meta). O Kommo entra como a camada onde sua equipe atende, registra pipeline, roda automações (Salesbot, regras, tarefas) e centraliza histórico — mas ele não “substitui” o BSP.
Na prática, se você já tem WhatsApp API com um BSP e quer usar Kommo, você conecta o canal ao Kommo. Se você está insatisfeito com o BSP (preço, suporte, instabilidade, limitações), trocar de BSP pode ser parte da decisão — e é aí que o risco de lock-in aparece.
O ponto objetivo para a compra: o Kommo tem planos em US$ por usuário/mês (Base US$15, Advanced US$25, Enterprise US$45). Em reais, isso oscila com o dólar (ex.: multiplicar pelo câmbio do dia e considerar impostos/IOF quando aplicável). Já o WhatsApp API tem custos variáveis por volume de conversas e, dependendo do BSP, pode ter mensalidade e/ou markup.
Onde o lock-in acontece de verdade: Kommo, BSP ou WhatsApp?
Se a pergunta é “vou ficar preso no Kommo?”, o lock-in do CRM é relativamente administrável: você costuma conseguir exportar dados (contatos/leads/negócios) e reconstruir parte do processo em outro CRM. O lock-in mais doloroso costuma ser operacional: automações reescritas, campos e regras, e principalmente a mudança do canal WhatsApp API por trás.
No WhatsApp, existe um conjunto de ativos que podem complicar migração: número de telefone, WhatsApp Business Account (WABA), templates aprovados, e a forma como o BSP configura e expõe relatórios e webhooks. Dependendo de como sua operação foi criada, você pode ter mais esforço para manter o mesmo número e os mesmos templates sem interrupção.
Resumo honesto: Kommo normalmente não é o gargalo para trocar de BSP. O gargalo é o desenho da sua implementação (quantos números, quantos funis, quantas integrações), e o processo/maturidade do BSP na migração.
Sinais práticos de que trocar de BSP faz sentido (mesmo se você continuar no Kommo)
1) Você não consegue prever a conta: quando o BSP não entrega relatórios claros (por categoria de conversa, por número, por time) e você só descobre o custo depois. O Kommo pode ajudar a enxergar operação e volume, mas o custo oficial e o detalhamento fino geralmente estão no BSP/Meta.
2) Suporte lento em incidente: WhatsApp é canal crítico. Se seu BSP demora para responder em bloqueio, queda de envio, problemas de template ou instabilidade, o risco comercial é real (perda de leads e atraso de resposta). Trocar pode ser racional mesmo que o preço seja similar.
3) Limitações técnicas no conector: alguns BSPs têm integrações mais maduras para certos recursos (status de mensagem, webhooks, controle de templates, qualidade de entrega). Se você depende disso para automação no Kommo (ex.: disparos com templates e follow-ups), um BSP fraco vira gargalo.
4) Governança e compliance: quando você precisa de controles (auditoria, histórico, segregação por números, regras) e o BSP não ajuda. Aqui, Kommo resolve parte (processo e registro), mas a parte de canal e política é do WhatsApp/BSP.
O custo real na decisão: o que muda (e o que não muda) ao trocar de BSP
O que NÃO costuma mudar: sua licença do Kommo (US$15/US$25/US$45 por usuário/mês), seu desenho de funil e seus dados no CRM (desde que você não troque o CRM). Você pode manter sua operação comercial praticamente igual do ponto de vista de interface.
O que MUDA: a camada de conexão com o WhatsApp. Isso impacta: (a) credenciais/configuração do canal, (b) templates (e eventualmente reaprovação/replicação), (c) relatórios de faturamento do WhatsApp, e (d) o tempo de mudança com risco de janela de instabilidade.
O custo mais subestimado não é “taxa de migração” — é hora interna de quem cuida do CRM (CRM Admin/RevOps) + tempo de testes com a operação (QA do funil, automações, mensagens, filas, regras de atribuição). Para quem toma decisão, isso precisa entrar no TCO do projeto, mesmo que você não pague uma fatura extra.
Comparativo rápido: cenários de troca de BSP e impacto na operação Kommo
A tabela abaixo ajuda a tirar a decisão do achismo. Ela não substitui o plano técnico do seu caso, mas mostra onde geralmente aparece esforço e risco.
| Cenário | Impacto no Kommo | Risco operacional | O que você precisa checar antes |
|---|---|---|---|
| Trocar BSP mantendo o mesmo número e WABA | Baixo a médio: reconectar canal, validar automações/roteamento | Médio: janela de instabilidade e delays em templates/webhooks | Propriedade do WABA, processo e prazo de migração, backup de fluxos e mensagens |
| Trocar BSP e mudar número (novo número no WhatsApp) | Médio: ajustar regras, reeducar time, possíveis mudanças de cadências | Alto: perda de histórico no número antigo do ponto de vista do cliente + impacto em conversão | Plano de comunicação ao mercado, redirecionamento, campanha de opt-in, governança de contatos |
| Operação com múltiplos números (escala) e troca de um BSP | Médio a alto: reconectar por número, revisar filas, permissões e times | Alto: inconsistência entre números pode quebrar SLA e distribuição | Mapa de números→times→funis, logs de entrega, testes por turno, contingência |
| Manter dois BSPs em paralelo por um período (migração gradual) | Alto: duplicidade de regras, monitoramento dobrado | Médio: reduz risco de corte, mas aumenta complexidade temporária | Critério de desligamento do antigo, controle de templates, prevenção de mensagens duplicadas |
Checklist de compra/implementação: como evitar ficar refém do BSP usando Kommo
1) Defina quem é dono do WABA e do número: parece burocrático, mas é o que define sua liberdade de troca. Se você não consegue provar/gerir isso, a migração vira negociação com terceiros.
2) Documente seus templates e fluxos: liste templates (nome, finalidade, variáveis), e quais automações do Kommo dependem deles (Salesbot, gatilhos, follow-up). Isso reduz tempo de QA e evita “apagão” de conversão após a troca.
3) Tenha um ambiente de testes e um roteiro de QA: mesmo que você não tenha sandbox completo, crie um checklist de validação (envio/recebimento, atribuição, mensagens de ausência, handoff bot→humano, anexos, horários). Troca de BSP sem QA vira aposta.
4) Separe custos por centro: (a) Kommo licenças em US$ por usuário/mês; (b) BSP (mensalidade/markup se existir); (c) WhatsApp (conversas); (d) operação (tempo interno). É comum tomar decisão olhando só (a) e esquecer (b)-(d).
5) Plano de contingência: se o novo BSP atrasar, o que acontece? Você consegue operar no antigo por mais 15–30 dias? O time tem um fallback (ex.: e-mail, ligação, outro canal) para leads quentes? Decisor que planeja contingência evita prejuízo real.
Pontos fortes do Kommo nesse tema (troca de BSP e flexibilidade)
Centralização do processo acima do provedor: quando seu pipeline, tarefas, cadências e governança estão no Kommo, trocar a “tubulação” (BSP) tende a ser menos traumático do que para quem opera só no painel do BSP ou no WhatsApp puro.
Visibilidade e padronização: o Kommo ajuda a garantir que a operação não dependa de jeitinho do vendedor no WhatsApp — isso reduz perda de contexto em mudanças técnicas.
Licenciamento transparente por usuário: você sabe a alavanca de custo do CRM (US$15/US$25/US$45 por usuário/mês), e consegue dimensionar time x ROI. O custo variável do WhatsApp fica fora, mas pelo menos não está misturado no preço do CRM.
Limitações reais do Kommo nesse tema (o que ele NÃO resolve)
Kommo não controla o faturamento oficial do WhatsApp: ele pode registrar conversas, eventos e produtividade, mas a cobrança do WhatsApp (e parte da visibilidade financeira) nasce no ecossistema Meta/BSP. Se seu objetivo é “baixar custo do WhatsApp”, o Kommo ajuda indiretamente (melhor processo), mas não substitui governança de custos no BSP.
Trocar BSP não é só trocar uma integração: se você tem automações complexas (Salesbots, roteamentos, regras por time, múltiplos números), o esforço de validação é real. Isso não é falha do Kommo; é custo de complexidade da operação.
Risco de expectativa errada: algumas empresas compram Kommo esperando que ele resolva qualquer bloqueio/instabilidade do WhatsApp. Kommo melhora controle e conformidade do processo, mas bloqueio e qualidade de entrega ainda são responsabilidade do canal e das práticas de uso (templates, opt-in, conteúdo, volume).
Recomendação editorial: quando eu consideraria Kommo na troca de BSP (e quando eu seguraria)
Eu consideraria Kommo uma boa âncora se seu problema é governança comercial (processo, histórico, handoff, produtividade) e você quer reduzir dependência do “WhatsApp de cada vendedor”. A troca de BSP vira um projeto técnico-operacional com começo/meio/fim, e o CRM ajuda a manter a operação consistente.
Eu seguraria a decisão (ou faria piloto) se sua operação depende de integrações muito específicas do BSP atual, se ninguém interno domina minimamente a administração do CRM, ou se o seu volume é tão crítico que você não pode ter instabilidade — nesses casos, a prioridade pode ser desenhar contingência e fazer migração gradual, não simplesmente “trocar de fornecedor”.
Se o seu decisor precisa de número para orçamento: comece por custo fixo do CRM (Kommo US$15/US$25/US$45 por usuário/mês, convertido pelo câmbio) e trate o WhatsApp como custo variável separado (conversas + condições do BSP). Só depois avalie se o ganho de trocar de BSP paga o custo interno de mudança.
Perguntas frequentes
Kommo é o próprio WhatsApp API?
Se eu trocar de BSP, eu perco meus dados do Kommo (leads, negócios e histórico do CRM)?
Vou conseguir manter o mesmo número de WhatsApp ao trocar de BSP?
Trocar de BSP reduz automaticamente meu custo com WhatsApp API?
O que é mais arriscado: trocar de BSP ou trocar de CRM (Kommo por outro)?
Leia também
Kommo + WhatsApp API (BSP): como escolher o provedor, evitar bloqueio e entender o custo real antes de comprar
Ler →Kommo e custos do WhatsApp API: o que o CRM mostra (e o que você só controla no BSP) antes de comprar
Ler →Consigo exportar meus dados do Kommo? Portabilidade e risco de lock‑in (o que sai e o que fica preso)
Ler →O software é bom. O resultado vem da implementação.
O Kommo é uma ferramenta excelente — mas quem transforma o CRM em máquina de vendas é o processo por trás dele. A rota mais rápida: entrar na Comunidade Kommo Brasil (implementação guiada com quem já fez centenas de vezes), garantir suas licenças ou acompanhar o conteúdo no YouTube.
Portal do ecossistema Luiz Otávio — engenharia digital, CRM e IA.