Todo projeto de e-commerce B2B tem um momento, geralmente na terceira semana, em que fica evidente que os dados do cadastro de clientes vão ser um problema maior do que a loja. Acontece com as melhores equipes. A apresentação da migração de plataforma falava de interface, mobile, busca, IA. O verdadeiro empecilho acaba sendo que o mesmo cliente existe três vezes no ERP com nomes ligeiramente diferentes, e cada duplicata tem um conjunto distinto de acordos de preços.
Este artigo é o fluxo que agora executamos em todo projeto antes de escrever qualquer código da loja. É o trabalho que ninguém dimensiona e que todos pagam de um jeito ou de outro.
Por que a loja piora isso
Em um mundo só de ERP, o funcionário do contas a receber que esbarra em um cliente duplicado simplesmente escolhe um e segue em frente. As pessoas absorvem problemas de qualidade de dados em silêncio por anos. No instante em que você coloca uma loja B2B de autoatendimento diante desses registros, cada falha vira um bug visível para o cliente:
- "Por que o preço está diferente do que meu representante cotou?" → Dois registros, dois acordos de preços.
- "Meu histórico de pedidos está vazio." → Estão olhando para a duplicata n.º 2, mas pediram pela duplicata n.º 1.
- "Por que minha conta está de repente em bloqueio de crédito?" → O contas a receber bloqueou a n.º 1. A loja enxerga a n.º 2.
- "Cadê meu endereço de entrega do mês passado?" → Armazenado em uma terceira duplicata que ninguém conhecia.
Os cinco problemas que sempre encontramos
- Duplicatas. A mesma entidade jurídica existe de 2 a N vezes. Muitas vezes criadas ao longo dos anos, à medida que diferentes representantes de vendas cadastravam o mesmo cliente por territórios ou linhas de produto distintos.
- Relações inconsistentes de entrega e cobrança. Alguns clientes têm todos os seus endereços de entrega sob um único pai; outros têm registros de cliente independentes de nível superior por localidade. O ERP pode não impor um padrão consistente.
- Atribuições desatualizadas. Representantes de vendas que saíram, condições de pagamento que não são revisadas há cinco anos, classes de cliente que apontam para linhas de produto descontinuadas.
- Lógica de negócio implícita em campos que ninguém documentou. "Classe de Cliente = X significa que enviamos via FedEx." Essa lógica está na cabeça de alguém, não na configuração do ERP.
- Certificados de isenção fiscal que não são aplicados. O certificado está no arquivo. O registro do cliente no ERP não sabe da existência dele. A loja vai cobrar imposto em um estado onde não deveria.
O fluxo que executamos
Fase 1: extrair e perfilar (semana 1)
Puxe todos os registros de cliente. Ainda não nos importamos com detalhes de preços: nos importamos com a identidade. Extraia: ID do cliente, razão social, nome fantasia (DBA), endereço principal, contato principal, ano de criação, data do último pedido, atribuição de representante de vendas, ID do pai (se houver hierarquia). Passe tudo por correspondência aproximada (usamos uma combinação de token-set ratio nos nomes mais distância de Levenshtein nos endereços, seguida de revisão humana).
Fase 2: apresentar o relatório de duplicatas (semana 2)
Devolva os candidatos a duplicata para a equipe de contas a receber e de operações de vendas. A reação deles revela o escopo real do projeto. Se a resposta for "sim, são essas mesmo que a gente já conhecia, vamos mesclar", você está em boa forma. Se a resposta for "espera, eu não sabia que tínhamos três registros da Acme Manufacturing, deixa eu verificar com o Bob", você encontrou uma longa cauda de trabalho de projeto que ninguém dimensionou.
Fase 3: normalização de hierarquia e endereços de entrega
Escolha um padrão: cliente pai com registros de entrega filhos, OU clientes planos com endereço de cobrança compartilhado. Ambos funcionam. A resposta errada é "vamos deixar dos dois jeitos". Documente, escreva um pequeno script de migração e execute-o.
Fase 4: enriquecer e validar
Adicione os dados de que a loja vai precisar e que o ERP não exigia: e-mails de usuários web, atribuições de papel por endereço de entrega (comprador, aprovador, contas a pagar), sinalizadores de isenção fiscal. Este também é o momento de perguntar "os representantes de vendas ainda deveriam ver o cliente X que não compra há três anos?": o arquivamento leve resolve boa parte da bagunça.
Fase 5: travar e testar de novo
Assim que os registros limpos forem implantados, escreva testes de integração que comprovem o básico: todo cliente ativo tem exatamente um registro principal, todo endereço de entrega pertence a um cliente, todo cliente tem pelo menos um contato válido. Execute-os antes de cada lançamento.
Como dimensionar isso em uma proposta
Enquadre como 10% a 15% do orçamento total do projeto para migrações de plataforma B2B. Isso parece alto até você ter ficado do lado errado da situação. Preferimos dimensioná-lo de forma explícita a deixá-lo vazar por todas as outras linhas e virar “por que esse projeto está atrasado?”
De quem é a responsabilidade
A limpeza é, em sua maior parte, trabalho de negócio, não de TI. A equipe certa é o seu líder de contas a receber mais o seu líder de operações de vendas, com a gente fornecendo os scripts, as ferramentas de detecção de duplicatas e o arcabouço de testes. Se a equipe de clientes se engajar desde a primeira semana, isso termina no prazo. Se forem incluídos só na décima semana, o projeto atrasa.
Se você está dimensionando uma migração de plataforma B2B e o cadastro de clientes não é auditado há cinco anos, fale com a gente antes de dimensionar a loja. A ordem importa.