Ao escolher um sistema de gestão de restaurantes convém começar não pelas funcionalidades de que precisa, mas por ver onde guarda hoje cada informação. Se o menu está num sítio, as reservas noutro, os pedidos no POS e os dados de cliente num quarto sistema, a mesma informação tem de ser atualizada e verificada mais do que uma vez.
Por isso, ao avaliar um sistema é mais útil olhar para onde vão ficar o menu, o pedido, a mesa, a reserva, o cliente e o pessoal. Para cada um, esclareça duas coisas: que sistema guarda o registo principal e se os outros o conseguem ler a partir daí. Estas respostas são a base da sua lista de requisitos.
O que faz um sistema de gestão de restaurantes
Pense em mudar um preço. Quando o sistema funciona, a alteração faz-se uma vez e aparece ao mesmo tempo no menu que o cliente vê, no portal de entregas e no relatório da semana. Quando não funciona, a mesma alteração faz-se em três sítios, um fica por mexer, e é quase sempre o que o cliente tem à frente.
O termo é usado com bastante largueza. Há fabricantes que vendem por baixo dele uma suite inteira e outros que chamam o mesmo a um único módulo, por isso a comparação arruma-se a perguntar de que registos cada um toma conta.
Convém contar também com aquilo que o software não resolve. Um canal de pedido digital encurta a espera do pedido, não a da comida: se a cozinha não conseguir acompanhar o ritmo a que as comandas entram, a espera muda-se da mesa para o passe e o cliente sente-a na mesma, apenas mais tarde.
O âmbito: os registos que o sistema guarda
Os nomes dos módulos que vê nas páginas de produto mudam de sistema para sistema: aquilo a que um chama gestão de pedidos, outro chama ecrã de vendas. Já a informação de menu, pedido, mesa e reserva tem de ser guardada algures, seja qual for o sistema. Escrever a lista de requisitos à volta dessa informação permite comparar sistemas com as mesmas perguntas.
| Registo | O que tem de guardar | Quem o lê a seguir |
|---|---|---|
| Artigo do menu | Nome, descrição, fotografia, um preço por cada tamanho, extras, alergénios e informação nutricional, e as horas a que pode ser pedido | Menu do cliente, site, portal de entregas, relatórios de vendas |
| Pedido | Canal, mesa ou morada, artigos com os seus extras, estado, forma de pagamento | Cozinha, caixa, contabilidade, relatórios |
| Mesa e zona | Em que zona fica, quantas pessoas senta, que código tem e em que estado está neste momento | Sala, pedidos, reservas |
| Reserva | Hora, número de pessoas, duração prevista, notas do cliente, sinal se existir | Planta da sala, ficha do cliente |
| Cliente | Contacto, consentimento, histórico de pedidos, comentários e avaliações de artigos | Promoções, segmentação, recuperação depois de um serviço mau |
| Pessoal | Função e permissões, quem pode enviar um pedido e quem o pode anular | Pedidos, relatórios, rendição de turno |
O artigo do menu é o registo de que mais coisas dependem e é também o pior especificado. Escrito como um nome e um preço, dá um sistema que não sabe dizer a um cliente se o prato leva frutos secos, que não consegue esconder os pequenos-almoços às três da tarde e que não sabe qual o tamanho que realmente se vende. Escrito por inteiro, leva preço por tamanho, extras, alergénios, informação nutricional e as faixas horárias em que o artigo pode ser pedido. Tudo o que vem depois lê dali.
Regras de negócio: a metade que as listas de requisitos esquecem
Um registo diz o que existe. Uma regra diz o que o sistema tem de fazer quando alguma coisa acontece, e é aí que um caderno de encargos se separa de uma lista de desejos.
A maior parte destas regras já governa a sua casa. Vivem na cabeça de alguém, explicam-se a cada pessoa que entra nova e nunca foram escritas. Escreva-as todas na mesma forma: quando acontecer isto, o sistema tem de fazer aquilo, e estas pessoas podem contrariá-lo.
- Horários. Em que dias e entre que horas se pode pedir cada artigo. Os pequenos-almoços fecham às onze e o menu do dia só existe ao almoço.
- Limiares. Valor mínimo para aceitar um pedido ao domicílio, custo de entrega, tempo de preparação e tempo de trajeto. A soma destes dois últimos é a promessa que faz ao cliente.
- Quem pode pedir o quê. Verificação de idade no álcool, um código promocional que vale nas entregas e não na sala, um desconto que abre acima de certo valor.
- Permissões. Quem envia um pedido, quem o anula e até que ponto da passagem pela cozinha ainda se pode anular.
- Dinheiro. Preço por tamanho, encargos que se somam à conta e em que canais se aplicam, como se divide uma conta por várias pessoas.
- Estados. O que acontece quando o cliente cancela, o que acontece a um artigo que acaba a meio do serviço, se a mesa fica aberta depois do pagamento.
É aqui que um sistema falha sem fazer barulho. Uma regra que o software não sabe exprimir volta a depender de alguém se lembrar dela em pleno serviço, e a essa hora a memória tem outras vinte coisas a competir com ela.
Como montar a lista de requisitos sem adivinhar
Não precisa de um modelo. Precisa de um serviço inteiro e de um caderno.
Assista a um serviço do princípio ao fim e aponte todas as vezes em que o mesmo dado é escrito num segundo sítio. Uma comanda lida em papel e reintroduzida na caixa. Uma reserva apanhada ao telefone e copiada para o livro. Um preço alterado no quadro e não na aplicação. Cada uma dessas vezes é uma linha de requisitos, e é uma linha que consegue defender porque a viu acontecer.
Depois siga um único pedido desde o momento em que é tirado até aparecer na contabilidade e conte por quantos sítios passa. Quantos mais forem, mais acima sobe a integração no caderno de encargos, porque cada salto é uma cópia que alguém mantém à mão.
Ficam duas perguntas. Para cada registo da tabela: quem o mantém hoje e quem o deve manter depois? E para cada regra que apontou: o software consegue exprimi-la, ou ela fica na cabeça de alguém?
Estas perguntas servem na mesma se, em vez de contratar um sistema, mandar desenvolver um de raiz. O que entrega a quem o vai programar é esta mesma lista, e um desenvolvimento à medida encarece precisamente onde a lista está a meio, porque cada registo mal definido acaba resolvido mais tarde e já com a casa a funcionar.
Aponte também o que a sala não vai aceitar. Nem todas as mesas querem pedir pelo telemóvel: os grupos grandes, os clientes mais velhos e certas ocasiões continuam à espera de alguém, e uma montagem que parte do princípio de que toda a gente vai ler um código acaba contornada logo na primeira semana.
A ordem por que se monta
A ordem não é uma preferência. Cada passo lê do anterior, por isso saltá-lo costuma significar fazer o trabalho duas vezes.
- Ficha do estabelecimento e horário de funcionamento. Daqui lê tudo o resto, incluindo o que for gerado mais tarde.
- O menu: secções, artigos, preço por tamanho, extras, alergénios e informação nutricional. É de longe o passo mais demorado e vale a pena acabá-lo antes de ligar seja o que for.
- Mesas e zonas: a que zona pertence cada mesa, quantas pessoas senta e com que código se identifica.
- Canais: sala, entrega, take-away e tablet, e que menu cada um deles mostra.
- Regras: a lista da secção anterior, metida como definição e não explicada de viva voz ao pessoal.
- Integrações: caixa, pagamento, impressora. Confirme os sistemas que já usa contra a lista compatível antes de assinar.
- Relatórios. Antes de ir para o ar, escolha um dia que já passou e peça-o ao sistema artigo a artigo. Se tiver de o exportar e refazer numa folha de cálculo, os relatórios ainda não estão dentro do âmbito, diga o que disser a lista de funcionalidades.
O que é gerado fica para o fim: o site, as fotografias, as traduções. Tudo isso lê dos registos acima e lançá-lo cedo é a maneira mais comum de o fazer duas vezes. Os limites de utilização, como o número de artigos, de mesas ou de idiomas, dependem do plano contratado, por isso confirme-os na página de preços antes de montar o menu inteiro.
Como isto funciona na FineDine
Na FineDine a ficha de um artigo guarda a descrição e a fotografia, um preço por cada tamanho, os extras, os alergénios e a informação nutricional por tamanho, os dias e as horas a que pode ser pedido e, num café, a cafeína em miligramas. O menu do cliente, os canais de pedido, o site e os relatórios leem essa mesma ficha, de modo que a alteração se faz uma só vez. Se a carta já existe em fotografia, PDF ou folha de cálculo, o criador de menus com IA retira dali as secções, os artigos e os preços e você corrige o que for preciso; o centro de tradução mantém depois o menu em vários idiomas sem o duplicar, com a percentagem concluída à vista.
As mesas e as zonas definem-se na gestão de mesas, e é de lá que saem os códigos com que cada uma é identificada. Os canais de pedido ativam-se em separado e cada um traz as suas regras, que ficam como definições e não como recados para o turno: valor mínimo, custo de entrega, tempo de preparação e de trajeto, verificação de idade e códigos promocionais que se podem limitar a um único canal.
O Marketplace lista as caixas registadoras, os gateways de pagamento e a impressora de talões a que nos ligamos, com fornecedores de pagamento pensados para a Turquia e o Médio Oriente ao lado dos globais. Algumas ligações vêm incluídas e outras pagam-se à parte, por isso confirme as que lhe interessam na página de preços. Os relatórios chegam em duas camadas: o resumo, o relatório por artigo e o de negócio de um lado, e por cima uma camada de IA que se atualiza a cada hora em vez de uma vez por noite.
Se quiser ver como ficam o seu menu, as suas mesas e as suas regras dentro de um mesmo sistema, peça-nos uma demonstração com o seu próprio serviço como exemplo.
Perguntas frequentes sobre sistemas de gestão de restaurantes
- Um sistema de gestão de restaurantes é o mesmo que um POS?
- Não exatamente, e a diferença está nos registos que cada um guarda. O POS toma conta da transação: o pagamento, a caixa, o talão. O sistema de gestão guarda o menu, o canal por onde o pedido entra, a mesa a que pertence e o cliente que está por trás. Muitas casas têm os dois a trabalhar ao mesmo tempo. A pergunta útil é qual deles guarda a versão boa do menu, porque esse é o registo que mais muda.
- E se o POS que uso não estiver na lista de integrações?
- Então o registo do pedido parte-se em dois e alguém o introduz uma segunda vez. Numa casa pequena aguenta-se; numa casa com volume sai caro. Antes de o dar como impeditivo, veja o que precisa mesmo de passar de um lado para o outro. Em bastantes restaurantes é o total de vendas do dia e não cada linha, e para isso basta uma reconciliação diária sem ligação em direto.
- Um café pequeno precisa de um?
- Se a mesma pessoa tira o pedido, prepara-o e cobra-o, e não há nada que se escreva duas vezes, o ganho é pequeno. A coisa muda quando o mesmo dado começa a viver em dois sítios, ou quando responder ao que se vendeu na terça passada significa pôr-se a contar talões.
- Quanto tempo demora a montar?
- A configuração é curta. O menu não é. O tempo vai para fotografar pratos, decidir os tamanhos e preencher os alergénios, e esse trabalho espera por si com qualquer sistema que escolha. Carregar a carta que já tem, em fotografia, PDF ou folha de cálculo, deixa um rascunho para corrigir em vez de uma lista vazia, e isso encurta bastante a primeira volta.
- O mesmo menu pode funcionar em vários idiomas?
- Pode, e convém saber o que isso implica na prática. A tradução avança campo a campo, por isso cada nome de prato e cada descrição é uma tarefa por si. Torna-se gerível quando o centro de tradução mostra a percentagem concluída de cada idioma e deixa filtrar o que continua por traduzir. A tradução automática dá uma primeira volta que depois se revê à mão, sobretudo nos nomes dos pratos e nos alergénios, e o número de idiomas depende do plano contratado.
