Seu CRM não precisa ser preenchido. Ele precisa de um zelador.

Abra o CRM de qualquer time de vendas e conte a mesma pessoa três vezes. Uma vez como “Maria S.” com um Gmail pessoal, uma vez como “Maria Silva” com um endereço de trabalho, uma vez como um registro solitário de empresa sem contato nenhum. O deal está anexado a um deles. Ninguém sabe qual. O relatório de pipeline soma os três.

Isso não é um bug no software. É o software funcionando exatamente como projetado, um conjunto de campos vazios esperando que um humano os preencha, perfeitamente, para sempre, à mão.

Aqui está a coisa que ninguém quer dizer em voz alta: um CRM é um banco de dados que apodrece a menos que alguém o limpe, e você nunca contratou esse alguém. A cura não é um formulário melhor. Seu CRM não precisa ser preenchido. Ele precisa de um zelador, um agent cujo trabalho inteiro é manter os registros limpos enquanto você faz as vendas. Este post é sobre o que esse zelador de fato faz.

Por que o CRM apodrece, e por que nenhuma feature jamais consertou isso

A correção ingênua para um CRM sujo é a que todo fornecedor lança: deixe o formulário melhor. Campos obrigatórios. Dropdowns em vez de texto livre. Um asteriscozinho vermelho que não te deixa salvar até escolher uma indústria. Regras de validação. Um e-mail de cobrança na sexta: 12 registros sem número de telefone.

Parece higiene. Na verdade é fricção. Cada campo obrigatório é um pequeno pedágio que o vendedor paga no pior momento possível, no meio da ligação, no meio do deal, quando a única coisa que importa é o humano do outro lado da linha. Então ele faz o que qualquer pessoa racional faz sob um pedágio: paga o mínimo. Digita “asdf” no campo obrigatório. Escolhe a primeira opção do dropdown. Pula o registro inteiro e mantém as anotações reais na cabeça, onde o relatório não alcança.

O formulário nunca foi o problema. O problema é que higiene de dados é uma tarefa, e tarefas que dependem da disciplina de um humano ocupado não são feitas. Você não consegue consertar um problema de disciplina com um formulário mais rígido. Você só move a podridão para onde o formulário não vê.

Pense em como isso de fato se acumula. Suponha que um time de vendas típico adicione, digamos, algumas centenas de registros por trimestre. Um punhado são duplicatas, mesma pessoa, novo e-mail. Um monte chega meio-vazio porque o formulário foi preenchido às pressas. E cada um deles começa a decair no momento em que é salvo: o contato muda de emprego, a empresa é adquirida, o número de telefone desconecta. Pesquisas da indústria há muito apontam a deterioração de dados B2B em cerca de 30% ao ano (Gartner, via Validity), o que significa que um terço do seu CRM estará silenciosamente errado daqui a doze meses mesmo que ninguém o toque.

A resposta ingênua é um projeto de limpeza trimestral. Bloqueie uma sexta. Exporte para uma planilha. Aperte os olhos para ela. Faça o merge do que você aguentar. Ajuda por uma semana. Depois a podridão retoma, porque a limpeza foi um evento e a podridão é um processo. Você não consegue vencer um problema contínuo com uma solução ocasional.

O erro inteiro é tratar higiene como uma coisa que você faz em vez de um papel que alguém ocupa.

Os quatro trabalhos do zelador

Se higiene é um papel, o papel tem uma descrição de cargo. Um agent zelador observando seu CRM faz quatro coisas concretas, nenhuma das quais depende de um humano lembrar de fazê-las.

Trabalho um: faça dedup antes da duplicata nascer

O jeito ingênuo de deduplicar é depois do fato: rode um relatório de fuzzy-match, encontre os pares que parecem iguais, peça a um humano que confirme cada merge. É lento, é manual, e roda tarde, quando o relatório sinaliza “Maria S.” e “Maria Silva”, o deal já está dividido entre os dois e o merge é uma cirurgia.

