Higiene de Dados de RevOps: A Fundação Nada Glamourosa da Orquestração

Ninguém é promovido por deduplicar contas. Não existe demo de keynote para uma lista suspensa bem aplicada e nenhum slide de conselho celebrando que a maioria das oportunidades finalmente tem um timestamp de entrada de estágio. Higiene de dados é encanamento. Invisível quando funciona, cara quando não funciona, e cronicamente subfinanciada porque seu valor é defensivo.

Mas todo projeto que um líder de RevOps realmente quer trabalhar se apoia nesse encanamento. Atribuição, pontuação, forecasting, próxima melhor ação, a própria orquestração. Rode um bom modelo sobre dados sujos e você recebe respostas confiantes, precisas e erradas. Já vimos equipes gastarem meses em um modelo de pontuação e depois descobrirem que boa parte de suas contas eram duplicatas, o que significava que o modelo vinha aprendendo com históricos de atividade divididos o tempo todo. Higiene é a camada menos glamourosa da arquitetura da plataforma de receita moderna, e aquela da qual tudo o mais silenciosamente depende.

Quatro formas pelas quais os dados se deterioram

Dados de receita se deterioram de formas previsíveis, e cada uma tem uma correção diferente, então ajuda nomeá-las.

Duplicação. "Acme," "Acme Inc" e "Acme Corporation" existem porque três ferramentas criaram a conta de forma independente e nada as resolve. As contagens de pipeline inflam, o histórico de atividade se divide em três, e nenhum registro único diz nada.

Incompletude. Campos que você precisa para análise estão em branco. Se 30% das oportunidades não têm origem de lead, a atribuição por origem não é 30% incerta. É inutilizável, porque você não tem como saber se os 30% ausentes se parecem em algo com os 70% que você consegue ver.

Inconsistência. O mesmo conceito é codificado de forma diferente em cada sistema. "Closed Won" aqui, "Won" ali, "6 - Closed" no terceiro. Cada junção entre esses sistemas descarta ou conta errado linhas, e faz isso silenciosamente.

Obsolescência. O campo estava certo uma vez. O campeão saiu, o nível mudou, e ninguém atualizou. Dados obsoletos são os mais perigosos dos quatro porque parecem limpos. Há um valor no campo. Só que está errado.

A maioria dos "nossos números não batem" tem origem em um desses. Descobrir qual é metade do trabalho.

Limpezas não se sustentam

O instinto quando a instância está uma bagunça é agendar uma limpeza. Trazer um consultor, reservar um trimestre, construir uma planilha de mesclagens. Isso funciona exatamente pelo tempo que leva até chegar nova sujeira, o que geralmente é algumas semanas. Você não pode armazenar limpeza. Você só pode continuar restaurando-a.

Então o trabalho real acontece nos pontos onde os dados entram e se movem entre sistemas.

Valide no momento da escrita. Rejeite ou sinalize dados ruins quando são criados, não meses depois. Campos obrigatórios, restrições de formato e listas suspensas aplicadas impedem a maior parte da incompletude e inconsistência na porta.

Resolva entidades na ingestão. À medida que os registros fluem para a camada de dados compartilhada, combine-os com entidades canônicas naquele momento. Fazer isso uma vez, centralmente, é muito mais fácil do que fazer em cada ferramenta, e é um dos argumentos mais fortes para uma camada de dados compartilhada em vez de integrações ponto a ponto. Caso contrário, cada ferramenta deduplica do seu jeito e você tem quatro opiniões diferentes sobre quantas contas você tem.

Monitore continuamente. Acompanhe completude, duplicação e atualidade como métricas contínuas com alertas, da mesma forma que você observaria uptime. Um dashboard que diz "12% das oportunidades abertas não têm próximo passo" transforma um problema invisível em um que alguém precisa responder por.

Passar de limpeza periódica para um sistema permanente é a única mudança mais útil que a maioria das equipes de RevOps pode fazer, e é principalmente sobre onde a lógica de higiene vive, não sobre quão inteligente ela é.

Limpo o suficiente para o quê

Dados perfeitos são uma fantasia, e persegui-los é seu próprio modo de falha. A pergunta útil é se os dados estão limpos o suficiente para a decisão que alimentam. Os padrões deveriam depender do consumidor.

Forecasting executivo precisa de alta precisão em um conjunto estreito de campos (estágio, valor, data de fechamento) e pode tolerar bagunça em outros lugares.

Roteamento automatizado e write-back precisam de consistência acima de tudo, porque máquinas não aplicam julgamento. Um valor de lista suspensa com a caixa errada quebra a regra e ninguém percebe até que um negócio seja roteado para o representante errado. A camada de write-back é implacável com inconsistência upstream exatamente por isso.

Atribuição precisa de completude em pontos de contato e identificadores, já que lacunas distorcem todo o modelo. A espinha dorsal de atribuição depende disso inteiramente.

Anotar esses limiares evita que você lance análises que os dados não conseguem sustentar, e que você poliça campos que nenhuma decisão jamais lê.

Por onde começar

Se você está encarando uma instância bagunçada, sequencie por alavancagem.

Instrumente antes de limpar. Estabeleça métricas de completude e duplicação primeiro, para que você possa medir o progresso e mostrar a alguém o que o trabalho comprou.

Corrija a entrada antes do backlog. Impedir que nova sujeira entre importa mais do que limpar sujeira antiga, porque um backlog limpo se suja de novo se a entrada continua aberta.

Padronize listas suspensas e campos obrigatórios entre sistemas para que o mesmo conceito tenha a mesma codificação em todos os lugares. Essa é a vitória mais barata com o benefício downstream mais amplo.

E dê a isso um dono. Qualidade de dados sem dono não tem futuro. Uma pessoa ou equipe nomeada responsável pelas métricas de higiene vale mais do que qualquer ferramenta que você poderia comprar.

Nada disso é tecnicamente difícil. É organizacionalmente difícil, porque compete por atenção com trabalho visível e empolgante. As equipes que se mantêm limpas são as que tornam a higiene chata e automática em vez de heroica e periódica.

Principais conclusões

• Dados ruins vêm em quatro sabores: duplicatas, campos em branco, codificações inconsistentes e valores obsoletos. Cada um precisa de uma correção diferente, então diagnostique antes de agir.
• Limpezas trimestrais não se sustentam. Coloque a lógica de higiene no momento da escrita e na ingestão, e monitore como uptime.
• Resolva entidades uma vez, na camada compartilhada, em vez de deixar cada ferramenta deduplicar do seu jeito.
• "Limpo" depende do consumidor. Forecasting quer precisão, automação quer consistência, atribuição quer completude.
• A parte difícil é organizacional. Instrumente primeiro, feche a entrada, padronize e dê a isso um dono.

Plataformas de orquestração como a Revnewo só são tão boas quanto os dados canônicos sobre os quais rodam. Antes de investir em modelos mais sofisticados, vale a pena verificar se a fundação consegue sustentá-los.