Imagine uma situação comum.
Um cliente compra pela primeira vez. No cadastro, o telefone entra com um dígito errado. Em outro sistema, o mesmo cliente aparece com um segundo e-mail. O CRM mantém um registro, a plataforma de marketing cria outro e o atendimento abre um terceiro quando ele entra em contato alguns meses depois.
Nada quebra.
Os sistemas continuam funcionando. Os dashboards abrem. As campanhas são disparadas. O CRM mantém suas oportunidades. Os relatórios são atualizados.
Esse é justamente o problema.
Um dado ruim raramente anuncia sua chegada provocando uma grande falha. Na maioria das vezes, ele entra silenciosamente na operação e continua circulando como se fosse verdadeiro.
O marketing pode considerar aquele cliente inativo porque não reconheceu sua última compra.
Vendas pode abordá-lo como um novo lead.
O atendimento pode não encontrar seu histórico.
Uma automação pode incluí-lo numa jornada inadequada.
Um relatório pode contar duas pessoas onde existe apenas uma.
Individualmente, cada erro parece pequeno. Em conjunto, eles revelam algo maior:
qualidade de dados não é apenas um problema da base. É um problema das decisões que dependem dela.
O erro mais perigoso é aquele que continua funcionando
Alguns problemas são fáceis de perceber.
Quando um sistema sai do ar, alguém abre um chamado. Quando uma integração quebra, surge um alerta. Quando um dashboard deixa de carregar, a falha fica evidente.
Dados ruins são diferentes.
Um campo incorreto normalmente não impede o sistema de funcionar.
Dois e-mails diferentes podem ser tecnicamente válidos. Dois registros com pequenas variações no nome podem passar pelas validações. Um telefone antigo continua tendo formato de telefone. Uma informação desatualizada continua ocupando corretamente seu campo.
É possível, portanto, ter sistemas tecnicamente saudáveis operando sobre informações que já não representam corretamente a realidade.
Enquanto poucas decisões dependem de uma informação, a consequência tende a permanecer localizada. Quando vários processos passam a consumi-la, aquela informação ganha poder operacional.
A pergunta deixa de ser apenas:
“O cadastro está correto?”
E passa a ser:
“Quais decisões dependem de esse cadastro estar correto?”
Essa mudança de pergunta altera a forma de tratar qualidade de dados.
Um erro não permanece onde nasceu
Considere um cliente chamado João.
No e-commerce, João está cadastrado pelo e-mail pessoal. No CRM, pelo corporativo. No atendimento, o telefone aparece sem o DDD. No programa de relacionamento, existe ainda um registro antigo criado em outra compra.
Para uma pessoa olhando os registros lado a lado, talvez seja evidente que todos representam o mesmo cliente.
Para os sistemas, não necessariamente.
Se não existe uma regra confiável de identificação, a empresa pode enxergar quatro clientes.
E a consequência não termina na duplicidade.
A frequência de compra pode ficar fragmentada.
O valor acumulado daquele cliente pode ser dividido entre registros.
A segmentação pode classificá-lo de forma inadequada.
Uma regra de retenção pode não reconhecer seu comportamento recente.
Uma campanha destinada a clientes recorrentes pode ignorá-lo, enquanto outra ação o trata como comprador de primeira viagem.
O dashboard, por sua vez, pode consolidar esses registros e levá-los até uma reunião executiva.
O dado ruim nasceu no cadastro.
Mas não ficou no cadastro.
Ele percorreu a operação.
Por isso, qualidade de dados precisa ser entendida não apenas como o estado de uma base, mas como a capacidade de impedir que inconsistências se transformem em decisões.
Quanto mais amplo o relacionamento, mais dados entram na decisão
Quando uma empresa deixa de enxergar o cliente apenas pelo momento da venda e passa a acompanhá-lo ao longo de todo o lifecycle, mais informações passam a participar das decisões.
Antes da venda, há origem, comportamento, interesse e identificação.
Durante a venda, surgem oportunidade, negociação, produto, valor e canal.
Depois da venda, entram uso, atendimento, recompra, retenção, relacionamento e fidelidade.
Essa visão amplia a capacidade de compreender o cliente.
Também aumenta o número de dependências.
Uma identidade duplicada pode comprometer a continuidade do histórico.
Uma preferência desatualizada pode influenciar ações futuras.
Um status comercial incorreto pode alterar prioridades.
Uma informação sem contexto pode ser interpretada de maneiras diferentes por áreas distintas.
Quanto mais pontos da operação dependem dos mesmos dados, menos sentido faz tratar qualidade como uma faxina periódica.
Porque o dado não espera a próxima faxina para ser usado.
Um dado não precisa estar “errado” para produzir uma decisão ruim
Esse é um ponto importante.
Quando falamos em qualidade, a imagem mais comum é a do erro de digitação: telefone incorreto, e-mail inválido, campo vazio.
Mas existem problemas menos evidentes.
Uma informação pode nascer incompleta.
Pode estar correta quando foi capturada e envelhecer.
Pode aparecer duplicada.
Pode existir em duas fontes com valores diferentes.
Ou pode continuar tecnicamente correta e perder o contexto necessário para ser interpretada.
“Cliente ativo”, por exemplo, pode significar coisas diferentes para vendas, financeiro, marketing e atendimento.
Para uma área, ativo pode ser quem possui contrato vigente.
Para outra, quem comprou nos últimos 90 dias.
Para uma terceira, quem interagiu recentemente.
Nenhuma definição precisa estar tecnicamente errada.
O problema surge quando a empresa usa essas definições como se fossem equivalentes.
Nesse momento, a discussão deixa de ser sobre preenchimento de campos.
Passa a envolver identidade, atualidade, consistência e contexto.
E isso explica por que limpar uma planilha não resolve, sozinho, um problema de qualidade de dados.
O dashboard não corrige aquilo que recebeu
Quando números divergem, existe uma tendência natural de olhar primeiro para o relatório.
“Por que esse dashboard está errado?”
Às vezes ele está.
Mas um dashboard também pode estar calculando perfeitamente aquilo que recebeu.
Se a base contém clientes duplicados, o relatório pode contar duplicidades com absoluta precisão.
Se uma compra não foi associada à identidade correta, o indicador pode calcular exatamente o histórico incompleto disponível.
Se duas áreas usam definições diferentes de “cliente ativo”, dois relatórios podem estar matematicamente corretos e operacionalmente incompatíveis.
Isso cria uma situação particularmente perigosa: a aparência de precisão.
Casas decimais, gráficos bem desenhados e atualizações frequentes não tornam a informação verdadeira.
Precisão de cálculo não compensa baixa qualidade da informação de origem.
Antes de perguntar qual dashboard está certo, existe uma pergunta anterior:
qual realidade os dados usados por ele representam?
O problema cresce quando o dado passa a acionar alguma coisa
Existe uma diferença importante entre um dado armazenado e um dado utilizado para decidir.
Enquanto permanece apenas registrado, uma inconsistência pode ser pouco percebida.
Quando começa a determinar segmentos, prioridades, alertas, comunicações ou ações, ela ganha consequência.
Imagine que uma regra identifique clientes sem compra recente para iniciar uma ação de retenção.
Se a última transação estiver associada a outro registro da mesma pessoa, o sistema pode classificar um cliente ativo como inativo.
A regra pode estar correta.
A execução pode estar correta.
O problema aconteceu antes: a visão usada para decidir estava incompleta.
Esse raciocínio vale para processos manuais e automatizados, mas a escala aumenta sua relevância. Uma regra executada repetidamente consegue reproduzir a mesma interpretação sobre muitos registros antes que a origem da inconsistência seja percebida.
Por isso, antes de avaliar apenas a lógica de uma ação, vale enxergar a cadeia completa:
dado → interpretação → decisão → ação → consequência.
Se existe fragilidade no início, tudo o que vem depois herda essa fragilidade.
A empresa precisa descobrir onde o erro ganha poder
Nem todo campo possui a mesma importância operacional.
Um erro no complemento de endereço e um erro na identidade do cliente não necessariamente produzem o mesmo impacto.
Por isso, começar tentando “limpar toda a base” costuma gerar uma lista enorme de problemas sem indicar claramente o que deve ser resolvido primeiro.
Existe um caminho mais útil.
Comece pela decisão.
Escolha, por exemplo:
identificar clientes em risco de abandono.
Quais informações determinam essa classificação?
Talvez sejam identidade do cliente, data da última compra, frequência, valor, interações recentes e status do relacionamento.
Agora faça a pergunta seguinte:
o que acontece se cada uma dessas informações estiver errada, incompleta ou desatualizada?
Se a última compra estiver incorreta, alguém ativo pode parecer inativo.
Se a identidade estiver fragmentada, parte do histórico desaparece.
Se o status estiver desatualizado, a pessoa pode entrar numa jornada incompatível com sua situação.
O exercício revela algo que uma auditoria genérica de campos dificilmente mostra:
onde um dado possui capacidade de alterar uma decisão.
É aí que a qualidade ganha prioridade.
Qualidade não é uma propriedade abstrata do dado
Um mesmo dado pode ser suficiente para uma finalidade e insuficiente para outra.
Um e-mail pode bastar para entregar uma newsletter.
Talvez não seja suficiente para consolidar com segurança todo o histórico de relacionamento de um cliente.
Uma informação atualizada uma vez por mês pode atender determinado relatório.
Pode ser inadequada para uma decisão que precisa acontecer em poucas horas.
Isso significa que qualidade não deveria ser avaliada apenas perguntando:
“Esse dado está correto?”
Também é preciso perguntar:
“Esse dado é confiável para esta decisão?”
A diferença parece pequena, mas muda a prioridade.
Em vez de perseguir uma base abstratamente perfeita, a empresa passa a buscar informação adequada ao uso que fará dela.
A qualidade deixa de ser uma propriedade isolada do registro.
Passa a ser uma relação entre dado, contexto e decisão.
Cinco perguntas para testar essa relação
Uma empresa não precisa iniciar um grande projeto para começar.
Escolha uma decisão relevante — retenção, segmentação, priorização comercial, relacionamento ou outra recorrente — e percorra cinco perguntas.
1. De quais dados essa decisão realmente depende?
Não quais dados existem.
Quais alteram a decisão.
2. De onde cada informação vem?
CRM? ERP? plataforma de marketing? atendimento? planilha? cadastro manual?
Conhecer a origem é parte da capacidade de investigar uma inconsistência.
3. Como sabemos que dois registros representam ou não a mesma entidade?
Qual é a âncora de identidade adequada ao contexto?
Sem uma regra de identificação, consolidar bases pode apenas aproximar registros sem garantir que representam a mesma pessoa ou empresa.
4. O que acontece quando duas fontes discordam?
Existe uma fonte prioritária?
O processo para?
A divergência é sinalizada?
Alguém revisa?
Ou cada sistema simplesmente mantém sua própria versão?
5. Qual ação será tomada com base nessa informação?
Essa pergunta conecta qualidade a negócio.
Quanto maior a consequência da ação, maior deveria ser a atenção à confiabilidade dos dados que a sustentam.
Qualidade precisa acontecer antes e depois da captura
Corrigir dados continuará sendo necessário.
Bases reais mudam. Pessoas mudam de telefone, endereço, emprego e comportamento. Sistemas acumulam histórico. Novas fontes entram na operação.
O problema é depender apenas da correção posterior.
Tudo o que aconteceu antes dela já aconteceu.
A comunicação já pode ter sido enviada.
A oportunidade já pode ter recebido outra prioridade.
O atendimento já pode ter tomado uma decisão.
O indicador já pode ter participado de uma reunião.
Por isso, qualidade madura combina correção com prevenção e monitoramento.
Quais informações precisam ser validadas na entrada?
Como duplicidades são tratadas?
Qual fonte prevalece quando sistemas discordam?
Quando uma informação deve ser considerada desatualizada?
Quem responde por sua definição?
Como uma mudança relevante chega aos processos que dependem dela?
Essas perguntas acabam produzindo regras técnicas.
Mas não começam na tecnologia.
Começam na operação.
O objetivo não é ter uma base perfeita
Existe um risco no sentido oposto.
Ao perceber a extensão do problema, uma empresa pode transformar qualidade de dados em um projeto interminável de perfeição.
Toda operação real convive com algum nível de incompletude, atraso ou inconsistência.
Esperar perfeição antes de usar dados pode ser tão improdutivo quanto ignorar sua qualidade.
O objetivo mais útil é outro:
ter dados confiáveis o suficiente para as decisões que precisam ser tomadas — e conhecer os limites dessa confiança.
Isso exige prioridade.
Dados ligados a identidade, relacionamento, receita e outras decisões críticas podem exigir controles diferentes de informações periféricas.
A maturidade não está em declarar que “a base está limpa”.
Está em saber quais informações são críticas, de onde vieram, quais regras determinam seu uso, quem responde por elas e quais processos dependem delas.
Essa visão transforma qualidade de dados de uma atividade eventual em parte da própria operação.
Antes de procurar o dado errado, procure a decisão que depende dele
Talvez sua empresa tenha milhões de registros.
Começar examinando todos eles provavelmente produzirá uma lista enorme de inconsistências e pouca clareza sobre o que resolver primeiro.
Faça o caminho inverso.
Escolha três decisões importantes tomadas repetidamente sobre clientes.
Para cada uma, mapeie os dados que a sustentam.
Depois descubra de onde esses dados vêm, como são identificados, quando são atualizados e o que acontece quando duas fontes discordam.
A discussão deixa de ser abstrata.
Você começa a distinguir problemas meramente incômodos daqueles capazes de alterar uma decisão relevante.
Essa diferença importa.
Porque o maior risco de um dado ruim não está necessariamente no registro.
Está na confiança que a operação deposita nele.
Um cadastro incorreto pode ser corrigido.
Mas, antes da correção, ele pode alimentar um indicador, alterar uma classificação, iniciar uma ação ou influenciar uma decisão.
E, quanto mais aquela informação circula, mais difícil fica enxergar que consequências diferentes tiveram a mesma origem.
Dados ruins não ficam parados.
Eles atravessam sistemas, processos e decisões.
Por isso, talvez a pergunta mais importante sobre qualidade de dados não seja:
“Quantos erros existem na nossa base?”
Mas:
“Quais decisões da nossa empresa não podem se dar ao luxo de confiar no dado errado?”