Modelo de dados de contas: a camada que trava tudo o resto

Existe uma frase que aparece em quase toda conversa sobre operação B2B, e em vários artigos deste site: o CRM precisa agrupar comportamento por conta, e a maioria não agrupa.

Ela vira pré-requisito de tudo — lead scoring, sinal de intenção, previsão de receita, medição de cobertura em ABM. E quase nunca é explicada: o que exatamente falta, e por que é difícil.

Este artigo é sobre isso. É a camada mais chata da operação e a que trava mais coisas.

O que significa "não agrupa por conta"

Na maior parte dos CRMs, o registro central é o contato — uma pessoa, com e-mail, telefone e histórico de interação. A empresa existe como um campo de texto ou como um registro secundário mal preenchido.

Isso funciona quando a compra é individual. Em B2B, produz três problemas concretos.

Você não sabe quantas pessoas de uma empresa estão engajadas. Três contatos da mesma organização aparecem como três leads independentes, e o sinal mais preditivo do funil — profundidade de engajamento na conta — simplesmente não existe nos seus dados.

A mesma empresa aparece várias vezes. "Indústria Silva", "Ind. Silva Ltda", "Silva Alimentos" e "INDUSTRIA SILVA S/A" são quatro registros. Qualquer contagem por empresa está errada.

Você não consegue medir cobertura. Em ABM, a pergunta "quantas das minhas trinta contas-alvo foram alcançadas" não tem resposta se as contas não são entidades estáveis.

A chave que resolve boa parte

O problema da duplicação tem uma solução específica no Brasil que raramente é usada: o CNPJ como chave da conta.

Diferente do nome, ele é estável, único e verificável em fonte pública. Duas variações do nome apontam para o mesmo número.

Três decisões que valem tomar de uma vez:

CNPJ obrigatório em conta de cliente. Em prospect ainda não é viável — você nem sempre sabe. Em cliente, é.

Matriz e filial: decidir e escrever. Filiais têm CNPJ próprio com a mesma raiz. Se você vende para o grupo, a raiz é a chave; se vende por unidade, o CNPJ completo é. As duas escolhas são válidas, e não escolher produz contagem inconsistente.

Grupo econômico como nível acima. Empresas com CNPJ diferente e mesmo controle. Só importa se você vende para várias delas — e aí importa muito, porque a expansão acontece nesse eixo.

A hierarquia que quase ninguém modela

Em B2B de ticket alto, a estrutura das empresas compradoras é mais complicada que "uma empresa, vários contatos" — e modelar isso errado produz decisões erradas sobre onde investir.

Quatro níveis que aparecem na prática

Grupo econômico. Várias empresas sob mesmo controle, com CNPJ raiz diferente. Uma decisão tomada no grupo se propaga.

Empresa. O CNPJ raiz. É o nível em que existe contrato, faturamento e política.

Unidade. Filial, planta, escritório regional. Tem CNPJ próprio e frequentemente autonomia operacional.

Área. Não tem CNPJ, e é onde a compra de fato acontece em empresas grandes: manutenção, TI, comercial.

Por que isso muda decisões

Se você trata cada unidade como conta independente, um grupo com doze plantas aparece como doze contas médias — e você não enxerga que é uma relação grande com potencial de expansão em série.

Se você trata o grupo como conta única, perde a granularidade que permite dizer que oito plantas já foram atendidas e quatro não. Que é justamente o mapa da expansão.

A modelagem que funciona mantém os dois: a conta é a unidade que compra, e existe um vínculo para o grupo acima dela. As contagens podem ser feitas nos dois níveis.

Quando não vale a complexidade

Se as suas contas são empresas de estrutura única, modelar grupo econômico acrescenta campo que ninguém preenche. A pergunta que decide: entre os seus clientes atuais, quantos pertencem a um grupo do qual você também atende outra empresa? Se for perto de zero, deixe de fora.

O vínculo que precisa existir

Chave estável resolve a identidade da conta. Falta ligar o resto a ela.

Quatro vínculos, em ordem de importância:

Contato pertence a conta. Obrigatório, não opcional. Um contato sem conta é um registro que não pode ser contado em nada.

Oportunidade pertence a conta. Não a um contato. Uma negociação envolve várias pessoas, e vinculá-la a uma só quebra quando essa pessoa sai.

Interação pertence a contato, e por herança a conta. É o vínculo que permite responder a pergunta de trinta segundos acima.

Comportamento no site pertence a contato. O elo mais frequentemente ausente, porque exige identificar quem está navegando — o que só funciona para quem já se identificou alguma vez.

O que fazer com o visitante anônimo

A maior parte do tráfego não está identificada. Duas abordagens que funcionam sem depender de comprar dado:

Reconciliar retroativamente. Quando alguém preenche um formulário, o histórico de navegação daquele navegador é associado ao contato. Isso recupera as visitas anteriores da mesma pessoa.

