Что такое QR-refill
QR-refill — это модель, в которой право гостя на один или несколько розливов связано с цифровым идентификатором, обычно QR-кодом. Код не должен сам по себе «открывать» постмикс. Его задача — указать системе, какое право нужно проверить.
После сканирования QR CTRL определяет, действует ли право сейчас, допускает ли оно ещё одну операцию, подходит ли конкретная точка и выполнены ли другие правила. Только после этой проверки контроллер получает команду разрешить розлив.
Где заканчивается QR-код и начинается система
QR легко воспринимать как сам продукт, потому что именно его видит гость. Но код — лишь транспорт для идентификатора. Если убрать серверную логику, состояние права и физический контроллер, останется просто картинка, которую можно показать сканеру.
Настоящая ценность появляется после сканирования: система должна понять контекст покупки, применить актуальные правила, принять решение и безопасно исполнить его на оборудовании. Затем операция должна попасть в журнал так, чтобы её можно было объяснить позже.
Поэтому при оценке решений полезно спрашивать не «какой QR вы используете?», а «где хранится состояние права, кто принимает решение и как оно связано с физической выдачей напитка?».
Из каких шагов состоит путь гостя
В базовом сценарии процесс выглядит так:
- гость покупает напиток, комбо или тариф;
- кассовая или другая система передаёт событие, на основании которого создаётся право;
- гость получает QR-код в согласованном канале;
- у постмикса код считывает QR-станция;
- QR CTRL проверяет право и правила;
- контроллер разрешает или запрещает операцию;
- результат сохраняется в журнале событий.
Для гостя важны скорость и понятность: он не должен разбираться, сколько систем участвует внутри. Для бизнеса важен обратный эффект — каждое звено должно иметь понятную ответственность, чтобы сбой можно было локализовать.
Какие правила можно применять
У refill нет единственной правильной политики. Одна сеть может обещать практически свободные повторные розливы в течение посещения, другая — ограниченное количество операций, третья — только один напиток из комбо.
Поэтому правила проектируют от коммерческого обещания гостю. Обычно рассматриваются срок действия права, количество успешных операций, минимальный интервал между ними, ресторан или группа станций, расписание и исключения.
Важно не использовать ограничения как самоцель. Если правило невозможно объяснить гостю одной фразой, оно почти наверняка создаст проблемы на кассе и у станции.
Почему одного QR-сканера недостаточно
Сканер умеет считать код, но не должен решать бизнес-задачу. Ему неизвестно, был ли заказ отменён, сколько раз право уже использовали и можно ли применять его в этом ресторане.
Отдельный программный слой нужен именно для того, чтобы правила не были зашиты в локальное устройство. Тогда новую политику можно внедрять централизованно, а аппаратная часть остаётся исполнителем решения.
Контроллер, в свою очередь, связывает цифровое решение с физическим оборудованием. Способ сопряжения зависит от конкретной модели постмикса и определяется при обследовании точки.
Какие данные получает бизнес
Касса отвечает на вопрос, сколько напитков или тарифов продано. Но для управляемого refill этого недостаточно. Бизнесу полезно видеть отдельные события использования: сколько прав создано, сколько из них применялось, сколько операций прошло успешно и сколько было отклонено.
Так появляется возможность отличать коммерческое событие от физического потребления. Эти данные важны не только для аналитики: они помогают поддержке понять, находится проблема в интеграции, правиле, связи или оборудовании.
С чего начинать проект
Правильная первая задача — не выбрать сканер. Сначала нужно описать один сквозной сценарий: что именно покупает гость, какое событие создаёт право, где появляется QR, какие правила действуют и что должно произойти у постмикса.
После этого проверяются модель оборудования, интеграция и условия монтажа. Для новой сети разумно начать с одной пилотной точки, заранее определить критерии результата и только затем проектировать тиражирование.
Так пилот становится способом проверить будущий стандарт, а не отдельной демонстрацией, которую потом придётся проектировать заново.
