Программа лояльности в CRM: карты и абонементы

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

Второй аргумент — узнавание клиента. Механика работает только тогда, когда на входе система понимает, кто перед ней, без бумажной карточки и вопроса «вы у нас уже были?». Такое узнавание строится на клиентской базе: телефоне, истории визитов, предыдущих заказах. У отдельного сервиса своя база, и её приходится синхронизировать — обычно выгрузкой раз в сутки. Клиент приходил вчера, начисление появится завтра, а спорит он с администратором сегодня.

Честно про границы. Отдельная платформа лояльности бывает оправдана: розничная сеть с кассовым софтом, мобильным приложением и сотнями тысяч карт получит там готовые механики, которых нет ни в одной CRM. Но у малого и среднего бизнеса — в услугах, HoReCa, фитнесе, салонах, клиниках — картина обратная. Клиентов обозримое количество, а ручной сверки между двумя системами получается много. Здесь дешевле и надёжнее сделать лояльность блоком рабочего контура.

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

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

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

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

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

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

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

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

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

Контур вокруг лояльности такой: бронирование кабинок ведётся во внутреннем приложении Битрикс24 («шахматка» занятости), портал сотрудника разделён по ролям — админ, администратор бани, специалист, официант, — а заказы кафе проходят через POS-кассу, работающую по Битрикс24 REST. Технически приложения построены на Node.js и Fastify, данные — в PostgreSQL, кэш — в Redis, интерфейсы — на React. Решение работает в проде, по нему ведётся действующее сопровождение.

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

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

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

Отсюда же вытекает требование к интеграции. Касса не обязана быть частью CRM, но обязана обращаться к ней напрямую — по API, а не через ночную выгрузку. В проекте банных комплексов POS-касса кафе работает по Битрикс24 REST именно поэтому: точка стыка одна, описана, и заказ официанта относится к тому же гостю и визиту, что и всё остальное. Такие вещи относятся уже к заказной разработке — готовой коробки под конкретную операционку обычно не существует.

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

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

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

По деньгам ориентир такой. Стоимость работ мы называем после бесплатного экспресс-аудита на 30 минут: объём зависит от числа точек, набора механик и того, есть ли уже настроенная система. Предсказуема только цена платформы — это официальные тарифы вендора: например, облачный Битрикс24 «Стандартный» на 50 пользователей стоит 4 893 ₽/мес при оплате за год, коробочная версия лицензируется по своим правилам. Работы по внедрению в тариф не входят.

Что посмотреть дальше на сайте. Страница внедрения Битрикс24 — про фундамент: воронки, права, портал, на которые потом ложится всё остальное. Страница заказной разработки — про приложения, личные кабинеты и POS, которых нет в готовых продуктах. Страница CRM — про перенос контура на своё размещение со сверкой данных. Кейс сети банных комплексов — про то, как лояльность, бронирование и касса работают в одном контуре в проде. В журнале смежные темы разбирают статьи «Автоматизация бани: бронирование, лояльность, учёт» и «Онлайн-запись клиентов: виджет, бот или CRM». Начать проще всего с аудита: его задача — понять, нужна ли вам вообще отдельная механика удержания, а не продать самый большой проект.