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.
- 1Cod la masă
- 2Meniu în browser
- 3Solicitare către echipă
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țiuni
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:Structura localului introdusă (locație, zone, mese), personal înregistrat în bot cu rolurile lui, reguli de notificare setate pe evenimente și codurile QR tipărite pe mese. Comenzile și plata online sunt comutatoare separate, care pot rămâne închise la primul 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.
Instrument publicO 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.