Como Projetar seu Modelo de Dados de CRM Antes de Mexer no Software

Uma equipe de vendas SaaS de 40 pessoas reconstruiu seu modelo de dados de CRM duas vezes em 12 meses. A primeira construção levou três semanas para configurar. A segunda reconstrução aconteceu porque descobriram, no meio do segundo trimestre, que seu modelo de contatos não conseguia suportar múltiplos contatos por negócio com papéis diferentes. A terceira tentativa, feita no papel antes de abrir o CRM, está rodando sem alterações estruturais há 18 meses.

Essa terceira tentativa começou com um whiteboard, não com um notebook.

A lição central: toda implementação de CRM que desmorona o faz porque alguém começou a clicar antes de pensar. Contatos vs. Leads vs. Contas vs. Negócios: os relacionamentos entre esses objetos determinam o que você pode reportar, o que pode automatizar e como seu Pipeline funciona. Erre isso e você passa o terceiro trimestre migrando dados que inseriu no primeiro trimestre.

Este guia orienta você a projetar um modelo de dados de CRM no papel antes de configurar um único campo.

Etapa 1: Liste seus Objetos de Negócio Principais

Comece com os quatro objetos padrão que todo CRM entrega:

  • Contatos: Pessoas individuais com quem sua equipe interage
  • Empresas (Contas): As organizações às quais os contatos pertencem
  • Negócios (Oportunidades): Processos de venda ativos com uma data de fechamento e valor
  • Atividades: Ligações, e-mails, reuniões, tarefas (o registro de interação)

Antes de adicionar qualquer coisa, valide que esses quatro cobrem 90% do seu processo de vendas. Geralmente cobrem. A tentação de adicionar objetos customizados é forte. Resista até provar que os objetos padrão não conseguem lidar com o caso de uso.

Objetos customizados valem a complexidade apenas quando:

  • Você está rastreando algo que não é uma pessoa, empresa ou negócio (ex.: ativos físicos, entregáveis de projetos, instalações de produtos)
  • A estrutura de relacionamento é fundamentalmente diferente de contato-empresa-negócio
  • Você tem 3 ou mais campos que se aplicam exclusivamente a essa entidade

No Salesforce, objetos customizados são poderosos, mas adicionam overhead de licenciamento e manutenção — o guia do Salesforce para objetos customizados cobre a configuração e as considerações de permissão. No HubSpot, objetos customizados estão disponíveis nos planos Enterprise e são cada vez mais capazes. No Pipedrive, objetos customizados não existem da mesma forma. Você usa campos customizados nos objetos existentes.

Se você não está no Salesforce Enterprise ou HubSpot Enterprise, não projete seu modelo em torno de objetos customizados. Projete para o que o CRM consegue suportar.

Etapa 2: Mapeie os Relacionamentos

Desenhe isso antes de abrir o CRM. Você precisa entender a cardinalidade: quantos de um objeto podem se relacionar com quantos de outro.

Relacionamentos padrão a definir:

Relacionamento Tipo Observações
Contato → Empresa Muitos-para-Um Um contato pertence a uma empresa (padrão)
Contato → Empresa Muitos-para-Muitos Um contato trabalha com múltiplas empresas (recurso Accounts do Salesforce, Associations do HubSpot)
Contato → Negócio Muitos-para-Muitos Múltiplos contatos podem estar em um negócio (compra por comitê)
Negócio → Empresa Muitos-para-Um Um negócio pertence a uma empresa
Atividade → Contato Muitos-para-Um Atividades são registradas em um único contato
Atividade → Negócio Muitos-para-Um Atividades são registradas em um único negócio

A pergunta não óbvia: um contato pode pertencer a múltiplas empresas? Na maioria das vendas B2B, isso acontece quando alguém é membro do conselho em duas empresas, ou quando você está vendendo para uma holding com múltiplas subsidiárias.

O Salesforce lida com isso via Account Relationships e Contact Roles. O HubSpot adicionou suporte a multi-associação em 2022 — a documentação do HubSpot sobre associações explica como rotular tipos de relacionamento entre objetos. O Pipedrive lida com isso de forma menos elegante. Você pode associar uma pessoa a múltiplos negócios, mas a empresa principal é singular.

Se seu processo de vendas frequentemente envolve contatos que pertencem a múltiplas contas, projete seu modelo em torno disso antes de configurar. Se for raro, trate-o como caso especial em suas notas em vez de adicionar complexidade ao modelo de dados para isso. Entender como cada CRM lida com associações de forma diferente pode evitar uma reconstrução dolorosa mais adiante.

Etapa 3: Defina o Que Fica em Cada Objeto

Para cada objeto, liste os campos. Não pule esta etapa em favor de "descobriremos durante a configuração". Não vai funcionar. Você adicionará campos reativamente e acabará com 80 campos no terceiro mês.

Para cada campo, defina:

  1. Nome: Como ele se chama. Seja consistente com as convenções de nomenclatura e decida agora entre Title Case e sentence case.
  2. Tipo: Texto, lista de seleção, número, data, checkbox, fórmula, lookup
  3. Obrigatório?: Sim ou Não. Mantenha esta lista curta.
  4. Finalidade: Reportar sobre ele, segmentar por ele, disparar automação com ele ou exibir para representantes

