VelOS
Começar grátis
← Blog
Multi-loja

Multi-loja para restaurante: como crescer sem perder cardápio, preços e horários

Equipa VelOS 8 min de leitura

Multi-loja para restaurante: como crescer sem perder cardápio, preços e horários

A primeira loja prova que o conceito funciona. A segunda multiplica o stress. A terceira partilha o seu fim de semana entre dois telefones. Este artigo é sobre como uma operação multi-loja consegue manter coerência (a marca lê-se igual em todas as lojas) sem perder flexibilidade (cada loja tem clientes próprios, custos diferentes, equipas distintas) — e como a infraestrutura do software muda esta equação.

Os 3 pontos onde uma operação multi-loja descarrila

Antes de qualquer ferramenta, o problema é organizacional. Três pontos repetem-se em quase todos os casos que vemos:

1. Drift de cardápio

Loja A adicionou um prato novo na semana de Natal. Loja B nunca soube. Quando o cliente do Instagram aparece na Loja B a pedir o “tal especial de bacalhau” e a equipa não sabe do que está a falar, perde-se o pedido e a confiança. Multiplicado por 4 lojas e 2 anos de operação, o cardápio “oficial” deixa de existir como entidade única.

2. Preços diferentes onde não deviam ser

Inflacção, ajustes regionais, custos de matéria-prima diferentes — algumas variações de preço são legítimas. O problema é quando ninguém sabe exactamente porquê a Loja C cobra €12,50 num prato que a Loja A cobra €11,80. Se o cliente compara (Instagram, Google reviews, conversa entre amigos), a marca paga o custo da incoerência.

3. Horários e disponibilidade fora de sincronia

A Loja D fechou às 14h ontem para inventário e ninguém actualizou no Google My Business. O cliente chega, encontra fechado, deixa review negativa. Esta semana já são 3 reviews 1-estrela. O ranking local cai. As outras 3 lojas pagam o custo.

O modelo da VelOS: cardápio universal + overrides por loja

A arquitectura que resolve isto não é “uma cópia do cardápio por loja”. É um cardápio único + regras de excepção por loja. Em termos concretos, a VelOS opera com duas tabelas:

Quando adicionas o “Bacalhau especial” à marca, ele aparece automaticamente nas 4 lojas com o preço base. Se a Loja A fecha terça-feira, marcas available_in_store=false para essa loja só nesse produto ou para o cardápio inteiro se a loja vai estar fechada todo o dia. Se a Loja D opera num bairro com poder de compra mais alto, podes ter price_in_store=12,50 na Loja D e 12,00 nas outras três.

A diferença com Excel é simples: a base é a mesma em todas as lojas. As excepções são explícitas, traçáveis, e visíveis no dashboard central. Quando precisas mudar um preço, mudas no produto-pai e propaga; quando precisas variar uma loja, mudas no product_store daquela linha.

Caso real: dois pratos, quatro lojas, zero drift

Imagine uma cadeia de churrascaria com 4 lojas em Portugal:

Operar isto coerentemente significa:

  1. Cardápio principal com 28 pratos, todos disponíveis em todas as lojas — excepto o “Cataplana de marisco” que só faz sentido no Algarve.
  2. Preços base definidos no produto. Overrides: Lisboa +8% nos pratos principais; Carregado preço base; Ovar -5% nos pratos individuais.
  3. Horários: cada loja tem opening_hours próprios; o app diner respeita automaticamente — se o cliente abrir o app às 16h e a Loja Ovar estiver fora do almoço, mostra “Disponível a partir das 19h” sem precisar bloquear pedidos manualmente.
  4. Mesas QR: cada loja tem 10 mesas (configuração padrão), cada mesa com QR único. Cliente que digitaliza QR de Lisboa-Centro entra no fluxo de Lisboa-Centro — tenant_id + store_id resolvem-se a partir do slug embutido no URL.

O dono opera as 4 lojas de um único dashboard. Quando ajusta o preço base, propaga. Quando precisa pausar a Loja Algarve em Outubro, marca-a como inactive e os apps + sites de mesa daquela loja mostram “Reabriremos em Junho”.

A pergunta que aparece sempre: e os colaboradores?

Multi-loja não é só catálogo. É também acesso: quem pode editar o quê, em que loja.

A VelOS resolve isto com user_store_access. Um colaborador pode ser:

O proprietário de cadeia tem visão consolidada (KPIs das 4 lojas no mesmo dashboard); o manager de Carregado vê só Carregado; o staff de Ovar não consegue ver receita de Lisboa-Centro mesmo que tente. Tudo controlado por user_store_access no servidor — a interface só mostra o que a query consegue retornar.

O custo de NÃO ter isto resolvido

Conhecemos cadeias que ficaram em 2 lojas durante 5 anos porque o sistema não escalava. Não foi falta de oportunidade comercial — foi medo de perder a coerência. Cada nova loja era uma noite acordado.

Quando a infraestrutura está desenhada para multi-loja desde o início (tenant_id + store_id em todas as queries, RLS no servidor a impedir cross-loja por engano, dashboard consolidado mas com filtros por loja), o salto de 2 → 4 lojas é uma decisão comercial, não técnica.

O custo de oportunidade de não escalar quando a procura está lá é real. Em PT, a janela de 18-24 meses entre “primeira loja a vender bem” e “fechar uma localização porque um competidor abriu ao lado” é curta. A infraestrutura tem de estar pronta antes da procura.

E se a cadeia já tem 3 lojas e Excel?

A migração não é toda-ou-nada. Vemos cadeias migrarem uma loja de cada vez ao longo de 60-90 dias:

  1. Semana 1-2: Loja-piloto. O dono escolhe a que tem operação mais estável; cardápio canónico é importado para o tenant.
  2. Semana 3-4: Loja-2 alinha. Os overrides identificados ficam explícitos. Excel deprecated.
  3. Semana 5-8: Loja-3 e Loja-4. Cada uma tem 2-3 dias de transição. Equipa treinada via app (não via documento).

Ao fim de 90 dias, a cadeia opera 4 lojas com 1 dashboard. As discrepâncias antigas (preços diferentes que não deviam ser, pratos que existem só em uma loja) ficam visíveis e o dono decide: corrigir ou tornar override explícito.

Próximo passo

Se a sua cadeia tem 2+ lojas e cada inventário mensal envolve 3 conversas de WhatsApp para confirmar preços, a VelOS resolve isto com multi-loja real. Para um plano de migração com calendário concreto, a equipa devolve uma proposta em 1-2 dias úteis após pedido. Ver preços ou usar a calculadora para estimar o ROI antes de avançar.

A coerência de marca não é luxo — é o que faz uma cadeia parecer uma marca em vez de “4 restaurantes com o mesmo nome”. O software certifica-se que isso aconteça sem comer o seu fim de semana.