Перейти до основного вмісту
megapromotingПоговорімо
Продукти Меню QR

Instrumente pentru ospitalitate Розробка та демонстрації

Меню, стіл і команда — в одному потоці.

Ми будуємо платформу для цифрових меню та операцій, доступних через QR. Клієнт отримує доступ до інформації з телефону, а команда адмініструє меню та запити.

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

Меню QR

Від інформації до виконаної роботи.

01

Scanezi

Код на столі відкриває меню в браузері.

02

Alegi

Ви переглядаєте доступні категорії, опції та інформацію.

03

Команда продовжує

Запити та статуси організовані в конфігурації закладу.

Де стає корисним.

Цифрове меню

Адміністрування продуктів, зображень і варіантів.

Взаємодії за столом

Сценарії для запиту персоналу, рахунку або замовлення.

Operațiuni

Ролі та з’єднання, адаптовані до способу роботи закладу.

Замовлення, платежі та зв’язок із системою обліку підтверджуються для кожного впровадження.

Міні-меню QR детально

Що ви можете робити з цим проєктом.

Міні-меню QR — це платформа, через яку клієнт сканує код на столі, відкриває меню на телефоні без встановлення нічого, замовляє, викликає офіціанта або просить рахунок. Код — це не лише посилання: його можна прив’язати до столу, зони, локації або послуги, а цей контекст передається далі з кожним запитом, тож персонал знає, звідки він надходить.

Усередині структура відображає те, як насправді виглядає заклад: ресторан, локації, зони (всередині, тераса, бар, VIP, зовні), столи, а над ними персонал із роллю — офіціант, бармен, hookah, кухар, адміністратор або власна роль — та розподіл по столах. Замовлення має сім станів із позначкою часу для кожного переходу: нове, підтверджене, у приготуванні, готове, доставлене, оплачене, скасоване. Виклик офіціанта має власний цикл: в очікуванні, прийнятий, вирішений.

Персоналу не потрібен новий застосунок: сповіщення надходять у Telegram, із правилами, налаштованими на подію — нове замовлення, непідтверджене замовлення, виклик до столу, негативний відгук, успішна або невдала оплата. Якщо ніхто не візьме його впродовж установленого інтервалу (за замовчуванням п’ять хвилин), сповіщення ескалується до адміністратора.

01

QR-код із контекстом, а не лише посилання

Чотири типи коду: стіл, зона, локація та послуга. Коди генеруються на платформі, їх можна експортувати як PDF для друку, а зібране посилання несе із собою заклад і стіл.

02

Меню з окремими перекладами вмісту

Категорії та продукти мають власні таблиці перекладів, тож текст іншою мовою не перезаписує оригінал. Автоматичний переклад спочатку йде через Anthropic (`claude-sonnet-4`), а якщо цього ключа немає, через Google (`gemini-2.0-flash`). Інтерфейс має румунську, російську та англійську.

03

Замовлення зі станами та міткою часу

Сім станів, кожен зі своїм зафіксованим моментом: підтвердження, приготування, доставка, оплата. Товари в замовленні мають власний стан і власні вибрані опції, що дозволяє частині замовлення піти в бар, а іншій — на кухню.

04

Сповіщення в Telegram, з ескалацією

Бот, збудований на grammy, у режимі webhook. Правила налаштовуються окремо для ресторану та події, а якщо ніхто не підтвердить у налаштований інтервал — за замовчуванням п’ять хвилин — запит піднімається до адміністратора. Кожне надіслане сповіщення залишається в журналі.

05

Платежі з рахунками закладу, не через нас

Платформа не посередничає кошти: ресторан використовує власні облікові дані. Реалізовано адаптери для Stripe, готівки та переказу. MAIB існує як каркас, позначений у коді як незавершений.

06

Функції, увімкнені за підпискою, а не всі одразу

Кожен ресторан має набір перемикачів — замовлення, виклик персоналу, онлайн-платежі, відгук, кілька мов, інтеграція з касовим апаратом, поділ рахунку, резервування столу, акції. За замовчуванням увімкнено лише виклик персоналу та оплату готівкою; решта активуються після плану. Ліміт столів перевіряється під час додавання, а не наприкінці місяця.

Дані та робота

Що входить у систему. Що потрібно перевірити.

Одне місце для всіх закладів, окремо між собою
PostgreSQL через Prisma, з ідентифікатором ресторану в усіх таблицях і політиками доступу на рівні рядка. Автентифікація адміністраторів відбувається через Supabase, персонал входить через Telegram, а клієнт за столом не має жодного облікового запису.
Клієнт залишається анонімним
Відвідувач отримує ідентифікатор сесії в cookie httpOnly, дійсний 24 години, позначений `secure` у продакшені. Не вимагає облікового запису, не вимагає телефону, нічого не встановлює. Замовлення і виклик офіціанта прив’язуються до цієї сесії та до столу.
Меню залишається закладу
Категорії, продукти, групи опцій і опції редагуються рестораном. Переклади зберігаються в окремих таблицях, тож неправильний автоматичний переклад виправляється без зміни оригіналу.
Що не підключено автоматично
Типів оплати, розпізнаних у коді, вісім, але написаних адаптерів існує для чотирьох, а той, що для MAIB, не завершений. Для решти — Moldindconbank, Paynet, Netopia, MobilPay — у списку є лише назви, без інтеграції. Це розрізнення треба зробити перед тим, як щось обіцяти закладу.

Від дослідження до впровадження

Як готуємо проєкт з Meniu QR.

01

Картографуємо заклад перед меню

Локації, зони, столи, персонал і їхні ролі. QR-коди генеруються на цій структурі; якщо структура неправильна, контекст у кожному запиті теж буде неправильним.

