Sistema de gestão de restaurante: o que cobre e como escrever os seus requisitos

Quem procura um sistema de gestão de restaurante costuma já ter vários programas em casa e pelo menos um número que alguém copia à mão de um para o outro. O nome não ajuda a escolher, porque cada fabricante lhe dá o âmbito que quer: para uns vai da sala ao processamento salarial, para outros é um único módulo. Na prática, é o software que guarda num só sítio os registos com que a casa trabalha. O menu, os pedidos, as mesas, as reservas e os clientes e, nas versões mais completas, o stock, as horas do pessoal e os custos. O que não guardar tem de ficar entregue a outro sistema, com alguém responsável por ele. Antes de comprar ou desenvolver, a pergunta que interessa é que registos da sua casa o sistema passa a guardar e quais continuam noutro lado.

Sala, cozinha e escritório: as três partes do trabalho

Ajuda separar o trabalho em três partes. A sala é o que o cliente vê e toca: o menu, o pedido e o pagamento, as mesas e as reservas, a ficha do cliente. A cozinha e o armazém ficam com o ecrã de cozinha, as contagens de stock, as compras e o custeio das fichas técnicas. O escritório trata dos horários do pessoal, do processamento salarial e da contabilidade.

Cada fabricante dá a estas peças o nome que lhe convém. Um chama-lhe gestão de pedidos, outro ecrã de vendas, e por baixo continua a ser um pedido. Por isso vale a pena escrever os requisitos em registos e regras, e não em nomes de módulos. O registo é o mesmo seja qual for o ecrã onde aparece, e a comparação entre fabricantes aguenta-se.

Mude um preço e veja quem manda no menu

Se para mudar um preço tem de ir ao POS, depois ao menu QR e depois à plataforma de entregas, o seu menu tem três donos, e mais cedo ou mais tarde as três cópias deixam de bater certo. O mesmo acontece às reservas apontadas num caderno e aos contactos de clientes que só existem no telemóvel do gerente.

Mudar um preço é a forma mais rápida de testar se um sistema guarda mesmo um registo. Introduza o preço novo uma vez e veja onde aparece. Se surge no menu do cliente, na plataforma de entregas e no relatório de vendas da semana seguinte, o artigo tem um só dono. Se alguém o tem de escrever em três ecrãs, o problema que já tinha continua lá, agora dentro do sistema novo.

A regra 30/30/30/10 como teste de âmbito

A regra 30/30/30/10 é uma referência prática para repartir a faturação. Cerca de 30 % vai para comida e bebida, 30 % para pessoal, 30 % para tudo o resto de que a casa precisa para abrir a porta (renda, água e luz, marketing, reparações) e perto de 10 % fica como lucro. Serve de orçamento de partida e pouco mais. Um bar de café e uma steakhouse não compram nem contratam da mesma maneira, e a repartição real de cada um pode ficar bem longe destes valores.

Onde a regra ajuda mesmo é na escolha de software, porque cada um dos quatro números sai de um registo diferente. A faturação sai dos pedidos. O custo de comida precisa do que se comprou, do que se contou e de uma ficha técnica por prato, porque um artigo com preço e sem ficha técnica não diz quanto custa o prato que sai para a sala. O custo com pessoal precisa das horas registadas e do valor pago à hora. Os custos operacionais saem das faturas lançadas na contabilidade.

Um sistema que só guarda registos da sala dá-lhe a faturação e nenhuma das três linhas de custo. Isso não é um defeito, desde que o saiba antes de assinar e já tenha decidido de onde vêm a comida, o pessoal e os gastos gerais. As contagens de stock que alimentam o custo de comida também dão a taxa de rotação de inventário, por isso, quando escolher o sistema que as vai guardar, pense nos dois números.

O software que um restaurante costuma ter instalado

