Para viagem é um negócio diferente do presencial. Os clientes não se sentam. Não há mesa onde deixá-los. Eles querem saber duas coisas: quando a comida fica pronta e como pagam. Qualquer coisa que atrapalhe essas duas perguntas é atrito — e atrito perde pedidos para o concorrente com um processo mais ágil.
Nos últimos anos, o playbook para pedidos para viagem migrou de ligações e balcões de atendimento para um fluxo de QR e fila que escala. Os clientes pegam um número de fila, montam o pedido no próprio celular, pagam enviando um comprovante de transferência bancária e retiram quando seu número é chamado. Tudo funciona no navegador — sem aplicativo, sem balcão de atendimento, sem headset.
Este artigo percorre as decisões práticas que fazem esse fluxo funcionar em um restaurante real.
Preços Separados para Viagem
A primeira decisão é se os preços para viagem devem ser iguais aos do presencial. Em muitos países, a resposta é não. O presencial inclui pratos, taças, serviço de mesa e uma experiência. O para viagem inclui embalagem e a suposição de que o cliente vai comer em outro lugar. As estruturas de custo são diferentes, e a disposição a pagar é diferente.
Um padrão comum é um pequeno acréscimo para viagem — talvez dez a quinze por cento — para cobrir embalagem e o trabalho marginal de embalar e entregar. Alguns restaurantes fazem o oposto e oferecem um pequeno desconto para viagem porque economizam em lavagem de louça e rotatividade de mesas. De qualquer forma, o sistema de cardápio precisa suportar um campo de preço separado por item, distinto do preço presencial, que só aparece quando o cliente está pedindo para retirada.
Os itens também precisam de um indicador de disponibilidade separado para viagem. Alguns pratos não viajam bem. Um suflê, um delicado carpaccio, uma sobremesa elaborada com múltiplos componentes — nenhum desses pertence a um cardápio para viagem. Devem permanecer no cardápio presencial, mas ser ocultados da lista de viagem com um único botão, sem a necessidade de manter dois cardápios paralelos.
A Confirmação do Pedido em Duas Etapas
O erro clássico é tratar um pedido para viagem como um checkout de site, onde o cliente confirma tudo de uma vez no final. Na prática, isso falha porque o pagamento é a etapa mais lenta e propensa a erros. Transferências bancárias levam tempo. O cliente pode digitar o valor errado. O comprovante pode estar ilegível. Se o pedido for confirmado antes da verificação do pagamento, a cozinha começa a preparar comida que o restaurante pode nunca receber.
Um fluxo melhor é a entrega em duas etapas. Etapa um: o cliente faz o pedido. O sistema registra os itens, calcula o total e mostra claramente o valor na moeda em que ele está pagando. Etapa dois: o cliente envia o comprovante de pagamento. Até o restaurante confirmar manualmente que o comprovante é válido, o pedido fica em estado de "aguardando confirmação". A cozinha não começa. O badge de status do cliente diz "Aguardando o restaurante confirmar o pagamento" para que ele saiba que a bola está com você, não com ele.
Isso parece lento. Na prática, a confirmação pela equipe leva dez segundos — abra o painel, dê uma olhada na imagem do comprovante, toque em um botão. A cozinha vê o pedido no momento em que o pagamento é confirmado, não antes — que é exatamente o momento certo.
Envios de Comprovante que Não Quebram
O modo de falha mais comum para envios de comprovante é de permissões. Celulares de clientes usam endereços IP aleatórios. Os tamanhos das imagens variam de 200 KB a 10 MB. Alguns clientes tiram print do aplicativo do banco, outros fotografam o recibo impresso com a câmera, outros colam uma imagem encaminhada de um chat. O sistema de envio precisa absorver tudo isso sem cuspir um erro.
Algumas regras práticas. Primeiro, aceite múltiplos formatos de imagem: JPEG, PNG e WebP cobrem essencialmente qualquer câmera de celular e ferramenta de print. Segundo, use URLs de envio presignadas que expiram em alguns minutos, para que o envio aconteça diretamente do celular do cliente para seu armazenamento, sem seu servidor no meio. Terceiro, valide o tipo de arquivo no servidor antes de emitir a URL. Quarto, armazene os comprovantes em um caminho claramente nomeado para que você possa auditá-los depois se um pagamento for contestado.
A interface voltada para o cliente deve ter um único botão grande rotulado "Enviar comprovante de pagamento", não um formulário em várias etapas. Após o envio, mostre uma miniatura do comprovante de volta ao cliente com uma opção "Substituir" caso ele tenha enviado a imagem errada. O badge de status deve mudar imediatamente para "Aguardando confirmação do restaurante" para que ele saiba que o envio funcionou.
Códigos de Referência para Retirada
Quando o cliente chega para retirar, você precisa de uma maneira rápida de associar o celular dele ao pedido na sua tela. Chamar um número de fila funciona em um restaurante tranquilo, mas falha em uma lanchonete de bubble tea movimentada com cinco clientes número 12 na fila.
Um código de referência curto — seis caracteres de um conjunto sem ambiguidade — resolve isso. Gere-o no servidor no momento do pedido. Mostre-o no celular do cliente ao lado do número de fila. Mostre o mesmo código no painel da equipe. Quando o cliente chega, ele mostra o celular, você compara os códigos e entrega a sacola. A troca toda leva três segundos e nunca depende de nomes gritados.
O código de referência também age como antitrapaça. Um cliente não pode alegar "sou o número 42" sem mostrar o código que vai com o número 42. Duas pessoas aleatórias não conseguem ter o mesmo código no mesmo dia em nenhum cenário plausível.
Reconciliação ao Final do Dia
A receita de viagem precisa ser reconciliada com as transferências bancárias diariamente. A maneira mais simples de fazer isso é uma visualização de Histórico no painel da fila que lista cada pedido marcado como Atendido em um determinado dia, com o número da fila, código de referência, horário, total e um link para a imagem do comprovante. Escolha uma data, veja a lista, veja o total do dia, cruze com o extrato bancário. Cinco minutos por dia, idealmente como parte da rotina de fechamento.
O histórico precisa lidar corretamente com o fuso horário. Um restaurante em São Paulo fechando à meia-noite no horário local deve ver todos os pedidos daquele dia do calendário agrupados juntos, não divididos pela meia-noite UTC no meio do serviço de jantar. O sistema deve conhecer o país do restaurante e usar o fuso horário local para o agrupamento.
O que Fazer quando Algo Dá Errado
Em qualquer fluxo real, casos excepcionais acontecem. O cliente paga o valor errado. O comprovante está ilegível. O cliente nunca aparece para retirar. A cozinha fica sem um item entre o pedido e a confirmação.
Para cada um desses, projete um caminho claro. Valor errado: a equipe abre o pedido, vê o problema e aceita um pagamento parcial com uma nota ou pede ao cliente que pague novamente. Comprovante ilegível: a equipe contata o cliente (se você tiver o número de celular) ou simplesmente não confirma; o cliente percebe que o status está travado e reenvia. Não apareceu: a entrada na fila fica em "preparando" até ser marcada manualmente como Atendida ou Cancelada, momento em que sai da lista ativa.
Sem estoque entre pedido e confirmação é o caso mais doloroso. A resposta mais limpa é um reembolso rápido para a mesma conta bancária do cliente, com um pedido de desculpas e uma nota. Os sistemas devem facilitar isso: um botão Cancelar no pedido que você pode usar depois de ver o comprovante, com o celular do cliente refletindo imediatamente o cancelamento.
Não Otimize o Caminho Feliz de Forma Excessiva
A tentação ao projetar um fluxo para viagem é assumir que todo pedido vai perfeitamente e projetar a interface de acordo. Essa é uma armadilha. A maioria dos pedidos vai perfeitamente, mas os ruins consomem tempo desproporcionalmente e criam o maior volume de trabalho de atendimento ao cliente. Construa o fluxo em torno dos casos ruins primeiro, e os bons cuidarão de si mesmos.
Um badge de status claro que o cliente consegue ler em três segundos. Um painel que mostra tudo o que a equipe precisa de uma só vez. Códigos de referência para entregas rápidas. Uma visualização de histórico para reconciliação ao final do dia. Mais uma expectativa padrão de que alguns pedidos precisarão de intervenção manual — e que o sistema facilita essa intervenção em vez de impossibilitá-la. Acerte esses pontos e você terá uma operação de viagem que escala.
