O cronograma de implantação de CRM que a PME costuma receber é dividido por módulo: semana 1 cadastro, semana 2 funil, semana 3 atividades, semana 4 relatórios. Parece organizado. Só que ele foi desenhado para um CRM que começa vazio — onde alguém precisa digitar cliente por cliente antes de qualquer coisa funcionar, e por isso faz sentido liberar o sistema por pedaços.
Quando o CRM lê o ERP, esse cronograma está errado desde a primeira linha. Não porque seja ambicioso demais, mas porque recorta pelo eixo errado.
O corte não é por módulo. É por quem digita
Divida tudo que uma implantação precisa entregar em duas pilhas.
Na primeira pilha está a carga: contas, nomes, histórico de faturamento, pedidos, propostas, recebíveis, produtos, potencial de compra, os próprios usuários. Nada disso é trabalho de vendedor: já existe no ERP, e a implantação só precisa buscar. É uma sequência de comandos, e a unidade de medida é hora.
Na segunda pilha está o hábito: registrar a conversa que aconteceu, abrir a oportunidade com valor e etapa, planejar a visita, concluir a atividade. Nada disso existe no ERP, porque nunca foi escrito. Aqui a unidade de medida não é hora — é repetição. Não há comando que instale hábito.
O cronograma por módulo mistura as duas pilhas em toda semana, e com isso dá à primeira um tempo que ela não precisa e à segunda um tempo que não basta. Os 30 dias existem por causa da segunda pilha. Só dela.
A carga: horas, não semanas
A ordem real é curta e roda antes de o time comercial ver a tela.
Primeiro crm:validate-erp-views, que confere o contrato das 17 views de integração: se existem, se têm as colunas esperadas e se os tipos batem. Essa etapa é a que descobre no dia 1, e não no dia 20, que falta expor a view de propostas.
Depois crm:sync-erp-accounts, que traz as contas, e crm:backfill-account-names, que preenche o nome — o CRM guarda o nome/fantasia junto com o vínculo, e por isso nenhuma tela mostra código cru de cliente, nem no primeiro dia. Por fim crm:sync-account-metrics, que calcula recência, frequência e valor. Em base defasada, --anchor-latest ancora o cálculo na data da nota mais recente, para "cliente parado há 90 dias" não ser efeito de a base estar atrasada.
Usuário também é importado, não cadastrado. A sincronização de contas cria um stub para cada vendedor dono de carteira; POST /api/admin/users/import reconcilia esse stub pelo código do vendedor, copia o hash de senha vindo do ERP e atribui o papel de vendedor. Consequência prática: não existe distribuição de senha nova na implantação. O vendedor entra com a senha que ele já usa.
Terminada essa sequência, a Conta 360 abre com faturamento, pedidos, propostas, financeiro, produtos, potencial e RFM. Numa base real, essa carga cobriu 3.309 contas. Ninguém digitou nenhuma delas.
Semana 1: o que fazer com o tempo que sobrou
Como a carga não consome a semana, a semana 1 serve para outra coisa: descobrir o que no cadastro do ERP vai atrapalhar.
A tela de Saúde dos dados roda 18 checagens sobre a base — cliente sem vendedor, sem CNPJ, CNPJ inválido ou duplicado, cliente sem contato, pedido em aberto sem data de entrega, inativo com pedido aberto, proposta vencida ainda aberta — e devolve cada uma com contagem, percentual de OK e uma amostra com nome de cliente. Isso troca a reunião de opinião ("nosso cadastro é ruim") por uma lista de trabalho com dono.
Nomeie o limite aqui: essa lista é corrigida por gente, no ERP. O CRM lê e aponta; não escreve no ERP e não conserta cadastro sozinho.
A semana 1 fecha ainda com permissões e carteira definidas — quem vê qual empresa, qual vendedor, e quem pode ver financeiro. É pré-requisito, não projeto: sem isso, o vendedor abre uma lista que não é a dele.
Semanas 2 a 4: a única coisa que leva 30 dias
Aqui está o trabalho de verdade, e ele é chato de admitir: são três semanas para conseguir que alguém registre uma conversa depois de desligar o telefone.
A boa notícia é que a rotina que se pede ao time não precisa ser configurada, porque vem derivada. Prioridades do dia já monta a fila com o que o ERP sustenta: proposta vencida, proposta em aberto, cliente para reativar, cliente em recuperação, entrega vencida e financeiro vencido para quem tem permissão. E a próxima ação de cada conta é a menor data entre os itens pendentes daquela conta — um campo a menos para configurar, porque ele se calcula sozinho.
Então o pedido ao vendedor é pequeno e específico, e cabe em três semanas: abra a fila de manhã, e quando o atendimento acontecer, registre a conversa e, se houver dinheiro em jogo, abra a oportunidade. Só isso. Conversa, oportunidade, contato próprio do CRM, atividade e visita são 100% humanos — não vêm do ERP e não virão.
Uma configuração fica de propósito para uma segunda rodada, depois que houver uso: recalibrar os cortes de RFM pelos quintis reais da base, ajustar a carência de vencido (padrão de 3 dias, com faixa verde até 2% e âmbar até 10%) e mapear os motivos de perda com o de-para do ERP. Nada disso trava a semana 1, e todos ficam melhores com duas semanas de dado real do que com um chute no kickoff.
Erros comuns nesse sequenciamento
- Prometer captação de leads na semana 4. Não existe lead independente do ERP. Um plano de implantação que promete topo de funil está descrevendo outro produto.
- Prometer migração de conversa antiga. O histórico que entra é o transacional do ERP. E-mail e WhatsApp antigos não entram, porque não há captura de canal.
- Adiar a Saúde dos dados para "depois que estabilizar". É o inverso: defeito de cadastro só fica mais caro depois que o time começou a confiar na fila.
- Tratar o esforço do cliente como zero. O ERP precisa expor as views do contrato, e alguém precisa corrigir cadastro. Isso é gente, não comando.
- Configurar RFM antes de ter uso. Calibrar régua sem base calculada é opinião com número.
Como isso se aplica no zCRM
O projeto de CRM que morre no meio costuma morrer assim: gastou seis semanas em carga de dados e chegou ao vendedor sem fôlego.
O zCRM ataca isso porque a carga vem do que já existe: as 17 views do contrato, validadas antes de tudo; contas, nomes, RFM e usuários sincronizados por comando; Conta 360 com histórico transacional no dia 1; 18 checagens de Saúde dos dados para virar lista de trabalho; Prioridades do dia e próxima ação derivadas, sem configuração.
O cronograma é que muda: em vez de negociar quais módulos entram em qual semana, você separa o que se importa do que se instala como hábito, dá horas ao primeiro e as três semanas restantes ao segundo.
O limite honesto: 30 dias é um plano de escopo, não uma garantia de resultado — este texto não promete percentual de melhoria em prazo nenhum. A implantação não escreve nada no ERP, não traz lead de fora do ERP, não importa conversa, e-mail ou WhatsApp, e não inclui migração de outro CRM, campos customizados ou automações configuráveis. O que ela entrega em 30 dias é o histórico do ERP virando fila de trabalho — e uma equipe que começou, com apoio, a registrar o que só ela sabe.
Próxima leitura
- Qualidade dos dados do ERP: por que CRM bom depende de cadastro confiável.
- Permissões no CRM: como dar visibilidade sem abrir informação sensível.
- Acompanhamento de uso do CRM: como saber se o time adotou de verdade.