O que dá errado no dia do show, e o que fica registrado

Todo evento tem uma história paralela que não entra em relatório nenhum: o som que chegou atrasado, o camarim que não existia, o gerador que faltou, o contratante que mudou o horário na véspera.

Essas histórias circulam entre quem estava lá. Viram piada na volta de van. E somem — até o próximo show no mesmo lugar, com o mesmo fornecedor, quando o problema acontece de novo e alguém diz "é, da última vez também foi assim".

O custo de não registrar é cumulativo

A perda não é do evento em que o problema aconteceu. Ali houve prejuízo, mas foi resolvido de algum jeito. A perda real é que a informação não sobrevive até a próxima decisão.

Três decisões ficam pior sem esse histórico:

Aceitar ou não o mesmo contratante. Quem atrasou pagamento, mudou condição na véspera ou não cumpriu o rider é informação comercial. Sem registro, o próximo vendedor fecha nas mesmas condições.

Precificar a praça. Cidade onde sempre falta estrutura tem custo de contingência real. Se isso não está em lugar nenhum, o preço sai igual ao de onde tudo funciona.

Escolher fornecedor. Locação de som que já falhou duas vezes continua sendo contratada porque quem contrata hoje não é quem estava lá.

Registro precisa ser fácil, senão não acontece

Aqui está a parte difícil, e vale ser honesto: quem está no evento não vai preencher formulário. Está trabalhando, quase sempre sob pressão, muitas vezes de madrugada.

Isso dá duas exigências práticas ao registro:

• Precisa caber numa frase. "Gerador não chegou, resolvido às 21h com aluguel local" é suficiente. Exigir categoria, gravidade e causa raiz garante que ninguém preencha.
• Precisa estar preso ao evento, não a uma caixa de e-mail. Anotação que vive no WhatsApp da produção não é histórico — é conversa, e some junto com o aparelho de quem saiu.

O status importa mais do que a classificação: saber se aquilo foi resolvido, e quando, é o que diferencia incidente contornado de problema em aberto no fechamento. E um problema pode voltar — o mesmo fornecedor falhando de novo reabre o assunto em vez de criar um caso novo, e é assim que o padrão fica visível.

Nem toda ocorrência é do fornecedor

Vale uma distinção que evita transformar o registro em lista de reclamações: boa parte do que dá errado tem origem interna.

A proposta que não detalhou o que estava incluso e gerou expectativa diferente dos dois lados. O rider enviado com a versão antiga. A equipe dimensionada para um formato e escalada para outro. A data confirmada para o artista antes de conferir o deslocamento anterior.

Registrar isso é desconfortável, e é exatamente por isso que vale. Um histórico em que todos os problemas são culpa de terceiros não é histórico — é narrativa, e não ajuda a melhorar nada. Quando aparece que três dos últimos cinco incidentes nasceram de proposta mal especificada, a correção deixa de ser "escolher fornecedor melhor" e passa a ser algo que a própria operação controla.

O tom do registro ajuda: descrever o que aconteceu, não quem errou. "Rider enviado em versão desatualizada" é utilizável; "fulano mandou errado" faz com que ninguém mais registre nada.

O fechamento é o momento certo de perguntar

Existe uma janela em que o registro é natural: o fechamento do evento, quando o repasse é calculado e alguém já está olhando aquele show de novo.

É o momento em que a memória ainda está fresca e em que há motivo prático para lembrar — custo extra precisa ser explicado. "Por que apareceu locação de gerador nesse evento?" é exatamente a pergunta que produz o registro sem que ninguém precise ter disciplina.

Por isso o registro de ocorrências e o fechamento do evento andam juntos: o custo não previsto e a ocorrência que o causou são a mesma informação vista de dois lados. Separá-los em sistemas diferentes garante que ninguém cruze os dois.

O que fazer com o que foi registrado

Registro que ninguém lê é burocracia. Três usos concretos justificam o esforço:

• Antes de fechar com o mesmo contratante, olhar o que aconteceu das outras vezes. Leva trinta segundos e muda a negociação.
• Ao montar orçamento de praça conhecida, incluir a contingência que a experiência mostra ser necessária, em vez de descobrir na hora.
• Na revisão do rider, transformar o que falhou repetidamente em cláusula explícita. Rider é documento vivo, e a ocorrência é a matéria-prima da próxima versão — o que conversa direto com o catálogo de tipos de show, onde o formato define o que precisa estar lá.

Vale uma expectativa realista: nada disso elimina imprevisto. Evento ao vivo tem variável demais, e sempre vai ter. O objetivo é menor e alcançável — que o mesmo imprevisto não surpreenda duas vezes.

A disciplina de olhar para trás sem procurar culpado é o que a engenharia chama de post-mortem, e o raciocínio é idêntico ao que a Sapienza descreve em por que projetos de software falham: o padrão só aparece quando alguém registra o caso isolado.

No Dominus.Booking a ocorrência é registrada no próprio evento, em texto livre, com estado de resolvido e possibilidade de reabrir. É deliberadamente simples — porque registro que exige esforço não é feito, e registro que não é feito não vira histórico. É o que sustenta a proposta que vira evento na vez seguinte: a mesma praça, o mesmo contratante, agora com o que já se sabe.