Como este tema funciona na sua empresa
Em empresa com menos de 50 funcionários, o modelo de dados costuma ser simplificado: contato e empresa colapsados na mesma entidade, oportunidade tratada como negócio único sem hierarquia. Plataformas como HubSpot, RD Station ou Pipedrive entregam modelo enxuto pronto. É aceitável quando o volume de contatos é baixo (poucos milhares) e o ciclo é simples. O risco aparece quando a empresa cresce e descobre que precisa separar dados de empresa de dados de pessoa — migração tardia é dolorosa.
Entre 50 e 500 funcionários, o modelo canônico se torna obrigatório: lead, contato, conta (account), oportunidade, atividade, caso (case). Em B2B, hierarquia de conta (matriz/filial, grupo econômico) entra em jogo. Campos personalizados são controlados — não é qualquer um que cria. Equipe de Operações de Receita (RevOps) é responsável pela governança do schema. Salesforce e HubSpot Enterprise são plataformas comuns nesse porte.
Acima de 500 funcionários, o modelo se estende: parceiro, ativo (asset), contrato, assinatura entram como entidades distintas. Modelagem multi-região e multi-moeda. Comitê formal de governança de dados define padrões. Arquiteto de soluções ou de dados desenha extensões. Plataformas como Salesforce com múltiplas instâncias, Microsoft Dynamics 365 ou plataformas de dados de cliente (CDP) como Segment, Tealium ou Treasure Data centralizam visão unificada do cliente.
Modelo de dados de cliente
é o desenho lógico das entidades, atributos e relacionamentos que representam pessoas, empresas e interações no CRM e nos sistemas conectados — define o que é um contato, o que é uma conta, como se ligam, quais campos são obrigatórios, quais listas controladas existem, como hierarquias são representadas — e funciona como a fundação invisível sobre a qual todos os processos comerciais e de marketing operam; modelo errado obriga customização eterna de relatórios e cria dívida técnica que ninguém quer pagar.
Por que o modelo de dados é a decisão mais subestimada do CRM
Toda empresa que implanta CRM toma, no primeiro mês, dezenas de decisões de modelagem: o que é um lead? Quando vira contato? Onde guardamos o nome da empresa-mãe? O cargo do contato fica em qual entidade? A maior parte dessas decisões é tomada por consultor de implantação ou por quem teve disponibilidade — e raramente é revisada depois.
O problema é que essas decisões viram fundação. Cinco anos depois, quando a empresa cresceu e o ciclo comercial ficou complexo, os relatórios começam a exigir joins (junções) cada vez mais complicados, a hierarquia de empresa não fecha porque foi modelada como texto livre, e a equipe descobre que o mesmo cliente aparece em três registros diferentes porque ninguém modelou identidade única. Reescrever modelo de dados em CRM ativo é cirurgia de coração aberto — possível, mas cara, demorada e arriscada.
Modelo bem desenhado, ao contrário, é invisível: ninguém percebe porque os relatórios saem naturalmente, a hierarquia de empresa fecha, lead-to-account funciona automatizado, e dashboards mostram dados confiáveis. A diferença entre os dois cenários é quase inteiramente o trabalho feito (ou não feito) na decisão original de modelo.
As seis entidades canônicas
O modelo canônico de CRM tem seis entidades centrais, herdadas de Salesforce e adotadas com variações por todas as plataformas modernas.
Lead. Pessoa que demonstrou interesse mas ainda não foi qualificada como oportunidade real. Tipicamente entra via formulário de site, lista de evento ou prospecção. Tem atributos próprios (origem, status de qualificação) e vida útil curta — em algumas semanas, vira contato qualificado ou é descartado. Em HubSpot, o "lead" foi reformulado como objeto separado em 2024; em Salesforce, é entidade clássica.
Contato (contact). Pessoa real, com vínculo conhecido a uma empresa. Tem nome, email, telefone, cargo, departamento. Em B2B, sempre se relaciona a uma conta. Em B2C, pode existir sozinho ou como representante de uma família/grupo. É a entidade mais consultada em campanhas e relatórios.
Conta (account). Empresa ou organização. Em B2B, é a entidade que organiza tudo: oportunidades, contatos, atividades, contratos pertencem a uma conta. Tem atributos como CNPJ, razão social, setor, faturamento, número de funcionários, hierarquia (matriz/filial, grupo econômico). Em B2C puro, a conta pode ser pessoa física ou o conceito não se aplica.
Oportunidade (opportunity). Negócio em andamento. Tem valor estimado, estágio do funil, data prevista de fechamento, probabilidade. Sempre vinculada a uma conta e a um ou mais contatos. É a entidade que governa previsão de receita e governança comercial.
Atividade (activity). Interação registrada — chamada, email, reunião, tarefa. Pode estar vinculada a lead, contato, conta ou oportunidade. É a entidade mais volumosa em CRM ativo: empresa média gera dezenas de milhares de atividades por mês.
Caso (case). Solicitação ou problema de suporte/atendimento. Tem prazo (SLA), prioridade, status, dono. Vinculado a contato e conta. Quando o CRM cobre operação de pós-venda, caso vira tão importante quanto oportunidade.
Como as entidades se relacionam
Os relacionamentos entre entidades formam o esqueleto do modelo. Os principais:
Lead ? Contato ? Conta. Quando o lead é qualificado, vira contato vinculado a uma conta. Esse processo de "conversão" precisa ser desenhado: como o lead encontra a conta (lead-to-account matching)? Cria conta nova ou usa existente? O lead some ou fica histórico? Erros aqui geram duplicatas.
Conta ? Oportunidade. Toda oportunidade pertence a uma conta. Não há oportunidade flutuando — se há, é erro de modelo. Uma conta pode ter múltiplas oportunidades em paralelo (cross-sell, novos produtos).
Contato ? Oportunidade. Relação de muitos para muitos — uma oportunidade tem múltiplos contatos envolvidos (decisor, influenciador, comprador, usuário), e um contato participa de múltiplas oportunidades ao longo do tempo. Em Salesforce, é o objeto "OpportunityContactRole".
Atividade ? Tudo. Atividade se vincula polimorficamente — pode pertencer a lead, contato, conta ou oportunidade. Boa modelagem garante que atividade aparece nos quatro contextos quando deveria.
Caso ? Contato ? Conta. Caso sempre tem contato (quem abriu) e conta (de quem é o caso). Em B2C, contato é o cliente direto; em B2B, contato é a pessoa e conta é a empresa.
Hierarquia de conta: matriz, filial, grupo econômico
Em B2B, uma "empresa" raramente é entidade única. Há matriz, filiais, subsidiárias, holding, grupo econômico, joint ventures. Modelar hierarquia mal feita gera dois problemas crônicos: comercial não enxerga o tamanho real do cliente (vende para uma filial sem saber que a matriz já é cliente em outro produto), e relatórios executivos não conseguem agregar (qual é o faturamento total com o Grupo X?).
O padrão canônico usa relacionamento de parente/filho (parent/child) entre contas — uma conta tem um parent_account_id apontando para a conta-mãe, ou vazio se é matriz/standalone. Isso permite construir árvore hierárquica de qualquer profundidade.
Para grupo econômico — onde empresas com CNPJs distintos e nomes diferentes pertencem ao mesmo controle —, alguns modelos adicionam entidade extra "Grupo" com vínculo a contas. Útil em mercados como bancos, holdings industriais, varejo com múltiplas bandeiras. Exige curadoria contínua: a estrutura societária muda, e o modelo precisa acompanhar.
A regra prática: se o time comercial pergunta "qual o tamanho desse cliente?" e a resposta exige somar manualmente várias contas, o modelo de hierarquia está incompleto.
Para empresa com menos de 50 funcionários e ciclo simples, modelo canônico básico (lead, contato, conta, oportunidade, atividade) sem extensões. Hierarquia de conta opcional — só se faz sentido para o negócio. Use o que a plataforma entrega por padrão (HubSpot, RD Station, Pipedrive) e resista à tentação de criar campos personalizados. A cada campo novo, justifique o uso. Dívida técnica começa cedo.
Modelo canônico completo com hierarquia de conta para B2B. Em vendas baseadas em conta (ABM) ou ciclos com grupo econômico relevante, modele parent/child de conta desde o início. Crie comitê de schema com RevOps, marketing e vendas — qualquer pedido de novo campo passa pelo comitê. Documente o dicionário de campos. Em CRM com mais de 100 campos personalizados, faça auditoria semestral para apagar os não usados.
Modelo canônico + entidades estendidas (parceiro, ativo, contrato, assinatura). Multi-região e multi-moeda implementados desde o desenho. Arquiteto de soluções dedicado ao CRM. Plataforma de dados de cliente (CDP) consolida visão unificada além do CRM, com resolução de identidade entre fontes. Comitê formal de governança de dados se reúne mensalmente. Mudanças de schema seguem processo de gestão de mudanças (RFC, revisão, implantação em ambiente de homologação primeiro).
Atributos mínimos por entidade
Cada entidade tem conjunto mínimo de atributos que sustenta processos comerciais e de marketing. Os principais:
Lead. Nome, email, telefone, empresa (texto livre), cargo, origem (com_que_canal_chegou), status (novo, em_qualificação, qualificado, descartado), data_de_criação, dono. Atributos calculados úteis: pontuação (lead scoring), dias_em_qualificação.
Contato. Nome, sobrenome, email (com unicidade), telefone, cargo, departamento, conta vinculada, status (ativo, inativo, opt-out), preferências de comunicação, idioma, fuso horário. Em B2B, identificação do papel na decisão (decisor, influenciador, usuário).
Conta. Razão social, nome fantasia, CNPJ, setor (taxonomia controlada), faturamento, número de funcionários, endereço principal, conta-mãe (parent_account_id), status (cliente ativo, cliente inativo, prospect, parceiro), dono. Em multi-região: país, idioma, moeda.
Oportunidade. Nome, valor, moeda, estágio (taxonomia controlada do funil), probabilidade, data_prevista_de_fechamento, conta vinculada, produto principal, fonte_da_oportunidade, motivo_de_perda (quando aplicável), dono.
Atividade. Tipo (chamada, email, reunião, tarefa), assunto, data, duração, descrição, vínculo polimórfico (lead, contato, conta, oportunidade), dono.
Caso. Tipo, prioridade, status, data_de_abertura, prazo (SLA), contato e conta, descrição, resolução, dono.
Listas controladas e taxonomias
Campos como "setor", "estágio da oportunidade", "motivo de perda" e "origem do lead" devem ser listas controladas, não texto livre. Texto livre vira lixo em três meses: aparecem "Tecnologia", "TI", "Tech", "tecnologia da informação" como valores diferentes do mesmo conceito. Relatório não fecha.
Taxonomia controlada exige decisão prévia sobre quais valores existem, governança sobre quem pode adicionar novos valores, e revisão periódica para consolidar. Boa prática: a cada trimestre, revisar listas com mais de 30 valores e identificar candidatos a fundir.
Para setor, use taxonomia consagrada como CNAE (Classificação Nacional de Atividades Econômicas) no nível de divisão ou grupo. Para estágio do funil, mantenha lista curta (5-8 estágios) e mutuamente exclusiva. Para motivo de perda, lista de 8-15 motivos cobre 95% dos casos — o resto vira "outros" e é revisado.
Campos personalizados: quando criar objeto novo
Toda implantação de CRM enfrenta a tentação de criar campos personalizados para tudo. A pergunta certa é: esse atributo pertence a entidade existente ou merece entidade própria?
Adicione campo personalizado à entidade existente quando: o atributo tem cardinalidade um para um com a entidade (uma conta tem um CNPJ, um contato tem um cargo), o atributo é consultado junto com a entidade na maioria das vezes, e a estrutura não muda ao longo do tempo.
Crie objeto personalizado novo quando: a relação é de um para muitos ou de muitos para muitos (uma conta tem múltiplas filiais? Filiais não cabem como campo, vira objeto), o objeto tem ciclo de vida próprio (contrato tem data de início, data de fim, valor, renovação — não é campo, é objeto), ou o objeto se relaciona com múltiplas entidades.
Exemplos comuns de objetos personalizados em B2B: contrato, assinatura, ativo instalado, projeto, parceiro, evento. Em B2C: pedido, item de pedido, programa de fidelidade, membro.
Modelos B2B vs. B2C
O modelo canônico nasceu em B2B e exige adaptação em B2C. Diferenças principais:
Conta em B2C. Em B2C puro (comércio eletrônico, serviços para pessoa física), "conta" pode ser pessoa física. Salesforce chama esse padrão de "Person Account" — junta contato e conta na mesma entidade. Útil quando não há empresa relevante por trás do cliente.
Identidade unificada. Em B2C, é comum o mesmo cliente aparecer em múltiplos canais (comércio eletrônico, app, loja física) com identificadores diferentes (email, CPF, telefone, chave do programa de fidelidade). Plataforma de dados de cliente (CDP) resolve identidade — junta os identificadores em um perfil único. CRM tradicional não faz isso bem.
Oportunidade em B2C. Em comércio eletrônico, "oportunidade" raramente faz sentido — o cliente decide e compra em minutos. O conceito é substituído por "pedido" (order) como entidade central. Em serviços de B2C de alto valor (imóveis, automóveis, planos), oportunidade volta a existir.
Volume. B2B costuma ter milhares ou dezenas de milhares de contas. B2C tem centenas de milhares ou milhões de clientes. O modelo precisa escalar — campos com cálculos pesados, índices em campos consultados, particionamento por geografia ou data.
Erros comuns no modelo de dados
Campos demais. CRM com 300 campos personalizados, dos quais 60% nunca preenchidos. Cada campo é dívida — alguém vai consultar, alguém vai esperar preenchimento. Auditoria semestral apaga o que não é usado.
Hierarquia frouxa. Hierarquia de conta modelada como texto livre ("empresa-mãe: Grupo X") em vez de relacionamento de parente/filho. Relatórios não fecham.
B2C tratado como B2B. Forçar conta para cada cliente pessoa física em B2C de massa. Cria milhões de contas com um contato cada, infla armazenamento e custo de licença sem benefício.
Sem identidade única. Mesmo cliente aparece três vezes (uma por canal) sem reconciliação. Marketing manda email de boas-vindas para quem já é cliente há cinco anos. CDP ou processo de deduplicação resolve.
Texto livre em campos taxonômicos. "Origem do lead" como texto livre vira 200 valores distintos. Lista controlada desde o início.
Sem governança. Qualquer admin cria campo, qualquer integração mete dados novos, qualquer relatório customiza objeto. Em dois anos, ninguém entende o modelo. Comitê de schema com RevOps no centro.
Sinais de que seu modelo de dados precisa de revisão
Se três ou mais cenários abaixo descrevem seu CRM atual, é provável que o modelo esteja gerando atrito sistemático — vale priorizar auditoria e plano de remodelagem.
- Relatórios executivos exigem múltiplas junções (joins) para responder perguntas básicas.
- Hierarquia de empresa não é confiável — ninguém sabe o tamanho real do cliente.
- Lead-to-account matching é manual — vendedor cria conta nova porque não acha a existente.
- Campos do mesmo significado têm nomes diferentes em entidades diferentes ("cargo" e "job_title").
- Muitos campos com mais de 70% de valores vazios.
- Objetos personalizados foram criados sem critério — três objetos parecidos para conceitos semelhantes.
- É difícil identificar qual é o contato principal de uma conta ou oportunidade.
- O mesmo cliente aparece em múltiplos registros porque não há resolução de identidade.
Caminhos para desenhar ou revisar o modelo de dados
A decisão entre estruturar internamente ou contratar consultoria depende da maturidade técnica do time de RevOps, da complexidade do modelo (entidades estendidas, multi-região) e do estágio do CRM (implantação nova vs. remodelagem).
RevOps e administrador da plataforma desenham o modelo, documentam o dicionário de campos, estabelecem governança de schema e implementam na ferramenta. Equipe comercial e de marketing validam que o modelo cobre os processos.
- Perfil necessário: RevOps com experiência em CRM + administrador certificado na plataforma (Salesforce Admin, HubSpot Operations Hub)
- Quando faz sentido: modelo canônico padrão, complexidade baixa a média, equipe interna de RevOps consolidada
- Investimento: tempo do time (80-160h para desenho e implementação inicial) + certificações (R$ 1.500-4.000 por pessoa)
Consultoria especializada ou arquiteto de soluções da plataforma desenha o modelo, conduz oficinas com stakeholders, implementa em ambiente de homologação e treina a equipe interna. Em remodelagem, inclui plano de migração de dados.
- Perfil de fornecedor: consultoria de implantação de CRM (parceiros Salesforce, HubSpot, Dynamics), arquiteto de dados independente, consultoria de inteligência de negócios com prática de modelagem
- Quando faz sentido: modelo complexo (entidades estendidas, multi-região, B2B com hierarquia profunda), remodelagem em CRM ativo, ausência de RevOps maduro
- Investimento típico: projeto de desenho e implantação R$ 40.000-200.000; remodelagem com migração R$ 80.000-500.000
Seu modelo de dados de cliente foi desenhado ou foi acumulando ao longo do tempo?
O oHub conecta sua empresa a consultorias de inteligência de negócios, especialistas em arquitetura de CRM e parceiros de implantação (Salesforce, HubSpot, Microsoft Dynamics). Em poucos minutos, descreva seu desafio e receba propostas de quem entende o mercado brasileiro.
Encontrar fornecedores de Marketing no oHub
Sem custo, sem compromisso. Você recebe propostas e decide se e com quem avançar.
Perguntas frequentes
Quais são as entidades de um CRM?
O modelo canônico tem seis entidades centrais: lead (pessoa não qualificada), contato (pessoa qualificada com vínculo a empresa), conta (empresa ou organização), oportunidade (negócio em andamento), atividade (interação registrada — chamada, email, reunião) e caso (solicitação de suporte). Em empresas maiores, o modelo se estende com entidades como contrato, assinatura, ativo instalado, parceiro e pedido.
O que é conta (account) no CRM?
Conta é a entidade que representa uma empresa ou organização. Em B2B, é a entidade central — oportunidades, contatos, atividades e contratos pertencem a uma conta. Tem atributos como CNPJ, razão social, setor, faturamento e relacionamento de hierarquia (matriz, filial, grupo econômico). Em B2C puro, "conta" pode ser pessoa física (Person Account no Salesforce) ou o conceito pode não se aplicar.
Como modelar dados de cliente B2B?
Use modelo canônico completo: lead, contato, conta, oportunidade, atividade, caso. Implemente hierarquia de conta (parent/child) desde o início — fundamental para enxergar tamanho real de clientes com matriz e filiais. Modele relação muitos para muitos entre contato e oportunidade (vários decisores por negócio). Crie objetos personalizados para conceitos com ciclo próprio (contrato, projeto, parceiro). Estabeleça governança de schema com comitê.
Que campos são essenciais?
Para conta: razão social, CNPJ, setor (lista controlada), faturamento, número de funcionários, conta-mãe, status, dono. Para contato: nome, email único, telefone, cargo, conta vinculada, status, preferências de comunicação. Para oportunidade: nome, valor, moeda, estágio, probabilidade, data prevista de fechamento, conta, motivo de perda, dono. Resista à tentação de adicionar campos sem caso de uso claro — cada campo é dívida.
Como modelar hierarquia de empresas?
Use relacionamento de parente/filho entre contas: cada conta tem um campo parent_account_id que aponta para a conta-mãe (ou vazio se é matriz). Permite construir árvore hierárquica de qualquer profundidade. Para grupo econômico — empresas com CNPJs distintos e nomes diferentes mas mesmo controle —, alguns modelos adicionam entidade extra "Grupo" com vínculo a contas. Exige curadoria contínua: estrutura societária muda e o modelo precisa acompanhar.
Diferença entre B2B e B2C no modelo?
Em B2B, conta é a entidade central (empresa) e oportunidade governa negociações longas com múltiplos decisores. Em B2C puro, "conta" pode ser pessoa física e "oportunidade" raramente faz sentido — substituída por "pedido" como entidade central. Volume é diferente: B2B tem milhares de contas, B2C tem milhões de clientes — o modelo precisa escalar. Identidade unificada (resolução cross-canal via CDP) é crítica em B2C, opcional em B2B.
Fontes e referências
- Salesforce Architects. Data Architecture & Management — modelos de dados, hierarquia de conta e governança.
- HubSpot Developers. Understanding the CRM Data Model — entidades, atributos e relacionamentos.
- Microsoft Learn. Dynamics 365 — referência do modelo de dados e ERD de Sales e Customer Service.
- DAMA International. DAMA-DMBOK — Data Management Body of Knowledge, referência de modelagem e governança.
- Forrester Research. Relatórios sobre Customer Data Platforms (CDP) e resolução de identidade.