Перейти к основному содержимому
megapromotingДавайте обсудим
Продукты Meniu QR

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

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

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

  1. 1Cod la masă
  2. 2Meniu în browser
  3. 3Solicitare către echipă
Пояснительная схема ·Meniu QR

Meniu 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

Платежи через счета заведения, а не через нас

Платформа не проводит деньги: ресторан использует собственные credentials. Реализованы адаптеры для 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 генерирует коды и передаёт данные оптически. Meniu QR — это платформа для сферы гостеприимства: меню, заказ, вызов персонала, уведомления по смене и платежи. Единственное общее — это код на столе.

Показательный пример

Вызов со стола, который не теряется

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

Исходная ситуация

Клиент сканирует код на столе 12 в зоне террасы и нажимает «вызвать официанта».

Как это работает

Запрос поступает, привязанный к анонимной сессии клиента и к столу из кода, со статусом «в ожидании». Правило уведомления ресторана отправляет сообщение в Telegram персоналу, закреплённому за соответствующей зоной.

Rezultatul

Официант подтверждает в Telegram, и запрос переходит в «принят», затем в «решён». Если никто не подтвердит в заданный интервал, по умолчанию пять минут, запрос поднимается к администратору. Каждое уведомление остаётся в журнале, так что позже можно увидеть, что именно задержалось.

Что необходимо: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 требует проверки соответствия, доступа и утверждений.

Это сценарии адаптации, а не заявления о существующих контрактах или партнерствах. Предлагаемые функции подтверждаются в рабочей области проекта.

Обсудить пилот

Часть экосистемы.

Что вы хотели бы наладить?

Расскажите о своём процессе. Вместе определим, что стоит построить, что можно подключить и как проверим результат.

Давайте обсудим