Aceitar a cobertura parcial. Você vai enxergar o comportamento de quem já se identificou e não o dos demais. Em operação com trinta contas-alvo, isso costuma ser suficiente — os contatos que importam já se identificaram.

Os campos que fazem diferença

Além da estrutura, alguns campos determinam o que dá para analisar depois.

Duas observações sobre a tabela.

Área e nível do cargo valem mais que o cargo em texto livre. "Gerente de TI" e "Coordenador de Tecnologia" viram a mesma coisa quando classificados em área e nível — e viram coisas diferentes quando ficam como texto.

Lista fechada é o que distingue campo analisável de campo decorativo. Motivo de perda em texto livre contém a informação mais honesta da operação e é inutilizável para filtro.

O mínimo para um programa de ABM funcionar

Vale ser específico, porque "organize os dados" é conselho vago e o conjunto realmente necessário é pequeno.

Cinco coisas, e nada além disso é pré-requisito:

1. A lista de contas-alvo existe como registros no CRM. Não numa planilha à parte. Enquanto ela viver fora do sistema, nenhuma medição de cobertura é possível — e a planilha e o CRM vão divergir em semanas.

2. Cada conta-alvo tem um campo que a marca como tal. Com o período: contas entram e saem da lista, e comparar desempenho exige saber quem estava dentro quando.

3. Contatos vinculados às contas. Para contar pessoas por empresa, que é a métrica central.

4. Área e nível do cargo preenchidos nos contatos das contas-alvo. Só nelas — preencher para a base inteira é trabalho sem retorno.

5. Interações registradas com data. De qualquer tipo: e-mail respondido, reunião, visita ao site, evento.

O que isso permite medir

Com essas cinco, três indicadores passam a existir — e são os que descrevem um programa de ABM melhor que qualquer outro:

Cobertura: quantas contas-alvo têm ao menos uma pessoa alcançada.

Profundidade: quantas pessoas distintas, de quantas áreas, por conta.

Progressão: quantas contas mudaram de patamar no período.

Nenhum depende de ferramenta comprada. Todos dependem dos cinco itens acima, que são configuração de CRM.

O erro de esperar o sistema perfeito

É comum adiar o programa até a base estar organizada. Para trinta contas, isso se resolve em dias — são trinta registros para conferir, não cinquenta mil.

Começar com as contas-alvo limpas e o resto bagunçado é perfeitamente viável, e é a ordem que entrega resultado antes.

O erro de tornar tudo obrigatório

A reação natural a dados ruins é exigir preenchimento. Isso produz dados piores.

Quando avançar um registro passa a exigir doze campos, o vendedor preenche qualquer coisa para seguir. Você troca dado ausente — que é visivelmente ausente — por dado errado, que parece válido.

Três princípios:

Obrigatório só o que muda decisão. Três ou quatro campos, no máximo.

Obrigatório no momento em que a informação existe. Pedir motivo de perda no cadastro é absurdo; pedir no fechamento é natural.

Preencher automaticamente o que der. CNAE e porte podem vir de consulta ao CNPJ. Data de estágio é registrada pelo sistema. Cada campo automatizado é um que ninguém precisa digitar errado.

O que a LGPD exige do modelo de dados

Organizar a base tem uma dimensão de conformidade que costuma ser tratada depois, e que fica muito mais barata quando é considerada no desenho.

Três campos que a lei praticamente exige

Origem do contato, com data. De onde veio e quando. Sem isso você não consegue demonstrar a base legal nem responder a um pedido de informação do titular. É também o que separa uma base defensável de um passivo — se você não sabe explicar de onde veio um contato, tem um problema.

Base legal aplicada. Consentimento ou legítimo interesse, por contato. Faz diferença prática: consentimento pode ser revogado, legítimo interesse pode receber oposição, e os dois exigem tratamentos diferentes.

Registro de solicitações do titular. Quem pediu o quê, quando, e o que foi feito. Precisa existir mesmo que nunca seja usado.

O que precisa funcionar de verdade

Eliminação que propaga. Um pedido de exclusão precisa alcançar todos os sistemas — CRM, ferramenta de e-mail, planilhas exportadas. É comum a exclusão acontecer num lugar e o contato continuar recebendo comunicação de outro.

Exportação em formato legível. O titular pode pedir os dados que você tem sobre ele. Se isso exige consulta manual em quatro sistemas, o prazo não é cumprido.

Prazo de retenção com regra. Dados não devem ficar guardados indefinidamente sem finalidade. Uma política simples — contatos sem engajamento há dois anos são eliminados — resolve, e coincide com a boa prática de higiene.

Uma nota sobre dado de empresa

CNPJ, CNAE e porte são dados de pessoa jurídica e não estão sob a mesma proteção. Nome, cargo e e-mail corporativo de um profissional são dados pessoais, ainda que em contexto profissional.

Isso tem uma implicação boa para o modelo: quanto mais informação você conseguir manter no nível da conta em vez do contato, menor o volume de dado pessoal tratado — e menor a superfície de conformidade.

