Terça-feira. O gerente comercial abre o Bitrix24 para entender por que 34 cards estão parados na etapa “Proposta Enviada” há mais de 15 dias. Quer cruzar por segmento de mercado — campo criado na implantação para “entender o perfil do cliente”.

De 34 cards: 26 em branco. Cinco com “outros”. Três com algo utilizável.

O filtro não serve. A reunião acontece sem dado. O gerente fecha o Bitrix24 e conclui que o CRM não dá visibilidade.

O problema real: o campo nunca teve dono. Nunca foi obrigatório em nenhuma etapa. Nunca apareceu em relatório que alguém de fato abrisse. Estava ali — com nome bonito, sem nenhuma função.

Campo sem uso operacional vira poeira.

—

O que o Bitrix24 permite fazer

O Bitrix24 oferece campos personalizados para leads, negócios, contatos, empresas e orçamentos. Tipos disponíveis: texto, número, lista, data, sim/não, moeda, link, endereço, arquivo, vínculo com usuário, entre outros.

Além de criar campos, o sistema permite torná-los obrigatórios — para todas as etapas do funil ou para etapas específicas. Um negócio pode exigir o preenchimento de “Fonte do lead” antes de avançar para “Em negociação”. O vendedor só move o card quando o campo estiver preenchido.

Isso resolve parte do problema. Só parte.

A obrigatoriedade garante preenchimento — não garante utilidade. Campo obrigatório mal posicionado vira atrito sem retorno. A decisão começa antes de criar o campo.

—

A pergunta que vem antes

Eu ouço variações do mesmo argumento em toda implantação: “Precisamos capturar isso para depois.” O segmento do cliente. O faturamento estimado. O horário preferido de contato.

Depois nunca chega. O campo fica vazio. O gestor conclui que o CRM não está funcionando.

A pergunta que resolve isso não é sobre o campo. É sobre o relatório que o campo alimenta.

Você consegue me mostrar um relatório que usa esse campo para tomar uma decisão comercial hoje — não amanhã, não quando o time estiver treinado, hoje?

Se a resposta for não, o campo não está pronto para existir. Não porque o dado seja inútil. Porque a operação ainda não tem rotina que o sustente.

Criar o campo antes da rotina é construir arquivo morto.

—

Os critérios antes de criar

Cinco perguntas. Três “não” ou “não sei” e o campo não deve ser criado agora.

1. Quem preenche — e em qual momento do processo, não “quando lembrar”? Campo sem momento definido no fluxo é campo aguardando a boa vontade do vendedor. Boa vontade não é processo.

2. Se ficar em branco, alguém percebe e cobra em menos de 48 horas? Sem supervisão ativa, campo vazio é padrão — não exceção. O monitoramento precisa existir antes da cobrança.

3. Esse dado aparece em relatório ou filtro que muda alguma decisão real? Não “pode aparecer”. Não “vai aparecer quando o processo amadurecer”. Aparece — em reunião que já acontece, em análise que alguém já faz.

4. Existe gatilho, automação ou obrigatoriedade de etapa que force o preenchimento no momento certo? Sem mecanismo que enforça, o campo é opcional por natureza — independente de qualquer orientação dada ao time.

5. Se remover esse campo em 90 dias, alguém vai sentir falta — ou o cartão vai ficar mais limpo? Essa pergunta separa campo que serve de campo que dá sensação de controle.

—

Quando usar

O campo existe quando existe processo que o alimenta e relatório que o consome.

Distribuidora com entrega: campo de endereço tem dono (logística), tem momento (fechamento do negócio), tem uso (rota de despacho ou integração com sistema externo). Ele sobrevive.

Empresa de serviços B2B que qualifica leads por porte: campo de faturamento estimado faz sentido se aparecer no relatório de conversão por faixa — e se o pré-vendas tiver roteiro que captura esse dado na primeira conversa.

A regra é simples: campo existe quando a operação sustenta o campo.

—

Quando NÃO usar

Quando a decisão de criar parte de uma intuição de implantação — “vamos capturar isso porque pode ser útil”.

Quando não há etapa definida para o preenchimento. Quando o relatório que vai consumir o dado ainda precisa ser criado. Quando o time está sendo treinado e ainda não tem cadência de registro.

Criar campo antes de ter operação que o suporte é como instalar painel de controle antes de a máquina funcionar. O painel fica ali. Sem nada para medir.

—

Exemplo aplicado

Uma gestora de distribuidora criou 23 campos personalizados no cartão de negócio durante a implantação. Endereço de entrega, horário preferido de contato, segmento, faturamento estimado, tipo de produto mais comprado — tudo parecia necessário na hora de configurar.

Seis meses depois: 17 desses campos estavam vazios em mais de 90% dos cartões. Os vendedores preenchiam nome, telefone e empurravam o card de etapa. O restante ficou ali.

Ela ligou dizendo que o CRM não estava funcionando.

Aplicamos os cinco critérios retroativamente. De 23 campos, 6 passaram em pelo menos três perguntas. Os outros 17 foram desativados. O cartão ficou mais limpo. A operação continuou igual — ninguém sentiu falta de nenhum deles.

O CRM não estava com problema. Estava com excesso de configuração sem operação por trás.

—

Erros que eu vejo o tempo todo

Campo criado por analogia com outro projeto. “Na empresa anterior tinha esse campo.” A empresa anterior tinha outro processo, outro time, outro estágio de maturidade. Campo copiado sem critério é campo órfão desde o primeiro dia.

Obrigatoriedade usada como atalho para preenchimento. Tornar o campo obrigatório sem definir momento e responsável gera atrito imediato: o vendedor preenche “n/a”, “a confirmar” ou qualquer coisa que desbloqueie o card. O campo fica preenchido — e inútil.

Relatório que nunca ninguém abre. O dado existe no CRM. O relatório existe no Bitrix24. Ninguém abre porque a reunião de pipeline roda em outro lugar, com outro formato, sem aquele filtro. Dado não acessado não é dado operacional. É dado arquivado.

Confundir arquitetura com operação. Cartão visualmente completo não é CRM funcionalmente completo. A sensação de controle vem da configuração — não da operação. Esses dois estados parecem iguais na tela. Na prática, são opostos.

—

Regra de ouro

Não é falta de dado. É excesso de campo sem dono.

Campo tem que trabalhar pela operação, não decorar o cartão. Quando o dado não alimenta decisão, não aparece em reunião, não tem responsável e não tem momento definido — ele não é informação. É campo vazio com nome bonito.

Dado duplicado cobra juros. Campo abandonado também.

—

Aplicação prática

Esta semana, abra o CRM e liste todos os campos personalizados dos cartões de negócio.

Para cada campo, responda: nas últimas quatro semanas, esse campo apareceu em algum relatório, filtro ou análise que gerou uma decisão?

Campos que não passarem nessa pergunta entram em revisão. Não apague ainda — marque como candidato a desativação. Valide com quem usa o CRM diariamente. Se ninguém defender o campo com um caso concreto de uso, desative.

Menos campo. Mais dado real.

—

Se o seu Bitrix24 tem mais campos do que relatórios que a equipe abre na reunião semanal — vale conversar antes de criar mais.

A arquitetura do cartão começa pelo processo. Não pela tela de configuração.

—

Fonte técnica de apoio

• Campos personalizados no CRM — Bitrix24 Helpdesk
• Como tornar um campo obrigatório em um cartão de CRM — Bitrix24 Helpdesk
• Bitrix24 Helpdesk