Почему продажа и розлив — разные события

Кассовая система отвечает на вопрос, что было продано. Для управляемого розлива этого недостаточно: после продажи гость может воспользоваться правом один раз, несколько раз, не воспользоваться совсем или получить отказ по правилам. Поэтому коммерческое событие и физическое использование нужно учитывать отдельно.

Если считать только чеки, бизнес видит выданные права, но не видит фактическое поведение у станции. Если считать только операции постмикса, теряется связь с заказом и коммерческим контекстом. Ценность появляется именно при соединении этих двух уровней.

Например, одна продажа безлимитного напитка может породить несколько физических операций. Для обычного напитка ожидаемая модель может быть другой: одна продажа — одно право — одна операция. Одинаковый счётчик чеков в этих сценариях имеет разный смысл, поэтому аналитике нужен тип права и фактическая история использования.

Полезно также различать «право создано» и «право активировано». Часть гостей может купить напиток и не подойти к станции. Это нормальная часть поведения, которая важна для оценки нагрузки и экономики сценария.

Между продажей и постмиксом удобно вводить отдельную сущность — цифровое право на розлив. Оно создаётся после нужного события в POS и содержит состояние, по которому QR CTRL принимает решение в момент сканирования.

Право может описывать срок действия, число разрешённых операций, минимальный интервал, точку или группу станций, а также сценарий — например refill, напиток из комбо или временную промоакцию. QR-код в этой модели не является разрешением сам по себе: он только позволяет найти конкретное право.

Какие события нужно связывать

Минимальная сквозная цепочка состоит из события продажи, создания права, попытки сканирования, решения QR CTRL и результата операции. Для разбора спорных ситуаций важно сохранять не только успешные розливы, но и отказы с причиной.

Отдельно стоит учитывать изменение состояния права: истечение срока, исчерпание лимита, отмену или отзыв. Тогда журнал отвечает не только на вопрос «что произошло», но и «почему система разрешила или запретила действие в конкретный момент».

Какие показатели становятся доступными

После связывания продажи и фактического использования можно разделить несколько показателей: сколько прав создано, сколько из них использовано, сколько успешных операций выполнено, сколько попыток отклонено и по каким причинам. Для refill дополнительно важны количество повторных операций и интервалы между ними.

Эти данные полезны не только для контроля. Они позволяют сравнивать точки, сценарии и периоды, находить нетипичное поведение и проверять, соответствует ли реальное использование правилам продукта.

На уровне ресторана показатели можно агрегировать по часу, смене или дню. На уровне сети — по формату точки, региону и версии правил. Главное сохранять первичные события, чтобы изменение отчёта не требовало менять сам механизм контроля.

Как находить расхождения

Система должна позволять пройти цепочку в обе стороны: от продажи к операциям и от конкретного сканирования к исходному праву. Для этого нужны стабильные идентификаторы заказа или позиции, права, точки, станции и операции.

Расхождение не всегда означает злоупотребление. Причиной могут быть отмена заказа, повторная печать чека, сетевой сбой, дублирование события или техническая ошибка станции. Поэтому контроль должен опираться на журнал и состояние, а не на одно число в отчёте.

Что проверить на пилоте

На пилотной точке достаточно проверить один полностью сквозной сценарий: POS создаёт право, QR доставляется гостю, станция считывает его, QR CTRL применяет правила, контроллер выполняет разрешённую операцию, а результат возвращается в журнал.

Критерий готовности — возможность по идентификатору заказа восстановить всю цепочку без ручного сопоставления нескольких независимых журналов. После этого модель можно расширять на дополнительные сценарии и отчётность.

Отдельно стоит провести тест сверки: взять несколько реальных заказов и убедиться, что число прав и операций совпадает с журналом станции. Такой контрольный набор быстро выявляет дубли, потерянные события и неоднозначные идентификаторы.

Что происходит, когда цифры не сходятся

Представим простую ситуацию: по кассе продано 120 напитков, а станция за смену зафиксировала 165 успешных операций. Это ещё не означает проблему. Если часть продаж — refill, несколько физических розливов на одно право могут быть нормой. Но без связи «продажа → право → операции» эти 45 дополнительных событий невозможно объяснить.

Другой пример выглядит наоборот: право создано, но ни одной операции нет. Возможно, гость передумал, забрал заказ с собой или не нашёл станцию. Для маркетинга и операционной команды это тоже полезный сигнал — он показывает, что продажа состоялась, а продуктовый сценарий не был завершён.

Поэтому хороший отчёт не пытается свести всё к одной красивой цифре. Он позволяет провалиться до конкретного права и восстановить, что произошло с ним от момента продажи до последней попытки у постмикса.

Практический принцип: продажа отвечает на вопрос «за что заплатили», а журнал розлива — «что реально произошло после покупки». Контроль появляется только тогда, когда эти две истории можно связать без догадок.
← Все материалыОбсудить ваш проект →