Как внедрить программу лояльности на сайте?

Что нужно определить до разработки:

• формат программы: скидки, бонусы, уровни или персональные предложения

• условия участия и идентификации клиента

• источник данных о покупках и бонусном балансе

• правила начисления, активации, списания и сгорания

• ограничения по товарам, акциям и способам оплаты

• порядок отмены, возврата и исправления ошибок

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

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

Сначала нужно выбрать цель программы лояльности

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

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

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

Вопрос «зачем клиенту возвращаться» должен получить ответ до вопроса «сколько бонусов показывать в кабинете»

Скидки, бонусы и уровни решают разные задачи

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

Сравнение основных форматов:

1С-Битрикс позволяет настраивать скидки, купоны и правила для корзины. Полноценная бонусная программа со сложным балансом, уровнями и обменом между каналами может потребовать отдельного модуля или интеграции с внешней системой

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

Правила программы нужно описать до интерфейса

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

Что должно быть определено:

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

• от какой суммы рассчитывается вознаграждение

• когда бонусы становятся доступными

• сколько бонусов можно использовать в одном заказе

• участвуют ли акционные товары

• совместимы ли бонусы с купонами и скидками

• действует ли ограничение по времени

• как обрабатываются отмены и возвраты

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

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

Клиента нужно одинаково определять во всех каналах

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

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

Для многоканальной программы дополнительно определяют:

• какой идентификатор считается основным

• как объединяются дубли

• где хранится профиль участника

• как сайт получает покупки из розницы

• что происходит при смене телефона или почты

• как сотрудник исправляет ошибочную привязку

• какие данные видит служба поддержки

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

Начисление должно происходить после подтверждённого события

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

Основные состояния начисления могут выглядеть так:

1. Заказ создан — программа рассчитывает ожидаемое вознаграждение

2. Условия выполнены — бонусы переходят в ожидающий статус

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

4. Заказ отменён или возвращён — начисление корректируется

5. Срок действия закончился — неиспользованный остаток сгорает по правилам программы

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

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

Списание бонусов нужно связывать с корзиной и оплатой

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

При настройке списания команда проверяет:

• минимальную и максимальную долю оплаты бонусами

• доступность для отдельных товаров и категорий

• совместимость с текущими акциями

• влияние на стоимость доставки

• округление итоговой суммы

• резервирование бонусов во время оплаты

• возврат баланса при неуспешной операции

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

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

Скидки и бонусы должны применяться в понятном порядке

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

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

Возможные правила сочетания:

• бонусы не применяются к акционным товарам

• промокод отменяет накопительную скидку

• бонусами нельзя оплачивать доставку

• вознаграждение начисляется с фактически оплаченной суммы

• подарочный товар не участвует в новом начислении

• персональная цена исключает другие преимущества

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

Возвраты и отмены определяют надёжность бонусной системы

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

Сценарии для проверки зависят от состояния заказа:

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

Личный кабинет должен объяснять, а не просто показывать баланс

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

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

• доступный и ожидающий баланс

• текущий уровень участника

• историю начислений и списаний

• срок действия бонусов

• условия использования

• сведения о заказе, связанном с операцией

• доступные персональные предложения

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

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

Интеграции нужны для единого баланса и истории покупок

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

Для каждого типа данных нужно выбрать основную систему:

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

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

Что включить в первый запуск программы

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

Разделение функций по этапам:

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

Компетентный разработчик понимает проект целиком

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

Вопросы, которые стоит задать разработчику:

• Какие сценарии вы изучите до выбора решения?

• Где будет храниться профиль и баланс участника?

• Какие данные заказа повлияют на начисление?

• Что произойдёт при отмене, возврате и повторной оплате?

• Какие функции вы проверите после выпуска?

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

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

Пример из практики Ameton

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

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

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

Для каких проектов подходят эти рекомендации

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

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

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

Ameton может начать работу с описания правил и жизненного цикла бонусной операции: начисление, активация, списание, отмена и возврат. На основании этой схемы можно выбрать возможности 1С-Битрикс, готовый модуль или индивидуальную интеграцию и определить состав первого запуска