Não conhecemos uma contagem pública e datada do software que a maioria dos restaurantes usa, e por isso não citamos quotas de mercado. Quando se faz o inventário de uma casa, o que costuma aparecer é uma pilha de programas e não um sistema único. Há um POS no balcão. Os pedidos de entrega chegam pelos tablets das próprias plataformas, as reservas vivem numa ferramenta à parte ou num livro de papel e o contabilista trabalha noutro programa. Algures no meio há uma folha de cálculo com o custo das fichas técnicas ou a escala do pessoal.

Ter vários programas não é, por si, o problema. O custo está nas junções, onde alguém lê um número num ecrã e o volta a escrever noutro. Faça a lista dessas junções antes de pedir a primeira demonstração.

Quanto custa um POS num mês normal da sua casa

O POS mais barato numa página de comparação costuma ser o da subscrição mais baixa, e essa linha raramente é a conta toda. Antes de comparar, some o que o sistema vai cobrar num mês normal.

Comece pela subscrição, contada para os espaços e terminais que tem de facto. Junte o processamento de pagamentos, que cresce com as vendas. No extrato mensal do processador, a linha das comissões mostra uma percentagem sobre o valor pago, uma taxa fixa por transação, ou as duas. A conta do mês é (percentagem × número de transações × talão médio) + (taxa fixa × número de transações). Preencha-a com o seu último extrato, por exemplo: 2 400 transações × talão médio de ___ € × ___ % + 2 400 × ___ € de taxa fixa. É esta conta que mostra se uma subscrição baixa presa a um único processador sai mais cara do que uma mais alta que o deixa escolher. Depois vem o equipamento (terminais, leitores de cartões, impressoras de cozinha, tablets), que uns fabricantes vendem, outros alugam e outros deixam trazer de casa.

Falta ainda o que liga o POS aos programas que a casa já usa. As integrações com entregas, reservas, contabilidade ou menu digital tanto podem ser gratuitas como ter uma mensalidade por ligação. Utilizadores a mais, espaços a mais e limites de pedidos mais altos também aparecem muitas vezes como extras, fora do preço base.

Faça a mesma conta para cada fabricante da lista curta, com um mês real e o seu número real de pedidos. Se recebe o pagamento na mesa, leia como funciona o pagamento por QR antes de decidir se é o POS ou outra ferramenta a tratar disso, porque essa escolha mexe na linha do processamento.

A ficha do cliente: o que um CRM de restaurante precisa de guardar

Um CRM vale o que valem as fichas de cliente que o alimentam, e num restaurante muitos clientes chegam anónimos. Quem entra sem reserva e paga em dinheiro não deixa nome. Antes de comparar ferramentas de CRM, liste por onde podem entrar os dados de um cliente: uma encomenda online, uma reserva, um formulário de opinião, a adesão a um programa de fidelização, um código promocional usado.

A ficha em si é curta. Nome e contacto, com consentimento para ser contactado. Histórico de visitas ou de pedidos. Notas da reserva, como alergias, preferência de lugar ou um aniversário. As opiniões e avaliações que o cliente deixou.

O melhor CRM para um restaurante é o que está onde esses dados já entram. Um CRM isolado, sem pedidos nem reservas a alimentá-lo, fica vazio, por muito bons que sejam os ecrãs de campanhas. Os formulários de opinião são uma fonte barata de fichas, e escolher bem as perguntas do inquérito decide se o cliente chega ao fim.

O artigo do menu pede a definição mais completa

A gestão do menu é muitas vezes o ponto de partida, e o artigo do menu é o registo que mais convém definir bem. Se o requisito diz só nome e preço, o sistema não consegue dizer a um cliente se o prato leva frutos secos, nem tirar os pequenos-almoços do menu às onze, nem mostrar que tamanho se vende. Um artigo completo tem descrição e fotografia, um preço por tamanho, extras (mais uma dose de café, sem cebola), alergénios e informação nutricional, e os dias e horas em que pode ser pedido.

