На первой встрече собственник объяснял, что хочет: бонусы за каждую покупку, скидки для сотрудников, три категории клиентов с разными процентами, промокоды, аналитику по потерям на скидках.
Я остановил его на середине. «Давайте сначала разберёмся, зачем вам это всё. Кто ваш типичный клиент?»
Типичный клиент — это корпоратив или семейный праздник. Барашок на двадцать человек, бешбармак на свадьбу. Раз в квартал, может реже. Крупный заказ, долгая подготовка, высокий чек.
Три уровня лояльности работают там, где клиент покупает часто и видит, как движется к следующему уровню. Здесь это не работает. Клиент просто не думает о вас между праздниками.
Для редких покупок лояльность решает другую задачу
Не мотивацию к покупке. Право напомнить о себе.
«Уважаемый Ербол, у вас накопилось 2400 бонусов. Они сгорят через 14 дней» — это не давление. Это повод выйти на связь, когда обычно непонятно с чего начать. И я скажу вам: для редких клиентов это работает лучше, чем любая многоуровневая система с накоплениями.
Для этого не нужны три категории. Нужен единый процент, срок жизни бонусов — и SMS за несколько дней до сгорания. Это закрывает 90% задачи.
Остальные 10% — скидки для сотрудников, специальные акции — тоже сделали. Но отдельно.
Почему это два разных модуля
Вот правильная последовательность:
Берём цену товара. Применяем скидку — если есть купон, который на него действует. Получаем итоговую сумму. С неё начисляем бонусы. Из неё же списываем бонусы при оплате.
Если сделать наоборот — сначала начислить бонусы, потом применить скидку — математика ломается. Клиент получает бонусы с суммы, которую он не заплатил.
Это не ошибка настройки. Это архитектурная ошибка — и её потом не исправить без перестройки системы.
Большинство готовых решений эту последовательность не соблюдают. Либо смешивают всё в один модуль, либо порядок применения непрозрачен. Мы строили через Умные процессы Битрикс24 — именно потому что нужна была собственная логика.
Как система защищала от ошибок операторов
Это я проговаривал с собственником отдельно.
Оператор не должен иметь возможность вбить 30% вместо 3%. Процент бонуса — в глобальных настройках, защищён от редактирования рядовым сотрудником. Промокоды — выбираются из справочника, не вписываются в комментарий к сделке. Ручное начисление бонусов — только администратор.
Бонусы начисляются при финальном статусе сделки, а не при создании. Потому что если клиент вернул товар — бонусы с возврата начислять не надо.
Аудит-лог на ключевых полях: кто изменил, когда, на что. Не для слежки — для разбора полётов, когда что-то пойдёт не так.
Всё это не усложняет работу оператора. Оператор видит: выбрать купон из списка, посмотреть баланс бонусов, применить. Сложность спрятана внутри.
Что в итоге
Две отдельные системы, которые применяются последовательно. Скидочная — снижает цену конкретных товаров до расчёта итога. Бонусная — начисляет и списывает с итоговой суммы.
SMS-уведомления о сгорающих бонусах как основной инструмент возврата клиентов.
Категории A/B/C — заложены в архитектуру, но не используются с первого дня. Когда накопится достаточно данных — включить несложно.
Скидки и бонусы — это слова, которые все понимают по-разному. До того момента, пока не начинаешь строить систему.
А что, если ваша нынешняя программа лояльности смешивает их в одном модуле?
Если хотите разобраться — напишите.