Mau Informado Ou Mal Informado

Como lidar com mau informado ou mal informado nos seus dados

Achei que todo mundo já sabia disso, mas vejo a mesma pergunta acontecendo todo dia em grupo de Slack e thread de suporte. A diferença entre mau informado e mal informado não é frescura gramatical. É a diferença entre um dado que você pode corrigir e um dado que vai te processar por difamação. Mau informado se refere a uma pessoa ou fonte que não tem o conhecimento adequado sobre algo. Mal informado é o estado da informação em si, que chegou distorcida ou incorreta ao destino. Em termos de dados, isso muda completamente a estrategia de tratamento. Quando você descobre que um lead veio mau informado, você entra em contato e educa. Quando é mal informado, você não pode confiar no registro original e precisa rastrear a fonte primária. Tem um detalhe que as pessoas costumam pular e que causou problema pra mim semana passada. Um cliente nosso recebeu uma planilha de CRM de uma consultoria externa. Os registros de origem estavam todos mal informados -- dados de setor econômico truncados pelo sistema deles durante uma migração. A gente tentou chamar os contatos pra confirmar, descobrimos que as pessoas também estavam mau informadas porque a própria empresa fornecia a versão errada nos formulários de cadastro. O resultado foi um loop de confirmação que durou três dias sem avanço. A solução foi parar de confiar nos campos preenchidos pelos usuários e fazer match direto com a base da Receita Federal usando o CNPJ como chave. Em vez de tentar corrigir o que já estava errado, simplesmente descartamos os campos problemáticos e trouxemos os dados de outra fonte.

Isso me leva a um ponto que parece óbvio mas que eu vejo muito errarem: validar a informação depois de ela entrar no sistema é muito mais caro do que impedir que chegue errada. Custa em média 12 vezes mais fazer limpeza de dados do que validar na entrada, segundo um estudo que a Gartner publicou e que eu vi sendo citado em vários casos internos aqui. Não é teoria. Eu acompanhei o orçamento de um projeto onde gastamos R$ 47 mil em higienização de dados que poderiam ter sido evitados com um campo obrigatório bem configurado e uma regra de validação no formulário.

Como identificar e corrigir na prática

O primeiro passo é saber qual tipo de erro você está encarando. Mau informado tem cara de pessoa bem-intencionada que não entendeu o campo. Mal informado tem cara de sistema falho, export defeituosa, API que truncou algo sem aviso. A distinção define o remédio. Para mau informado, a abordagem é direta. Você pega o contato, explica o problema, pede a correção. Funciona bem quando há relação estabelecida e boa vontade. O gargalo aqui é tempo. Se você tem mais de 500 registros suspeitos, liga um por um vira tarefa impossível. Aí você parte para automação: e-mails sequenciais com links de atualização, formulários self-service, chatbot que coleta os dados corretos. Isso corta o tempo de resolução de algo em torno de 40 minutos por registro para cerca de 3 minutos, considerando a taxa de resposta que varia entre 30% e 55% dependendo do segmento. Para mal informado, a coisa complica. Você não adianta ligar pra pessoa perguntar se o dado tá certo, porque o erro já estava no registro original. Aqui você precisa de uma terceira fonte. Os caminhos mais comuns são APIs governamentais, bureaus de dados especializados, ou cross-reference com bases de. No caso do exemplo que citei acima, a Receita Federal resolveu porque é a fonte primária. Mas nem sempre é tão simples. Quando eu lidava com dados de endereços comerciais, por exemplo, o CEP correto não resolvia porque o sistema de correios não atualiza mudanças de logradouros em tempo real. Aí a gente acabou usando o Google Places API como camada intermediária -- não perfeito, mas pelo menos trazia geolocalização válida e nome do estabelecimento confirmado.

Um erro comum que eu vejo repetindo é tratar ambos os casos com a mesma ferramenta. Há empresas que usam o mesmo software de limpeza de dados tanto para mau informado quanto para mal informado. O resultado é sempre ruim porque o algoritmo não sabe se deve pedir correção ao usuário ou buscar em outra fonte. Você gasta processamento à toa e ainda gera ruído nas comunicações com os contatos.

Frameworks de decisão rápida

Eu desenvolvi um fluxograma simples que uso como referência interna. Primeiro pergunta-se: a informação veio de um formulário humano ou de um sistema automatizado. Se veio de humano, é provável mau informado. Se veio de sistema, é provável mal informado. Segunda pergunta: existe uma fonte confiável e acessível para cross-check? Se sim, vai de automação. Se não, volta pro humano com perguntas específicas. Isso funciona na maioria dos cenários. Tem exceções, claro. Sistemas automatizados às vezes transmitem dados corretos que foram coletados de forma errada por humanos na origem. Aí você cai num caso misto que exige investigação manual mesmo. Nesse ponto, o custo-benefício de investigar individualmente só faz sentido se o registro tiver alto valor -- contratos acima de certo threshold, clientes estratégicos, dados regulatórios sensíveis. Para o resto, você marca como suspeito e segue em frente. A parte mais chata é quando você precisa lidar com mau informado ou mal informado no mesmo lote de dados. É mais comum do que parece. Uma importação massiva de CRM traz ambos os tipos misturados. Nesses casos, eu costumo fazer uma triagem inicial com regras heurísticas -- campos vazios, formatos inválidos, valores fora da média estatística -- e separo em dois buckets. Cada bucket segue um fluxo diferente. Isso normalmente reduz o tempo de processamento pela metade comparado a tratar tudo igual.

Limitações que ninguém conta

Nenhuma abordagem resolve tudo. A validação contra fontes externas depende da disponibilidade dessas fontes. APIs cobram por requisição. Bureaus de dados têm dados defasados em alguns segmentos. Fontes governamentais têm lag de semanas ou meses. Você precisa saber disso antes de construir um processo que depende delas como única salvaguarda. Outro ponto: corrigir dados não resolve problemas de estratégia. Já vi equipe inteira dedicar dois sprints inteiros limpando uma base de 2 milhões de registros só pra descobrir que a base em si era irrelevante para o produto que estavam construindo. Às vezes o problema não é mau informado ou mal informado. É que você está coletando os dados certos do jeito certo, mas os dados certos pra coisa errada. Se o seu volume for grande e a variabilidade alta, considerar uma ferramenta de data quality dedicada pode valer o investimento. Ferramentas como Talend, Informatica ou até soluções mais leves como Great Expectations conseguem automatizar buena parte do trabalho de detecção e correção. O custo inicial é maior, mas o retorno aparece em questões de meses, não de semanas. Depende do seu cenário, claro. Para times pequenos com volumes menores, um script Python bem feito com pandas e requisições para APIs públicas resolve 80% dos casos com um fraction do custo.

O que eu posso garantir é que ignorar o problema não funciona. Dados mal tratados se propagam. Um campo errado no cadastro original vira métrica errada no dashboard, vira decisão errada na reunião, vira prejuízo no fechamento. O trabalho de identificar se é mau informado ou mal informado e aplicar o remédio certo é chato, mas é exatamente esse trabalho que separa equipes que confiam nos próprios dados das que passam o mês inteiro discutindo se os números fazem sentido.