Acontaqueovendedorfazianamãoviroupropostaprontanacall

O contexto

Uma plataforma de infoprodutos vive de convencer produtores (quem vende curso, mentoria, assinatura) a trazer a operação para ela. Quase sempre o produtor já vende em outro lugar, e a pergunta dele é uma só: quanto eu economizo se mudar?

Responder pedia uma conta com muitas peças: taxa sobre a venda, valor por transação, mensalidade, área de membros por aluno, hospedagem de vídeo, parcelamento. Dos dois lados, para o faturamento e o ticket daquele produtor. E a conta era feita na mão, durante a call, com o cliente esperando.

A ferramenta que construí faz essa conta sozinha enquanto o vendedor preenche o cenário, e transforma o resultado em proposta, relatório técnico e deck. O que continua com o vendedor é o que só ele sabe: o que o produtor paga hoje e o que ele está disposto a conceder.

A dor

Com cada vendedor montando a conta do seu jeito, apareciam três problemas.

• Erro de cálculo em público. Um número errado na frente do cliente derruba a credibilidade da proposta inteira.
• Proposta sem padrão. Cada vendedor mandava um material diferente, com as cláusulas escritas do seu jeito.
• Dependência. Taxa negociada, meta de cashback, cláusula de exclusividade: o vendedor precisava confirmar com alguém antes de fechar.

A ferramenta precisava fazer a conta e devolver ao vendedor o controle da conversa.

O estudo

O primeiro passo foi separar o que muda de cliente para cliente do que é regra.

Regra é a tabela de custos de cada plataforma: itens, categorias e forma de cobrança. Isso não pode morar no código nem na cabeça do vendedor. Precisa estar num cadastro que o admin atualiza quando o concorrente muda o preço.

Cenário é o que o vendedor pergunta ao produtor: faturamento, ticket médio, alunos ativos, modelo de venda (recorrente, lançamento, perpétuo).

Negociação é o que o vendedor concede: taxa acordada, taxas personalizadas, cashback por meta, cláusulas.

Com isso separado, o motor de cálculo ficou previsível. Cada item de custo tem um tipo de cobrança (percentual, por transação, mensal, por aluno ou único, diluído em 12 meses) e pode valer só para certos modelos de venda. As transações saem de faturamento ÷ ticket, sem o vendedor estimar.

A outra premissa: quem usa está numa call, sob pressão, e não pode perder o fio da conversa. Isso guiou quase todas as escolhas de interface.

A solução

A conta roda a cada campo

A simulação é um passo a passo em cinco etapas: cenário, concorrente, serviços, negociações e resultado. Desde a segunda etapa, um painel lateral mostra a economia mensal e a projeção anual, e o valor muda a cada campo preenchido. O vendedor não precisa terminar o formulário para ter o que dizer.

Os custos do concorrente já vêm preenchidos pelo cadastro, mas todos são editáveis. Se o produtor diz “aqui eu pago menos que isso”, o vendedor ajusta na hora ou adiciona um custo que não estava previsto. Existe também o modo “não tenho concorrente”, para quem ainda não vende em lugar nenhum.

Negociação com trilho, decisão do vendedor

A etapa de negociações transforma o que era conversa solta em campos estruturados. A taxa acordada vem herdada da etapa anterior. As taxas personalizadas saem de um catálogo mantido pelo admin, com busca.

Cashback por meta de faturamento, cláusula de exclusividade e observação de produto high ticket são interruptores. Ligados, entram na proposta com o texto padrão. Desligados, a seção aparece como “sem acordo”. O que conceder é escolha do vendedor. O texto da cláusula, não.

Da conta ao material, sem sair da tela

No resultado, a economia aparece em letras grandes, com a redução percentual e o nome do concorrente comparado. Logo abaixo ficam as saídas: modo apresentação, envio ao CRM, relatório técnico e duas variantes de proposta, uma para quem acompanha o cliente e outra para quem fecha a venda.

