Português

Auditoria de Dados Pós-Migração: O Que Verificar e Quando

Um time de RevOps aprovou sua migração numa sexta-feira à tarde. A importação foi concluída sem erros. As contagens de linhas pareciam razoavelmente corretas. O time foi para casa.

Seis semanas depois, uma campanha de marketing foi lançada e enviou 14.000 e-mails. Taxa de rejeição: 11%. O motivo: 11% dos contatos tinham campos de e-mail em branco no novo CRM. A importação havia falhado silenciosamente para registros em que os dados de origem tinham endereços de e-mail em um formato de coluna ligeiramente diferente. O log de erros os havia sinalizado, mas ninguém o havia lido.

Seis semanas de representantes registrando chamadas, atualizando negócios e construindo Pipeline em cima de 11% de registros de contato ruins. A limpeza levou duas semanas, exigiu deduplicação de registros corrigidos manualmente e gerou confusão suficiente para que as previsões de Pipeline de três representantes tivessem de ser reconstruídas do zero.

Uma auditoria de 30 minutos no dia da migração teria identificado o problema.

Este guia apresenta o processo de auditoria em três camadas que previne esse cenário, estruturado por cronograma com verificações específicas em cada intervalo. Ele se baseia diretamente no dia de cutover: o checklist que evita desastres: as verificações realizadas durante a migração são o que esta auditoria mede nas horas seguintes.

Quando Executar a Auditoria

Hora 1. Execute antes de o time de vendas ter acesso. Você está verificando falhas críticas: registros ausentes, campos obrigatórios em branco, relacionamentos quebrados. Esses são os problemas que tornam o CRM inutilizável ou enganoso desde o primeiro minuto.

Hora 24. Depois que o sistema estiver ativo por um dia, verificações de integridade mais profundas se tornam possíveis. Os relacionamentos tiveram tempo para se resolver. A detecção de duplicatas foi executada. As regras de automação dispararam. Agora você pode verificar se os dados se comportam corretamente, não apenas se existem.

Hora 72. Três dias após o go-live, os problemas de lógica de negócios aparecem. Os relatórios de Pipeline não correspondem aos snapshots pré-migração. O roteamento de Lead não está funcionando corretamente. A automação está disparando incorretamente em registros importados. Esses problemas só ficam visíveis depois que o sistema está realmente em uso.

Por que esperar até a "semana 2" é tarde demais:

A cada dia que o time de vendas usa o CRM, eles acumulam novas atividades em cima dos dados existentes. A pesquisa da Gartner sobre qualidade de dados estima que o custo de corrigir um problema de qualidade de dados aumenta 10 vezes a cada etapa em que progride sem ser tratado: identificar problemas na primeira hora é ordens de magnitude mais barato do que encontrá-los na segunda semana. Um contato com campo de e-mail em branco que um representante envia na segunda-feira agora tem um registro de atividade, uma nota e uma tarefa de acompanhamento associados. Limpar esse contato significa perder esses registros ou migrá-los manualmente para o registro corrigido. Quanto mais cedo você identificar os problemas, mais barato será corrigi-los.

Camada 1: Verificações Críticas (Hora 1)

Essas verificações acontecem antes que qualquer pessoa, exceto o time de migração, tenha acesso.

1. Contagens de linhas por objeto

Extraia a contagem de registros de cada objeto migrado do novo CRM e compare com o snapshot de origem pré-migração.

Objeto Contagem na origem Contagem importada Variação aceitável
Contatos [da origem] [do CRM] ± 1% (log de erros explica o restante)
Contas/Empresas [da origem] [do CRM] ± 1%
Negócios/Oportunidades [da origem] [do CRM] ± 0,5%
Atividades [da origem] [do CRM] ± 2% (variação maior é aceitável)

Se a diferença for superior a 2% em Contatos ou Negócios, não abra o sistema. Leia primeiro o log de erros. Discrepâncias significativas que não podem ser explicadas pelo log de erros podem atender às suas condições de gatilho de rollback: decida antes de abrir o acesso ao time de vendas.

