Sari la conținut
megapromotingHai să discutăm
Produse Meniu QR

Instrumente pentru ospitalitate Dezvoltare & demonstrații

Meniul, masa și echipa, în același flux.

Construim o platformă pentru meniuri digitale și operațiuni accesibile prin QR. Clientul ajunge la informație de pe telefon, iar echipa administrează meniul și solicitările.

  1. 1Cod la masă
  2. 2Meniu în browser
  3. 3Solicitare către echipă
Schemă explicativă ·Meniu QR

Meniu QR

De la informație la lucru făcut.

01

Scanezi

Codul de la masă deschide meniul în browser.

02

Alegi

Explorezi categoriile, opțiunile și informațiile disponibile.

03

Echipa continuă

Solicitările și statusurile sunt organizate în configurația localului.

Unde devine util.

Meniu digital

Administrarea produselor, imaginilor și variantelor.

Interacțiuni la masă

Scenarii pentru solicitarea personalului, notei sau comenzii.

Operațiuni

Roluri și conexiuni adaptate modului de lucru al localului.

Comenzile, plățile și legătura cu sistemul de gestiune se confirmă pentru fiecare implementare.

Meniu QR în detaliu

Ce poți face cu acest proiect.

Meniu QR este platforma prin care un client scanează codul de pe masă, deschide meniul pe telefon fără să instaleze nimic, comandă, cheamă ospătarul sau cere nota. Codul nu e doar un link: el poate fi legat de o masă, de o zonă, de o locație sau de un serviciu, iar contextul acela merge mai departe cu fiecare cerere, deci personalul știe de unde vine.

În spate, structura urmărește cum arată de fapt un local: restaurant, locații, zone (interior, terasă, bar, VIP, exterior), mese, iar peste ele personal cu rol — ospătar, barman, hookah, bucătar, administrator sau rol propriu — și repartizare pe mese. Comanda are șapte stări cu marcaj de timp pentru fiecare tranziție: nouă, confirmată, în preparare, gata, livrată, plătită, anulată. Chemarea ospătarului are propriul ciclu: în așteptare, preluată, rezolvată.

Personalul nu are nevoie de o aplicație nouă: notificările merg pe Telegram, cu reguli configurate pe eveniment — comandă nouă, comandă neconfirmată, chemare la masă, feedback negativ, plată reușită sau eșuată. Dacă nimeni nu preia în intervalul stabilit (implicit cinci minute), notificarea escaladează către administrator.

01

Cod QR cu context, nu doar un link

Patru tipuri de cod: masă, zonă, locație și serviciu. Codurile se generează în platformă, se pot exporta ca PDF pentru tipar, iar linkul construit poartă cu el localul și masa.

02

Meniu cu traduceri separate de conținut

Categoriile și produsele au tabele de traducere proprii, deci textul în altă limbă nu suprascrie originalul. Traducerea automată merge întâi prin Anthropic (`claude-sonnet-4`), iar dacă acea cheie lipsește, prin Google (`gemini-2.0-flash`). Interfața are română, rusă și engleză.

03

Comandă cu stări și marcaj de timp

Șapte stări, fiecare cu momentul ei înregistrat: confirmare, preparare, livrare, plată. Produsele din comandă au propria stare și propriile opțiuni alese, ceea ce permite ca o parte din comandă să plece la bar și alta la bucătărie.

04

Notificări pe Telegram, cu escaladare

Bot construit pe grammy, în regim webhook. Regulile se setează per restaurant și per eveniment, iar dacă nimeni nu confirmă în intervalul configurat — implicit cinci minute — cererea urcă la administrator. Fiecare notificare trimisă rămâne în jurnal.

05

Plăți cu conturile localului, nu prin noi

Platforma nu intermediază banii: restaurantul își folosește propriile credențiale. Sunt implementate adaptoarele pentru Stripe, numerar și transfer. MAIB există ca schelet, marcat în cod ca neterminat.

06

Funcții pornite pe abonament, nu pe toate deodată

Fiecare restaurant are un set de comutatoare — comandă, chemare personal, plăți online, feedback, mai multe limbi, integrare cu casa de marcat, nota împărțită, rezervare de masă, promoții. Implicit sunt pornite doar chemarea personalului și plata cu numerar; restul se activează după plan. Limita de mese se verifică la adăugare, nu la sfârșit de lună.

Date și funcționare

Ce intră în sistem. Ce trebuie verificat.

Un singur loc pentru toate localurile, separate între ele
PostgreSQL prin Prisma, cu identificatorul restaurantului pe toate tabelele și politici de acces la nivel de rând. Autentificarea administratorilor se face prin Supabase, personalul intră prin Telegram, iar clientul de la masă nu are cont deloc.
Clientul rămâne anonim
Vizitatorul primește un identificator de sesiune într-un cookie httpOnly, valabil 24 de ore, marcat `secure` în producție. Nu cere cont, nu cere telefon, nu instalează nimic. Comanda și chemarea ospătarului se leagă de sesiunea aceea și de masă.
Meniul rămâne al localului
Categorii, produse, grupuri de opțiuni și opțiuni sunt editate de restaurant. Traducerile stau în tabele separate, deci o traducere automată greșită se corectează fără să atingă originalul.
Ce nu e conectat automat
Tipurile de plată recunoscute în cod sunt opt, dar adaptoare scrise există pentru patru, iar cel pentru MAIB e neterminat. Pentru celelalte — Moldindconbank, Paynet, Netopia, MobilPay — există doar numele în listă, nu și integrarea. E o distincție care trebuie făcută înainte de a promite ceva unui local.

De la explorare la implementare

Cum pregătim un proiect cu Meniu QR.

01

Cartografiem localul înainte de meniu

