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

Инструменты для гостеприимства Разработка и демонстрации

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

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

  1. 1Код у стола
  2. 2Меню в браузере
  3. 3Запрос к команде
Пояснительная схема ·Meniu QR

Meniu QR

От информации к сделанному делу.

01

Scanezi

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

02

Alegi

Вы просматриваете категории, опции и доступную информацию.

03

Команда продолжает

Запросы и статусы организованы в конфигурации заведения.

Где это становится полезным.

Цифровое меню

Управление товарами, изображениями и вариантами.

Взаимодействия за столом

Сценарии для вызова персонала, счёта или заказа.

Операции

Роли и подключения, адаптированные к способу работы заведения.

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

Меню 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, и запрос переходит в «принят», затем в «решён». Если никто не подтвердит в заданный интервал, по умолчанию пять минут, запрос поднимается к администратору. Каждое уведомление остаётся в журнале, так что позже можно увидеть, что именно задержалось.

Что необходимо:Структура заведения введена (местоположение, зоны, столы), персонал зарегистрирован в боте со своими ролями, правила уведомлений заданы по событиям, а QR-коды напечатаны на столах. Заказы и онлайн-оплата — отдельные переключатели, которые могут оставаться закрытыми для первого заведения.

Возможности сотрудничества

Meniu QR, в контексте вашей организации.

Точки доступа и локальная передача

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

Частные компании

Мы определяем пилот вокруг реального процесса: пользователи, данные, интеграции, затраты и критерии приемки. Масштабирование следует после оценки результата.

Государственные учреждения и компании

Мы устанавливаем требования к доступности, размещению, защите данных и совместимости. Любое соединение с сервисами AGE или STISC требует проверки соответствия, доступа и утверждений.

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

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

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

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

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

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