2. Completude da chave primária

O e-mail é a chave primária para Contatos. O telefone é secundário. Verifique se esses campos estão preenchidos na taxa esperada.

Execute um filtro rápido: Contatos com e-mail vazio. Se o resultado for superior a 2-3% do total de contatos, você tem uma falha de importação ou um problema nos dados de origem. De qualquer forma, corrija antes de o time começar a enviar e-mails ou fazer ligações.

3. Oportunidades abertas presentes com estágios corretos

Os negócios abertos precisam estar no CRM com os valores de estágio corretos. Filtre todas as Oportunidades abertas. Verifique:

  • A contagem total corresponde à origem
  • A distribuição de estágios corresponde aproximadamente ao que você tinha no sistema de origem
  • Nenhum negócio foi colocado em um estágio genérico por causa de incompatibilidade no nome do estágio

4. Revisão do log de erros

Toda ferramenta de importação de CRM gera um log de erros. Leia-o. Cada linha nesse log representa um registro que não foi importado: falhou completamente ou foi importado com um valor de campo ignorado.

Entradas comuns no log de erros:

  • "Record already exists" (registro já existe): a detecção de duplicatas impediu a importação; decida se vai mesclar ou ignorar
  • "Invalid email format" (formato de e-mail inválido): os dados de origem têm e-mails malformados
  • "Required field empty" (campo obrigatório vazio): a importação ignorou um campo obrigatório; o registro foi importado, mas está incompleto
  • "Value not in picklist" (valor fora da lista): um valor de estágio ou status nos dados de origem não corresponde às opções do CRM

Crie uma lista de triagem: quantos registros, qual tipo de erro, pode ser corrigido em lote ou precisa de revisão manual?

Camada 2: Verificações de Integridade de Dados (Hora 24)

Após 24 horas, execute uma camada mais profunda de verificações em relacionamentos e completude de campos.

1. Integridade de relacionamento

Contatos sem Contas. Negócios sem Contatos. Negócios sem Contas. Esses registros órfãos são utilizáveis, mas incompletos, e vão acumular confusão à medida que os representantes tentam usá-los.

Para cada tipo de órfão, decida:

  • Isso foi intencional (os dados de origem não tinham Conta para esses Contatos)?
  • Ou é um erro de importação (a importação da Conta falhou, então o Contato não tem nada ao qual se vincular)?

Se for um erro, corrija. Se for intencional, documente.

2. Completude de campos personalizados em objetos-chave

Escolha os 5 a 10 campos personalizados mais importantes (os que o time de vendas usa para relatórios ou filtragem). Para cada um:

  • Qual % dos registros relevantes tem esse campo preenchido?
  • A taxa de preenchimento corresponde ao sistema de origem?

Um campo personalizado que estava 80% preenchido no sistema de origem deve estar aproximadamente 80% preenchido no destino. Se cair para 30%, o campo não foi mapeado corretamente durante a importação.

3. Resultados da varredura de detecção de duplicatas

A maioria dos CRMs executa detecção automática de duplicatas na importação ou tem uma varredura integrada que você pode acionar manualmente. Execute-a nas primeiras 24 horas, antes de os representantes começarem a adicionar dados. Se você não realizou o teste de importação paralela (shadow import) antes do go-live, as duplicatas são mais prováveis: a importação paralela foi desenvolvida especificamente para revelar esses casos antes que cheguem à produção.

Revise o relatório de duplicatas com esta abordagem:

  • Duplicatas exatas de e-mail: mesclar imediatamente
  • Mesmo nome, empresa semelhante: sinalizar para revisão do gerente de vendas antes de mesclar
  • Possíveis duplicatas (nome semelhante, e-mail diferente): sinalizar para revisão manual, não mesclar automaticamente

4. Registros de atividade vinculados aos registros corretos

Pegue 20 registros de atividade aleatórios (notas, logs de chamadas) da importação. Para cada um:

  • Está vinculado a um Contato?
  • Está vinculado ao Contato correto (não a uma duplicata ou pessoa errada)?
  • O conteúdo é exibido corretamente (sem problemas de codificação, sem truncamento)?
  • O campo de data está preenchido e correto?