É também no artigo que a sala e a cozinha se encontram. O preço está no menu ou no POS, e a ficha técnica que dá o custo do prato costuma estar num sistema de back-office. Se os dois não partilham o mesmo artigo, comparar o que se vendeu com o que custou passa a ser uma folha de cálculo que alguém refaz à mão todas as semanas. Pergunte ao fabricante por essa ligação antes de perder tempo com o ecrã do menu.

As regras que a equipa já cumpre sem estarem escritas

Um registo é algo que existe: um artigo, uma mesa, uma reserva. Uma regra é o que o sistema faz quando alguma coisa acontece. Quase todas as casas já trabalham com regras que ninguém pôs no papel, explicadas a cada pessoa nova e lembradas a meio do serviço. Escreva cada uma numa linha, com o que acontece, o que o sistema faz e quem pode passar por cima.

Os artigos de pequeno-almoço deixam de se poder pedir às onze, e o menu de almoço só aparece à hora de almoço. Uma encomenda de entrega abaixo do valor mínimo é recusada, e o tempo de entrega prometido é a soma da preparação com o trajeto. O álcool pede verificação de idade. Um código promocional pode valer nas entregas e não na sala, ou só acima de certo valor.

Depois vêm as perguntas sobre quem. O pedido é enviado pelo cliente no telemóvel, pelo empregado no tablet, ou pelos dois? Quem o pode anular, e até que ponto da cozinha a anulação ainda é permitida? O dinheiro tem regras próprias: preços por tamanho, couvert e taxa de serviço, percentagens de gorjeta sugeridas, a forma de dividir uma conta. E há os momentos difíceis, como um artigo que acaba a meio do serviço ou uma mesa que já pagou e continua sentada.

Algumas destas regras não vão caber em nenhum programa que avaliar. Guarde-as numa lista à parte. Ficam a cargo da equipa, e são as primeiras em que uma pessoa acabada de chegar se engana.

Requisitos tirados de um serviço real

Não precisa de modelo. Leve um caderno durante um serviço inteiro, de preferência um cheio e outro calmo, e aponte cada vez que a mesma informação é escrita pela segunda vez. Uma comanda em papel que depois é marcada na caixa. Uma reserva feita por telefone e copiada para o livro. Um preço mudado no quadro e esquecido na aplicação. Cada uma dá um requisito que consegue defender, porque o viu acontecer.

A seguir, acompanhe um pedido desde que é tirado até chegar à contabilidade e conte por quantos sítios passa. Se forem dois ou três, a integração sobe para o topo da lista.

Há duas coisas que o caderno não apanha. Um canal de pedido digital encurta a espera para pedir, mas a cozinha não cozinha mais depressa por causa disso, e se não acompanhar, o atraso sai da mesa e vai parar ao passe. Também nem todas as mesas querem pedir pelo telemóvel, porque grupos grandes e certas ocasiões continuam à espera do empregado. Planeie as encomendas online no restaurante como um canal que corre ao lado do serviço à mesa, e não como substituto dele.

Desenhar um sistema de gestão como projeto de software

Muita gente que procura este tema quer construir um sistema de gestão de restaurante, não comprá-lo, muitas vezes como projeto de software. Nesse caso, a divisão entre registos e regras já é o desenho. Cada registo passa a ser uma entidade com os seus campos: artigo, extra, pedido, linha de pedido, mesa, zona, reserva, cliente, funcionário. Cada regra do caderno passa a ser uma validação ou uma mudança de estado, como um pedido que deixa de poder ser anulado quando a cozinha o começa.

Um projeto que parte dos ecrãs tende a acabar com os mesmos dados guardados em dois sítios. Partir do artigo, do pedido e da mesa mantém o âmbito sob controlo, e as entidades da cozinha, como fichas técnicas e contagens de stock, podem entrar mais tarde sem obrigar a refazer a parte da sala.

Lista curta de fabricantes e ordem da configuração

Nós fazemos um destes sistemas, por isso não vamos ordenar os dos outros. Em vez disso, agrupe os fabricantes pelo registo à volta do qual construíram o produto. As suites de back-office partem do inventário, das compras e da contabilidade. Os sistemas centrados no POS partem do pedido e do pagamento. As plataformas viradas para o cliente partem do menu, dos canais de pedido, do site e das reservas. O caderno mostra em qual destes três grupos estão as suas falhas.

