Padronização de campos no CRM

Por que CRM degrada — e onde a degradação começa

CRM novo, recém-implantado, parece organizado. Seis meses depois, o campo "Setor" tem 73 valores únicos para 800 clientes ("Tecnologia", "TI", "tecnologia da informação", "Tecnologia ", "TECNOLOGIA"). O campo "Cidade" virou bagunça com variações de acento, abreviações e estado misturado. "Cargo" tem 200 valores ("Diretor", "Diretora", "Diretor Comercial", "Diretora de Vendas", "Dir. Comercial"). Segmentar virou impossível; relatórios precisam de limpeza manual cada vez; e ninguém confia mais nos dados.

A degradação não acontece por má fé. Acontece porque o CRM foi configurado com campos texto livre onde deveria haver lista controlada, sem máscara de entrada, sem regra clara de quando criar campo novo, sem governança. Cada pessoa preenche do jeito que entende — e cada jeito é ligeiramente diferente.

Este artigo defende uma tese simples: lista controlada deve ser o padrão, texto livre só onde a variabilidade legítima exige. Ensina governança de catálogo de campos, naming, validação na entrada e como migrar campos legados com segurança. O custo de implantar disciplina hoje é muito menor que o custo de limpar bagunça acumulada por anos.

Texto livre versus lista controlada: a decisão de origem

Quando você cria um campo, a primeira decisão é se ele aceita qualquer texto ou se restringe valores a uma lista pré-definida. Essa escolha determina 80% do destino do campo.

Texto livre permite ao usuário digitar qualquer coisa. Vantagem: flexibilidade absoluta. Desvantagem: variabilidade inevitável (acento, abreviação, sinônimo, erro de digitação). Use texto livre só quando: o conteúdo é genuinamente único por registro (nome do cliente, observação livre, descrição de oportunidade) ou quando lista controlada seria longa demais para manter (acima de 100 valores).

Lista controlada (picklist) apresenta opções pré-definidas. Vantagem: consistência garantida, segmentação confiável, validação automática. Desvantagem: requer manutenção do catálogo (adicionar valores, descontinuar valores). Use lista controlada para: setor, estado, status (de oportunidade, de contato), origem do contato, tipo de negócio, faixa de tamanho da empresa, idioma, fuso horário. Tudo que tem conjunto finito conhecido deve ser lista controlada.

Lista controlada com múltipla escolha permite ao usuário selecionar mais de um valor. Use com cuidado: tem custo de relatório (precisa de função que abre cada valor) e tendência a inflar (usuário marca tudo para não pensar). Bom uso: tags de interesse de produto, fontes múltiplas de aquisição. Mau uso: campos onde só um valor deveria valer.

Lookup (vínculo) aponta para outro registro (Conta ? Contato, Oportunidade ? Conta). Não é texto, é referência. Garante integridade: muda o nome da conta uma vez, todos os contatos refletem a mudança.

Regra prática: ao criar campo novo, pergunte primeiro "este conteúdo tem conjunto finito conhecido?". Se sim, lista controlada. Se a resposta é "talvez, depende" ou "sim, mas pode crescer", lista controlada com processo de mudança. Texto livre só quando a resposta é claramente "cada registro é único".

Padrão de nomenclatura: como evitar caos de nomes

Nome de campo é detalhe técnico, mas detalhe que decide se uma operação é navegável ou virou labirinto. Operação madura define padrão e segue.

Prefixo por área. Campos de marketing começam com mkt_ ou marketing_; de vendas, com sales_ ou vendas_; de pós-venda, com cs_ ou sucesso_. Vantagem: quem precisa só dos campos de marketing filtra por prefixo. Desvantagem: campos compartilhados ficam ambíguos (origem é de marketing ou vendas?). Estabeleça regra: o prefixo é da área que cria o campo, não da que usa.

