Quem é o cliente

5.2 Quem é o cliente

A resposta que quase todo mundo escreve é que o Omie está inflado em 67 registros, porque o CRM é o sistema do comercial e o comercial sabe quem é cliente. É uma resposta razoável e é a resposta errada, pelo motivo mais interessante possível: os dois estão certos. O Omie conta estabelecimentos porque é isso que ele precisa contar para emitir nota fiscal. O Salesforce conta contas porque é isso que ele precisa contar para atribuir dono. A pergunta “quantos clientes temos” não tem uma resposta correta. Tem cinco, e todas são corretas em anéis diferentes.

Pare no último anel por um instante, porque ele é desconfortável. A Órbita publica retenção líquida de 97,3% e retenção bruta de 80,4% nos materiais do conselho. As duas métricas se calculam sobre assinaturas agregadas a alguma unidade de cliente. A empresa não tem objeto de assinatura, não tem contagem de assinaturas e não escolheu a unidade de agregação. Os números não são inventados: eles saem da cascata de ARR, que fecha. O que não existe é a capacidade de auditar de onde eles vêm registro a registro. Isso funciona enquanto ninguém pede a planilha de apoio. Na diligência da Série C, alguém pede.

O presente chamado CNPJ

Tire 18 duplicatas e 8 contas de teste do cadastro do ERP e sobram 585 estabelecimentos faturáveis. Tire as 41 filiais e sobram 544 entidades legais, que é exatamente o número do CRM. A coincidência é o achado, não o conforto: os dois sistemas chegaram ao mesmo número por caminhos independentes que ninguém nunca conferiu, e ninguém na Órbita sabe que eles coincidem. Se soubessem, a discussão de janeiro teria durado quinze minutos. O dataset registra o defeito com a evidência crua: CRM 544 vs Omie 611: 41 filiais cadastradas como cliente próprio + 18 duplicatas + 8 contas de teste.

A escolha de anel não aparece só na contagem. Ela aparece em dinheiro, e é ela que explica a maior parte da distância entre o ERP e a definição canônica de ARR. Os dois totais são vizinhos, então esta conta vai em R$ mil, unidade declarada aqui uma vez, para fechar no último real: o Omie fecha em 25.212 contra os 24.800 da definição canônica, e o dataset abre as três causas. A primeira, R$ 680 mil, é matriz e filial faturadas e contadas separadamente: é o anel de estabelecimento sendo somado como se fosse o anel de entidade legal. A segunda, R$ 190 mil, são contratos cancelados que continuam ativos no cadastro, que é o defeito de evento ausente do capítulo 5.1 aparecendo do outro lado da casa. A terceira é negativa, R$ -458 mil, e são contratos com vigência já iniciada e ainda não faturados: o ERP está inflado numa ponta e atrasado na outra ao mesmo tempo. Líquido: R$ 412 mil, que é a diferença entre os dois totais do começo do parágrafo.

Repare que apenas a primeira das três é um problema de anel. As outras duas são de natureza diferente e exigem correções diferentes, e é por isso que este módulo insiste em decompor em vez de arbitrar. Uma reunião de alinhamento não conserta nenhuma das três. Um campo, um evento e uma data consertam as três.

-- Um cadastro, três contagens. A diferença entre elas não é erro:
-- é o anel em que a pergunta foi feita.
SELECT
  COUNT(*)                                                    AS estabelecimentos,
  COUNT(DISTINCT LEFT(REGEXP_REPLACE(cnpj, '[^0-9]', ''), 8)) AS entidades_legais,
  COUNT(DISTINCT COALESCE(
      grupo_economico_id,
      LEFT(REGEXP_REPLACE(cnpj, '[^0-9]', ''), 8)))           AS grupos_economicos
FROM erp.cliente
WHERE situacao <> 'teste'
  AND cnpj IS NOT NULL;

Por que hierarquia de contas não soma

Chegamos ao ponto em que um detalhe técnico vira um problema de conselho. No Salesforce, o campo Conta-Pai é um relacionamento do tipo lookup, que é uma ligação frouxa: o filho aponta para o pai, sobrevive sem ele e não herda nada. O outro tipo de ligação, chamado master-detail, é forte: o filho não existe sem o pai, herda permissões e permite campos de totalização. Campos de totalização não funcionam sobre lookup. Como Conta-Pai é lookup, hierarquia de contas não totaliza receita nativamente. Isso não é bug. É consequência direta da escolha de relacionamento, e está documentado.

Antes de seguir, desarme uma confusão que este módulo criaria em você mais adiante. Os R$ 780 mil são o grupo inteiro, somando as 4 contas. O contrato de fevereiro de 2025 que o capítulo 5.4 disseca linha a linha é um deles, de R$ 114 mil de ARR, e não o grupo. Os dois números convivem no mesmo dataset e descrevem coisas diferentes: um é a exposição da carteira a um cliente, o outro é o que um papel específico gera por ano. É exatamente por existirem só assim, separados e sem ninguém dizer qual é qual, que ninguém na Órbita enxerga o tamanho do grupo olhando um contrato.

E há uma segunda consequência, mais sutil e mais cara, que quase ninguém antecipa: o CRM guarda uma hierarquia por vez, e a empresa precisa de três. A hierarquia jurídica diz quem assina o contrato. A comercial diz quem atende a conta. A financeira diz quem paga a fatura. Elas não coincidem, e quando alguém reorganiza a árvore para servir a uma delas, desmonta silenciosamente as leituras das outras duas. Na Órbita esse problema ainda não apareceu, porque nenhuma das três existe. A boa notícia é que decidir agora, com 544 contas, custa uma semana. Decidir com quatro mil contas e três ciclos de comissão pagos em cima custa um trimestre e envolve o jurídico.