Proposta assinada na sexta, cobrança no dia 5

A proposta foi assinada na sexta às cinco da tarde. A primeira cobrança precisa sair no dia 5. Entre esses dois momentos existe um trecho curto que, na maioria das empresas, é o mais frágil de toda a operação — e é frágil porque é feito à mão.

Alguém abre a proposta assinada, lê o valor, abre o sistema financeiro, cadastra o cliente de novo, digita o valor, escolhe o vencimento, define a recorrência. Quatro ou cinco campos digitados a partir de um documento. Cada um deles é uma chance de errar, e o erro só aparece semanas depois, no fechamento.

Os três erros que esse trecho produz

Valor divergente. O desconto que foi concedido na proposta não foi replicado na cobrança, ou foi replicado errado. O cliente recebe um boleto diferente do que assinou e liga reclamando — com razão, e com o documento na mão.

Cliente duplicado no financeiro. Quem cadastra às pressas não procura antes, e a mesma empresa passa a existir duas vezes. A partir daí, o relatório de inadimplência conta dois clientes onde há um, e a régua de cobrança manda lembrete de um título que já foi pago no outro cadastro.

Atraso silencioso. É o mais comum e o menos percebido. A proposta foi assinada na sexta, mas quem lança no financeiro só trabalha às segundas. A primeira cobrança sai com uma semana de atraso, o ciclo inteiro se desloca, e ninguém registra isso como problema porque o dinheiro acabou entrando.

O aceite como evento, não como documento

A mudança conceitual é tratar o aceite como um evento que dispara consequências, e não como um arquivo que alguém precisa ler.

Quando a proposta é assinada por token, o sistema sabe exatamente o que foi aceito: quais itens, em qual quantidade, com qual desconto, em quantas parcelas. Essa informação é estruturada — não precisa ser interpretada por um humano para virar um lançamento.

No aceite, três coisas acontecem juntas: o contrato é gerado a partir do modelo, o cliente é vinculado ao cadastro que já existe (não a um novo), e o título a receber nasce com o valor e o cronograma que estavam na proposta.

O que continua exigindo decisão humana

Não vale prometer que tudo é automático, porque não é. Três coisas costumam continuar sendo decisão:

• A data do primeiro vencimento. "Todo dia 5" é regra fácil; "trinta dias após a entrega" depende de saber quando foi a entrega. Quando o serviço tem implantação, a régua começa em um marco que alguém confirma.
• A conferência do que foi negociado fora do modelo. Se o vendedor combinou uma condição que não existia no catálogo, alguém precisa olhar. O sistema pode sinalizar a exceção; não pode aprová-la sozinho.
• O cadastro fiscal. Emitir cobrança precisa de menos dados do que emitir nota. Inscrição estadual, regime tributário e endereço completo costumam ser completados depois, e é melhor que sejam — exigir tudo na proposta derruba a assinatura.

A automação certa reduz o trabalho ao que exige julgamento. Ela não elimina o julgamento.

Contrato gerado não é contrato revisado

Um cuidado que economiza dor de cabeça: gerar o contrato automaticamente a partir de um modelo é ótimo enquanto o modelo estiver certo. Um erro no modelo se replica em todos os contratos gerados, silenciosamente, até alguém notar.

A prática que recomendamos é versionar o modelo e registrar, em cada contrato, qual versão o originou. Assim, quando um problema aparece no contrato de março, é possível saber exatamente quais outros contratos nasceram do mesmo molde.

O efeito no fluxo de caixa

Há um ganho que só aparece depois de alguns meses e que costuma ser o mais relevante para quem decide: previsibilidade. Quando todo aceite gera título na mesma hora, a projeção de recebimento passa a existir de verdade, porque nada está esperando ser lançado.

O contrário disso é a situação comum em que o financeiro descobre no dia 3 que existem quatro contratos assinados no mês anterior que ninguém lançou. A projeção estava errada e a decisão tomada com base nela também.

Esse tipo de gargalo entre duas etapas é o que a Sapienza chama de sinal clássico de falta de integração, em quatro sinais de que sua empresa precisa de integração de sistemas.

Recorrência e reajuste: o que precisa estar definido no aceite

Contrato de serviço recorrente carrega duas informações que costumam ser combinadas verbalmente e depois viram discussão: por quanto tempo a cobrança se repete e como o valor é atualizado.

A duração é a mais simples de esquecer. Recorrência sem fim definido continua gerando cobrança depois que o serviço acabou, e a descoberta acontece quando o cliente reclama — o que é constrangedor e, dependendo do caso, exige devolução.

O reajuste é o que gera mais atrito quando não está escrito. Índice, periodicidade e data-base precisam estar na proposta que foi aceita, não numa conversa. Quando estão, a atualização anual é um aviso; quando não estão, é uma renegociação inteira com um cliente que já se acostumou ao valor antigo.

O ponto comum aos dois é que a informação nasce na venda e é consumida pelo financeiro meses depois. Quando as duas pontas moram no mesmo registro, o que foi combinado é o que é aplicado — que é, no fundo, o ganho do ciclo inteiro numa base só.

O que muda no dia seguinte

Ninguém abre a proposta assinada para ler o valor. O título existe desde o aceite, a régua de cobrança começa a contar sozinha, e o que sobra para o financeiro é a exceção — o cliente que pediu para mudar o vencimento, o contrato com condição especial. A emenda entre vender e cobrar é uma das que o Dominus.CRM existe para eliminar.