Skip to content

Por que todos os projetos de limpeza de CRM regridem em seis meses

A RevOps consegue o orçamento, uma consultora executa um sprint de seis semanas, os duplicados fecham-se, os relatórios melhoram. Seis meses depois os duplicados estão de volta. Uma nota sobre por que a limpeza é manutenção, não um projeto, e o que a higiene contínua realmente exige.

Rai Chadee
Rai Chadee
3 min de leitura
Equipa de RevOps a rever analíticas de CRM no ecrã

Já vi este padrão em cinco empresas. A RevOps consegue um orçamento para um projeto de limpeza de CRM. Uma consultora ou um prestador entra, executa um sprint de seis semanas e entrega uma auditoria que fecha 3.000 duplicados, normaliza 60% dos campos de texto livre e produz um relatório de 40 páginas com um trimestre de recomendações. A equipa de dados celebra. Os relatórios melhoram de forma mensurável. As previsões ficam mais limpas durante algumas revisões de pipeline. A equipa avança para o próximo projeto.

Seis meses depois os duplicados estão de volta, os campos de texto livre voltaram a desviar-se, e a apresentação usada para explicar por que os números de pipeline não batem certo é a mesma que se usou seis meses antes.

Por que os projetos regridem

A auditoria corrige os dados existentes. Não corrige o sistema que produziu os dados maus em primeiro lugar.

As importações continuam a acontecer com formatos incompatíveis. Os formulários web recolhem texto livre em campos que deveriam ser listas de seleção. Os AE que trabalham um negócio fora da plataforma durante um sprint nunca sincronizam o registo de volta e, quanto mais antigo fica o negócio, menos provável é que alguém o limpe. As operações de marketing lançam uma nova campanha com as suas próprias convenções de campos, porque ninguém lhes disse que as convenções tinham sido reestandardizadas há três meses. Cada uma destas é uma fonte fresca de desvio, e nenhuma foi abordada no âmbito do projeto.

O enquadramento honesto é que a limpeza é manutenção, não um projeto. Os projetos têm uma data de fim e o trabalho deixa de acontecer. A manutenção é uma carga contínua de que alguém é dono para sempre, e fingir o contrário é o que produz o próximo projeto de limpeza.

O que «contínuo» realmente parece

A higiene mantém-se entre limpezas quando três peças estão no lugar. Normalmente estão em falta.

Uma camada de regras que corre na escrita. Valida o formato, verifica contra a lista de seleção, faz correspondência aproximada com contas existentes e, ou aceita o registo, ou encaminha a exceção para uma fila. Sem ela, o novo desvio chega mais depressa do que o desvio antigo é resolvido, e a fila é insondável desde o primeiro dia.

Uma fila de exceções com dono, com uma pessoa nomeada e um horário recorrente. Não «como parte do seu papel» de forma abstrata — efetivamente na agenda de alguém, todas as terças-feiras às 10h. As empresas que mantêm a qualidade dos dados entre limpezas têm todas isto. As que regridem tratam a fila como um esforço best-effort, o que significa que recebe o tempo que sobra depois de tudo o resto, o que significa que não recebe tempo nenhum.

A qualidade dos dados reportada como uma métrica de primeira classe — taxa de duplicados, completude dos campos, contagem de registos obsoletos — num dashboard que o responsável de RevOps revê com uma cadência normal. Se esses números ficarem invisíveis entre projetos, já está a delinear a próxima limpeza antes de alguém voltar a olhar.

O nosso playbook de limpeza de dados de CRM está construído em torno de tornar essas três peças sustentáveis sem criar uma nova posição de colaborador.

A versão deste trabalho que não regride é aquela que previne o desvio no ponto de entrada. A versão de limpeza regride sempre.