Quando o produto é uma data: a operação de quem vende evento

Existe uma família de negócios que compartilha um traço estrutural e raramente é tratada como categoria: aqueles cujo produto acontece num dia marcado e não acontece em nenhum outro.

Show, casamento, feira, congresso, formatura, produção audiovisual com janela de gravação. São mercados diferentes, com margens e clientes diferentes, e com o mesmo conjunto de restrições operacionais — restrições que a maioria das ferramentas de gestão simplesmente não modela.

Três restrições que mudam tudo

O prazo não se move. Em quase todo negócio de serviço, atraso é ruim mas negociável: entrega na semana seguinte, o cliente reclama, a vida segue. Aqui não existe semana seguinte. O que não foi entregue no dia não foi entregue — e o cliente não tem como aceitar um substituto, porque o público dele já foi convidado.

Isso muda a natureza do risco. Em projeto normal, o pior caso costuma ser custo maior e prazo mais longo. Aqui o pior caso é binário.

A capacidade é finita e disputada. Duas propostas para o mesmo sábado não são duas oportunidades: são uma oportunidade e um problema. Quem trabalha com data sabe disso intuitivamente, mas quase nenhum sistema comercial trata assim — o funil genérico registra as duas, soma as duas na previsão de receita e não avisa ninguém.

O efeito prático é uma previsão que superestima sistematicamente, porque conta como possível o que é mutuamente exclusivo.

O erro não tem segunda chance. Um documento errado num contrato normal se corrige com aditivo. Um equipamento que não chegou ao palco não se corrige com nada. Essa assimetria justifica um nível de conferência prévia que, em outros negócios, pareceria exagero.

O ponto onde a maioria falha

Pela nossa experiência implantando operações assim, o problema quase nunca está na execução do dia. Equipe de evento é boa em resolver no improviso — é literalmente o ofício.

O problema está no compromisso assumido antes, em geral por uma dessas três vias:

A disponibilidade confirmada de memória, por telefone ou mensagem, sem que nada fique bloqueado. A pessoa que confirmou sabe que aquele dia está ocupado; o sistema, não; o colega, muito menos.

O aceite que não bloqueia. O cliente diz sim, todo mundo comemora, e a data continua tecnicamente livre até alguém lembrar de marcar. Entre uma coisa e outra existe uma janela em que dois vendedores podem fechar o mesmo dia.

A condição combinada fora do documento. "Eles vão fornecer o som" dito numa ligação e não escrito em lugar nenhum vira custo não previsto na véspera — e discussão sobre quem disse o quê.

As três têm a mesma correção: o compromisso precisa produzir um efeito no sistema no instante em que é assumido, e não depois. É o que o time do Dominus.OS descreve ao tratar conflito de agenda como trava e não como aviso — um alerta que pode ser ignorado não protege data nenhuma.

Material comercial que circula e envelhece

Há um problema específico desse mercado e que pouca gente trata: a proposta e o material de apresentação ficam circulando por semanas, às vezes meses, entre pessoas que não conversam entre si.

O contratante recebeu uma apresentação em março, encaminhou para o patrocinador em abril, e em maio pergunta sobre uma condição que já mudou duas vezes. Se ninguém sabe qual versão ele tem em mãos, a conversa vira disputa de memória — e quem perde é sempre quem não tem o documento.

Isso não se resolve com cuidado; resolve-se com versão. Cada material enviado precisa ter identidade, e precisa ser possível responder "o que exatamente essa pessoa recebeu, e quando". É a mesma disciplina que qualquer empresa aplica a contrato, aplicada ao que vem antes do contrato — e é onde a maioria relaxa, porque "ainda é só uma proposta".

Medir o que sobrou, não o que foi fechado

A métrica que domina esse mercado é o valor fechado. É a mais fácil de obter e a menos útil para decidir.

Dois contratos do mesmo valor podem ter resultados muito diferentes depois de considerar deslocamento, equipe, estrutura que o contratante prometeu e não entregou, e imposto. O único jeito de saber é medir o resultado por evento realizado, com todos os custos atribuídos àquele dia.

Quando isso existe, três perguntas passam a ter resposta:

• Qual formato de entrega dá mais margem, e não mais receita.
• A partir de que distância o evento fora da praça deixa de compensar.
• Qual cliente sempre gera custo extra não previsto, apesar de negociar bem.

A terceira é a mais incômoda e a que mais muda comportamento comercial. É o mesmo raciocínio que aplicamos a contratos de projeto em escopo aberto versus escopo fechado: preço fixo com custo variável transfere risco para quem executa, e só se enxerga isso medindo depois.

O que registrar, e o que não vale a pena

Operação de evento tem uma resistência legítima a processo: quem está em campo não preenche formulário, e sistema que exige isso é abandonado na primeira semana.

A regra prática que funciona é registrar pouco e no momento certo:

No fechamento comercial — o que foi combinado, incluindo o que a outra parte se comprometeu a fornecer. É o que evita a discussão da véspera.

No aceite — o bloqueio da data e o congelamento dos valores. Depois disso, número que muda na tela é fonte de conflito.

No fechamento financeiro — os custos reais e as ocorrências que os causaram. É o único momento em que alguém tem motivo prático para lembrar, porque precisa explicar a despesa.

Tudo o mais é opcional. Tentar registrar durante a montagem é desejar um comportamento que não vai acontecer.

Por que isso raramente cabe em ferramenta genérica

Não é que CRM comum seja ruim. É que ele foi desenhado para um funil onde a data é consequência da venda, e aqui ela é o recurso escasso que a venda disputa.

Adaptar exige gambiarra: campo personalizado para a data, calendário separado que alguém sincroniza à mão, planilha paralela de custos por evento. Funciona por um tempo e quebra exatamente quando o volume cresce — que é quando importa.

Na Sapienza, quando o cliente descreve esse conjunto de restrições, tratamos como categoria própria de operação, e não como CRM com campos extras. É a mesma leitura por trás do Dominus.Booking, em que a proposta aceita vira evento e bloqueia a agenda no mesmo movimento — porque, quando o produto é uma data, é a data que precisa estar no centro do modelo.