Como funciona o pré agendamento na prática
O pré agendamento é basicamente uma forma de reservar um horário antes da confirmação final. Eu já perdi conta de vezes que vi gente confundir isso com agendamento comum, e o resultado é sempre o mesmo: hora marcada duas vezes, cliente reclamando, e ninguém com culpa. A diferença entre pré agendamento e agendamento definitivo é simples mas muita gente não lê direito. No pré, você segura uma vaga temporariamente. Pode ser 15 minutos, 2 horas, um dia inteiro — depende da sua regra. O agendamento confirmadonão volta. Quando chega o dia, o horário está ocupado, ponto.
pré agendamento ou pré agendamento: qual o certo?
Essa dúvida aparece o tempo todo. Tecnicamente, as duas formas estão corretas, mas o uso varia conforme o contexto. Se você está falando do sistema, do processo, use "pré agendamento". Se está num título de documentação ou menu de software, a versão com "ou" aparece mais porque às vezes o campo no formulário pede isso. Não tem erro grave em nenhuma das duas. O que realmente importa é como o sistema trata cada estado. Eu trabalho com plataforma de agendamento há anos e já vi implementação que deixa o pré ativo por 48 horas sem nenhum aviso ao usuário. Resultado? Todo mundo marcava horário, esquecia, e o sistema enchia de vagas fantasmas que ninguém usava.
O problema que ninguém conta
Existe um detalhe técnico que a maioria dos tutoriais ignora: o timeout do pré agendamento. Quando o pré expira, o horário volta pro pool disponível automaticamente? Sim, na maioria dos sistemas modernos. Mas aqui vai a parte que dá trabalho — e eu sei porque passei por isso na última semana. Tive um caso onde o sistema de pré agendamento de um cliente tinha configuração de timeout em 30 minutos, mas a integração com o gateway de pagamento estava lenta. O cliente clicava em confirmar, o pagamento levava 2 minutos pra processar, e o pré já tinha expirado. O sistema cancelava o agendamento antes mesmo do pagamento ser aprovado. Perdi três horas num dia entendendo por que os horários sumiam.
A solução foi simples: aumentar o timeout do pré para 5 minutos e adicionar um status intermediário "pagamento pendente" que trava o horário sem liberar. Antes disso, eu testava manual mesmo — entrava no sistema, via o log, e ajustava.
Como configurar corretamente
Vamos começar pelo mais importante: definir a duração do pré. Recomendação prática que funciona na maioria dos casos é entre 10 e 15 minutos pra agendamentos rápidos, e até 24 horas pro que envolve consulta ou atendimento presencial com documentação. Não precisa ser complicado. O campo de validação é onde a maioria erra. Se você não setar um campo "data_expiracao" no banco, o sistema não consegue limpar os pré automaticamente. Aí vira uma bola de neve: horários ocupados que nunca serão usados, lista de espera crescendo, e cliente furioso porque o sistema mostra disponibilidade mas na hora de confirmar dá erro.
Use um cron job ou um listener de eventos. Eu prefiro listener porque é mais barato computacionalmente e funciona em tempo real. Quando o timer do pré chega no zero, você dispara um evento que libera o horário de volta. Simples.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Pegadinhas que custaram caro
A primeira: horário de verão e fuso horário. Eu vi sistema que guardava a data do pré em UTC mas exibia em horário local sem conversão. Resultado? O pré expirava 3 horas antes ou depois do que o usuário via na tela. Isso gera reclamação direta, perda de confiança, e perda de receita. A segunda: concorrência real. Duas pessoas clicam em "confirmar" no mesmo horário de pré ao mesmo tempo. Quem ganha? O sistema precisa ter lock otimista ou pessimista. Eu recomendo otimista porque é mais simples de implementar e funciona bem quando a taxa de colisão é baixa. Se seu negócio tem pico de acessos, aí vai precisar de pessimista mesmo.
A terceira: cancelamento manual. O cliente cancela o pré antes de confirmar. O sistema libera o horário instantaneamente? Deveria. Mas eu vi sistemas que deixavam o horário bloqueado por mais 10 minutos depois do cancelamento. O cliente precisava ligar pra reclamação. Isso não é aceitável num sistema moderno.
Quando o pré agendamento não funciona
Vou ser direto: em serviços com demanda extremamente alta e capacidade limitada, o pré agendamento pode piorar a experiência. Se você tem 5 vagas por dia e 500 pessoas tentando marcar, cada pré bloqueia uma vaga que alguém poderia usar. Nesse cenário, recomendo sistema de fila ou loteria, não pré. Também não funciona bem quando o tempo de confirmação é variável. Se você precisa de aprovação manual, avaliação de documentação, ou qualquer coisa que leve mais de alguns minutos, o pré se torna uma armadilha. O cliente acha que está garantido, mas na verdade só está na fila de espera.
Alternativa: sistema de notificação de cancelamento. Em vez de pré, o cliente se cadastra numa lista e recebe aviso quando uma vaga aparece. É menos friccional, não bloqueia recursos, e funciona melhor quando a demanda flutua muito.
O que eu faria diferente hoje
Se eu fosse montar um sistema de pré agendamento do zero, começaria pela experiencia do usuário. Mostrar claramente o timer contando, o status do pré, e o que acontece quando expira. Nada de silêncio. Se o pré expirar, o usuário deve receber notificação automática com opção de renovar ou cancelar. Também implementaria logging detalhado de cada transição de estado: pré criado, pré expirado, pré convertido, pré cancelado. Isso facilita debugging em produção. Eu perdi meio dia um bug que era simplesmente um pré sendo expirado duas vezes porque o sistema tinha dois listeners sobrepostos.
A parte de métricas também é importante. Acompanhar taxa de conversão de pré pra confirmação, tempo médio até confirmação, e taxa de expiração. Se sua taxa de conversão está abaixo de 60%, algo está errado. Ou o pré está muito longo, ou a experiência de confirmação é ruim, ou o preço não está competitivo. Eu testo tudo isso manualmente primeiro. Crio um pré, espero o timer, vejo o que acontece. Se o sistema não tem dashboard de métricas, eu rodo queries diretas no banco. É mais trabalhoso mas funciona.
Se quiser ver como isso funciona na prática, posso compartilhar um exemplo de schema de banco e os campos principais que você precisa ter. A pergunta é se você está construindo do zero ou otimizando algo existente.
