Интеграция программы лояльности с сайтом, 1С и Битрикс24: кейс Pasionaria

Pasionaria связала интернет-магазин на 1С-Битрикс, программу лояльности Dinect/РусБонус, 1С и Битрикс24. Задача состояла в том, чтобы покупки из разных каналов учитывались у нужного клиента, бонусы рассчитывались по фактическому состоянию заказа, а менеджеры видели актуальный баланс в CRM.

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

Главная идея: Dinect/Rusbonus остаётся основной системой программы лояльности, а сайт, 1С и Bitrix24 обмениваются с ней данными по понятным бизнес-правилам.

Изначально на проекте уже был модуль Dinect/Rusbonus. Однако реальная задача Pasionaria была заметно шире его стандартных сценариев. При этом мы не стали глубоко переписывать базовый API-класс модуля: он остался почти без изменений и продолжил отвечать за низкоуровневое общение с сервисом.

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

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

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

Отдельный вопрос — где хранится “правильный” бонусный баланс. На сайте 1С-Битрикс есть собственный механизм внутреннего счёта, но использовать его как самостоятельную систему лояльности было бы опасно: в Dinect поступают и другие операции, в том числе из офлайн-каналов.

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

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

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

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

Когда заказ доходит до нужной бизнес-стадии, система при необходимости регистрирует клиента в Dinect. А покупка отправляется только тогда, когда заказ считается действительно выполненным. Таким образом, правила отдела продаж и учёта были перенесены в программную логику, а не заменены упрощённой схемой “есть заказ — начисляем бонусы”.

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

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

Следующая нестандартная ситуация — заказ существует в 1С, но не существует в интернет-магазине. Такое бывает, когда покупка была оформлена другим каналом. Для программы лояльности она всё равно должна учитываться.

Мы расширили уже существующий обмен с 1С: для выполненного заказа система ищет клиента по доступным данным, проверяет, не была ли эта покупка уже передана в Dinect, и только после этого регистрирует новую операцию. Для таких заказов используется отдельный идентификатор, поэтому повторная обработка не должна создавать дубли.

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

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

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

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

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

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

Отдельная проблема — поиск контакта по телефону. В CRM один и тот же номер мог храниться в разных форматах: с +7, через 8, со скобками и пробелами. Вместо хрупкого сравнения строк перешли на штатный механизм поиска дублей Bitrix24, а затем уже получали нужные карточки контактов. Это небольшая деталь, но именно такие детали часто определяют надёжность интеграции на реальных данных.

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

Сначала проблему пытались решить уже после создания заказа, но это упёрлось в ограничения внутренней модели заказов 1С-Битрикс. Поэтому решение перенесли туда, где клиент определяется изначально — в модуль интеграции s-Products. Теперь при создании заказа он пытается найти существующего пользователя по данным контакта, а если пользователя нет — создаёт его. Дополнительно предусмотрели регистрацию по телефону даже в случаях, когда у контакта нет полноценного email.

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

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

Следующим этапом стала автоматическая сегментация клиентов в Битрикс24: расчёт сегмента, активности и розничного типа. Этой задаче посвящён отдельный кейс.