Программа лояльности в приложении: как объединить онлайн и кассы магазина

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

Программа лояльности мобильные приложения Ритейл E-commerce системная интеграция Кассы 24 мин чтения

---

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

Единая программа лояльности: что это технически

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

Участники обмена

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

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

Эффект для маркетинга, финансов и розницы

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

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

Единый клиент: как приложение и касса узнают одного покупателя

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

Ключ профиля

В российской розничной практике основной ключ — номер телефона: он уже есть у покупателя, не теряется и подтверждается кодом. Остальные признаки (адрес электронной почты, номер пластиковой карты, внутренний идентификатор) привязываются к профилю как дополнительные. Одному человеку соответствует одна запись, и у этой записи один баланс.

Способы опознать покупателя на кассе и ограничения каждого

Правила объединения дублей

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

• по какому признаку профили считаются одним человеком;
• какой профиль остаётся основным;
• что происходит с балансами и историей покупок;
• кто имеет право подтвердить объединение вручную.

Балансы при объединении складываются с сохранением исходных сроков действия каждой партии бонусов — иначе объединение само становится причиной спора.

Согласия и персональные данные

Профиль покупателя — это персональные данные, а значит, на обработку нужно согласие, и его формулировка одинакова для приложения и для кассы. Практическая часть: на кассе хранится минимум полей (идентификатор профиля, баланс, признак участия в программе), полная карточка остаётся в сервисе лояльности, а доступ кассира к данным ограничен его рабочей ролью. Текст согласия, порядок отзыва и сроки хранения согласуются с юристом и соответствуют требованиям Федерального закона № 152-ФЗ «О персональных данных».

Архитектура обмена: где живут правила и баланс

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

Двухфазное списание

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

Повторные запросы и идемпотентность

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

Таймауты и поведение кассы при недоступности сервиса

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

Журнал операций и ежедневная сверка

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

Начисление и списание бонусов в одном чеке

Механика программы кажется простой, пока её не начинают описывать в требованиях. Тогда выясняется, что «начисляем процент от покупки» — это ещё не правило, а заголовок правила.

База начисления и исключения

База — сумма, от которой считается начисление. Решения, которые нужно принять до разработки:

• считать базу от суммы чека до скидок или после;
• учитывать ли часть чека, оплаченную бонусами;
• начислять ли на доставку и на подарочные карты;
• какие товарные категории исключены из программы по правилам сети.

Исключения задаются на стороне сервиса лояльности по данным товароучётной системы, а не списком артикулов в кассовой программе: иначе каждое изменение ассортимента превращается в задачу на обновление касс.

Лимит списания и округление

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

Отдельное решение — как списание бонусов выглядит в фискальном чеке: как скидка на позиции или как частичная оплата. От этого зависит и выручка в отчётности, и состав чека, поэтому формулировку согласуют с бухгалтерией и сверяют с требованиями Федерального закона № 54-ФЗ о применении контрольно-кассовой техники до того, как разработчики начнут реализацию. Как устроена оплата в приложении, если покупатель платит за заказ онлайн, мы описывали в материале о встроенном платёжном чекауте.

Отложенное начисление в онлайн-заказах

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

Возвраты: что происходит с бонусами

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

Полный и частичный возврат

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

Возврат покупки, оплаченной бонусами

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

Возврат в другом канале

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

Сроки действия бонусов и сгорание

Срок действия бонусов решает две задачи: ограничивает обязательства компании и возвращает покупателя в магазин до даты сгорания. Обе работают, только если механика понятна покупателю и одинаково считается в обоих каналах.

Три модели срока действия

• Срок от даты начисления. Каждая партия бонусов живёт свой период; баланс состоит из партий с разными датами сгорания.
• Срок от последней активности. Бонусы сохраняются, пока покупатель покупает; после периода без покупок сгорает весь баланс.
• Фиксированные периоды. Все бонусы сгорают в конце календарного периода — проще объяснить покупателю, но даёт пики нагрузки перед датой сгорания.

Модель влияет на требования к обмену. При партийном учёте сервис лояльности должен уметь отдавать кассе не только общий баланс, но и ближайшую дату сгорания: покупатель на кассе спрашивает именно об этом.

Порядок списания партий

При списании первыми уходят партии с самым близким сроком сгорания. Такой порядок выгоден покупателю, снижает объём сгоревших бонусов и в итоге уменьшает количество обращений в поддержку. Обратный порядок — когда списываются свежие партии, а старые догорают, — технически проще, но каждая сгоревшая партия превращается в разговор на кассе.

Уведомления и публичные правила