Um exemplo de definição do objeto Contato:

Campo Tipo Obrigatório Finalidade
Primeiro Nome Texto Sim Exibição
Sobrenome Texto Sim Exibição
E-mail Texto Sim Sincronização de e-mail, automação
Telefone Texto Não Exibição
Cargo Texto Não Exibição
Fonte do Lead Lista de seleção Sim Relatório, automação
Status do Lead Lista de seleção Sim Roteamento, relatório
Adequação ao ICP Lista de seleção Não Segmentação
Data da Última Atividade Data (sistema) — Gerada pelo sistema
Responsável pelo Contato Lookup → Usuário Sim Roteamento

E um objeto Negócio:

Campo Tipo Obrigatório Finalidade
Nome do Negócio Texto Sim Exibição
Estágio do Pipeline Lista de seleção Sim Pipeline, previsão
Data de Fechamento Data Sim Previsão
Valor do Negócio Moeda Sim Relatório
Tipo de Negócio Lista de seleção Sim Segmentação
Motivo da Perda Lista de seleção Não (obrigatório no fechamento perdido) Relatório
Conta Lookup → Empresa Sim Relacionamento
Contato Principal Lookup → Contato Sim Relacionamento
Categoria de Previsão Lista de seleção Não Previsão

Este é exatamente o trabalho que evita que a conversa sobre campos customizados saia dos trilhos. Veja o guia de campos customizados para o modelo de decisão para cada solicitação de campo.

Etapa 4: Construa os Valores de Lista de Seleção em Equipe

É aqui que começa a qualidade ruim dos dados: um representante digita "Serviços Financeiros" no campo de setor, outro digita "Fintech", outro digita "Banco e Finanças". Agora seu relatório de setor é inútil.

Listas de seleção impõem consistência. Mas só funcionam se os valores forem projetados para relatórios, não apenas para entrada de dados.

Listas de seleção principais a definir antes do go-live:

Fonte do Lead: De onde os contatos entram no CRM. Valores de exemplo: Inbound Web, SDR Outbound, Indicação, Parceiro, Evento, Download de Conteúdo, Anúncio Pago, Cadastro em Trial. Mantenha esses no nível da fonte, não "Anúncio Facebook - Nome da Campanha - Março 2026." Valores no nível da fonte permanecem limpos. O nível de campanha pertence à sua ferramenta de atribuição de marketing.

Setor: Use uma taxonomia consistente. Comece com 10 a 12 valores e resista a pedidos de adição de mais nos primeiros 90 dias. SaaS, Serviços Financeiros, Saúde, Manufatura, Serviços Profissionais, Varejo, Mídia, Educação, Sem Fins Lucrativos, Outros.

Motivo da Perda: Esses são críticos para o aprendizado, mas quase sempre uma bagunça. Bons motivos de perda são honestos e acionáveis: Sem Orçamento, Escolheu Concorrente (nomeado), Sem Decisão, Timing, Perfil Inadequado, Sumiu. Evite opções vagas como "Outro" como catch-all.

Estágio do Pipeline: Defina esses com cuidado. Veja o guia de estágios de Pipeline para como construir estágios em torno de marcos do comprador em vez de atividades do representante.

Tipo de Negócio: Novo Negócio, Expansão, Renovação, Reativação. Se você só vende um tipo, pule isso. Se tem múltiplos processos, este campo separa seu Pipeline em Funnels distintos.

Para cada lista de seleção, defina: quem é o responsável pelos valores, como novos valores são adicionados (processo de aprovação ou aberto) e o que acontece com valores antigos quando não são mais precisos (arquivar, não excluir).

Etapa 5: Projete para Relatórios, Não Apenas para Entrada de Dados

Aqui está o teste para cada campo: se você não consegue consultá-lo ou agrupá-lo em um relatório, não o armazene como texto livre.

"Notas do cliente" como campo de texto é útil para um representante lendo contexto antes de uma ligação. É inútil para qualquer análise agregada. "Ponto de Dor" como campo de texto livre significa que você nunca saberá que 60% dos seus negócios mencionam "processos manuais" como o problema central. Ninguém consegue analisar 2.000 entradas de texto.

Quando alguém pede um campo de texto livre, pergunte: você vai querer algum dia contar quantos negócios se enquadram em diferentes categorias deste campo? Se sim, deve ser uma lista de seleção. Se for narrativa contextual genuína, texto está bom. Mas pertence à seção de notas ou ao registro de atividade.

Campos de fórmula são úteis, mas exigem manutenção. Se o valor de um campo pode ser calculado a partir de outros campos (ex.: Dias no Estágio = Hoje - Data de Entrada no Estágio), use uma fórmula. Mas campos de fórmula no Salesforce têm limites e no HubSpot exigem o Operations Hub Professional — a documentação de propriedades de fórmula do HubSpot mostra o que é suportado em cada plano. Conheça as capacidades de campos de fórmula do seu CRM antes de projetar um modelo que depende delas.