Camada 3: Verificações de Lógica de Negócios (Hora 72)

Essas verificações exigem que o sistema tenha sido utilizado. Elas identificam problemas em como o CRM se comporta, não apenas nos dados que contém.

1. Relatórios de Pipeline correspondem aos snapshots pré-migração

Antes da migração, exporte um snapshot do seu Pipeline: total de negócios abertos, valor total do Pipeline, contagem de negócios por estágio, tamanho médio do negócio. Compare com o mesmo relatório no novo CRM na marca de 72 horas.

Se os números forem significativamente diferentes, com variação superior a 5% no valor total do Pipeline, você tem um problema de dados. Os negócios podem não ter migrado, os valores podem ter chegado incorretamente ou o mapeamento de estágios alterou a distribuição dos negócios.

2. Regras de roteamento de Lead disparando corretamente

Se o seu CRM usa roteamento automático de Lead (novos Leads são roteados para representantes ou territórios específicos com base em regras), teste com um novo registro. Crie um Lead de teste que corresponda a uma regra de roteamento e verifique se ele é roteado corretamente.

Registros importados frequentemente acionam regras de roteamento incorretamente se o roteamento for baseado em data ou na data de criação do registro. Um registro criado em 2023 que foi importado na data da migração pode ter sua data de criação definida como a data de importação, o que aciona regras de roteamento que não deveriam se aplicar a registros históricos. Verifique isso dentro de 72 horas antes que crie um acúmulo de registros mal mapeados.

3. Gatilhos de automação não disparando incorretamente em registros importados

Este é um dos problemas pós-migração mais comuns e prejudiciais. Se o seu CRM tem automações que disparam na criação de registros, como e-mails de boas-vindas, sequências de Onboarding e notificações internas, os registros importados podem acionar todos eles simultaneamente. O artigo do Wikipedia sobre automação de workflow fornece contexto útil sobre como sistemas baseados em gatilhos se comportam quando grandes volumes de novos registros são inseridos e por que suprimir automações durante importações em lote é prática padrão.

A maioria dos CRMs tem uma opção para suprimir automações durante a importação. Se você não a utilizou, verifique se alguma automação disparou para o volume total de importação. Se disparou, você pode ter enviado e-mails automáticos para todos os contatos que migrou.

Verifique seu log de atividade de automação dentro de 72 horas. Se houve disparos incorretos, você precisará suprimir futuros gatilhos em registros importados ou enviar uma comunicação de correção.

4. Lógica de atribuição de usuário correta

Abra 20 Negócios aleatórios e 20 Contatos aleatórios. Para cada um, verifique se o representante atribuído corresponde ao que estava no sistema de origem. Atribuição incorreta de representante cria dois problemas: representantes não conseguem ver registros que possuem, e representantes veem registros que não possuem.

Causas comuns: incompatibilidade no formato de nome de usuário entre origem e destino (firstname.lastname vs. firstname_lastname), usuários inativos na origem que precisam ser reatribuídos ou uma atribuição genérica que roteou registros sem correspondência para um único usuário.

Como Documentar e Priorizar os Achados

Classificação de severidade:

Severidade Descrição Exemplo Prazo para correção
P1: Perda de dados Registros totalmente ausentes ou campos críticos em branco 500 Contatos não foram importados Antes do acesso do time de vendas
P2: Qualidade de dados Registros importados com valores incorretos ou ausentes Campo personalizado em branco em 15% dos contatos Dentro de 24 horas
P3: Lógica de negócios Automação ou roteamento disparou incorretamente E-mails de boas-vindas enviados a todos os contatos importados Dentro de 72 horas
P4: Cosmético Problemas de exibição, formatação, inconsistências menores Inconsistência no formato de telefone Dentro de 30 dias

Modelo de triagem:

Para cada achado, documente:

  • Descrição do achado
  • Nível de severidade
  • Contagem de registros afetados
  • Causa raiz (se conhecida)
  • Abordagem de remediação
  • Responsável
  • Data alvo de correção

