O contexto
Restaurante de bairro com trinta e dois lugares e uma pessoa no salão. A reserva chega por telefone durante o almoço, quando ninguém consegue atender, e por mensagem à noite, quando a mesma pessoa está fechando o caixa. O caderno de reservas fica no balcão e some com frequência.
O Veranda é um projeto autoral: o problema veio de conversas com donos de restaurante pequeno, mas nenhum deles contratou este trabalho. O que está aqui é o método, não um case de cliente.
O problema real
O gargalo não é reserva. É atenção. O salão não tem folga cognitiva para operar mais um sistema durante o serviço, então qualquer solução que exija atenção no horário de pico já nasce morta.
Isso derruba a hipótese óbvia, que seria um painel completo de gestão de mesas. Ninguém vai olhar para ele às vinte e uma horas.
As decisões
A reserva se confirma sozinha. O cliente escolhe horário em uma página pública e recebe a confirmação na hora. O salão não aprova nada, só é avisado.
A tela do salão é uma lista, não um mapa. Mapa de mesas é bonito em captura de tela e inútil de pé, segurando um prato. A lista mostra horário, nome e número de pessoas, em corpo grande, ordenada pela próxima chegada.
Overbooking é problema de configuração, não de operação. O dono define quantas mesas libera por faixa de trinta minutos uma vez, no cadastro, e o sistema simplesmente para de oferecer horário quando enche.
O que foi descartado
Um aplicativo para o cliente final. Restaurante de bairro não tem recorrência que justifique alguém instalar um aplicativo, e cada instalação a mais é uma fricção a mais entre a vontade de jantar e a reserva feita.
Também ficou de fora a integração com sistema de comanda. Aumenta muito o escopo e resolve um problema que este restaurante ainda não tem.
O resultado
Uma página pública de reserva que carrega em menos de um segundo em rede móvel, e uma tela de salão que cabe inteira em um celular apoiado no balcão, legível a um braço de distância.