Ícaro Iasbeck
Frameworks e metodologias

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.

18 min de leitura

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

  1. Dias 1 a 3: nomeie o patrocinador e o responsável pelo modelo. Escreva o que o responsável aprova e comunique às áreas.
  2. 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.
  3. Dias 8 a 12: desenhe objetos e associações, aplicando o teste de ciclo próprio a cada candidato a objeto personalizado.
  4. Dias 13 a 17: preencha o documento de desenho com as propriedades-chave, os tipos, quem preenche, quando e os valores de cada lista.
  5. Dias 18 a 21: escreva pipelines, etapas e nomenclatura, com critério de saída e propriedades obrigatórias por etapa.
  6. Dias 22 a 26: valide com casos reais e corrija o desenho onde algum caso não coube.
  7. 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.

  • Modelo de dados do CRM
  • CRM
  • Arquitetura de dados
  • Implantação de CRM
Do texto para a prática

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.

Levar Adoção de CRM para o meu time