Предупреждение о сгорании отправляется заранее и по тому каналу, на который покупатель дал согласие: push-уведомление в приложении, сообщение или электронное письмо. Сами правила программы публикуются как документ с датой вступления в силу, и в нём же описывается порядок изменения правил. Это снимает значительную часть споров: вместо обсуждения механики по памяти обе стороны смотрят в один документ. Как программа лояльности работает в связке с мобильным каналом на стороне маркетинга, разобрано в материале об удержании клиентов в fashion-ритейле.

Офлайн-режим касс: продажи без связи

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

Разрешённые операции без связи

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

• запретить списание без связи совсем;
• разрешить списание в пределах локально сохранённого баланса;
• разрешить списание в пределах небольшого лимита, который сеть готова потерять при расхождении.

Выбор зависит от среднего чека и от того, как часто пропадает связь на точках. Перед сезонными пиками офлайн-политику стоит проверить отдельно — вместе с остальными пунктами подготовки приложения к распродажам.

Очередь операций и порядок синхронизации

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

Конфликты и их разрешение

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

• признать операцию кассы и допустить отрицательный баланс;
• отклонить операцию и компенсировать покупателю разницу из маркетингового бюджета;
• отклонить операцию и передать случай в поддержку.

Кассир в момент продажи должен видеть на экране понятное сообщение о том, что точка работает без связи и списание ограничено, — иначе объяснять ситуацию покупателю он будет своими словами.

Спорные ситуации: таблица решений

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

Спорные ситуации, поведение системы и предмет согласования

Согласование правил: кто отвечает за логику лояльности

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

Распределение ответственности

• Маркетинг — механика программы, условия акций, сегменты покупателей, тексты уведомлений.
• Финансы — стоимость обязательств, правила округления, порядок отражения бонусов в отчётности.
• ИТ — обмен данными, двухфазное списание, обработка повторных запросов, предельное время ответа, журнал и сверка.
• Юрист — публичные правила программы, согласие на обработку персональных данных, порядок изменения условий.
• Розница — сценарий работы кассира, тексты сообщений на экране кассы, обучение сотрудников точек.

Версионирование правил

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

Показатели контроля после запуска

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

Критерии приёмки интеграции

Приёмка интеграции лояльности отличается от обычной проверки функций: проверять нужно не только нормальный сценарий, но и обрывы, повторы и возвраты. Этот перечень удобно включать в требования до начала работ — тогда разработчики и тестировщики проектируют под него с самого начала.

Проверки приёмки интеграции программы лояльности с кассами

Частые ошибки внедрения

• Правила живут только в коде. Любой вопрос покупателя требует разработчика, запуск акции — отдельной доработки.
• Списание в одну фазу. Отменённый чек оставляет покупателя без бонусов, а поддержку — с обращением.
• Нет ключа операции. Повторный запрос при обрыве связи списывает бонусы дважды.
• Начисление по факту оплаты онлайн-заказа. Отказ при получении превращается в потерю бонусов и спор.
• Разное округление в приложении и на кассе. Расхождения на каждом чеке и недоверие покупателя к балансу.
• Офлайн-политика не описана. Каждая торговая точка в момент сбоя действует по своему усмотрению.
• Кассиров не обучили. Механика работает, а объяснить покупателю отказ в списании на точке некому.

Проверку поведения обмена под пиковой нагрузкой удобно планировать вместе с подготовкой к сезону: как это организуют перед распродажами, описано в материале о нагрузочном тестировании приложения интернет-магазина.

Итог: единая программа лояльности на одной странице

Объединение онлайна и касс держится на четырёх решениях, принятых до разработки: один профиль покупателя с понятным ключом, один сервис, который считает бонусы, описанные правила начисления, списания, возвратов и сроков действия, и заранее выбранное поведение кассы без связи. Эти решения принимают маркетинг, финансы и ИТ вместе, и именно их отсутствие, а не выбор технологии, чаще всего превращает программу лояльности в источник споров на кассе.

Порядок действий для сети, которая начинает проект

1. Описать правила программы как документ: база начисления, лимиты списания, округление, сроки действия, возвраты.
2. Выбрать ключ профиля покупателя и способ опознавания на кассе, определить порядок объединения дублей.
3. Согласовать поведение кассы при недоступности сервиса и офлайн-лимит списания.
4. Включить таблицу спорных ситуаций и критерии приёмки в требования до начала разработки.
5. Заложить ежедневную сверку и журнал операций в объём работ первого выпуска, а не в доработки после запуска.

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

Обсудим вашу задачу

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