O cliente escolhe dois pratos, clica em finalizar compra e recebe uma taxa de entrega calculada para o endereço errado. Ou pior: faz o pedido às 23h40, quando a cozinha já fechou, e o site aceita. Se você está montando um pedido online restaurante WooCommerce, esse é o tipo de falha que aparece só depois que o pedido real chega, e quase sempre no horário de pico.
O WooCommerce sozinho é uma loja de produtos com estoque e envio. Restaurante não funciona assim: o cardápio muda por dia, o cliente quer retirar no balcão ou receber em casa, a taxa muda por bairro, existe pedido mínimo e existe horário. Cada uma dessas regras precisa de um lugar no fluxo, e é aí que a receita de “só ativar o WooCommerce” quebra.
O que o checkout padrão não resolve no pedido online restaurante WooCommerce
Antes de escolher ferramenta, liste o que o restaurante realmente exige. O checkout nativo do WooCommerce cobre bem: produto, variação, cupom, meio de pagamento e cálculo de frete por CEP ou faixa de peso. Ele não cobre, sem customização:
- Escolha entre entrega e retirada no mesmo pedido, com taxas diferentes.
- Taxa por bairro, sem depender do CEP exato do cliente.
- Pedido mínimo que muda conforme o modo escolhido (retirada costuma ter mínimo menor).
- Bloqueio de pedido fora do horário de funcionamento.
- Campo de observação por item (“sem cebola”, “ponto da carne”).
- Confirmação rápida para o cliente, por WhatsApp ou e-mail, com o resumo do pedido.
Na prática, o problema não é o WooCommerce em si: é que o restaurante trata frete como regra de negócio, e o WooCommerce trata frete como cálculo de transporte. São coisas diferentes.
As três rotas possíveis, e quando cada uma serve
Existem três caminhos que funcionam em produção. A decisão depende de quantas regras condicionais o restaurante tem e de quem vai manter isso depois.
| Rota | Serve quando | Limite |
|---|---|---|
| Plugin de delivery para WooCommerce | O restaurante tem bairros fixos, taxa por região, retirada e entrega, horário e pedido mínimo. | Você fica dependente do plugin para regras fora do padrão. Teste antes de fechar com o cliente. |
| Campos condicionais no checkout | Poucas regras: só entrega ou retirada, uma taxa fixa e um campo de observação. | Regra complexa vira código no functions.php e quebra na próxima atualização do WooCommerce. |
| Formulário externo + link de pagamento | Cardápio pequeno, pedido por WhatsApp já é a operação real, e o site só organiza o pedido. | O pedido não entra no WooCommerce. Relatório e histórico ficam fora do painel. |
Por isso, a pergunta certa não é “qual plugin é melhor”, e sim “quantas regras condicionais o restaurante tem hoje e quantas ele vai querer em seis meses”. Restaurante muda cardápio, muda taxa e muda horário com frequência. Se a resposta for “muitas e sempre”, a rota do plugin de delivery costuma ser a mais barata de manter.
Como configurar a rota do plugin de delivery
Esta é a rota mais comum para quem quer pedido online restaurante WooCommerce com regras reais. O passo a passo abaixo é o que costuma dar certo, mas confirme os nomes exatos das opções na documentação do plugin escolhido, porque cada um usa rótulos próprios.
- Instale o plugin de delivery em um ambiente de teste, nunca direto no site do cliente em horário de movimento.
- Cadastre os bairros atendidos e a taxa de cada um. Se o plugin usar CEP, teste com CEPs reais das pontas de cada bairro, porque CEP de divisa costuma cair na faixa errada.
- Defina o modo retirada com taxa zero e, se o restaurante quiser, um pedido mínimo diferente do de entrega.
- Configure o horário de funcionamento por dia da semana. Inclua feriados e o intervalo em que a cozinha fecha entre almoço e jantar.
- Crie o campo de observação por item e um campo geral de observação do pedido.
- Teste um pedido completo de cada modo: entrega em bairro com taxa, entrega em bairro sem atendimento, retirada, pedido abaixo do mínimo e pedido fora do horário.
O ponto que mais falha é o cálculo do frete. Quando o plugin de delivery e o cálculo nativo do WooCommerce disputam a mesma taxa, o cliente vê um valor e o restaurante recebe outro. Desative o cálculo de frete nativo para as zonas atendidas pelo plugin, ou deixe o plugin assumir a taxa por completo. Se o checkout travar durante os testes, o caminho para achar a causa é o mesmo de qualquer erro de checkout, e vale seguir o roteiro de checkout do WooCommerce travando antes de culpar o plugin novo.
Campos condicionais no checkout: quando ainda vale
Se o restaurante só precisa de um seletor entre entrega e retirada, com taxa fixa para entrega e um campo de observação, dá para resolver com campos condicionais no checkout, sem plugin de delivery. É menos peso no site e menos coisa para atualizar.
Porém, esse caminho tem um custo escondido. Regra condicional escrita em código precisa ser revista a cada atualização relevante do WooCommerce, porque a estrutura do checkout muda. Em site de cliente que você não vê toda semana, isso vira dívida técnica. Se você mantém vários sites, vale guardar o código em um lugar versionado, como explicado em snippets WordPress: onde guardar código, para não depender da memória de quem escreveu.
Além disso, a confirmação do pedido precisa chegar ao restaurante de forma legível. E-mail padrão do WooCommerce costuma sair com a taxa de entrega em linha separada e sem o bairro escolhido, o que gera ligação de volta para o cliente. Ajuste o template de e-mail ou use um canal de confirmação que mostre modo de entrega, bairro, taxa e observações no topo.
Formulário externo: quando ele é a resposta honesta
Muitos restaurantes já operam por WhatsApp. Nesse caso, forçar o pedido inteiro para dentro do WooCommerce pode piorar a operação, porque a cozinha continua olhando o celular. Um formulário externo que monta o pedido e envia para o WhatsApp, com link de pagamento separado, resolve mais rápido e com menos manutenção.
O que se perde: o pedido não entra no histórico do WooCommerce, não gera relatório de vendas por item e não alimenta cupom nem programa de fidelidade. Se o restaurante quer esses dados, essa rota não serve. Se ele só quer receber o pedido certo, serve bem.
Quando NÃO usar cada rota
Não use plugin de delivery quando o restaurante tem um único bairro de entrega e taxa fixa. O peso do plugin não se paga, e você cria uma dependência que ninguém vai querer manter.
Não use campos condicionais no checkout quando as regras passam de três ou quatro condições. A partir daí, o código fica frágil e o teste manual deixa de cobrir todos os casos.
Não use formulário externo quando o restaurante precisa de relatório de vendas, controle de estoque de insumos ou integração com impressora fiscal. Nesses casos, o pedido precisa nascer dentro do WooCommerce.
Erros comuns que quebram o pedido online restaurante WooCommerce
- Deixar o cálculo de frete nativo ativo junto com o plugin de delivery, gerando duas taxas no mesmo pedido.
- Cadastrar bairro pelo nome sem conferir a lista de CEPs atendidos, o que aceita pedido de região que o motoboy não cobre.
- Configurar horário de funcionamento só no fuso do servidor, e não no fuso do restaurante. O pedido é aceito uma hora depois do fechamento.
- Esquecer o pedido mínimo no modo retirada, o que permite um pedido de um refrigerante só.
- Não testar o e-mail de confirmação com um pedido real. O restaurante recebe o pedido sem o bairro e liga para o cliente.
- Publicar a mudança em horário de pico, sem janela de reversão.
Quando algo dá errado em produção, o primeiro lugar para olhar é o log. Se o pedido some ou o checkout devolve erro 500, siga o roteiro de logs de erro do WordPress antes de desativar plugin no escuro. E se a página de agradecimento ou o cardápio sumir depois de uma alteração, confira se não é só permalink, com o passo a passo de erro 404 em páginas do WordPress.
Prevenção: o que deixa o pedido estável
Antes de subir qualquer mudança de checkout, faça uma cópia do site em ambiente de teste e rode os seis pedidos de validação: entrega com taxa, entrega fora de área, retirada, abaixo do mínimo, fora do horário e com observação por item. Guarde o resultado. Na próxima atualização do WooCommerce ou do plugin de delivery, repita os mesmos seis pedidos.
Além disso, monitore o checkout depois de cada atualização. Um plugin de delivery atualizado em um site pode funcionar, e no site do cliente ao lado quebrar por causa de outra versão do WooCommerce. Quando você administra vários restaurantes, esse tipo de regressão só aparece quando o cliente reclama que perdeu pedido. Uma checagem automática de performance e disponibilidade em vários sites ajuda a pegar o checkout fora do ar antes do primeiro pedido do dia, como descrito em checagem automática de performance.
Por fim, documente as regras do restaurante em um lugar que o cliente consiga ler: bairros atendidos, taxas, pedido mínimo, horário e feriados. Boa parte dos pedidos errados não vem do site, e sim de regra que só existia na cabeça de quem configurou. Se você entrega sites para clientes, um manual simples evita retrabalho, e o que incluir nele está em manual para cliente WordPress.
Quando chamar alguém
Se o restaurante precisa de regra de frete por raio de distância, integração com impressora na cozinha, controle de estoque de insumos ou cardápio que muda por dia da semana, o projeto deixa de ser configuração de plugin e vira desenvolvimento. Nesse ponto, vale envolver quem já fez isso antes, porque o custo de errar no checkout é pedido perdido em horário de pico, quando não dá para corrigir com calma.
Se você administra o site de vários restaurantes, o risco se multiplica: cada um tem bairros, taxas e horários próprios, e cada atualização de plugin pode quebrar um checkout diferente. O 100% WP centraliza atualizações, backups e monitoramento desses sites em um painel só, o que ajuda a perceber um checkout fora do ar antes do cliente ligar reclamando do pedido que não chegou.