O jeito do zelador é pegar a colisão na porta. Quando um novo contato está prestes a ser criado, o agent o checa contra o que já existe, não só correspondências exatas de e-mail, mas o mesmo humano vestindo um endereço diferente, a mesma empresa escrita de três jeitos. Se está confiante, ele faz o merge e mantém os dois endereços de e-mail no único registro. Se está incerto, ele não chuta; sinaliza o par e pergunta. A duplicata que nunca é criada é mais barata que a duplicata que você faz merge depois, e infinitamente mais barata que a que você nunca pega.

Trabalho dois: enriqueça o registro meio-vazio

Um registro chega com um nome e um e-mail e nada mais. A correção ingênua é fazer o vendedor ir achar o resto, a empresa, o cargo, a indústria, a faixa de quadro de pessoal. Ou comprar um fornecedor de enriquecimento de dados e acoplá-lo, pagando por consulta esteja o campo vazio ou não.

O zelador preenche os buracos que consegue preencher, a partir das fontes que você já tem. A assinatura de e-mail na thread diz “VP de Operações”. A empresa aparece em três outros deals. O domínio te diz a firma. Nada disso é inteligência exótica, é montagem. É o mesmo fato, espalhado pelo e-mail e pelo CRM existente, que ninguém se deu ao trabalho de coletar no único registro. O agent o coleta, e marca de onde cada valor veio, para que um humano possa confiar nele ou corrigi-lo.

Trabalho três: preencha a partir do rastro de e-mails

Este é o trabalho que paga a coisa inteira, e é o que um formulário nunca consegue fazer.

A história real de um relacionamento não mora no CRM. Ela mora na inbox, a thread onde o preço foi acordado, a mensagem onde o contato mencionou que estava saindo, a resposta onde o deal escorregou um trimestre. O CRM ingênuo pede ao vendedor que copie tudo isso à mão, o que significa que nunca acontece, o que significa que o CRM e a verdade se afastam até o CRM ser ficção.

O zelador lê o rastro e escreve o registro para frente. Uma reunião aconteceu; o próximo passo é registrado. O contato respondeu de um novo endereço; esse endereço se junta ao registro. A thread ficou quieta por três semanas; o agent nota a estagnação em vez de deixar o deal sentado verde e mentindo. O CRM para de ser uma coisa que você atualiza sobre o trabalho e vira uma coisa que se atualiza sozinha a partir do trabalho, porque o trabalho já deixou um rastro, e o rastro sempre foi legível por máquina.

Trabalho quatro: nunca deixe um registro apodrecer

Os primeiros três trabalhos são sobre deixar um registro limpo. O quarto é sobre mantê-lo limpo depois que você para de olhar.

A decadência é silenciosa. O contato muda de emprego e o e-mail começa a quicar, mas nada no CRM fica vermelho, então o registro fica ali parecendo saudável enquanto já está morto. O sistema ingênuo espera um humano perceber, geralmente quando uma campanha quica ou uma ligação não dá em nada. O zelador observa os sinais que a decadência deixa para trás, o quique, a resposta automática dizendo que alguém saiu, o trimestre de silêncio total no que está marcado como deal ativo, e os traz à tona enquanto ainda há tempo de agir. Um registro não apodrece de uma vez. Ele apodrece um sinal não-observado por vez, e um sistema que nunca para de observar pega cada um.

Por que um agent, e não só mais automação

Há uma versão mais branda dessa ideia, e vale nomeá-la porque é a que a maioria dos times busca primeiro. Vamos automatizar. Escreva uma regra: se um campo está vazio, busque-o. Se dois registros compartilham um e-mail, faça merge. Um construtor de workflow, alguns if-thens, pronto.

Funciona até o input ter uma dobra, o que é sempre. A regra que faz merge por e-mail correspondente não consegue ver que “Maria S.” e “Maria Silva” são a mesma pessoa com dois endereços, não há chave compartilhada para disparar. A regra que preenche o cargo a partir de uma assinatura quebra no momento em que a assinatura é uma imagem de logo em vez de texto. A regra que sinaliza um deal estagnado dispara num deal que estagnou por um bom motivo, e agora é ruído. Automação rígida lida com o caso que você antecipou e tomba no que você não antecipou, e dados de CRM não são nada além dos casos que você não antecipou.