O modo apresentação gera um deck a partir da simulação: capa com o nome do cliente, cenário, custos lado a lado, percentual de redução, projeção em 12, 24 e 36 meses, bônus incluídos e fechamento. Dá para voltar ao wizard sem perder o que foi preenchido, um vai-e-volta que chegou a apagar dados e foi corrigido.

Os PDFs são gerados no próprio navegador, com um motor de componentes compartilhado entre proposta, relatório técnico e tabela de parcelamento. Por isso a identidade visual é a mesma em todos. Ao renderizar o PDF de verdade, e não só testar a lógica, apareceu um erro antigo: a última coluna da tabela vazava alguns milímetros da margem. Ninguém tinha visto antes.

Parcelamento como argumento de venda

Um segundo simulador responde outra pergunta comum: o que acontece quando o comprador parcela? São três abas: com juros (o cliente paga), sem juros (o produtor absorve) e cashback sobre os juros. O cashback foi aba própria, foi mesclado na aba com juros e voltou a ser aba própria depois que o cliente viu as duas versões no ar.

Detalhes pesam em quem digita com pressa. Os campos de valor funcionavam como maquininha de cartão: digitar num campo preenchido acrescentava dígitos ao valor antigo. Agora o campo zera no foco e restaura o valor se nada for digitado. E o rascunho fica salvo no navegador: se a aba fechar no meio da call, o vendedor retoma de onde parou.

No celular também

No celular, o resumo vira uma barra fixa acima dos botões, que abre como painel. A estrutura da tela é uma só nos dois tamanhos. Antes, trocar entre a versão desktop e a mobile recarregava a página e apagava o formulário em edição.

Histórico e regras de negócio num só lugar

Toda simulação salva vai para um histórico com status (em aberto, fechada, perdida), indicação de envio ao CRM e exportação em CSV. O admin mantém os cadastros que alimentam o cálculo: concorrentes, categorias, itens de custo, serviços oferecidos como bônus e o catálogo de taxas.

De MVP a produto

A primeira versão nasceu no Lovable, com banco, login e arquivos no Supabase. Serviu para validar a ideia. Para virar ferramenta de trabalho, precisava de controle: deploy previsível, regras de acesso no servidor e não no navegador, dados sob guarda do cliente.

Por isso a migração foi decisão de produto, não só técnica. Entraram API própria (Node e Express) e PostgreSQL em container, e o front perdeu o acesso direto ao banco. O login virou código de seis dígitos por e-mail, liberado só para domínios corporativos. O envio ao CRM ganhou modo de simulação e registro de cada tentativa. E promover alguém a administrador ficou fora do painel, de propósito.

O que mudou

A migração saiu do Lovable sem perda de dados: usuários, cadastros e histórico vieram com os identificadores preservados, e as senhas antigas continuaram valendo. Uma bateria de testes (API, unidade, ponta a ponta no desktop e no celular, infraestrutura) achou três bugs reais e fechou a segunda rodada com todos os casos passando. Um deles: o banco devolvia decimais como texto, e a calculadora mostrava “NaN”.

O que era feito na mão. A conta de economia, montada por cada vendedor do seu jeito durante a call, e a proposta escrita depois, com as cláusulas redigidas por ele.

O que ficou automático. O cálculo a cada campo preenchido, as transações derivadas de faturamento ÷ ticket, o deck, a proposta em PDF, o relatório técnico, a tabela de parcelamento e o envio ao CRM.

Onde a pessoa decide. O vendedor edita qualquer custo do concorrente, escolhe o que concede na negociação e decide quando enviar. O admin mantém o cadastro que alimenta a conta. Promover alguém a administrador fica fora do painel.

O que eu levo desse projeto

Ferramenta interna costuma ser tratada como produto de segunda linha. Mas quem usa esta está numa conversa que vale dinheiro, e cada segundo de hesitação diante do cliente custa.

A decisão central foi tirar a regra da cabeça das pessoas e pôr num cadastro. O resto veio disso: número ao vivo, negociação com trilho, material pronto.

E a lição de processo: validar no artefato final. O erro de margem do PDF e o formulário que sumia ao virar o celular só apareceram quando alguém abriu o arquivo e usou a tela de verdade.