Программа лояльности: вы возвращаете гостей или оплачиваете их привычку?

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

В отчёте всё верно. Только этот человек и раньше приходил по четвергам. Бонусы дали ему новую причину вернуться или помогли ресторану узнать своего постоянного гостя?

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

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

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

У технологий здесь разные задачи. CDP собирает историю гостя из разных каналов, CRM помогает выстраивать общение, BI связывает действия гостей с показателями бизнеса. Иногда всё это умеет одна система. Но если исходные данные неверны, красивый отчёт лишь делает ошибку убедительнее.

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

В Domino’s я работал с Insider, а с инструментами Retail Rocket знаком по другой профессиональной работе. Этот опыт научил меня смотреть не на число настроенных сегментов и рассылок, а на их пользу. Кому, когда и зачем мы пишем? Что изменится для гостя и что это принесёт бизнесу? Технология помогает выполнить решение, но за его экономику отвечает руководитель.

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

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

Вернёмся к нашему четверговому гостю. Если он не пришёл четыре недели подряд, это может означать, что привычка изменилась. Другой человек посещает тот же ресторан раз в квартал; для него такая пауза нормальна. Отправлять обоим одинаковое «Мы соскучились» с одной и той же скидкой легко. Но зачем?

Я смотрю, когда гость покупал в последний раз, как часто приходит и сколько тратит. В аналитике это называют RFM. Затем оцениваю, кто действительно перестал возвращаться, какой маржинальный доход оставляют покупки и во что обойдётся стимул. Для одного человека месяц без визита уже тревожный сигнал. Для другого это обычный интервал. Поэтому скидку стоит предлагать там, где она способна изменить поведение.

В публичном кейсе Retail Rocket о международной сети пиццерий приводится хороший пример: в одном городе клиента считают «уснувшим» после двух недель без заказа, а в другом только после четырёх. У гостей разный ритм покупок, поэтому единый срок здесь не подходит. Сама настройка ещё не доказывает, что программа принесла дополнительные заказы.

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

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

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

В двух заведениях суммы чеков распределялись по-разному. Это означало, что одинаковые пороги могли сделать привилегии слишком доступными в одном ресторане и почти недостижимыми в другом.

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

Поэтому я рассчитал разные денежные пороги для каждого заведения. Главным ориентиром была экономика: привилегии должны оставаться привлекательными для гостей, но не съедать ожидаемый дополнительный доход ресторана. Бонусный баланс планируем общим. Насколько удачным будет решение, покажут реальные начисления, списания и изменение маржинального дохода после запуска.

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

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

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

Допустим, гостям начислили 10 000 баллов, каждый из которых даёт скидку в один рубль. Если они используют 60%, номинал будущих скидок составит 6 000 рублей. Это ещё не убыток и не дополнительная выручка. Чтобы оценить экономику, нужно понять, что гости купят с этими баллами, сколько останется маржи и что произошло бы без бонусов.

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

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

Возьмём условный A/B-тест. Двести сопоставимых гостей случайным образом разделили на две равные группы по сто человек. Группе A ничего не предложили, группе B дали купон. За выбранный период купили двадцать человек в B и пятнадцать в A, каждый по одному разу. Разница в пять покупок даёт предварительную оценку возможного эффекта. Приписывать программе все двадцать покупок неправильно.

Теперь предположим, что каждая покупка в обеих группах даёт 600 рублей маржинального дохода до скидки и других расходов на кампанию. Купон уменьшает его на 100 рублей и применяется ко всем двадцати покупкам тестовой группы. Дополнительные пять покупок приносят 3 000 рублей до скидок. Скидки на двадцать чеков обходятся в 2 000 рублей. Остаётся 1 000 рублей до затрат на платформу, коммуникации и команду.

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

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

В опубликованном кейсе Retail Rocket есть интересная финансовая деталь. Поставщик сообщает, что средний чек участников программы вырос на 32%, а у анонимных покупателей на 28%. При этом количество потраченных бонусов сократилось на 24%, что, по оценке компании, положительно повлияло на маржинальность.

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

Я использую BI, чтобы видеть не просто отчёты, а последствия решений. Стали ли гости покупать чаще? Что произошло с удержанием? Как изменился маржинальный доход после скидок и других затрат? Ответы помогают решить, стоит ли продолжать механику, менять её условия или отказываться от стимула.

Но гость не думает категориями CRM и маржи. Для него важнее, понравился ли ужин, удобно ли заказать и сработала ли обещанная привилегия без спора у кассы. Если приложение обещает одно, а сотрудник говорит другое, впечатление испортит даже математически безупречная программа.

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

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

Гость возвращается не в CRM. Он возвращается в ресторан.