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