02

Обираємо, що запускається з першого дня

Замовлення, онлайн-оплата та інтеграція з касовим апаратом — окремі перемикачі. Для першого закладу виклику офіціанта й цифрового меню достатньо, щоб протестувати потік із реальним персоналом.

03

Допрацьовуємо частину оплати та касового апарата для цього закладу

Адаптер MAIB і узгодження столів із касовою системою — це робота, яку треба виконати, а не налаштувати. Її оцінюють на основі конкретного постачальника закладу, з його обліковими даними та документацією.

04

Тестуємо з персоналом, у реальній зміні

Потік ламається на людях, а не на коді: хто підтверджує, за який час, що відбувається, коли ніхто не відповідає. Ескалація через п’ять хвилин — це відправна точка, яку калібрують у закладі.

Питання, які варто уточнити.

Чи може заклад використовувати його завтра?

Ні. Це повністю покритий прототип, але незавершений і не випущений: одна міграція бази даних, від 4 квітня 2026 року, жодного коміту після цієї дати, жодного автоматичного тесту і жодної публічної інсталяції. Що можна зробити завтра: демонстрацію на структурі реального закладу, щоб побачити потік від початку до кінця і оцінити, чого ще бракує.

Чи потрібно клієнту встановлювати застосунок?

Ні. Скануєте код, і він відкривається в браузері. Він отримує ідентифікатор сесії в cookie httpOnly, дійсний 24 години — без облікового запису, без телефону, без персональних даних. Замовлення і виклик офіціанта прив’язуються до цієї сесії та до столу з коду.

Чи можна платити онлайн?

Це залежить від постачальника, і варто сказати точно. Адаптер Stripe функціонує, як і готівка та переказ. Адаптер MAIB написаний як каркас і в коді позначений як незавершений — йому потрібні SDK банку та TLS-сертифікати. Для Moldindconbank, Paynet, Netopia та MobilPay є лише назви в списку типів, без інтеграції. Важливо пам’ятати: платформа не зберігає гроші; заклад використовує власні облікові дані.

Чи пов’язується це з касовим апаратом ресторану?

Частково, і саме тієї частини, якої бракує, найбільше не вистачає. Написані адаптери для iiko (Syrve) і для Poster, з реалізованими автентифікацією та обміном токенів, тож меню можна підтягнути з їхньої системи. Надсилання замовлення назад не готове: зіставлення столу в закладі зі столом і групою терміналів у їхній системі ще потрібно вирішити. Тобто імпорт так, повна синхронізація — ще ні.

Як персонал дізнається, що хтось замовив або викликав офіціанта?

У Telegram, через власного бота в режимі webhook — без нового застосунку, який треба встановлювати на їхні телефони. Правила налаштовуються для кожного ресторану і для кожної події: нове замовлення, непідтверджене замовлення, виклик до столу або до адміністратора, негативний відгук, персонал на перерві, успішна або невдала оплата. Якщо ніхто не візьме в обраний інтервал, за замовчуванням п’ять хвилин, запит ескалується до адміністратора, а кожне надіслане сповіщення залишається в журналі.

Якими мовами працює меню?

Інтерфейс має румунську, російську та англійську. У меню є окремі таблиці перекладів для категорій і товарів, тож переклад не перезаписує оригінальний текст і його можна виправити вручну. Автоматичний переклад спочатку використовує Anthropic (`claude-sonnet-4`) і, якщо цей ключ відсутній, Google (`gemini-2.0-flash`).

Чи це те саме, що й MEGA QR?

Ні. MEGA QR генерує коди та передає дані оптично. Мeniu QR — це платформа гостинності: меню, замовлення, виклик персоналу, сповіщення в зміні та платежі. Єдине спільне — код на столі.

Ілюстративний приклад

Виклик із столу, який не губиться

Сценарій використання, без даних клієнта чи приписаних комерційних результатів.

Початкова ситуація

Клієнт сканує код на столі 12 у зоні тераси й натискає «викликати офіціанта».

Як працює

Запит надходить, прив’язаний до анонімної сесії клієнта та до столу з коду, зі статусом «в очікуванні». Правило сповіщення ресторану надсилає повідомлення в Telegram персоналу, призначеному на цю зону.

Rezultatul

Офіціант підтверджує це в Telegram, і запит переходить у «взяте в роботу», потім у «вирішене». Якщо ніхто не підтвердить у налаштований інтервал, за замовчуванням п’ять хвилин, запит піднімається до адміністратора. Кожне сповіщення залишається в журналі, тож згодом можна побачити, що саме затримало.

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.

Можливості співпраці

Meniu QR, у контексті вашої організації.

Пункти доступу та локального передавання

Коди для доступу до публічної інформації, інструкції або контакти; оптичне передавання файлів між сумісними пристроями з оцінкою політик безпеки установи.

Приватні компанії

Ми визначаємо пілот навколо реального процесу: користувачі, дані, інтеграції, витрати та критерії приймання. Розширення відбувається після оцінки результату.

Державні установи та компанії

Визначаємо вимоги до доступності, хостингу, захисту даних та інтероперабельності. Будь-яке з’єднання з послугами AGE або STISC потребує валідації придатності, доступу та схвалень.

Це сценарії адаптації, а не заяви про наявні контракти чи партнерства. Запропоновані функції підтверджуються в межах робочої сфери проєкту.

Обговорити пілот

Частина екосистеми.

Що вам хотілося б налагодити?

Розкажіть про свій процес. Разом визначимо, що варто збудувати, що можна підключити і як перевіримо результат.

Поговорімо