O problema
A agência vende excursão: ônibus fretado, roteiro montado, saída marcada. Cada viagem tem um número fixo de assentos, e cada assento vendido tem um preço que depende de quem senta nele.
Tudo isso vivia em planilha compartilhada, editada por três pessoas ao mesmo tempo. Funciona até o dia em que para de funcionar, e o jeito como para é sempre o mesmo: duas pessoas vendendo o último lugar do ônibus, um pagamento que ninguém marcou como recebido, um preço digitado errado numa linha que ninguém revisou.
O custo não aparece como prejuízo contábil. Aparece no atendimento: alguém liga para desfazer uma venda, alguém viaja em pé, alguém descobre no embarque que pagou diferente do vizinho de poltrona. Cada um desses episódios consome horas de quem deveria estar vendendo a próxima viagem, e desgasta a relação com um cliente que costuma voltar todo ano.
Já tinham tentado disciplinar a planilha com regra combinada entre as três pessoas. Regra combinada não sobrevive à alta temporada.
As restrições
As decisões
Idade calculada na data da viagem
O preço de excursão varia por faixa etária, e uma criança pode mudar de faixa entre a compra e o embarque. Calcular na compra é mais simples de implementar e gera cobrança errada meses depois, sempre a favor da agência, sempre descoberto pelo cliente no ônibus.
Congelar o preço na compra. Descartado: transfere o erro para o atendimento no dia da viagem.
A vaga é reservada antes do pagamento, e a reserva expira sozinha
O assento sai do estoque no instante em que alguém começa a comprar, e volta se o pagamento não vier dentro da janela. Um bloqueio curto em memória resolve, sem depender de ninguém lembrar de liberar.
É a única forma de duas atendentes venderem ao mesmo tempo sem vender o mesmo lugar, que era exatamente a falha que a planilha não conseguia evitar.
Confirmar a vaga só depois do pagamento aprovado. Descartado: abre uma janela em que o assento está vendido e disponível ao mesmo tempo, e é justamente na alta temporada, com duas vendas simultâneas, que a janela importa.
A planilha continua sendo verdade até a última etapa
A migração foi desenhada por partes: primeiro o cadastro de viagem e a venda, depois o pagamento, depois o embarque. Enquanto uma etapa não migra, a planilha segue como fonte para aquela etapa, com importação de mão dupla.
Custa mais trabalho do que trocar tudo de uma vez, e é a razão de a proposta caber na alta temporada. Um sistema que exige parar a venda para entrar não entra.
Virada única, com data marcada para a operação inteira mudar de lugar. Descartado: concentra todo o risco num dia, e se esse dia der errado a agência perde vendas que não voltam, porque a excursão sai com o ônibus vazio.
O resultado
O trabalho parou no levantamento e na arquitetura, e é isso que foi entregue: o mapa da operação como ela realmente funciona, as decisões acima com as alternativas descartadas registradas, e o desenho técnico que sustenta a substituição por etapas.
A mudança concreta, antes de qualquer linha de código, foi de clareza. As três pessoas que operavam a planilha passaram a ter escrito o que cada uma faz, onde uma pisa na outra, e em que ordem trocar cada pedaço sem parar de vender.
Não há número aqui porque não houve sistema em produção para medir. Quando houver, os indicadores que importam já estão definidos: quantas vendas duplicadas acontecem por temporada, e quanto tempo de atendimento é gasto corrigindo o que a planilha deixou passar.
ficha técnica
- stack
- Next.js · NestJS · PostgreSQL · Redis
- papel
- Levantamento e arquitetura de solução