Программа лояльности для клиентов: правила и запуск

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

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

Какую задачу должна решать программа

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

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

До выбора сервиса запишите:

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

Скидка, баллы или подарок за визиты

В разборе Яндекс Пэй среди вариантов программы описаны скидки, бонусы и привилегии. Выбирайте механику по тому, насколько легко объяснить её клиенту и проверить сотруднику.

Не запускайте несколько правил одновременно в первой версии. Сотруднику будет труднее объяснить клиенту, почему скидка не сложилась с баллами или почему посещение не засчиталось.

Сначала проверьте экономику

Посчитайте отдельную покупку с использованием вознаграждения. Допустим, услуга стоит 1 000 ₽, а её условные переменные затраты — 600 ₽. Без бонусной скидки остаётся 400 ₽ до постоянных расходов, налогов и других неучтённых затрат. Если клиент списывает 100 баллов по курсу 1 балл = 1 ₽, денежная оплата составит 900 ₽, остаток — 300 ₽.

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

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

Опишите правила до создания приложения

Для учебной модели возьмём такие условия:

Разница между «5% от суммы до скидки» и «5% от оплаченной суммы» меняет результат. В покупке на 1 000 ₽ со списанием 100 баллов это 50 и 45 баллов соответственно. В нашей модели верно 45.

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

Пример начисления и списания

У вымышленного клиента «Демо-А» есть 100 баллов. Он совершает две учебные покупки. Суммы для простоты указаны в целых рублях.

Формулы для первой покупки: 1 000 − 100 = 900 ₽; 900 × 5% = 45 баллов; 100 − 100 + 45 = 45 баллов.

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

Скачайте контрольные примеры в CSV. Откройте файл в табличном редакторе с разделителем «точка с запятой». В нём только вымышленные операции и ожидаемые результаты, без клиентских данных.

Что должно быть в первой версии приложения

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

Один редактируемый счётчик «баланс» не объясняет, откуда взялись баллы. Если сотрудник ошибся, по журналу должно быть видно, какую операцию исправлять.

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

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

Готовое задание для учебной версии

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

Создай учебное приложение бонусной программы мастерской.
Данные вымышленные, не публикуй проект. Хранение только в памяти;
покажи предупреждение, что перезагрузка сбрасывает пример.
Клиент «Демо-А», стартовый баланс 100 баллов. 1 балл = 1 рубль скидки.
Форма: постоянный ID покупки, сумма в целых рублях > 0,
списание в целых баллах >= 0.
Не разрешай списать больше баланса или floor(20% суммы покупки).
При ошибке покажи причину; журнал и баланс не меняй.
К оплате = сумма минус списание.
Начисление = floor(5% от суммы к оплате).
Новый баланс = прежний минус списание плюс начисление.
Повтор покупки с тем же ID ничего не начисляет и не списывает.
Журнал: ID, сумма, списание, к оплате, начисление, баланс после.
Полная отмена возвращает списанные баллы и снимает начисленные
ровно один раз. Если баланс станет отрицательным — отклони отмену
и объясни причину. Денежные возвраты не выполняй.
Добавь сброс учебных данных, подписи полей и мобильную версию.
Проверка: T001, сумма1000, списать100 → оплата900, начислить45, баланс45.
T002, сумма500, списать0 → оплата500, начислить25, баланс70.
ПовторT002 → баланс70. ОтменаT001 → баланс125.
Повтор отмены → баланс125. Сумма500, списать101 → ошибка лимита20%.
Не подключай оплату, кассу, SMS, внешние API и реальные контакты.

Если раньше вы использовали ИИ только для вопросов, начните с этого задания. После генерации сравните результат с таблицей выше. Просите исправить конкретное расхождение: например, «при T001 начисляется 50, а по правилу должно быть 45».

Что проверить перед работой с клиентами

Проведите контрольные покупки по порядку, затем попробуйте ошибочные действия:

• сумма 500 ₽ и списание 101 балла — отказ по пределу 20%;
• списание выше текущего баланса — отказ без изменения журнала;
• пустая, отрицательная или дробная сумма в этой целочисленной модели — ошибка;
• повтор покупки и повтор отмены — баланс не меняется;
• отмена после расходования начисленных баллов — выбранное правило не создаёт скрытый отрицательный баланс;
• работа с телефона — суммы, ошибки и подтверждение видны без горизонтальной прокрутки.

Приёмка прототипа не заменяет проверку рабочего приложения. В отдельном тестовом окружении проверьте сохранение после входа заново, доступ разных сотрудников и одновременные операции. Если покупка была отменена в кассе, её бонусная операция тоже должна обрабатываться по согласованным правилам; одной кнопки «Отмена» в макете недостаточно.

Как понять, есть ли результат

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

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

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

Источники и границы примера

Виды механик сверены с Яндекс Пэй и RetailCRM. Числа, операции T001/T002 и правила округления разработаны для этого учебного примера; это не клиентский кейс. Материал не описывает готовое подключение к кассе, финансовые возвраты или юридические условия рабочей программы.