1) Defina o “dono” dos campos (e quem aprova)
Escolha um responsável claro (normalmente RevOps/CRM Ops) e um pequeno comitê de aprovação quando o campo impactar mais de uma área (Vendas, Marketing, CS, Financeiro). Sem isso, cada time cria o seu campo “do jeito que dá” e a base vira um mosaico impossível de reportar.
2) Crie um formulário padrão de solicitação de campo
Toda solicitação precisa responder: objetivo do campo, quem usa, em qual objeto (Contato/Empresa/Negócio/Atendimento), tipo (texto, número, lista), valores permitidos, se será obrigatório e quais relatórios/automação dependem dele. Solicitação sem contexto vira campo morto em poucos meses.
3) Padronize nomenclatura e semântica (o que o campo realmente significa)
Defina um padrão simples: prefixos por área quando necessário, nomes no singular, sem abreviações internas, e descrição obrigatória. O erro mais comum não é “campo demais”; é campo com nome ambíguo (ex.: “Fonte”, “Origem”, “Canal”) representando coisas diferentes.
4) Registre no dicionário de dados (com exemplos)
Mantenha um dicionário com: nome técnico, nome amigável, descrição, exemplos válidos, lista de valores, regras de preenchimento, dependências (relatórios, integrações, automações), e responsável. Isso reduz briga entre times e acelera onboarding.
5) Controle mudanças como produto: versionamento e janela de alteração
Toda alteração (renomear, trocar tipo, mudar lista de valores, tornar obrigatório) deve ter: motivo, impacto esperado, plano de testes e data de publicação. Se o CRM não tiver “release notes”, crie um changelog interno: é o que evita surpresa em dashboards e integrações.
6) Estabeleça critérios para tornar campo obrigatório (sem travar o time)
Campo obrigatório só quando: (a) há decisão operacional ligada a ele (roteamento, SLA, compliance), (b) existe definição objetiva do valor, e (c) o momento certo de coleta é claro. Caso contrário, o time inventa qualquer coisa para passar de etapa — e você ganha ‘dados’ que não valem nada.
7) Rode auditorias de “campo zumbi” (uso real, não opinião)
Uma vez por ciclo (mensal/trimestral, conforme volume), liste campos com baixa taxa de preenchimento, campos duplicados por sinônimo e campos que não alimentam nada (nenhum relatório/automação/regra). Quando o CRM não entrega métricas perfeitas de uso, combine sinais: preenchimento, presença em formulários, dependência em relatórios e reclamações de usuários.
8) Deprecie antes de apagar: migração + convivência controlada
Processo seguro: marcar como “DEPRECATED”, tirar de telas principais, bloquear para novos registros quando possível, mapear substituto, migrar dados (batch/ETL quando necessário), atualizar relatórios/automações e só depois remover. Apagar direto é receita para quebrar histórico e relatórios legados.
Perguntas frequentes
O que é “campo zumbi” no CRM?
Quando devo criar um novo campo em vez de usar uma tag ou nota?
Quem deve aprovar a criação de campos: TI, RevOps ou o time de Vendas?
É seguro apagar campos antigos do CRM?
Leia também
Campo personalizado no CRM: o que criar (e o que não criar) para não sujar a base
Guia editorial sobre campo personalizado no CRM: critérios práticos para criar só o que vira decisão/segmentação, evitar texto livre, padronizar valores e manter a base limpa sem matar a adoção do time.
Ler →
Como criar um changelog de campos e automações no CRM (sem parar o time)
Guia prático para criar um changelog (registro de mudanças) no CRM: o que anotar, quem aprova, como versionar campos e automações e como auditar sem virar burocracia.
Ler →
Rotina de qualidade de dados no CRM: como implantar sem parar as vendas
Guia prático para criar uma rotina de qualidade de dados no CRM (padronização, duplicidade, obrigatórios, auditoria e governança) sem interromper vendas e atendimento.
Ler →