Caso de escrita: snake_case ou camelCase. Defina um e siga. Mistura (alguns campos data_ultimo_contato, outros dataUltimoContato) gera bug em integração e relatório. Salesforce e HubSpot têm padrão próprio em campos de sistema; campos personalizados sigam o padrão da plataforma para consistência.

Evite abreviação. data_ult_cont economiza caracteres mas confunde quem chega depois. Use data_ultimo_contato. Espaço em disco é grátis; tempo de quem decifra abreviação não é.

Use português ou inglês — não misture. Empresa multinacional padroniza em inglês; empresa brasileira pura pode usar português. O que não pode é alternar: data_last_contact, tipo_lead, customer_segment no mesmo CRM. Misturado é o pior de dois mundos.

Rótulo amigável + nome técnico. A maioria dos CRMs permite separar nome técnico (mkt_setor_principal__c) de rótulo exibido ("Setor principal"). Use isso: nome técnico segue padrão rígido, rótulo é amigável ao usuário.

Validação na entrada: filtro antes da bagunça

Lista controlada resolve metade do problema. A outra metade é validação ativa em texto livre que precisa seguir formato.

Máscara em campos de formato conhecido. CNPJ (00.000.000/0000-00), CPF, CEP, telefone, data. Não aceite "11999998888"; force "(11) 99999-8888". Não aceite "27/2024"; force "27/02/2024". Configurável em formulário (HubSpot, RD Station, Salesforce com regras de validação).

Validação contra base externa. CNPJ pode ser validado contra a API da Receita Federal (existem serviços que fazem isso e enriquecem com razão social, atividade, capital social). CEP pode ser validado contra base do Correios. E-mail pode passar por validador (e-mails descartáveis bloqueados, sintaxe correta exigida).

Regex em campos com padrão. Código de produto interno, número de pedido, identificador de cliente — qualquer campo com formato definido pode ser validado por expressão regular. Bloqueia entrada inválida na origem.

Lista de domínios proibidos. Em B2B, e-mails pessoais (Gmail, Outlook, Yahoo) tipicamente não representam contato qualificado. Lista de bloqueio em formulário evita captação de baixo valor — ou pelo menos sinaliza para o vendedor que aquele contato chegou via canal pessoal.

Validação cruzada. Regra que liga dois campos: se "Tipo de cliente" = "Pessoa Física", esconder campo CNPJ e mostrar CPF. Se "Estado" = "SP", oferecer lista de cidades de SP em vez de todas. Reduz erro e fricção ao mesmo tempo.

Obrigatoriedade: trade-off completude versus fricção

Cada campo obrigatório é simultaneamente garantia de completude e fonte de fricção. Operação amadora marca tudo como obrigatório; operação amadora oposta marca quase nada. Operação madura calibra por tipo de registro.

Campos sempre obrigatórios: identificador (nome, e-mail), regra de unicidade (CNPJ em conta, e-mail em contato). Sem isso, o registro não tem âncora.

Campos obrigatórios por estágio. Um contato recém-capturado em formulário precisa só de nome + e-mail. Quando vira oportunidade qualificada, exigir cargo, telefone, tamanho da empresa, setor. Cada estágio acrescenta requisitos. Configurável via regras de validação que rodam quando o registro muda de status.

Campos críticos para segmentação. Se "Setor" e "Tamanho da empresa" são base de toda segmentação, devem ser preenchidos antes de qualquer ação de marketing. Não obrigatório em captura inicial (atrapalha conversão), mas obrigatório antes de entrar em jornada.

Campos opcionais. Tudo o mais. Inclui campos "nice to have" que enriquecem o registro mas não bloqueiam operação se ausentes.

Regra prática: cada campo obrigatório precisa ter justificativa registrada ("este campo é obrigatório porque..."). Sem justificativa, vira opcional. Auditoria semestral remove obrigatoriedade de campos pouco preenchidos ou pouco usados.

Catálogo de campos: o documento vivo

Sem catálogo de campos, ninguém lembra por que aquele campo existe, quem criou, o que é para preencher. Catálogo é o documento que responde, para cada campo, sete perguntas:

1. Nome técnico (exatamente como aparece no banco).
2. Rótulo visível (como aparece para o usuário).
3. Tipo (texto livre, lista controlada, número, data, lookup, fórmula).
4. Valores possíveis (se lista controlada — lista completa, com data da última atualização).
5. Definição (o que significa esse campo, com exemplo).
6. Quem preenche e quando (formulário web? vendedor? sistema externo via API?).
7. Dono (pessoa ou função responsável por manter a definição e os valores).

Ferramentas: Notion, Confluence, planilha compartilhada (mínimo), ferramentas dedicadas (Atlan, Collibra, Alation para grandes operações). O importante não é a ferramenta, é manter atualizado. Catálogo desatualizado é pior que catálogo nenhum — gera falsa confiança.

Regra de criação de campo novo: ninguém cria campo personalizado sem antes registrar no catálogo (nome, definição, valores, dono, uso documentado). Sem essa porta, o CRM acumula campos órfãos que ninguém sabe o que são.

Migração de campos legados: como deprecar sem trauma

Toda operação madura herda campos antigos: criados por alguém que não está mais lá, preenchidos só nos primeiros meses, substituídos por outros campos sem que o original fosse removido. Remover esses campos é doloroso porque sempre há risco de quebrar relatório ou integração. Estratégia em fases:

Fase 1 — descoberta. Listar todos os campos personalizados com: percentual de preenchimento (quanto da base tem valor), última data de criação/modificação, uso em relatórios e automações. Campos com menos de 5% de preenchimento e zero uso em relatórios são candidatos a sunset.

Fase 2 — comunicação. Anunciar campos em fase de descontinuação para o time. Renomear com prefixo _DEPRECATED_ ou _legado_. Manter visível mas marcado. Prazo típico: 90 dias.

Fase 3 — bloqueio de novos preenchimentos. Tornar o campo somente leitura. Quem tinha o hábito de preencher precisa decidir: ou usa o campo novo que substitui, ou registra ausência da necessidade.

Fase 4 — ocultar. Esconder o campo de telas e formulários, mas manter no banco. Relatórios antigos ainda funcionam. Prazo típico: 6 meses nessa fase.

Fase 5 — remover. Após ninguém reclamar, remover de vez. Backup dos valores em arquivo separado, caso futuramente seja necessário recuperar.

Erro comum: pular fases e remover campo direto. Resultado: integração quebrada, relatório antigo gerando erro, vendedor perdendo informação importante. Migração em fases custa tempo mas evita crise.

Erros comuns que destroem qualidade de CRM

Campo "Setor" com 100+ valores únicos. Texto livre onde deveria haver lista controlada. Cada vendedor digita diferente. Resultado: impossível segmentar por setor.

Mesmo conceito em campos diferentes. "Cargo", "Função", "Posição" — três campos para a mesma informação, preenchidos parcialmente em cada um. Consolidar e descontinuar dois.

Campo "Observação" como tudo. Vendedor coloca telefone alternativo, data de aniversário, nome do filho, preferência de contato — tudo em um único campo de texto livre. Informação valiosa que ninguém consegue extrair. Criar campos específicos para o que se repete.

Campo "Outros" como majoritário. Lista controlada de origem com opção "Outros", e 60% dos contatos caem em "Outros". Sinal de que a lista está incompleta ou mal mantida. Auditar e revisar.

Criação de campo sem dono. Alguém cria campo personalizado em um arroubo, esquece, e o campo fica órfão. Processo de criação com dono obrigatório evita isso.

Listas controladas que crescem sem limite. "Setor" começou com 12 valores, hoje tem 87 — porque cada vendedor pediu para adicionar uma variação. Auditar trimestralmente e consolidar.

Naming inconsistente. data_ultimo_contato, ultimoContatoData, last_contact coexistindo. Quebra integração e relatório. Padrão único, aplicado retroativamente quando possível.