Etapa 6: Documente o Modelo em uma Planilha de Schema

Antes de configurar qualquer coisa, documente seu design em uma planilha simples. Uma aba por objeto, colunas para: nome do campo, tipo de campo, obrigatório, valores (para listas de seleção) e finalidade.

Uma planilha de schema básica tem:

  • Aba de Definições de Objeto: Lista de todos os objetos, sua finalidade e se são padrão ou customizados
  • Aba de Relacionamentos: Cada relacionamento objeto-a-objeto com a cardinalidade anotada
  • Abas de Definições de Campos: Uma por objeto com o formato de tabela acima
  • Aba de Valores de Lista de Seleção: Cada lista de seleção e cada valor, com uma nota sobre quem é o responsável

Este documento se torna sua especificação de implementação. Seu admin de CRM configura a partir dele. Sua equipe revisa antes do go-live. Seu gestor consegue lê-lo sem abrir o CRM.

Mantenha a planilha de schema em um drive compartilhado, não apenas na sua cabeça. Admins de CRM mudam. Seu eu do futuro vai agradecer.

Como Isso Difere por CRM

Antes de fechar seu schema, vale revisar como o modelo de dados do Rework se compara à estrutura de objetos padrão do Salesforce — especialmente se você está considerando uma opção mais leve.

Salesforce: O modelo de dados do Salesforce é o mais poderoso e o mais complexo. Os objetos padrão são Leads, Contatos, Contas e Oportunidades. O processo de conversão de Lead para Contato exige design deliberado. Quando um Lead se torna um Contato com uma Conta e Oportunidade associadas? Essa transição é uma fonte comum de confusão. Objetos customizados e relacionamentos customizados estão disponíveis na maioria dos planos de licença, mas exigem expertise de Admin ou Desenvolvedor para configurar corretamente.

HubSpot: O modelo padrão do HubSpot é Contatos, Empresas, Negócios e Tickets. O recurso de Associações (disponível em todos os planos pagos) permite relacionamentos multi-objeto, mas tem limites nos tipos de associação em planos inferiores. O HubSpot não tem um objeto Lead por padrão. Contatos cumprem esse papel, o que simplifica o modelo, mas exige campos claros de Status do Lead e Lifecycle Stage para rastrear a progressão. Objetos customizados são apenas para Enterprise.

Pipedrive: O Pipedrive mantém o modelo simples: Pessoas, Organizações, Negócios, Atividades. Não suporta objetos customizados. Os relacionamentos são diretos e há menos flexibilidade, mas também menos para dar errado. Se seu processo de vendas é relativamente padrão, a simplicidade do Pipedrive é uma vantagem. Se você precisa de hierarquia complexa de contas ou papéis de contato em negócios, você vai atingir seus limites.

Close: O Close usa Leads como objeto de nível superior, com Contatos abaixo deles. Isso difere da maioria dos CRMs e exige adaptação se você está migrando do Salesforce ou HubSpot. O modelo é adequado para vendas internas, mas menos flexível para estruturas complexas de contas enterprise.

Armadilhas Comuns

Muitos campos customizados no primeiro dia. A média de CRMs tem 80% dos campos não utilizados dentro de 6 meses. Comece enxuto — 15 a 20 campos por objeto — e adicione apenas quando houver uma necessidade demonstrada de relatório ou automação. Você sempre pode adicionar campos. Limpar 60 campos não utilizados e os dados ruins neles é um projeto.

Proliferação de listas de seleção. Quando múltiplas pessoas podem adicionar valores a listas de seleção sem um processo de governança, você acaba com 12 versões de "Serviços Financeiros" no campo de setor. Defina a propriedade das listas de seleção antes do go-live. Uma pessoa aprova novos valores.

Construir para o caso especial. Um representante tem um negócio com quatro contatos, cada um com um papel diferente. Isso é real, mas não é o caso comum. Não projete todo o seu modelo de dados em torno da exceção. Trate o caso comum de forma limpa e documente como tratar o caso especial manualmente.

Não envolver as pessoas certas na revisão do schema. A planilha de schema deve ser revisada por pelo menos um representante (isso corresponde à forma como trabalho?), um gestor (consigo construir os relatórios que preciso?) e uma pessoa de finanças (os dados do negócio suportam nossa previsão?). RevOps construindo o modelo isoladamente é como você acaba com um modelo que satisfaz a ferramenta, mas não o negócio. O modelo de maturidade de RevOps é contexto útil aqui — ele mapeia quais decisões de design de dados exigem propriedade centralizada versus contribuição da equipe.

O Que Fazer em Seguida

Pegue a planilha de schema que você construiu e apresente-a a três pessoas: um representante, um gestor e uma pessoa de finanças ou operações. Dê a cada um deles uma pergunta para responder: "Com base neste modelo, você consegue fazer o que faz com mais frequência no seu fluxo de trabalho de CRM?" Se alguém disser não, corrija o modelo antes de abrir o software.

Depois disso, leia o guia de campos customizados para obter um modelo de decisão para cada solicitação de campo que chegar durante a implementação. E haverá muitas.

Saiba Mais