Locații, zone, mese, personal și rolurile lor. Codurile QR se generează pe structura asta; dacă structura e greșită, contextul din fiecare cerere e greșit.

02

Alegem ce se pornește din prima

Comenzile, plata online și integrarea cu casa de marcat sunt comutatoare separate. Pentru un prim local, chemarea ospătarului și meniul digital sunt suficiente ca să testezi fluxul cu personalul real.

03

Terminăm partea de plată și de casă de marcat, pentru localul respectiv

Adaptorul MAIB și potrivirea meselor cu sistemul de casă sunt muncă de făcut, nu configurare. Se estimează pe furnizorul concret al localului, cu credențialele și documentația lui.

04

Testăm cu personalul, în tură reală

Fluxul se rupe la oameni, nu la cod: cine confirmă, în cât timp, ce se întâmplă când nimeni nu răspunde. Escaladarea la cinci minute e un punct de pornire care se calibrează în local.

Întrebări care merită clarificate.

Poate un local să-l folosească mâine?

Nu. E un prototip complet ca acoperire, dar neterminat și nelansat: o singură migrare de bază de date, din 4 aprilie 2026, niciun commit după acea zi, niciun test automat și nicio instalare publică. Ce se poate face mâine: o demonstrație pe structura unui local real, ca să se vadă fluxul cap-coadă și să se estimeze ce mai lipsește.

Trebuie clientul să instaleze o aplicație?

Nu. Scanează codul și se deschide în browser. Primește un identificator de sesiune într-un cookie httpOnly valabil 24 de ore — fără cont, fără telefon, fără date personale. Comanda și chemarea ospătarului se leagă de sesiunea aceea și de masa de pe cod.

Se poate plăti online?

Depinde de furnizor, și merită spus exact. Adaptorul Stripe e funcțional, la fel numerarul și transferul. Adaptorul MAIB e scris ca schelet și marcat în cod drept neterminat — are nevoie de SDK-ul băncii și de certificate TLS. Pentru Moldindconbank, Paynet, Netopia și MobilPay există doar numele în lista de tipuri, fără integrare. Important de reținut: platforma nu ține banii; localul folosește propriile credențiale.

Se leagă de casa de marcat a restaurantului?

Parțial, și partea care lipsește e cea care contează. Sunt scrise adaptoare pentru iiko (Syrve) și pentru Poster, cu autentificare și schimb de token implementate, deci meniul se poate aduce din sistemul lor. Trimiterea comenzii înapoi nu e gata: potrivirea mesei din local cu masa și grupul de terminale din sistemul lor e încă de rezolvat. Deci import da, sincronizare completă nu încă.

Cum află personalul că cineva a comandat sau a chemat ospătarul?

Pe Telegram, cu un bot propriu în regim webhook — fără aplicație nouă de instalat pe telefoanele lor. Regulile se setează per restaurant și per eveniment: comandă nouă, comandă neconfirmată, chemare la masă sau la administrator, feedback negativ, personal în pauză, plată reușită sau eșuată. Dacă nimeni nu preia în intervalul stabilit, implicit cinci minute, cererea escaladează la administrator, iar fiecare notificare trimisă rămâne în jurnal.

În ce limbi merge meniul?

Interfața are română, rusă și engleză. Meniul are tabele de traducere separate pentru categorii și produse, deci traducerea nu suprascrie textul original și se poate corecta manual. Traducerea automată încearcă întâi Anthropic (`claude-sonnet-4`) și, dacă acea cheie lipsește, Google (`gemini-2.0-flash`).

Este același lucru cu MEGA QR?

Nu. MEGA QR generează coduri și transferă date optic. Meniu QR e o platformă de ospitalitate: meniu, comandă, chemarea personalului, notificări în tură și plăți. Singurul lucru comun e codul de pe masă.

Exemplu ilustrativ

O chemare de la masă care nu se pierde

Un scenariu de utilizare, fără date de client sau rezultate comerciale atribuite.

Situația inițială

Un client scanează codul de pe masa 12 din zona de terasă și apasă „cheamă ospătarul”.

Cum lucrează

Cererea intră legată de sesiunea anonimă a clientului și de masa din cod, cu starea „în așteptare”. Regula de notificare a restaurantului trimite mesajul pe Telegram către personalul repartizat pe zona respectivă.

Rezultatul

Ospătarul confirmă din Telegram și cererea trece pe „preluată”, apoi pe „rezolvată”. Dacă nu confirmă nimeni în intervalul configurat, implicit cinci minute, cererea urcă la administrator. Fiecare notificare rămâne în jurnal, deci se poate vedea ulterior ce a întârziat.

Ce este necesar: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.

Posibilități de colaborare

Meniu QR, în contextul organizației tale.

Puncte de acces și transfer local

Coduri pentru acces la informații publice, instrucțiuni sau contacte; transfer optic de fișiere între dispozitive compatibile, cu evaluarea politicilor de securitate ale instituției.

Companii private

Definim un pilot în jurul unui proces real: utilizatori, date, integrări, costuri și criterii de acceptare. Extinderea urmează după evaluarea rezultatului.

Instituții și companii de stat

Stabilim cerințele de accesibilitate, găzduire, protecție a datelor și interoperabilitate. Orice conexiune cu servicii AGE sau STISC necesită validarea eligibilității, accesului și aprobărilor.

Acestea sunt scenarii de adaptare, nu declarații despre contracte sau parteneriate existente. Funcțiile propuse se confirmă în domeniul de lucru al proiectului.

Discută un pilot

Parte dintr-un ecosistem.

Ce ai vrea să funcționeze mai bine?

Povestește-ne despre procesul tău. Împreună stabilim ce merită construit, ce putem conecta și cum verificăm rezultatul.

Hai să discutăm