Pizzaria é o teste mais duro para qualquer sistema de restaurante. Não porque a operação seja mais difícil, mas porque o produto tem uma estrutura que a maioria dos softwares não foi feita para representar.
Se o seu sistema atual te obriga a cadastrar “Pizza Calabresa Grande” e “Pizza Calabresa Média” como dois produtos diferentes, você já viu o problema de perto.
Por que a modelagem errada custa caro
Quando o sistema não entende a estrutura da pizza, a operação se adapta na força:
- Cada combinação de tamanho vira um produto novo no cadastro
- Meio a meio é lançado como “produto especial” com preço digitado à mão
- Borda entra como item separado, com preço igual para todos os tamanhos
- Relatório de produtos mais vendidos fica inútil, porque o mesmo sabor está espalhado em cinco cadastros
O resultado prático: cadastro gigante, preço errado com frequência e nenhuma informação confiável no fim do mês.
A estrutura correta, em quatro camadas
Uma pizza não é um produto simples. Ela é um produto com camadas de escolha. Modelada corretamente, fica assim:
1. O produto
“Pizza” é o produto. Não “Pizza Calabresa Grande”. Um produto só.
2. O tamanho é uma variação
Broto, média, grande e família são variações do mesmo produto, cada uma com seu preço base. Isso resolve o cadastro inflado de uma vez: um produto com quatro variações, não quatro produtos.
3. O sabor é um grupo de opções
Aqui está a parte que a maioria erra. Sabor não é o produto: é uma escolha dentro do produto, com regra:
- Quantos sabores no mínimo (normalmente 1)
- Quantos no máximo (normalmente 2 ou 4, dependendo do tamanho)
- Como calcular o preço quando há mais de um
Essa última regra é a que gera mais discussão na casa. As três políticas mais usadas:
Maior valor. Meio calabresa (R$ 50) e meio portuguesa (R$ 60) custa R$ 60. É a mais comum e a mais simples de explicar ao cliente.
Média dos valores. A mesma pizza custa R$ 55. É mais “justa” na matemática e mais difícil de explicar no telefone.
Preço fixo por tamanho com sabores agrupados em faixas. Sabores tradicionais e especiais têm preços diferentes, e a faixa mais alta manda.
Não existe certo absoluto. Existe a política da sua casa, e o sistema tem que suportá-la sem digitação manual.
4. Borda e adicional são opções com preço por tamanho
Este é o detalhe que mais causa erro de cobrança. Borda de catupiry numa pizza broto e numa família não custam o mesmo. Se o sistema só permite um preço por opção, você vai cobrar errado em um dos dois casos, todos os dias.
A modelagem correta permite preço da opção por variação: catupiry custa X na média e Y na família.
E a remoção de ingredientes?
“Sem cebola” não é adicional, não é desconto e não pode ser só uma observação solta que a cozinha talvez leia.
O jeito certo é tratar remoção como uma opção do grupo de ingredientes, com preço zero. Assim ela fica registrada no item, aparece na ficha de produção e não depende de alguém decifrar um texto livre.
Por que isso não deveria exigir “sistema de pizzaria”
Um ponto importante de arquitetura: nada disso é exclusivo de pizza.
Açaí tem tamanho de copo e complementos com limite de escolha. Hamburgueria tem ponto da carne, adicionais e troca de acompanhamento. Marmitaria tem tamanho e escolha de proteína e guarnições. Sorveteria tem número de bolas e sabores.
É a mesma estrutura: produto, variação, grupo de opções com mínimo e máximo, item de opção com preço por variação.
Quando um fornecedor te diz que precisa de um módulo específico de pizzaria, ele está dizendo que o cardápio dele foi modelado por tipo de comida, e que qualquer novidade no seu menu vai exigir desenvolvimento.
Checklist para testar um sistema com pizza
Leve isso para a demonstração e peça para fazerem na sua frente:
- Cadastrar uma pizza com quatro tamanhos e preços diferentes
- Permitir dois sabores na média e quatro na família
- Definir política de preço para múltiplos sabores
- Cadastrar três bordas com preço diferente por tamanho
- Lançar um pedido de família, quatro sabores, borda recheada, sem cebola em um dos sabores
- Ver esse pedido chegar completo na ficha de produção
- Abrir o relatório e ver qual sabor mais vendeu no mês
Se travar no item 3 ou 4, o sistema não modela pizza, ele improvisa.
Como o SBMenu trata isso
No SBMenu, tamanhos são variações do produto e sabores, bordas, adicionais e remoções são grupos de opções com regra de mínimo, máximo e preço por variação. Não existe tabela separada para pizza no banco de dados, e isso é deliberado, porque a mesma estrutura precisa atender açaí, hambúrguer e marmita sem desenvolvimento novo.
O pedido guarda o que foi escolhido, então a ficha de produção mostra o item exatamente como o cliente montou.
Veja a solução para pizzarias ou peça uma demonstração com o seu cardápio.