Scanezi
O código na mesa abre o menu no browser.
Produtos Meniu QR
Ferramentas para hotelaria e restauração Desenvolvimento e demonstrações
O menu, a mesa e a equipa, no mesmo fluxo.
Construímos uma plataforma para menus digitais e operações acessíveis por QR. O cliente chega à informação a partir do telefone, e a equipa administra o menu e os pedidos.
- 1Código sobre a mesa
- 2Menu no navegador
- 3Solicitação à equipa
Meniu QR
Da informação ao trabalho feito.
Alegi
Explora as categorias, as opções e as informações disponíveis.
A equipa continua
Os pedidos e os estados são organizados na configuração do local.
Onde se torna útil.
Menu digital
A administração dos produtos, imagens e variantes.
Interações na mesa
Cenários para solicitar o pessoal, a conta ou o pedido.
Operações
Funções e ligações adaptadas ao modo de trabalho do local.
As encomendas, os pagamentos e a ligação com o sistema de gestão são confirmados para cada implementação.
Menu QR em detalhe
O que você pode fazer com este projeto.
Meniu QR é a plataforma através da qual um cliente lê o código na mesa, abre o menu no telemóvel sem instalar nada, faz o pedido, chama o empregado de mesa ou pede a conta. O código não é apenas uma ligação: ele pode estar associado a uma mesa, a uma zona, a uma localização ou a um serviço, e esse contexto segue adiante com cada pedido, por isso o pessoal sabe de onde vem.
Nos bastidores, a estrutura segue como é realmente um espaço: restaurante, localizações, zonas (interior, esplanada, bar, VIP, exterior), mesas, e, acima delas, pessoal com função — empregado de mesa, barman, hookah, cozinheiro, administrador ou função própria — e distribuição por mesas. O pedido tem sete estados com marca temporal para cada transição: novo, confirmado, em preparação, pronto, entregue, pago, cancelado. A chamada do empregado de mesa tem o seu próprio ciclo: em espera, assumida, resolvida.
O pessoal não precisa de uma nova aplicação: as notificações vão para Telegram, com regras configuradas por evento — pedido novo, pedido não confirmado, chamada à mesa, feedback negativo, pagamento bem-sucedido ou falhado. Se ninguém assumir dentro do intervalo definido (por defeito, cinco minutos), a notificação é escalada para o administrador.
Código QR com contexto, não apenas uma ligação
Quatro tipos de código: mesa, zona, localização e serviço. Os códigos são gerados na plataforma, podem ser exportados em PDF para impressão, e a ligação construída leva consigo o local e a mesa.
Menu com traduções separadas do conteúdo
As categorias e os produtos têm as suas próprias tabelas de tradução, por isso o texto noutra língua não substitui o original. A tradução automática passa primeiro por Anthropic (`claude-sonnet-4`), e, se essa chave faltar, por Google (`gemini-2.0-flash`). A interface tem romeno, russo e inglês.
Pedido com estados e marca temporal
Sete estados, cada um com o seu momento registado: confirmação, preparação, entrega, pagamento. Os produtos do pedido têm o seu próprio estado e as suas próprias opções escolhidas, o que permite que uma parte do pedido vá para o bar e outra para a cozinha.
Notificações no Telegram, com escalada
Bot construído em grammy, em regime webhook. As regras são definidas por restaurante e por evento, e se ninguém confirmar no intervalo configurado — por defeito, cinco minutos — a solicitação sobe para o administrador. Cada notificação enviada fica no registo.
Pagamentos com as contas do local, não através de nós
A plataforma não intermedeia o dinheiro: o restaurante usa as suas próprias credenciais. Estão implementados os adaptadores para Stripe, numerário e transferência. MAIB existe como esqueleto, marcado no código como inacabado.
Funções ativadas por subscrição, não todas de uma vez
Cada restaurante tem um conjunto de interruptores — pedido, chamar pessoal, pagamentos online, feedback, vários idiomas, integração com a caixa registadora, conta dividida, reserva de mesa, promoções. Por predefinição, só estão ativados chamar o pessoal e o pagamento em numerário; o restante é ativado conforme o plano. O limite de mesas é verificado ao adicionar, não no fim do mês.
Dados e funcionamento
O que entra no sistema. O que deve ser verificado.
- Um único local para todos os estabelecimentos, separados entre si
- PostgreSQL através de Prisma, com o identificador do restaurante em todas as tabelas e políticas de acesso ao nível da linha. A autenticação dos administradores é feita através de Supabase, o pessoal entra por Telegram, e o cliente da mesa não tem conta de todo.
- O cliente permanece anónimo
- O visitante recebe um identificador de sessão num cookie httpOnly, válido por 24 horas, marcado `secure` em produção. Não pede conta, não pede telefone, não instala nada. A encomenda e o pedido ao empregado de mesa ligam-se a essa sessão e à mesa.
- O menu continua a ser do estabelecimento
- Categorias, produtos, grupos de opções e opções são editados pelo restaurante. As traduções ficam em tabelas separadas, por isso uma tradução automática errada é corrigida sem tocar no original.
- O que não está ligado automaticamente
- Os tipos de pagamento reconhecidos no código são oito, mas existem adaptadores escritos para quatro, e o da MAIB está inacabado. Para os restantes — Moldindconbank, Paynet, Netopia, MobilPay — existe apenas o nome na lista, não a integração. É uma distinção que precisa de ser feita antes de prometer algo a um estabelecimento.
Da exploração à implementação
Como preparamos um projeto com Meniu QR.
Mapeamos o estabelecimento antes do menu
Locais, zonas, mesas, pessoal e os seus papéis. Os códigos QR são gerados com base nesta estrutura; se a estrutura estiver errada, o contexto em cada pedido também fica errado.
Escolhemos o que é iniciado desde o primeiro momento
As encomendas, o pagamento online e a integração com a caixa registadora são interruptores separados. Para um primeiro estabelecimento, o pedido ao empregado de mesa e o menu digital são suficientes para testar o fluxo com pessoal real.
Terminamos a parte do pagamento e da caixa registadora, para esse estabelecimento
O adaptador da MAIB e a correspondência das mesas com o sistema de caixa são trabalho a fazer, não configuração. É estimado com base no fornecedor concreto do estabelecimento, com as suas credenciais e documentação.
Testamos com o pessoal, num turno real
O fluxo quebra-se nas pessoas, não no código: quem confirma, em quanto tempo, o que acontece quando ninguém responde. A escalada aos cinco minutos é um ponto de partida que se calibra no estabelecimento.
Perguntas que vale a pena esclarecer.
Pode um estabelecimento usá-lo amanhã?
Não. É um protótipo completo em cobertura, mas inacabado e não lançado: uma única migração da base de dados, de 4 de abril de 2026, nenhum commit depois desse dia, nenhum teste automático e nenhuma instalação pública. O que se pode fazer amanhã: uma demonstração com a estrutura de um estabelecimento real, para ver o fluxo de ponta a ponta e estimar o que ainda falta.
O cliente tem de instalar uma aplicação?
Não. Lê o código e abre-se no navegador. Recebe um identificador de sessão num cookie httpOnly válido por 24 horas — sem conta, sem telefone, sem dados pessoais. A encomenda e o pedido ao empregado de mesa ligam-se a essa sessão e à mesa do código.
Pode pagar online?
Depende do fornecedor, e vale a pena dizer exatamente. O adaptador Stripe está funcional, assim como numerário e transferência. O adaptador MAIB está escrito como esqueleto e marcado no código como inacabado — precisa do SDK do banco e de certificados TLS. Para Moldindconbank, Paynet, Netopia e MobilPay existem apenas os nomes na lista de tipos, sem integração. Importante reter: a plataforma não guarda o dinheiro; o estabelecimento usa as suas próprias credenciais.
Liga-se à caixa registadora do restaurante?
Parcialmente, e a parte que falta é a que importa. Estão escritos adaptadores para iiko (Syrve) e para Poster, com autenticação e troca de token implementadas, por isso o menu pode ser trazido do sistema deles. O envio da encomenda de volta não está pronto: a correspondência da mesa do local com a mesa e o grupo de terminais no sistema deles ainda está por resolver. Portanto, importação sim, sincronização completa ainda não.
Como é que o pessoal sabe que alguém encomendou ou chamou o empregado de mesa?
No Telegram, com um bot próprio em regime webhook — sem nova aplicação para instalar nos seus telemóveis. As regras são definidas por restaurante e por evento: nova encomenda, encomenda não confirmada, chamada para a mesa ou para o administrador, feedback negativo, pessoal em pausa, pagamento bem-sucedido ou falhado. Se ninguém assumir no intervalo definido, por defeito cinco minutos, o pedido é escalado para o administrador, e cada notificação enviada fica no registo.
Em que línguas funciona o menu?
A interface tem romeno, russo e inglês. O menu tem tabelas de tradução separadas para categorias e produtos, por isso a tradução não substitui o texto original e pode ser corrigida manualmente. A tradução automática tenta primeiro Anthropic (`claude-sonnet-4`) e, se essa chave faltar, Google (`gemini-2.0-flash`).
É a mesma coisa que MEGA QR?
Não. MEGA QR gera códigos e transfere dados opticamente. Meniu QR é uma plataforma de hospitalidade: menu, encomenda, chamada do pessoal, notificações no turno e pagamentos. A única coisa em comum é o código na mesa.
Exemplo ilustrativo
Uma chamada da mesa que não se perde
Um cenário de utilização, sem dados de cliente nem resultados comerciais atribuídos.
Situação inicial
Um cliente lê o código da mesa 12 na zona da esplanada e carrega em «chamar o empregado de mesa».
Como funciona
O pedido entra associado à sessão anónima do cliente e à mesa no código, com o estado «em espera». A regra de notificação do restaurante envia a mensagem no Telegram para o pessoal atribuído à respetiva zona.
Rezultatul
O empregado de mesa confirma no Telegram e o pedido passa para «assumido», depois para «resolvido». Se ninguém confirmar no intervalo configurado, por defeito cinco minutos, o pedido sobe para o administrador. Cada notificação fica no registo, por isso depois se pode ver o que atrasou.
O que é necessário:Estrutura do local introduzida (localização, zonas, mesas), pessoal registado no bot com as respetivas funções, regras de notificação definidas por eventos e os códigos QR impressos nas mesas. As encomendas e o pagamento online são botões separados, que podem permanecer fechados no primeiro local.
Possibilidades de colaboração
Meniu QR, no contexto da sua organização.
Pontos de acesso e transferência local
Códigos para acesso a informação pública, instruções ou contactos; transferência ótica de ficheiros entre dispositivos compatíveis, com avaliação das políticas de segurança da instituição.
Empresas privadas
Definimos um piloto em torno de um processo real: utilizadores, dados, integrações, custos e critérios de aceitação. A expansão segue após a avaliação do resultado.
Instituições e empresas públicas
Estabelecemos os requisitos de acessibilidade, alojamento, proteção de dados e interoperabilidade. Qualquer ligação a serviços AGE ou STISC requer a validação da elegibilidade, do acesso e das aprovações.
Estes são cenários de adaptação, não declarações sobre contratos ou parcerias existentes. As funções propostas confirmam-se no âmbito de trabalho do projeto.
Fale sobre um pilotoParte de um ecossistema.
Agentes de voz com IA
Kallina
Construímos agentes que atendem e fazem chamadas, usam a informação do negócio e trabalham com os seus sistemas.
PlataformaConversas e suporte
aichat
Um assistente ligado à informação do seu negócio, nos canais por onde os clientes lhe escrevem.
PlataformaFerramentas no navegador
MEGA QR
O MEGA QR inclui um gerador de códigos e uma ferramenta de transferência ótica.
Instrumento públicoO que gostaria que funcionasse melhor?
Conte-nos o seu processo. Em conjunto decidimos o que vale a pena construir, o que podemos ligar e como verificamos o resultado.