A diferença é juízo. Uma regra executa; um agent decide. Quando o zelador não tem certeza se dois registros são a mesma pessoa, ele não faz merge e torce, ele sinaliza o par com seu raciocínio e pergunta. Quando não consegue ler o cargo de uma assinatura, ele tenta as outras threads, a página da empresa, os deals existentes, do jeito que uma pessoa faria. Quando um deal ficou quieto, ele pesa se quieto significa morto ou significa que o cliente está de férias. Uma regra só consegue fazer a coisa que você descreveu. Um agent consegue fazer a coisa que você quis dizer.

E, esta é a parte que importa para um sistema que toca seus dados reais de cliente, o agent trabalha dentro de um limite. Ele propõe um merge; não reescreve silenciosamente seu pipeline pelas suas costas. As jogadas destrutivas permanecem com trava. A Apollo é construído para que o zelador possa limpar continuamente mas não possa silenciosamente corromper: os consertos pequenos e seguros fluem, e qualquer coisa que possa perder dados espera por um aceno humano. Confiança num zelador autônomo não é um interruptor que você liga. É uma escada que você sobe, deixe-o fazer dedup e enriquecer primeiro, veja-o acertar, depois amplie o que ele pode tocar.

Quanto vale de fato um CRM limpo

É tentador medir isso em campos preenchidos e duplicatas mescladas. Essa é a unidade errada. A coisa que um CRM sujo te custa não é arrumação, são decisões tomadas sobre ficção.

A previsão que está errada porque três registros são um deal contado três vezes. A campanha que queima boa vontade num contato que saiu há um ano. O vendedor que entra numa ligação frio porque o histórico que o teria aquecido estava numa inbox que ninguém copiou. O novo contratado que herda um território e herda, junto, um banco de dados em que não pode confiar, então reconstrói o quadro do zero, na cabeça, onde vai apodrecer de novo no dia em que ele sair. Cada um desses é uma perda real, e nenhum deles aparece num score de “completude de dados”.

Um CRM limpo vale exatamente o que um mapa honesto vale para alguém navegando no escuro. Você não o nota quando está certo. Você só nota o precipício quando está errado.

A virada: pare de ser seu próprio zelador

Aqui está a parte que não é sobre software.

Agora mesmo, na maioria das empresas, a higiene de dados é feita, mal, tarde, com ressentimento, pelas pessoas que você menos quer fazendo isso. O vendedor registrando anotações fora do expediente em vez de vender. O líder de operações rodando a limpeza trimestral que se desfaz até a primavera. O founder que, no fundo, não confia no número do pipeline e por isso o reconta à mão antes de cada reunião de board, porque já foi queimado pela podridão antes.

Esse trabalho parece diligência. É um imposto. Cada hora gasta cuidando do banco de dados é uma hora não gasta no relacionamento que o banco de dados deveria servir. Você se tornou seu próprio zelador porque nenhum sistema ocupava o papel, então o papel caiu, como esses papéis sempre caem, sobre quem se importou o suficiente para notar a bagunça.

A promessa não é um CRM com menos campos vazios. É que o registro já está limpo quando você o abre, deduplicado, enriquecido, atual, preenchido a partir do rastro que você ia deixar de qualquer jeito, para que as pessoas mais capazes do time parem de manter o mapa e voltem a caminhar pelo território.

---

É isso que estamos construindo na Apollo: não um formulário mais rígido, mas um zelador que ocupa o papel que ninguém quis, mantendo a memória da empresa sobre seus clientes limpa enquanto todos os outros a usam. Se você já contou a mesma pessoa três vezes no seu próprio pipeline, você já sabe que o CRM nunca ia se limpar sozinho. Agora algo pode.