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