Migrar para um CRM sem perder o histórico de clientes

O medo de perder o histórico é legítimo e costuma levar à decisão errada: trazer tudo. Uma base nova com anos de registos duplicados, campos que ninguém preencheu e clientes que já fecharam portas não preserva o histórico — enterra-o, e a equipa chega ao fim do primeiro mês a dizer que no sistema antigo encontrava as coisas mais depressa.

Que perguntas é que o histórico tem de continuar a responder?

«Não perder nada» não serve como critério, porque não se consegue verificar. Um critério verificável é uma lista de perguntas que a empresa tem de conseguir responder no dia seguinte à mudança.

Por exemplo: quando um cliente ligar a perguntar o que ficou combinado, onde está a resposta? Quando um comercial novo receber uma carteira, o que precisa de ler para não começar do zero? Quando houver uma reclamação sobre um trabalho de há dois anos, o que é preciso mostrar? Quando se quiser saber quais dos clientes inativos vale a pena voltar a contactar, que informação sustenta essa escolha?

Cada pergunta aponta para dados concretos, e a lista é sempre mais curta do que se esperava. O que não responde a nenhuma pergunta não é histórico: é arquivo. E arquivo pode ficar onde está, acessível para consulta, sem entrar na base nova a ocupar espaço nos ecrãs de todos os dias.

Três camadas que não se migram da mesma maneira

Tratar tudo como «dados» é a origem das migrações mais dolorosas. Há três camadas com naturezas diferentes:

• Identidade. Clientes, empresas, contactos, moradas, números fiscais. É o alicerce e migra-se quase sempre por inteiro — e é aqui que os duplicados fazem mais estragos, porque contaminam tudo o que se lhes liga depois.
• Relação. Interações, propostas, documentos, notas, reclamações. É o histórico propriamente dito, e migra-se por seleção e não por varrimento: interessa o que explica decisões e compromissos, não cada registo que alguém deixou.
• Processo em curso. Oportunidades abertas, tarefas, estados, etapas. Isto não se migra — recria-se. As etapas do sistema novo não são as do antigo, e traduzir estados de um para o outro é inventar informação com aparência de dado verdadeiro.

A confusão entre a segunda e a terceira camada é a que dá mais trabalho. Alguém tenta mapear estados antigos para etapas novas, descobre que não há correspondência e resolve o problema com uma etapa chamada «outro» — que ao terceiro mês é a mais populosa do sistema e não significa nada.

Recriar o processo em curso é menos trabalho do que parece, porque as oportunidades verdadeiramente vivas são poucas. E tem uma vantagem: obriga cada responsável a olhar uma vez para a sua própria carteira e a admitir o que já não está a andar.

A migração é a única ocasião em que limpar é barato

Nunca vai haver um momento melhor para tratar os duplicados e os campos inúteis. Antes do arranque, mexer nos dados é trabalho de preparação. Depois do arranque, é mexer em registos que a equipa já usa, com o risco de apagar o que alguém escreveu ontem — e ninguém autoriza isso de bom grado.

Duas decisões resolvem a maior parte do problema, e têm de ser tomadas por escrito. A primeira é a regra de identidade: o que faz de dois registos o mesmo cliente. O número fiscal serve, o endereço de correio eletrónico às vezes serve, o nome nunca serve. A segunda é o critério de sobrevivência: quando dois registos discordam, qual vence — o mais recente, o do sistema principal, o que tem mais informação preenchida? Sem estas duas regras escritas, a decisão é tomada registo a registo por quem estiver a fazer o trabalho, e deixa de ser explicável.

Quanto aos campos que quase ninguém preencheu: não são campos em falta no sistema novo. São uma pergunta sobre se alguma vez fizeram sentido. Levá-los vazios é levar o hábito de não os preencher.

Onde está o histórico que ninguém contou

A lista de origens quase nunca é só «o sistema antigo». Está também na caixa de correio de cada comercial, em folhas de cálculo pessoais que nunca foram partilhadas, numa pasta com propostas em ficheiros de texto, e nas conversas de telemóvel que ninguém considera registo da empresa — e são-no, muitas vezes as mais importantes.

Fazer esse inventário antes de começar muda o plano, porque mostra que a parte difícil não é técnica. É decidir o que passa a ser registo oficial da empresa e o que fica deliberadamente fora. É uma decisão de organização, da mesma família daquela que separa o que pertence a cada ferramenta, e não se delega a quem executa a importação.

Como saber que a migração correu bem

Comparar totais de registos não prova nada. Dá para trazer tudo, com os totais a bater, e ter uma base inutilizável — e dá para deixar metade de fora com toda a informação que interessa presente.

A verificação que serve é narrativa. Escolha meia dúzia de clientes reais: um antigo com muita história, um recente, um que tenha apresentado uma reclamação, um que comprou várias vezes, um que desapareceu a meio de uma negociação. Reconstrua a história de cada um usando apenas o que está na base nova, e peça a quem trata desses clientes para ler e dizer o que falta. Quem conhece o cliente deteta em minutos o que nenhuma verificação automática apanha.

Defina também, por escrito, até quando o sistema antigo fica disponível para consulta e a partir de que data deixa de estar. Sem essa data, ele nunca desaparece — e enquanto duas fontes existirem, a equipa vai continuar a acreditar na antiga, que é uma das formas mais silenciosas de uma implementação falhar.

No nosso modelo de trabalho, a migração faz parte da implantação acompanhada e não de um orçamento à parte, por uma razão prática: quem desenha a plataforma é quem está em melhores condições para decidir o que vale a pena trazer. Traga a lista das origens do seu histórico ao diagnóstico, com as folhas de cálculo e as caixas de correio incluídas. É esse documento que faz a conversa deixar de ser sobre importar ficheiros e passar a ser sobre o que a sua empresa precisa de continuar a conseguir responder.