Quem já viveu uma implantação de CRM conhece a cena. Alguém pergunta "e o histórico dos clientes, entra?", e a resposta vem em forma de planilha: exporta do ERP, ajusta coluna, importa. Três semanas depois, o vendedor abre a ficha de um cliente, vê "última compra: março" e desconfia. Vai no ERP: o cara comprou anteontem. A partir daí, ninguém mais olha o CRM.
O erro não foi a importação ter dado errado. Foi ter existido. E o vocabulário ajudou a errar: "carregar histórico" descreve uma mudança de lugar que não precisa acontecer.
Nada é copiado — o que se carrega é uma chave
Vale ser literal sobre o que entra no banco do CRM quando uma conta é criada a partir do ERP. No zCRM, o comando crm:sync-erp-accounts percorre as entidades do ERP e grava quatro campos:
erp_entity_id— o identificador da entidade no ERP;erp_entity_code— o código como o cliente conhece;erp_name— o nome de exibição (fantasia, quando existe);owner_user_id— o dono da conta.
É isso. Não entra faturamento, pedido, nota, título nem histórico de compra. O banco do CRM não fica sabendo quanto aquele cliente comprou no ano passado — e não precisa.
O erp_entity_id é a única cola entre os dois bancos: uma string opaca, tratada como identificador e nada mais — o CRM nunca faz conta com ela, porque em outro ERP ela pode ser um inteiro, um GUID ou um código composto. Carregar histórico, na prática, é gravar essa chave uma vez por cliente.
O histórico continua morando no ERP — e é por isso que ele não envelhece
Aqui está o ganho que a importação joga fora. Uma cópia nasce certa e apodrece: é uma fotografia de terça-feira que continua sendo terça-feira para sempre, enquanto o cliente segue comprando. Toda a engenharia de "sincronizar" depois existe para consertar um problema que a cópia criou.
Quando o vendedor abre a Conta 360 e olha os pedidos daquele cliente, o zCRM lê no ERP, naquele momento, filtrando pela chave da conta. O dado não está desatualizado porque nunca foi armazenado. O pedido que o faturamento lançou às 11h aparece às 11h — não porque exista uma sincronização esperta, mas porque não existe sincronização nenhuma naquele caminho.
Isso tem uma consequência vendida como limite que é, na verdade, a garantia: o CRM não escreve no ERP. As views de integração são somente leitura. Nome errado se corrige no ERP, e o CRM passa a mostrar certo. Nunca há duas versões da verdade brigando, porque só existe uma.
O que o comando faz, linha a linha
É aqui que o "primeiro dia" acontece de verdade. Para cada entidade do ERP, o sync procura uma conta com aquela chave. Não achou — cria, com os quatro campos. Achou — atualiza o código e o nome, e para por aí.
O dono sai do vendedor_codigo do ERP. Se aquele vendedor ainda não tem login no CRM, o sync cria o usuário ativo, com papel de vendedor e um e-mail técnico (erp-seller-*@crm.local), amarrado ao código do ERP. Quando a importação de usuários rodar depois com o e-mail real, esse usuário é promovido, não duplicado — a carteira que já estava apontando para ele continua apontando.
E tem a parte que decide se o CRM sobrevive ao segundo mês: o sync preserva o trabalho humano. Se alguém trocou o dono na mão, definiu temperatura, marcou potencial ou escreveu uma nota, rodar o sync de novo não desfaz nada disso — o dono só é preenchido quando está vazio. Um sync que atropela o que a equipe editou treina a equipe a não editar.
Antes de valer, dá para ensaiar: --dry-run mostra o que aconteceria sem gravar, --limit=N roda num pedaço e --include-inactive decide se cliente inativo entra.
O cache de métricas: a exceção, e por que ela existe
Se nada é copiado, por que a tela de clientes em risco abre rápido?
Porque existe uma exceção deliberada. CRM e ERP são bancos Firebird separados, e o Firebird não faz join entre bancos — cada consulta roda contra um banco só. Casar as duas pontas é sempre trabalho de aplicação, e fazer isso ao vivo, varrendo anos de notas de 3 mil clientes a cada tela, castigaria o servidor do ERP no horário comercial.
Então o crm:sync-account-metrics agrega uma vez por dia, às 02:30, e grava em crm_account_metrics o que é caro de calcular e barato de guardar: última compra, dias sem comprar, contagem e receita de 12 meses, ticket médio, RFM, segmento e risco. Isso é cache derivado, não cópia de histórico: pode ser jogado fora e recalculado do ERP a qualquer momento, sem perder nada.
A regra prática que separa os dois mundos: agregação pesada é job; leitura ao vivo só com filtro por entidade e período. É por isso que a lista de risco é de ontem à noite e o drill de um cliente específico é de agora.
Erros comuns na hora de ligar os dois
- Exportar o ERP e importar no CRM. Cria uma segunda verdade que começa a divergir na primeira hora e obriga alguém a conciliar planilha para sempre.
- Tratar o cache como se fosse o dado. Discutir com o vendedor se o RFM está certo às 15h, quando ele foi calculado às 02:30, é discutir a hora do relógio.
- Achar que o sync é a implantação. Ele é a última etapa. Antes, alguém precisou criar as views
v_crm_*no ERP e apontar a conexão. Sem isso, não há primeiro dia. - Mostrar código no lugar de nome. É por isso que o
erp_nameexiste como cache de exibição (comcrm:backfill-account-namespara as contas antigas). Tela que mostra "cliente 10842" não é usada. - Supor que o vínculo automático acerta tudo. Cliente sem vendedor no ERP vira conta sem dono, e ninguém reclama de uma conta que não aparece na tela de ninguém.
Como isso se aplica no zCRM
O que dói, concretamente, é o CRM que começa vazio e pede para a equipe digitar aquilo que a empresa já sabe há dez anos. O time paga o custo antes de receber qualquer valor — e, previsivelmente, não paga.
O zCRM roda hoje sobre dados reais: milhares de contas sincronizadas do ERP, com métricas RFM calculadas. E é útil olhar o que o primeiro dia entrega cheio e o que ele entrega vazio, porque não é a mesma coisa. Cheio: a carteira, com dono, e tudo que o ERP já sabe — quem comprou, quanto, quando, há quantos dias parou, qual o ticket, qual o risco. Vazio: a camada transacional do CRM — oportunidades, atividades, contatos, visitas e conversas começam em zero, porque esses fatos nunca existiram em lugar nenhum para serem carregados.
Essa assimetria é o ponto. O que a empresa já sabe, ela não digita de novo. O que ela nunca registrou, ela passa a registrar a partir de agora — sobre uma carteira que já está de pé.
Repare no que isso faz com a primeira semana: em vez de "vou alimentar o CRM até ele ficar útil", o gestor pergunta no dia um "quem da minha carteira parou de comprar?" — e a resposta existe, porque ela sempre existiu no ERP; só estava sem endereço.
O limite honesto, explícito: o zCRM não importa e não migra histórico. Não há cópia de notas, pedidos ou títulos para o banco do CRM, e não há escrita no ERP — cadastro errado se corrige no ERP. Também não é instantâneo: alguém precisa criar as views v_crm_* e apontar a conexão antes. E o vínculo automático não acerta 100%: cliente sem vendedor_codigo no ERP vira conta sem dono, e conta sem dono não aparece no escopo de carteira de ninguém — precisa ser atribuída na mão. Por fim, as métricas são de um job diário; só o drill por conta é ao vivo. Quem promete tempo real na carteira inteira está descrevendo outro produto.
Próxima leitura
- Integrar CRM ao ERP sem trocar o ERP: o que a PME precisa saber.
- ERP como fonte oficial: por que não duplicar cadastro de cliente no CRM.
- Checklist do primeiro dia: quais dados do ERP carregar no CRM.