QR CTRL01
Цифровое право
QR ведёт не на статическую страницу, а к конкретному праву: что куплено, действует ли оно сейчас и сколько операций ещё доступно.
ВОЗМОЖНОСТИ
Контроль начинается не у сканера — он охватывает весь путь напитка
Продать напиток и реально выдать его — два разных события. Между ними может быть несколько повторных розливов, просроченное право, попытка на другой точке или технический отказ. QR CTRL делает эти состояния видимыми и управляемыми, вместо того чтобы сводить всё к факту печати QR.
02
Срок действия
Например, refill может действовать только во время визита. Когда срок заканчивается, доступ закрывается автоматически — сотруднику не нужно помнить об этом вручную.
03
Количество операций
Считаются именно успешные розливы. Это позволяет отличать реальное использование от случайных или отклонённых сканирований.
04
Интервал
Если бизнес-модель требует паузы между refill, система проверяет её при каждой новой попытке — одинаково для всех точек.
05
Точка и станция
QR можно ограничить конкретным рестораном или группой станций, чтобы право не путешествовало по сети вместе с фотографией чека.
06
Разные сценарии
Безлимит, комбо, промо, персонал, мероприятия и дегустации работают на одном механизме, но с разными основаниями и правилами.
07
Журнал событий
В журнале видно не только успешные розливы, но и отказы с причиной — это важно и для аналитики, и для поддержки.
08
Централизованная настройка
Изменение правила не должно начинаться с рассылки новой памятки по ресторанам. Централизованная настройка позволяет менять стандарт управляемо.
ДАННЫЕ
Продажа и фактическое использование — не одно и то же событие
Чек показывает коммерческий факт: напиток продан. Но он не отвечает, подошёл ли гость к станции, сколько раз воспользовался refill, столкнулся ли с отказом и почему. Без второго слоя данных часть реального процесса остаётся невидимой.
Проданосколько прав создано
Использованосколько успешных операций прошло
Отклоненосколько попыток не прошло правила
Причинакакое условие остановило операцию
НЕ ЖЁСТКИЙ «ТУРНИКЕТ»
Правила можно настроить под конкретную бизнес-модель
Хорошие правила не должны ощущаться наказанием. Если ресторан обещает безлимит в течение визита, система должна защищать именно это обещание — а не заставлять человека ждать у аппарата из-за чрезмерно жёстких ограничений. Поэтому параметры настраиваются под бизнес-модель и обязательно проверяются на живом пилоте.
Посмотреть сценарии →
Продолжить изучение
Связанные разделы
Чтобы понять, как эти возможности превращаются в рабочий контур, посмотрите архитектуру платформы, интеграции и сценарии использования.
Следующий шаг
Не выбирайте правила в переговорной — проверьте их на реальных гостях.
На пилоте быстро становится видно, где правило действительно защищает экономику, а где просто создаёт лишнее трение для гостя. Настроим сценарий так, чтобы контроль не ломал сервис.
Обсудить пилот ↗