“Quero essa, metade de cada sabor”
A pessoa escolhe no cardápio e abre o WhatsApp. A recepção pede tamanho, sabores, borda e endereço. É possível que ela tenha acabado de informar parte disso em outra tela. Nesse exemplo ilustrativo, a fricção está na passagem entre canais: a escolha existe, mas não chega organizada a quem atende.
Um site para pizzaria pode melhorar esse percurso sem começar com um sistema completo de delivery. Primeiro, é preciso mapear onde a equipe recebe o pedido e o que ela precisa confirmar.
Desenhe o pedido no papel antes da tela
Escolha uma combinação permitida pelo cardápio e descreva seu caminho: consulta, escolha, envio, conferência, pagamento, produção e entrega ou retirada. Marque quem responde por cada etapa. Ao discutir o escopo de Sites e sistemas, use esse mapa para identificar quais etapas já funcionam e quais precisam de mudança.
Se um pedido só entra na cozinha depois da confirmação da recepção, abrir uma conversa não pode ser descrito como pedido concluído. A mensagem preparada pelo site pode carregar as escolhas e ainda pedir revisão do cliente antes do envio.
Tamanhos e metades precisam de uma regra escrita
Nomes de sabores são apenas parte do cardápio. A pessoa também compara tamanho, quantidade de sabores permitida, bordas e adicionais. A regra de preço das metades deve estar no percurso usado para concluir o pedido, conforme a política real da pizzaria.
Veja um roteiro de conteúdo, não um cardápio real:
| Escolha | Informação a obter com a equipe |
|---|---|
| Tamanho | Quais tamanhos são vendidos e como identificá-los |
| Dois sabores | Em quais tamanhos a combinação é permitida |
| Borda ou adicional | Opções, disponibilidade e forma de calcular o valor |
| Entrega | Área atendida e momento de confirmar a taxa |
| Retirada | Endereço, horário e orientação de chegada |
Evite deduzir essas regras a partir de uma foto do menu. Um configurador precisa representar as combinações aceitas; caso contrário, apenas transfere erros para a recepção.
Três formas de começar, com responsabilidades diferentes
Cardápio e contato servem quando a equipe confere manualmente escolhas e condições. O site apresenta e encaminha, e a comunicação deixa explícita a confirmação posterior.
Link para a plataforma usada pela casa aproveita uma operação existente. A página pode explicar a oferta e encaminhar para o destino adequado, sem duplicar um carrinho que já funciona.
Pedido no próprio site exige definir cálculo, entrega, disponibilidade, pagamento e atendimento de falhas. Vale estudar essa opção quando houver uma necessidade operacional demonstrada e capacidade de manter o fluxo. Nesse caso, o roteiro de checkout no celular ajuda a revisar a etapa de pagamento.
Os links de ação do Perfil da Empresa no Google podem encaminhar para pedidos, conforme os recursos disponíveis. Confira quais destinos aparecem atualmente: pode haver links de fornecedores externos além do canal preferido pela pizzaria.
Teste a entrega da informação à recepção
Use dados fictícios em um ambiente de teste, sem gerar cobrança ou produção. Selecione retirada e depois entrega. Confira se a mudança altera as informações solicitadas e se a recepção consegue interpretar o pedido sem reconstruí-lo.
Também simule um destino indisponível. Um contato alternativo visível evita que o cardápio termine num link sem saída. Horários e condições devem ser atualizáveis, principalmente quando salão, retirada e delivery funcionam em períodos distintos.
Leve para o briefing um pedido representativo e o percurso que ele faz hoje. Isso permite discutir uma mudança verificável, em vez de contratar funções por aparência. Os materiais para organizar essa conversa estão em sites para pizzarias.
Fontes e referências
- Manage your local business linksGoogle Business Profile · Consulta em 2 de outubro de 2026
Os critérios e exemplos deste artigo são uma análise editorial da lork. Cenários ilustrativos não representam resultados de clientes.
