QR do restaurante: pedido direto ou aplicativo de delivery?

Comece pelo cliente e pela promessa impressa

Quem está no balcão já sabe de qual restaurante quer comprar. Pode querer pedir para retirar depois, repetir uma refeição conhecida ou encontrar a opção de entrega que a casa já oferece. Quem navega em um marketplace de delivery pode estar comparando restaurantes e usando a conta e as opções daquele aplicativo. Esses pontos de partida não pedem o mesmo convite.

Escreva a promessa antes de escolher a URL. “Pedir para retirar neste restaurante” deve abrir um canal configurado para retirada no endereço certo. “Pedir pelo nosso perfil neste aplicativo” deve abrir o perfil atual da unidade. “Ver cardápio e opções de pedido” pode abrir uma página pública quando o visitante realmente precisa escolher entre canais mantidos.

O canal vai além do nome no botão. Confira como a pessoa escolhe itens, quais opções de retirada ou entrega aparecem, que horário vale e onde recebe confirmação. Não chame PDF de cardápio de sistema de pedidos nem apresente uma mensagem de contato como transação concluída. Se o contato existente recebe solicitações, explique que a equipe confirma o pedido pelo processo da casa.

Compare pedido direto e perfil no marketplace

As alternativas podem coexistir. O restaurante pode manter marketplace para quem prefere aquele aplicativo e canal direto para quem vem do site ou material da própria casa. A página pública organiza escolhas; os serviços de pedidos continuam recebendo e processando as transações.

“Direto” não significa que o restaurante desenvolveu o software ou emprega todos os entregadores. Na descrição da própria Uber, Uber Direct atende entregas originadas nos sites, aplicativos ou outros canais do estabelecimento; Uber Eats Marketplace lista estabelecimentos lado a lado para entrega ou retirada. São exemplos específicos do fornecedor, não garantia de que sua conta ou região admite determinada configuração.

Separe a descoberta da entrega. O lugar onde a pessoa encontra a casa pode ser diferente do sistema que recebe o pedido e do serviço que o entrega. Confirme os três antes de anunciar o botão. Mudar o destino do QR não cria uma operação de pedidos ou entrega que ainda não existe.

Confira a operação por trás de cada link

Peça a quem opera cada canal para abrir a visão real do cliente. Confira restaurante, unidade, cardápio, horários, instruções de retirada e opções de entrega. Um perfil que abre pode continuar exibindo menu antigo ou horário que a cozinha não atende. A origem precisa de correção; acrescentar página pública não sincroniza essas informações.

Identifique quem recebe o pedido. A equipe vê a solicitação em tablet, conexão com PDV, painel do fornecedor ou contato acompanhado? Quem confere durante um turno movimentado? Onde o cliente vê confirmação e quem trata uma solicitação ainda não aceita? Use os registros reais do fornecedor, sem considerar scan ou captura enviada pelo cliente como prova de pedido concluído.

Depois, identifique quem cumpre a entrega. Na retirada, defina o ponto e a pessoa que entrega a comida. No delivery, confirme qual serviço aceita a tarefa e como a equipe prepara e repassa o pedido. Não pressuponha que um link direto exige entregador próprio ou que todo pedido de marketplace usa a mesma operação.

Cardápio e disponibilidade pertencem aos sistemas em uso. Confira qual é a origem das opções e dos horários. Se dois canais exigem atualizações separadas, atribua as duas tarefas explicitamente. A página pública apresenta links e localização; não deve copiar detalhes variáveis para uma segunda fonte que ninguém mantém.

Por fim, defina onde a pessoa pergunta sobre confirmação ausente, atraso na retirada ou problema na entrega. Confirme a resposta com a casa e seus fornecedores. Não prometa processo uniforme de reembolso, suporte ou entregador para serviços diferentes.

Um restaurante fictício com dois canais ativos

Cenário ilustrativo, não resultado de cliente VISU. O Balcão Cedro tem um link configurado para retirada e um perfil atual em marketplace de delivery. O cartão do balcão precisa ajudar o cliente a pedir outra refeição. Primeiro, a gerente decide se o convite promete retirada na casa ou acesso ao perfil no aplicativo.

Dentro do horário atendido, um cartão “Pedir para retirar” pode abrir diretamente o canal existente. A pessoa encontra cardápio e opções de retirada naquele fornecedor. A equipe recebe o pedido no sistema habitual e segue o processo confirmado de entrega no balcão. O QR não faz o pedido, não distribui capacidade da cozinha nem confirma que a comida ficou pronta.

Para um cartão geral, o Cedro pode usar uma página pública com links identificados para retirada e marketplace, desde que ambos sejam mantidos. A gerente não apresenta as opções como iguais. O link de retirada abre o serviço correspondente; o link com nome do aplicativo abre o perfil correto e suas opções configuradas.

Quando a retirada muda, a equipe atualiza primeiro o sistema de pedidos e revisa o convite do cartão e a página pública. Se o impresso promete um serviço indisponível, a gerente corrige o material que controla, sem afirmar que qualquer QR muda sozinho. A gerente registra cada canal atendido e responsável pela atualização para a equipe explicar as escolhas e revisar o convite depois de uma mudança no serviço.

Dê à página pública do restaurante uma função própria

A página apresenta a casa e ajuda a encontrar informações e canais existentes. Pode mostrar links de cardápio, endereço, horário e opções aprovadas de pedido. É útil quando a pessoa precisa escolher; um link direto pode ser mais claro quando o convite impresso já identifica uma ação atendida.

A Solução Restaurantes atual oferece página da casa, arquivo de QR para impressão e artes de peças especificadas, usando links que o restaurante já tem. A casa fornece cardápio, canal de pedidos e material aprovado, aprova peças e providencia impressão. Isso não implica pedido, checkout, estoque, despacho de entregador ou marketplace nativos da VISU.

Para uma página e QR com escopo definido, liste quais links devem aparecer e por quê. Indique quem mantém cada origem e corrige os nomes públicos depois de uma mudança. Se falta conta no fornecedor ou configuração de entrega, resolva essa escolha operacional antes de apresentá-la como disponível.

Teste a experiência do cliente e o repasse à equipe

Abra o QR no celular sem login de funcionário e leia o convite em voz alta. Confira se a primeira tela corresponde ao restaurante, canal e ação de retirada ou entrega prometidos. Combine um teste planejado com o responsável do restaurante e o fornecedor, usando a prévia quando existir, para evitar um pedido acidental.

Confira cada canal real separadamente. Dois botões funcionando não provam que a cozinha consegue atender os dois ao mesmo tempo. Revise capacidade e repasse com o operador pelo processo real do restaurante. Publique apenas promessas de retirada ou entrega que a casa consegue manter.

Avalie a Solução Restaurantes pelas entregas declaradas de página pública, QR e artes. Fornecedores e equipe continuam responsáveis por transação e atendimento do pedido. Um scan ou clique de saída, isoladamente, não confirma uma refeição pedida ou entregue.