Pegue nas três duplicações que mais vezes apareceram e peça a cada fabricante da lista curta que as resolva numa demonstração, no ecrã dele e com o seu menu carregado. Se a resposta for o nome de uma funcionalidade, peça para ver o ecrã.

A configuração segue uma ordem fixa, porque cada passo lê do anterior. Primeiro o menu, artigo a artigo, com tamanhos, extras, alergénios e disponibilidade, e é este o passo que costuma demorar mais. Depois as mesas e as zonas, os canais em que o menu aparece, as regras do caderno passadas para as definições e as ligações ao POS, ao fornecedor de pagamentos e à impressora. No fim do primeiro dia de serviço, peça ao sistema esse dia, artigo a artigo. Se tiver de o exportar e refazer numa folha de cálculo, o requisito de relatórios não está cumprido.

O conteúdo gerado fica para o fim, porque copia o que já está no sistema. Em julho de 2026 gerámos no painel da FineDine um site de teste para uma pastelaria. A secção Popular Items mostrou um T-Bone Steak e um Filet Mignon, vindos do menu de exemplo, e como a ficha do estabelecimento estava vazia, a localização saiu como texto de preenchimento. Fosse qual fosse a descrição que escrevemos, essas partes vieram do menu e da ficha do estabelecimento. Uma tradução ou um relatório gerados sobre um menu a meio podem repetir os erros desse menu da mesma maneira.

O que a FineDine cobre e o que deixa a outros sistemas

A FineDine cobre a sala e os relatórios. No Menu Manager, cada artigo guarda descrição, fotografia e vídeo, preço por tamanho, extras, informação nutricional e alergénios, e os dias e horas em que está disponível. O menu QR que o cliente abre mostra esse mesmo artigo, com ícones de alergénios e preços por tamanho, e o AI Website Builder lê a partir dele. Se a carta já existe em fotografia, PDF, Excel ou CSV, o Menu Manager monta um menu a partir do ficheiro carregado, e o passo mais longo da configuração passa a ser verificar e corrigir o que entrou.

As mesas ficam organizadas por zonas numa planta da sala, e cada mesa pode ter o seu código QR ou partilhar um. O código pode só mostrar o menu ou também receber pedidos. Os tablets têm três modos: na mão do empregado, fixos na mesa ou como quiosque de autosserviço. As reservas são um módulo à parte, com definições próprias. A maior parte das regras do caderno tem uma definição correspondente: pedido mínimo, custo de entrega, tempo de preparação e de trajeto, verificação de idade, percentagens de gorjeta, couvert e taxa de serviço, e códigos promocionais limitados a um canal ou a um valor mínimo. As fichas de cliente vêm dos pedidos, das reservas, dos formulários de opinião e das avaliações aos artigos, e ficam juntas em Guests & Engagement.

Os relatórios têm duas camadas. Os relatórios padrão cobrem resumo, artigos, negócio e reservas. O AI Reports (FineDine IQ) atualiza de hora a hora, compara faturação, pedidos e valor médio por conta com um período anterior, assinala anomalias e sugere ações, como acrescentar fotografia aos artigos que não a têm. Com as duas camadas fica coberta a linha da faturação da regra 30/30/30/10. As ligações a POS, pagamentos e impressora estão no Marketplace, umas gratuitas e outras com mensalidade, por isso confirme primeiro se as suas lá estão.

A FineDine não tem módulo de inventário, compras, custeio de fichas técnicas, horários do pessoal, processamento salarial ou contabilidade. As contas do pessoal têm funções que definem quem pode fazer o quê, mas não registam horas. O custo de comida, o pessoal e os custos operacionais vão ter de vir de outro sistema. O que falta acrescentar aos requisitos é como esse sistema recebe as vendas por artigo, seja da FineDine, seja do POS que ligar.