Limpar o que já existe

Toda operação com alguns anos tem uma base com duplicatas, campos vazios e registros mortos. Três movimentos, em ordem.

1. Deduplicar por CNPJ. Onde ele existe, é mecânico. Onde não existe, exige inferência por nome e domínio de e-mail — e revisão manual dos casos ambíguos.

2. Enriquecer o que dá. A partir do CNPJ, preencher CNAE, porte e situação cadastral. É consulta a fonte pública.

3. Arquivar o que está morto. Contatos sem interação há dois anos, oportunidades paradas há um ano, contas com situação cadastral baixada. Arquivar, não apagar — mas fora da base ativa, para não contaminar contagem.

O erro de tentar limpar tudo

Uma base de cinquenta mil registros não vai ficar perfeita. E não precisa.

O que importa é que as contas que você trabalha estejam corretas. Em operação com trinta contas-alvo, limpar trinta registros com cuidado vale mais que um projeto de seis meses tentando salvar o resto.

O que impede a base de degradar de novo

Limpeza é evento; a base suja de novo em dois anos se nada mudar no processo.

Validação na entrada. CNPJ conferido no cadastro, e-mail com formato válido, alerta de possível duplicata antes de criar.

Automação do que é automatizável. Cada campo preenchido por consulta é um que não degrada.

Revisão trimestral curta. Uma hora olhando quantos registros novos entraram sem os campos essenciais. Se o número cresce, o processo está furado em algum ponto identificável.

Um dono. Sem alguém responsável, a base degrada em silêncio — como qualquer coisa sem dono.

Como vender isso internamente

Trabalho de modelo de dados não tem resultado visível. Ninguém aplaude uma base deduplicada, e a comparação com "lançar uma campanha" é sempre desfavorável.

Três argumentos que funcionam melhor que apelar para boa prática.

Mostre uma decisão que foi tomada errado

Procure um caso concreto: uma conta abordada duas vezes por vendedores diferentes, um relatório que apresentou número inflado por duplicata, uma oportunidade perdida porque ninguém viu que outra área já era cliente.

Um caso real convence mais que qualquer argumento sobre qualidade de dado. E ele existe — em toda base bagunçada existe.

Traduza em algo que já foi pedido

Provavelmente alguém já pediu um relatório que não foi possível entregar: quantas contas do setor X estão no pipeline, qual o tempo médio de ciclo por porte, quantas contas-alvo foram tocadas.

Ligar o trabalho de dados a um pedido que ficou sem resposta transforma uma iniciativa técnica em resolução de um problema que alguém sentiu.

Entregue em fatias com resultado visível

Um projeto de seis meses de organização de base é cancelado no terceiro. Uma sequência de entregas de duas semanas, cada uma destravando um relatório específico, sobrevive.

A ordem que funciona: primeiro as contas-alvo, que destravam medição de cobertura; depois os clientes ativos, que destravam análise de expansão; por último a base histórica, se ainda fizer sentido.

O argumento que não funciona

"Precisamos organizar os dados antes de fazer qualquer coisa." É verdadeiro e paralisa. Sempre há como começar com uma fatia limpa enquanto o resto espera — e começar é o que mantém o trabalho vivo.

Sobre trocar de CRM

A conclusão tentadora de um diagnóstico desses é que a ferramenta é o problema. Quase nunca é.

Praticamente todos os CRMs relevantes suportam conta como entidade de primeira classe, vínculo obrigatório e campos de lista fechada. O que falta costuma ser configuração e disciplina, não capacidade.

Migrar sem resolver o modelo de dados produz a mesma bagunça em outra interface, com o custo adicional da migração — e com o agravante de que problemas de dado antigo viram problemas de importação.

A ordem que faz sentido: definir o modelo, limpar a base, ajustar o processo. Se depois disso a ferramenta continuar sendo o gargalo, aí a troca resolve alguma coisa.

Duas semanas para destravar

1. Dia 1 — faça o teste de trinta segundos em cinco contas. Isso dimensiona o problema melhor que qualquer diagnóstico.
2. Dia 2 — decida as chaves. CNPJ como identificador, e a regra de matriz e filial, por escrito.
3. Dias 3 e 4 — meça a duplicação. Quantas contas distintas você tem de fato, contra quantos registros existem.
4. Dia 5 — defina os campos obrigatórios. Três ou quatro, no momento certo do fluxo.
5. Semana 2 — limpe as contas que importam. Clientes ativos e contas-alvo. Não a base inteira.
6. Fim da semana 2 — ligue a validação na entrada e agende a revisão trimestral.

O passo 5 é onde a maioria dos projetos morre, por tentar abarcar tudo. Limpar duzentos registros que você usa toda semana entrega resultado imediato; limpar cinquenta mil que ninguém consulta entrega uma planilha bonita e nenhuma mudança na operação.