Mantenha isso como um documento compartilhado com o gerente de vendas e o responsável de TI. Os problemas P1 e P2 devem ser resolvidos antes de reportar "migração concluída" às partes interessadas.

Comunicando os Resultados da Auditoria às Partes Interessadas

O que dizer ao VP de Vendas:

Comece pelo que está funcionando. Forneça a contagem de Contatos, Contas e Negócios abertos que migraram com sucesso. A pesquisa da Harvard Business Review sobre gestão de mudanças constatou que os funcionários resistem a mudanças que não entendem: uma comunicação transparente e factual sobre o status da migração reduz significativamente o ceticismo que desacelera a adoção do CRM nas primeiras semanas. Reporte quaisquer achados P1 com o prazo de correção. Não forneça um detalhamento técnico de cada verificação: lidere com o impacto nos negócios.

Se houver problemas significativos: "Identificamos 220 Contatos com campos de e-mail ausentes. Estamos corrigindo hoje e isso não afetará nenhum negócio aberto. O problema estava nos dados de origem, não no processo de importação." O guia como comunicar a migração ao time de vendas cobre como enquadrar essas conversas para que não corroam a confiança dos representantes no novo sistema antes que a adoção se consolide.

O que manter internamente:

Os achados P3 e P4 não precisam ir para a liderança de vendas. Trate-os operacionalmente e inclua-os em um resumo escrito na marca de 30 dias.

Como gerenciar expectativas sobre problemas conhecidos:

Se houver problemas que levem mais de um dia para corrigir, informe o time de forma proativa. "Você pode ver alguns contatos sem número de telefone esta semana: estamos executando uma correção em lote e será resolvido até quinta-feira." Isso evita que os representantes abram tickets de suporte achando que o CRM está com defeito.

Armadilhas Comuns

Verificação por amostragem em vez de varredura sistemática. Abrir 10 registros aleatórios e declarar sucesso não é uma auditoria. É otimismo. Use as verificações de contagem de linhas, completude de campos e integridade de relacionamento como um processo estruturado.

Ignorar a camada de lógica de negócios. A maioria dos times só executa as verificações da Hora 1 e então abre o sistema. Disparos incorretos de automação e erros de roteamento, os problemas da Hora 72, são frequentemente os que prejudicam a confiança dos representantes e criam ruído contínuo no CRM.

Não comparar com um snapshot de referência pré-migração. Sem um snapshot do sistema de origem feito imediatamente antes da migração, você não pode verificar definitivamente o que deveria ter migrado. Faça um snapshot antes de cada migração. Exporte as contagens de registros e os totais de Pipeline para um arquivo de referência.

Declarar sucesso antes de a janela de 72 horas ser concluída. O cronograma em três camadas existe porque diferentes tipos de problemas aparecem em intervalos diferentes. Encerrar a auditoria após a Hora 1 é como verificar se o coração de um paciente está batendo e mandá-lo para casa: é uma verificação necessária, mas não suficiente.

O Que Fazer a Seguir

Agende uma revisão de qualidade de dados de 30 dias após o encerramento da auditoria de 72 horas. Essa revisão analisa as métricas de qualidade de dados que só ficam visíveis após um mês de uso real: taxas de preenchimento de campos, acúmulo de duplicatas, registros com relacionamentos ausentes que os representantes têm contornado.

Para orientações sobre como prevenir problemas antes mesmo de a importação ser executada, o guia testando a migração com uma importação paralela (shadow import) cobre como identificar a maioria desses problemas em um ambiente de teste antes do go-live.

E se a auditoria revelar achados que exijam consideração de rollback, o guia planejamento de rollback: torça para não precisar define quando e como tomar essa decisão, incluindo o que "rollback" realmente significa após 72 horas de uso em produção.

A auditoria em si se conecta diretamente ao dia de cutover: o checklist que evita desastres: as verificações realizadas durante a migração informam no que a auditoria deve se concentrar nas horas seguintes.

Saiba Mais