Três meses depois, o dono pergunta por que a fábrica de embalagens não fechou os R$ 34 mil. O vendedor lembra vagamente. Alguém abre o ERP: a proposta 6288 está lá, com status "vencida". Nenhum pedido. Nenhuma nota. Nenhum título.
E aí acaba a investigação. O ERP guardou impecavelmente o que aconteceu — e não tem uma linha sobre por que parou de acontecer. Esse é o buraco que "unir o ciclo comercial" deveria tapar. A maioria das tentativas tapa outra coisa.
Quatro documentos, quatro granularidades
Antes de unir, vale enxergar que não são quatro versões da mesma coisa:
A proposta tem validade. É o único documento do ciclo que morre sozinho, por decurso de prazo. Ninguém precisa fazer nada para uma proposta vencer — e é exatamente por isso que ela vence.
O pedido tem saldo e data de entrega. Compromisso parcial e vivo: pode estar 60% faturado, com o resto prometido para o dia 20. Ele não morre; arrasta.
A nota é o realizado. Não tem futuro nem pendência. É fato consumado, e a única coisa do ciclo que o contador reconhece.
O título é o recebível. Nasce da nota, mas responde a outra pergunta: não "vendi?", e sim "recebi?". Um mês excelente de nota pode ser um mês péssimo de título.
Repare que a granularidade não bate. Uma proposta pode virar três pedidos; um pedido, cinco notas parciais; uma nota, seis títulos. Não existe linha reta ligando os quatro — e qualquer sistema que finja o contrário está mentindo em algum lugar.
Justapor não é unir
A tentativa mais comum é colocar tudo na mesma tela: aba Propostas, aba Pedidos, aba Faturamento, aba Financeiro. Fica bonito na demonstração — e continua sendo quatro relatórios. Você trocou quatro consultas no ERP por quatro abas no CRM: economizou cliques, não respondeu nada.
A prova é simples. Com as quatro abas abertas, tente dizer se o pedido 9102 nasceu da proposta 6288. Você não consegue — só consegue achar que sim, porque o cliente é o mesmo, o valor é parecido e a data é próxima. Achar não é dado: é a memória do vendedor com uma tela de fundo.
União é outra coisa: é a oportunidade carregar a chave da proposta e a chave do pedido. Só a chave permite responder "por que se perdeu" depois que a decisão já foi tomada.
O ponto exato onde o ciclo arrebenta
O ciclo não arrebenta dentro de um documento. Arrebenta no intervalo entre dois.
Entre a proposta que venceu e o pedido que nunca entrou, não existe documento nenhum — o ERP só registra o que virou papel. Naquele intervalo aconteceu uma ligação, um "vou levar para a diretoria", um silêncio de duas semanas, um concorrente com prazo melhor. Nada disso é documento. Tudo isso é a explicação.
É por isso que um CRM que só espelha documentos do ERP não une ciclo nenhum: reproduz, com mais cor, os mesmos vazios. Os quatro documentos são os pontos; faltava a linha entre eles — e a linha é conversa, não papel.
O que o CRM tem a dizer que o ERP não tem
Em três das quatro etapas, o CRM não tem nada de próprio a acrescentar. O valor faturado é o valor faturado. O saldo do pedido é o saldo do pedido. O título vence quando vence. Repetir isso numa tela mais bonita é trabalho de BI, não de CRM.
A proposta é a exceção. O ERP registra que ela venceu — e "vencida" não é motivo, é consequência. Por que o cliente disse não? Preço? Prazo? Foi para o concorrente? Sumiu sem responder? Nada disso está no ERP, e não está por uma razão legítima: não é dado fiscal, é dado comercial. É a única coisa do ciclo que nasce de uma conversa, não de uma transação.
Um detalhe de quem já abriu o ERP: muitos até têm campo de motivo de perda na proposta. O problema é o vocabulário. O ERP costuma oferecer meia dúzia de opções operacionais ("preço", "prazo de entrega", "outros motivos"), e faltam justamente as que explicam a venda perdida — "concorrente", "sem orçamento", "sem retorno". Um de-para resolve as que coincidem. As que não coincidem não são falha de mapeamento: são perguntas que o ERP nunca fez.
Erros comuns na costura do ciclo
- Vincular por semelhança. Casar proposta e pedido por cliente + valor + data aproximada funciona até o dia em que o cliente tem duas negociações abertas. Aí o histórico fica errado sem avisar ninguém — e erro silencioso é pior que ausência.
- Tratar "vencida" como desfecho. Vencida é a ausência de desfecho. Ganha e perdida são desfechos. Empilhar as três no mesmo bolo apaga o que se queria medir.
- Derivar um documento do outro dentro do CRM. É tentador calcular o faturamento a partir do pedido. Não faça: existe cancelamento parcial, devolução, faturamento em duas notas. O CRM que recalcula acaba discordando do ERP — e quem discorda do ERP perde a discussão.
- Achar que o vínculo é trabalho do sistema. Ligar o pedido à oportunidade custa dez segundos de quem está na negociação. Nenhuma heurística acerta isso melhor que a pessoa que atendeu.
Como isso se aplica no zCRM
A dor é a pergunta de três meses depois: por que este cliente parou entre a proposta e o pedido? Ela morre por falta de fio, não por falta de dado.
O zCRM lê cada documento de uma view própria do ERP — propostas, pedidos, notas, recebíveis. Nenhum é derivado do outro dentro do CRM. As abas Propostas, Pedidos, Faturamento, Produtos e Financeiro da conta bebem das mesmas views que alimentam os painéis gerenciais: por isso a conta e o painel do dono não discordam.
Sobre essa leitura, o CRM acrescenta três coisas que o ERP não tem:
O vínculo. A oportunidade guarda a chave da proposta e a chave do pedido do ERP. Há operação explícita para marcá-la como ganha, ligar a proposta e ligar o pedido — e cada vínculo vira evento no histórico da conta, com autor e data. É o que transforma quatro documentos soltos numa história com começo e fim.
A cobrança pela data do documento. As propostas em aberto que estão para vencer entram na Agenda pela própria data de validade, com o produto principal e a contagem dos demais itens. A proposta cobra follow-up sozinha.
A hierarquia do que está interrompido. Em Prioridades, proposta vencida sem ganho nem perda pesa mais que proposta apenas aberta (urgência 85 contra 55, ordenadas depois por valor). Por trás disso há uma opinião assumida: ciclo interrompido é mais urgente que ciclo lento.
A decisão que muda: em vez de "quanto faturamos", o gestor pergunta "onde o ciclo está parando, e em qual cliente isso vale mais". E "por que perdemos" passa a ter resposta com nome e número de documento.
O limite tem duas camadas. A primeira: o zCRM não escreve no ERP. Não gera proposta, não converte proposta em pedido, não fatura, não dá baixa em título. Não há CPQ, regra de preço nem aprovação de desconto. O ciclo é operado no ERP; o CRM lê, vincula e guarda a decisão comercial. O título é lido, não conciliado.
A segunda é a que dói: o elo mais frágil do ciclo é humano. Entre a proposta e o pedido está a conversa, e o registro de conversa no zCRM é manual — não há captura de WhatsApp, e-mail ou ligação. O mercado chama isso de captura de canais e vende como recurso; aqui não é recurso, é ausência declarada. O vínculo também é ação do usuário: nenhuma IA liga documento por você. O zCRM dá o lugar certo para registrar. Quem registra é gente.
Próxima leitura
- Proposta vencida: o dinheiro parado entre o ERP e o follow-up.
- Win/loss: como aprender com propostas ganhas e perdidas.
- Carteira a faturar: quando pedido em aberto vira problema comercial.