- Preço é por usuário, não por unidade: Kommo cobra por licença (US$15/25/45 por usuário/mês, conforme plano), então o “rateio” vira processo interno — não um recurso de cobrança por centro de custo.
- Fatura separada por filial geralmente exige múltiplas contas: separar por contas pode facilitar aprovação e pagamento por CNPJ/centro, mas tende a piorar governança de dados (contatos duplicados, visão do cliente fragmentada).
- Relatório por time/unidade é possível, mas depende de disciplina: com campos obrigatórios (ex.: Unidade, Canal, Time) e regras de criação/roteamento, você consegue medir custo e resultado por unidade — sem necessariamente separar cobrança.
- O custo real não é só Kommo: se o WhatsApp for oficial (API), há custo do provedor/BSP e custo por conversa/mensagem do WhatsApp; isso costuma ser a parte mais difícil de ratear com precisão no mesmo “centro de custo” do CRM.
- O que decide a arquitetura: (1) necessidade de faturas separadas vs (2) necessidade de visão única do cliente vs (3) capacidade de manter padronização e qualidade de dados.
O problema real: Financeiro quer centro de custo; Kommo vende licença
Na prática, a pergunta de compra não é “Kommo é bom para WhatsApp?”. É: “Consigo justificar e distribuir esse gasto entre áreas/unidades sem virar briga interna?” Em empresas com filiais, franquias, squads (SDR, Closer, CS), ou canais (parceiros/representantes), o Financeiro frequentemente pede: centro de custo, pedido de compra (PO) por área, fatura por unidade, e visão clara de custo x resultado.
O Kommo é um CRM conversacional focado em vendas (muito forte em WhatsApp), mas não é um sistema de billing/ERP. A cobrança é por usuário/mês em US$, por plano. Referência de preço (público e típico do Kommo): Base US$15, Advanced US$25 e Enterprise US$45 por usuário/mês. Em reais, usando câmbio de R$5,50/US$, isso dá aproximadamente R$83, R$138 e R$248 por usuário/mês (sem entrar em IOF e regras contábeis da sua empresa).
Resultado: se você precisa de rateio “automático” por centro de custo, o Kommo vai exigir decisão de arquitetura e processo — não apenas configuração.
O que o Kommo faz (e o que ele não faz) para rateio por unidade
O que ele faz bem: permite organizar operação por funis, equipes, usuários, automações, atribuição de leads, e medir desempenho (quantidade de leads, etapas do pipeline, atividades, tempo de resposta etc.). Isso viabiliza montar relatórios internos de produtividade e conversão por unidade/time, desde que você padronize o cadastro (campo “Unidade” ou “Marca”, por exemplo) e mantenha disciplina operacional.
O que ele não faz (na prática de compras): não é ferramenta de gestão financeira. Não espere um módulo de centro de custo com alocação automática de licenças, emissão de faturas separadas por time, ou conciliação completa com custos do WhatsApp API (BSP + conversas). Dá para chegar em algo “bom o bastante”, mas é construção, não recurso pronto.
Para decisores, a pergunta correta é: vocês precisam de cobrança/fatura separada ou apenas de visibilidade e rateio interno? Essas duas coisas levam a soluções bem diferentes.
3 modelos de implementação (e qual tende a doer menos)
Modelo A — Uma conta única (workspace) para todas as unidades: costuma ser o melhor para ter visão única do cliente e governança do funil. Você faz rateio “por relatório”: campos obrigatórios (Unidade/Time), roteamento, e exportação para planilha/BI. Limitação: Financeiro pode não ter fatura separada por unidade; o rateio vira procedimento interno mensal.
Modelo B — Uma conta por unidade/filial/franquia: facilita separar cobrança e acesso, e tende a agradar Financeiro/Compras. Por outro lado, aumenta risco de duplicidade de contatos, perda de histórico em operações que atendem o mesmo cliente por mais de uma unidade, e dificulta inteligência comercial centralizada.
Modelo C — Conta única + BI (Power BI / data warehouse): é o modelo mais “corporativo”: dados padronizados no Kommo e rateio/resultado modelados no BI. Funciona melhor quando há maturidade de dados e alguém (interno ou parceiro) cuidando do pipeline de dados. Limitação: adiciona custo e dependência de time/fornecedor.
Com tabela: comparação rápida dos modelos de rateio (na prática)
Abaixo, um resumo objetivo para decisão. Não existe perfeito — escolha o que reduz risco para o seu contexto (Financeiro vs Operação vs Dados).
| Modelo | O que resolve | Onde complica | Quando faz sentido |
|---|---|---|---|
| A) 1 conta para tudo | Visão única do cliente; governança; padronização de funil e automações | Rateio não sai “na fatura”; precisa disciplina de campos e relatórios | Empresa quer gestão central e aceita rateio interno por relatório |
| B) 1 conta por unidade | Separação de acesso e, muitas vezes, de pagamento/aprovação | Dados fragmentados; duplicidade; histórico do cliente espalhado | Franquias/filiais com operação e metas muito independentes |
| C) 1 conta + BI | Rateio e DRE comercial por unidade/time com mais robustez | Custo/complexidade de dados; demanda governança contínua | Operação maior (15–50+ usuários) e decisão orientada a números |
Como fazer “rateio interno” no Kommo sem virar bagunça (passo a passo de decisão)
Se sua empresa não precisa de fatura separada por unidade, dá para implementar um rateio interno razoável com três pilares:
1) Campo obrigatório de Unidade/Centro (e regras de preenchimento): o rateio só funciona se o dado existir e for confiável. Na prática, você precisa tornar obrigatório (no processo) um campo como “Unidade”, “Marca”, “Canal”, “Projeto” ou “Centro de custo”. Se o lead entra via WhatsApp e vira negócio sem esse preenchimento, você perde rastreabilidade.
2) Roteamento e ownership consistentes: para ratear esforço, você precisa que o dono do lead (responsável) reflita a unidade/time. O Kommo é bom em atribuição e distribuição, mas o desenho tem que respeitar seu organograma (ex.: SDR central + closers por unidade).
3) Exportação e periodicidade: mesmo quando o Kommo tem relatórios, o Financeiro geralmente quer uma extração mensal (CSV/planilha) para consolidar. Se sua operação já usa BI, esse caminho é mais sustentável.
O limite aqui é humano: sem governança (alguém cuidando do CRM), os campos começam a ficar inconsistentes e o rateio vira discussão, não dado.
Custo que bagunça o rateio: WhatsApp API (BSP + mensagens) não “fecha a conta” no CRM
Muita empresa acha que “o custo do WhatsApp” está no Kommo. Não está. Se você usa WhatsApp oficial (API), o custo mensal tende a ter pelo menos três camadas: (1) licença do Kommo por usuário (US$15/25/45), (2) custo do provedor/BSP (varia por fornecedor e pacote), e (3) custo de conversas/mensagens conforme a política do WhatsApp/Meta.
Para rateio, isso importa porque a licença do Kommo você rateia por cabeça (usuário), mas o WhatsApp API você normalmente precisaria ratear por volume de conversas, tipo de conversa (marketing/serviço/utilidade/autenticação) e origem (unidade/campanha). Parte dessas informações pode ficar mais clara no BSP do que no CRM.
Na decisão, pergunte: quem vai consolidar a planilha do BSP com o Kommo? Se a resposta for “ninguém”, a empresa vai perder controle do rateio e discutir custo com base em achismo.
Forças do Kommo nesse cenário (o que ajuda de verdade)
1) Estrutura por funil e visibilidade operacional: para times/unidades, o Kommo tende a ser mais prático do que CRMs tradicionais quando o WhatsApp é canal central, porque a conversa e o pipeline ficam próximos — isso reduz “venda no chat sem registro”.
2) Permissões e organização por equipe: dá para separar times e restringir visibilidade (dependendo do desenho de acesso). Isso ajuda a reduzir conflito entre unidades e dá mais segurança operacional.
3) Automações e padronização: você consegue impor etapas, tarefas e critérios de qualificação. Para rateio, isso é indiretamente importante: reduz variação e melhora qualidade do dado.
4) Preço previsível por usuário: para Financeiro, um ponto positivo é que o custo do Kommo é linear por licença (US$15/25/45 por usuário/mês). Se sua operação cresce, você sabe o que muda: número de usuários e (fora do Kommo) volume no WhatsApp API.
Limitações reais (o que costuma gerar retrabalho e custo político)
1) Sem centro de custo “de cobrança”: se você precisa de alocação formal por centro de custo com faturamento separado, o Kommo não é um sistema financeiro. Você pode até separar por contas, mas isso tem custo de dados e gestão.
2) Rateio por unidade depende de dados limpos: sem um CRM admin (ou alguém com tempo para governança), campos ficam incompletos, duplicidades surgem e o rateio vira disputa interna.
3) Fragmentação de histórico se você separar por contas: para negócios em que um cliente transita por unidades (ou marca/produto), separar workspaces pode ser um tiro no pé — você perde visão 360º e aumenta risco de atendimento desconexo.
4) Custo em dólar e variação cambial: não é um “defeito” do produto, mas é um risco de orçamento. Se você precisa de previsibilidade em reais por 12 meses, vai ter que tratar isso (reserva, hedge, política interna, etc.).
Checklist de decisão (antes de contratar): 8 perguntas que evitam surpresa
1) Precisamos de fatura separada por unidade ou apenas rateio interno por relatório?
2) O cliente é atendido por mais de uma unidade ao longo do ciclo? Se sim, separar contas vai gerar problema de histórico?
3) Qual é a unidade mínima de gestão no Kommo: por time, por funil, por unidade, por marca?
4) Quem será dono da governança de dados (campos obrigatórios, duplicidade, padrões)?
5) Como vamos ratear o WhatsApp API (BSP + mensagens)? Temos acesso aos relatórios do BSP por unidade/campanha?
6) O Financeiro aceita cobrança em US$ e variação de câmbio? Qual taxa interna será usada no rateio (ex.: PTAX, fechamento, câmbio do cartão, etc.)?
7) Vamos precisar de BI para consolidar (Kommo + BSP + mídia paga)?
8) O ganho operacional (resposta, conversão, governança) compensa a complexidade do rateio escolhido?
Veredito editorial (sem torcida): para quem o Kommo é boa compra nesse tema
O Kommo é uma boa compra quando sua dor principal é organizar vendas no WhatsApp e você consegue aceitar que “rateio por centro de custo” será um processo (relatórios + disciplina), não um recurso financeiro nativo. Em termos de orçamento, é relativamente transparente por usuário (US$15/25/45), mas o custo total do canal (WhatsApp API) e a governança de dados é o que decide se o rateio vai funcionar sem conflito.
Se sua exigência é cobrança formal por unidade com controle financeiro (modelo ERP/chargeback completo), você provavelmente vai precisar de (a) múltiplas contas e aceitar fragmentação, ou (b) BI/integração para fechar a conta fora do Kommo. Não é impeditivo, mas precisa entrar no business case antes de assinar — porque depois, o retrabalho vira custo invisível.
Perguntas frequentes
O Kommo tem centro de custo para ratear licença por unidade automaticamente?
Dá para ter faturas separadas por filial/franquia no Kommo?
Se eu ficar em uma conta única, consigo medir resultado por unidade?
O custo do WhatsApp (API) fica todo dentro do Kommo?
Quanto custa o Kommo em reais para planejamento interno?
Leia também
Kommo: análise honesta sobre custos ocultos e licenciamento para times de vendas
Ler →Kommo vale a compra? O que Financeiro e Compras precisam checar (câmbio, cobrança e aprovação) antes de implementar
Ler →Kommo é cobrado em dólar, tem IOF, nota fiscal e reembolso? O que muda para empresas no Brasil (review de compra)
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.