Modelo de dados do CRM: como desenhar em 7 decisões
O CRM configurado sem desenho acumula campos que ninguém explica e relatórios em que a diretoria não confia. As sete decisões do modelo de dados, do objeto à nomenclatura, o documento que registra quem preenche o quê e quando, e como validar o desenho com as áreas antes de configurar.
O modelo de dados do CRM é o desenho que define quais objetos a empresa registra, como empresa, contato, negócio, produto e ticket, quais propriedades cada objeto guarda, como os registros se ligam e por quais pipelines passam, e ele precisa estar escrito e aprovado pelas áreas antes de alguém abrir a tela de configuração. O desenho cabe em sete decisões e num documento de poucas páginas que diz, para cada informação que pesa numa decisão, em que objeto ela fica, quem preenche e em que momento. Pular essa etapa custa caro meses depois, quando relatórios, automações e integrações já dependem da estrutura configurada às pressas e mudar um objeto obriga a equipe a refazer o que construiu em cima. A empresa que implanta sem desenho termina com mais campos do que alguém consegue explicar e uma diretoria que volta à planilha para ter um número.
Nos diagnósticos que conduzo em CRMs que chegam para reestruturação, a primeira lista que peço é a das propriedades do negócio com data de criação e percentual de preenchimento, e ela costuma mostrar campos que ninguém abre mais e duplicados com nomes parecidos, criados a pedido, um por vez, sem um desenho que dissesse onde cada informação deveria ficar. A disciplina de desenhar antes de construir tem cinquenta anos na computação: em 1976, Peter Chen propôs o modelo entidade-relacionamento como técnica de desenho de bancos de dados, separando as coisas que a organização registra, os relacionamentos entre elas e os atributos de cada uma (Chen, 1976). O vocabulário do CRM é a versão comercial dessa ideia.
O que é o modelo de dados do CRM?
O modelo de dados é o mapa da informação comercial dentro do CRM. Objeto é o tipo de coisa que a empresa registra, com tela, lista e relatórios próprios, e registro é cada ocorrência dele, como uma empresa da base com o seu CNPJ. Propriedade é a informação guardada em cada registro, o campo da tela. Associação é o vínculo entre registros, e o rótulo de associação diz que papel esse vínculo representa, como o contato que é decisor num negócio. Pipeline é a sequência de etapas por onde um registro passa, com critério para avançar.
As sete decisões seguem essa ordem: objetos padrão, objetos personalizados, propriedades, associações, pipelines, nomenclatura e o documento de desenho. A fronteira entre objeto e propriedade é a decisão que mais pesa, porque define o que a empresa consegue contar, filtrar e somar depois.
Por que desenhar o modelo antes de implantar ou reestruturar?
A ordem que protege o projeto vai do desenho ao dicionário de dados, depois à configuração, à migração e às integrações. A integração com o ERP mapeia propriedades que precisam existir com o tipo certo, a migração precisa de um de-para entre campo antigo e novo, e o relatório da diretoria só sai se a informação estiver num formato que ele consiga agrupar. Corrigir no papel custa uma reunião, e depois da virada custa reconfiguração e painéis refeitos.
Na reestruturação, o trabalho começa pelo inventário do que existe, com o preenchimento de cada propriedade e os relatórios e automações que dependem dela. O desenho novo nasce das decisões de negócio, e o inventário entra depois, para montar o de-para que a migração de CRM vai executar.
Quais objetos padrão o CRM precisa ter?
Quase toda operação B2B começa com os objetos padrão, os que a plataforma traz prontos, com relatórios e automações preparados para eles. Quando o CRM conversa com o ERP, o código do produto no catálogo precisa ser o mesmo do faturamento, e o desenho diz qual dos dois sistemas cria e mantém o catálogo.
| Objeto | O que representa | Pergunta que responde |
|---|---|---|
| Empresa | A organização que compra ou pode comprar, identificada por CNPJ ou domínio | Quanto cada conta e cada segmento representam na receita |
| Contato | A pessoa com quem a empresa se relaciona | Quem decide, quem usa e quem paga em cada conta |
| Negócio | Uma oportunidade de receita, com valor, etapa e data | Quanto entra, quando e com que chance |
| Produto e item de linha | O catálogo e as linhas de cada negócio, com quantidade, preço e desconto | O que a empresa vende, a que preço e com que desconto |
| Ticket | Uma solicitação do cliente que alguém precisa resolver | Quanto cada conta pede e qual motivo concentra problemas |
Quando criar um objeto personalizado?
O objeto personalizado é um tipo de registro que a empresa cria quando nenhum objeto padrão representa algo que ela precisa acompanhar. Eu aprovo a criação quando a coisa existe por conta própria, uma empresa pode ter várias dela ao mesmo tempo e ela tem ciclo próprio, com datas, situação e responsável que mudam sem que a empresa ou o negócio mudem. Contrato com vigência e renovação passa nesse teste, assim como unidade atendida numa rede, equipamento instalado no cliente e matrícula numa escola.
Se a informação descreve um registro que já existe, como porte ou região, ela é propriedade. Se marca um momento da venda, como a proposta enviada, ela é etapa ou atividade. Cada objeto personalizado precisa de propriedades, permissões, relatórios e mapeamento nas integrações, e em algumas plataformas depende do plano contratado, por isso a pergunta de negócio precisa justificar esse custo.
Como definir as propriedades de cada objeto?
Cada propriedade responde a uma pergunta que alguém vai fazer ao CRM, e o desenho registra essa pergunta antes de criá-la. A propriedade que nasce sem ela vira campo que ninguém explica.
Qual tipo de propriedade escolher?
O tipo define o que a empresa consegue fazer com o dado: texto não soma e data em texto não filtra por período.
| Tipo | Quando usar | Exemplo |
|---|---|---|
| Lista de seleção única | Classificação que vira filtro ou agrupamento | Segmento, porte, motivo de perda |
| Seleção múltipla | Mais de um valor vale ao mesmo tempo, sem entrar em soma | Produtos de interesse |
| Número e moeda | Quantidade ou valor que entra em conta, com unidade e período no rótulo | Valor do negócio, número de funcionários |
| Data | Momento que alguém vai filtrar ou medir, separando previsto de realizado | Data prevista de fechamento, início da vigência |
| Sim ou não | Condição com duas respostas e um significado definido para o vazio | Exige cadastro de fornecedor |
| Usuário | Pessoa responsável dentro da empresa, uma propriedade por papel | Dono da conta, CSM |
| Texto | Identificador único ou contexto que ninguém agrupa | CNPJ, resumo da reunião |
| Calculada | Valor derivado de outras propriedades, com fórmula documentada | Valor anual a partir do mensal |
Obrigatoriedade no momento em que a pessoa tem a informação
A propriedade obrigatória na criação do registro produz dado inventado, porque o vendedor não sabe o valor do negócio no primeiro contato. No desenho, a obrigatoriedade fica amarrada à etapa ou ao evento em que a informação existe. A regra de campos por etapa está em qualidade de dados no CRM.
Lista fechada em vez de texto livre
Toda informação que a liderança vai filtrar, agrupar ou comparar entra como lista, com os valores escritos na sessão de desenho com as áreas. Cada valor tem um rótulo, que o time lê, e um valor interno, que integrações e relatórios usam. O rótulo pode mudar com o vocabulário do mercado, e o valor interno fica estável, porque alterá-lo quebra filtros salvos e mapeamentos de integração.
Um único escritor para cada propriedade
Cada propriedade tem uma fonte: uma pessoa, uma integração ou uma automação. Quando o ERP manda no status financeiro do cliente, o CRM mostra o valor em modo de leitura, senão a sincronização seguinte apaga a correção que o vendedor fez à mão. O desenho marca o sistema mestre e a direção de cada dado que vem de fora, e os fluxos entre os dois sistemas estão em integração CRM e ERP.
Associações e rótulos de associação: como ligar os registros?
A associação define quais registros se conectam e quantos de cada lado. Um negócio se liga a uma empresa principal, a vários contatos e a vários itens de linha. Um contato pode estar ligado a mais de uma empresa, como o diretor que trocou de emprego, e um ticket se liga à empresa e a quem abriu o chamado. O desenho escolhe a associação que manda nos relatórios, como a empresa principal do negócio, que decide em que conta a receita aparece.
O rótulo diz o papel do vínculo. Entre negócio e contato, os rótulos descrevem o comitê de compra, como decisor, influenciador, usuário, compras e jurídico, e a liderança passa a filtrar os negócios em proposta sem decisor associado; o mapeamento desse grupo está em comitê de compra B2B. Entre empresas, os rótulos registram matriz e filial, grupo econômico, revenda e cliente final. Numa rede em que a matriz assina e as unidades usam o serviço, a receita fica na matriz, os tickets nas unidades, e o relatório da conta soma as duas pontas pela associação.
Pipelines e etapas: onde entram no modelo?
O pipeline pertence a um objeto. O negócio tem o pipeline de venda nova e, quando a decisão do cliente muda, o de renovação e expansão, e o ticket tem a fila de atendimento. No desenho, cada etapa carrega o critério de saída, as propriedades que passam a ser obrigatórias, quem pode mover o registro e a automação que a mudança dispara. O método para escrever critérios pela decisão do comprador está em funil de vendas B2B. Vendedor, região e canal funcionam melhor como propriedade e filtro do que como pipeline próprio.
Como nomear objetos, propriedades e valores?
Cada propriedade tem dois nomes. O rótulo aparece na tela e segue a linguagem do time, e o nome interno, usado por integrações, automações e exportações, segue um padrão técnico e não muda depois de criado, porque a integração aponta para ele.
O documento de desenho: objeto, propriedades-chave, quem preenche e quando
O documento de desenho registra as decisões numa tabela que a diretoria lê em poucos minutos e que o administrador usa para configurar. Ele traz as propriedades-chave, aquelas que alimentam relatório, passagem de bastão, integração ou regra. O modelo abaixo é o ponto de partida que adapto com cada operação, com um objeto personalizado de contrato como exemplo.
| Objeto | Propriedade-chave | Tipo | Quem preenche | Quando | Relatório ou decisão que usa |
|---|---|---|---|---|---|
| Empresa | CNPJ | Texto com validação | SDR ou enriquecimento | Na criação | Duplicidade e cruzamento com o ERP |
| Empresa | Segmento | Lista única | SDR | Antes da qualificação | Conversão por segmento |
| Empresa | Dono da conta | Usuário | Liderança de vendas | Na distribuição da carteira | Carteira e comissão |
| Contato | Nível do cargo | Lista única | Marketing ou SDR | Na qualificação | Critério de lead e cobertura do comitê |
| Negócio | Valor | Moeda, calculada pelos itens | Vendedor | Na proposta | Forecast |
| Negócio | Data prevista de fechamento | Data | Vendedor | Na proposta, revisada toda semana | Reunião de pipeline |
| Negócio | Motivo de perda | Lista única por etapa | Vendedor | Ao marcar como perdido | Análise de perdas |
| Ticket | Categoria | Lista única | Atendimento | Na abertura | Volume por motivo e por conta |
| Contrato | Início e fim da vigência | Data | Integração do ERP | Na assinatura | Renovações do trimestre |
O documento tem mais duas peças: o diagrama das associações, com uma caixa por objeto e os rótulos escritos em cada linha, e a lista de pipelines com etapas, critérios de saída e propriedades obrigatórias. O dicionário de dados completa o conjunto, fixando o que cada termo e cada campo desse modelo significa para o negócio, com regra de cálculo, fonte e dono.
Como validar o modelo de dados com as áreas?
As exceções aparecem quando alguém tenta registrar um cliente de verdade no modelo novo. Nas implantações que acompanho, o teste com casos reais é o que mais muda o desenho, porque o cliente que comprou por uma revenda ou o contrato assinado pela matriz para várias unidades surge no caso e não surge em nenhuma reunião de levantamento. A versão que passa nos testes recebe número e data, a diretoria assina, e só então o administrador configura.
| Teste | Como fazer | Quem participa | Aprovado quando |
|---|---|---|---|
| Casos reais | Percorrer no papel dez clientes do último ano, do primeiro contato à renovação | Vendas, marketing e CS | Cada informação do caso tem objeto e propriedade |
| Relatórios da diretoria | Cada liderança lista os relatórios da reunião mensal | Lideranças e diretoria | Cada relatório sai do modelo sem planilha paralela |
| Passagem de bastão | Simular a entrega do lead a vendas e do cliente ganho ao CS | SDR, vendedor e CSM | A área seguinte encontra o que precisa numa propriedade com dono |
| Integrações | Marcar as propriedades que vêm de outro sistema | TI e operações de receita | Cada propriedade tem um único escritor |
| Dados pessoais | Revisar a finalidade de cada propriedade com dado pessoal | Encarregado de dados e jurídico | Nenhum dado pessoal sem finalidade escrita |
| ## Quem é dono do modelo de dados do CRM? |
| Papel | O que faz no modelo | O que aprova |
|---|---|---|
| Diretoria, como patrocinadora | Define prioridades e arbitra conflitos entre áreas | A versão final e mudanças que afetam relatório oficial |
| Responsável pelo modelo, em operações de receita ou na administração do CRM | Escreve o desenho, mantém o documento e recebe os pedidos de mudança | Propriedades novas, valores de lista e nomenclatura |
| Lideranças de marketing, vendas e CS | Dizem quais decisões precisam de dado e cobram o preenchimento | Propriedades, listas e etapas da própria área |
| TI | Responde por integrações, acesso e segurança | Mapeamentos de integração e perfis de acesso |
| Encarregado de dados e jurídico | Conferem finalidade e necessidade de cada dado pessoal | Propriedades com dado pessoal |
O pedido de propriedade nova chega ao responsável pelo modelo com a pergunta de negócio, o relatório que vai usar o valor, quem preenche e quando. Ele procura antes uma propriedade existente que responda à mesma pergunta e decide na reunião mensal com as lideranças.
Erros comuns ao desenhar o modelo de dados do CRM
Copiar a planilha antiga
A planilha do time vira, coluna por coluna, o conjunto de propriedades do negócio. Ela misturava empresa, contato e contrato numa linha, e o CRM herda a mistura, com decisor em texto e produto escrito à mão. Use as colunas como lista de requisitos e deixe o desenho decidir em que objeto cada uma mora.
Criar um campo para cada pedido
Cada área pede o seu campo, o administrador atende, e em um ano o negócio tem propriedades que só uma pessoa preenche. Quando o campo guarda dado pessoal, o excesso tem peso legal: a LGPD exige propósitos “legítimos, específicos, explícitos e informados ao titular” e limita o tratamento “ao mínimo necessário para a realização de suas finalidades” (Lei 13.709/2018, art. 6º, incisos I e III).
Texto livre onde a liderança vai precisar de filtro
O campo de texto parece flexível na configuração e cobra o preço no primeiro relatório, com o segmento escrito de cinco jeitos e um histórico que alguém vai padronizar registro a registro. Na sessão de desenho, pergunte se alguém vai filtrar, agrupar ou comparar a informação, e se a resposta for sim, a propriedade nasce como lista.
Forçar tudo para dentro do negócio
Contrato, implantação e chamado viram negócios em pipelines improvisados, porque o negócio é o objeto que o time conhece. O relatório de pipeline passa a somar receita nova com renovação e reclamação, e o forecast mistura coisas que não se somam. O que tem ciclo próprio depois da venda pede ticket ou objeto personalizado.
Capacitação: quem precisa aprender o quê
O responsável pelo modelo aprende a escolher tipos, montar associações, avaliar pedidos e manter o documento. As lideranças aprendem a ler o desenho, a saber qual propriedade alimenta cada relatório que levam à diretoria e a cobrar o preenchimento na reunião da equipe. Vendedores, SDRs, marketing e CS aprendem o que preenchem, quando e para quem aquele dado serve, no CRM já configurado com o modelo aprovado, e recebem uma atualização curta a cada mudança relevante.
Roteiro de 30 dias para a liderança
- Dias 1 a 3: nomeie o patrocinador e o responsável pelo modelo. Escreva o que o responsável aprova e comunique às áreas.
- Dias 4 a 7: liste decisões e relatórios. Cada liderança traz os relatórios da reunião mensal e as perguntas que hoje não consegue responder; na reestruturação, rode também o inventário das propriedades.
- Dias 8 a 12: desenhe objetos e associações, aplicando o teste de ciclo próprio a cada candidato a objeto personalizado.
- Dias 13 a 17: preencha o documento de desenho com as propriedades-chave, os tipos, quem preenche, quando e os valores de cada lista.
- Dias 18 a 21: escreva pipelines, etapas e nomenclatura, com critério de saída e propriedades obrigatórias por etapa.
- Dias 22 a 26: valide com casos reais e corrija o desenho onde algum caso não coube.
- Dias 27 a 30: aprove a versão 1 e abra o fluxo de pedidos. A diretoria assina e o administrador configura a partir do documento.
Se a sua empresa vai implantar ou reestruturar o CRM e ninguém sabe dizer onde cada informação deve morar, esse é o trabalho do treinamento in company de adoção de CRM. Eu conduzo a formação com as lideranças, o responsável pelo modelo e cada papel que registra, sobre os casos e os relatórios da sua operação. A turma sai com o guia de boas práticas de CRM, com objetos, propriedades e nomenclatura desenhados, e com o manual de gestão de carteira e base, que define dono de conta, associações e a rotina que mantém o modelo de pé.
Perguntas frequentes
O que é modelo de dados do CRM?
É o desenho que define quais objetos o CRM registra, quais propriedades cada um guarda, como os registros se associam e por quais pipelines passam. Ele fica escrito num documento aprovado pelas áreas antes da configuração e orienta integrações, migração e relatórios.
Quando criar um objeto personalizado no CRM?
Quando a coisa que a empresa precisa acompanhar existe por conta própria, aparece várias vezes na mesma conta e tem ciclo próprio, com datas, situação e responsável. Contrato, unidade atendida e equipamento instalado costumam passar nesse teste. Se a informação só descreve um registro existente, ela é propriedade.
Qual a diferença entre modelo de dados e dicionário de dados?
O modelo de dados mostra a estrutura: objetos, associações, pipelines e as propriedades-chave com quem preenche e quando. O dicionário fixa o que cada termo e cada campo significa para o negócio, com regra de cálculo, fonte e dono. O modelo vem antes da configuração, e o dicionário acompanha a operação depois.
Quantas propriedades um objeto do CRM deve ter?
Nenhum número serve de régua; o critério vale mais que a contagem. Cada propriedade precisa de uma pergunta de negócio, de alguém que preencha e de um relatório ou regra que use o valor, e a que falha nesse teste sai na revisão do modelo.
Dá para mudar o modelo de dados depois que o CRM está em uso?
Dá, com custo maior a cada mês de uso, porque relatórios, automações e integrações dependem da estrutura. A mudança passa pelo responsável pelo modelo, com análise do que depende dela, plano para o histórico e aviso aos papéis afetados.
Como preparar o time para trabalhar com o novo modelo de dados?
Treine cada papel no CRM já configurado, mostrando o que ele preenche, em que momento e qual relatório ou área usa aquele dado. As lideranças passam antes pela formação, porque são elas que cobram o registro na reunião da equipe. Repita uma atualização curta a cada mudança relevante no modelo.
Quer levar isso para o seu time?
No treinamento in company de Adoção de CRM, cada papel aprende a usar o CRM na própria rotina e o time sai com o guia de boas práticas e o manual de carteira.
Outros textos sobre o mesmo assunto.

Resultado de treinamento: como medir em 4 níveis e 90 dias
A pesquisa de satisfação mede a aula e deixa a diretoria sem saber se o funil mudou. Como medir o resultado de um treinamento de vendas, de CRM ou de IA nos quatro níveis de Kirkpatrick e no ROI de Phillips, com linha de base, grupo de comparação e painel de 90 dias.
18 min de leituraLeia mais
Health score de clientes: 6 sinais e como calibrar
O health score avisa o risco de cancelamento meses antes quando junta uso, relacionamento, chamados, pagamento, patrocinador e NPS com pesos tirados dos cancelamentos passados. Como calibrar, o que o CS faz em cada faixa e como montar o score no CRM.
18 min de leituraLeia mais
Governança de IA: 4 níveis de risco e quem aprova cada uso
A maioria das diretorias não sabe dizer quantas IAs a empresa usa nem em que decisões elas pesam. Governança de IA é o sistema que responde a isso: inventário de casos de uso, classificação por risco, donos com nome, ciclo de aprovação, monitoramento, contratos e capacitação.
18 min de leituraLeia mais