Чат-бот программы лояльности: баланс, начисление и отмена операции

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

Бот не подтверждает оплату самостоятельно. Он получает уже подтверждённое событие из согласованного источника программы лояльности и показывает результат участнику. Рекомендательная допродажа также остаётся за границами этого процесса.

Какую задачу решает этот процесс

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

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

Граница процесса проходит до платёжного контура. Источник покупки сообщает, что операция подтверждена; бот не определяет, состоялся ли платёж. Процесс также не выбирает товары для допродажи и не формирует персональные рекомендации.

Какие данные и правила подготовить

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

Ниже приведён заполненный синтетический образец. Идентификаторы и значения условные и не относятся к клиентам Switch On AI.

Правила начисления, списания, округления и срока действия принадлежат конкретной программе. Их нельзя восстанавливать по примеру из другой системы. В официальной документации Microsoft Dynamics 365 Commerce отдельно описаны программы лояльности, карты, правила начисления и погашения баллов, а также просмотр операций по карте. Для интеграции с этой платформой нужно отдельно согласовать структуру данных. Документация не подтверждает совместимость будущего бота с конкретной установкой, тарифом или набором прав.

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

Как идентифицировать участника программы

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

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

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

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

Как начислять и списывать баллы

Баланс выводят из журнала операций, а не хранят как число без объяснения происхождения. Для каждой записи нужны как минимум event_id, purchase_id, participant_id, тип операции, величина, основание, время и статус. Для возврата дополнительно сохраняют ссылку на исходную покупку.

Базовая формула выглядит так:

Баланс = сумма начислений − сумма списаний.

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

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

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

Как отменять операцию и объяснять баланс

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

Для разных причин нужны разные основания:

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

Пользователю показывают понятное описание: например, «Списано 40 баллов из-за частичного возврата по покупке P31». Рядом нужны дата и основание. Внутренние технические идентификаторы можно оставить в деталях операции, но нельзя заменять ими объяснение.

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

Учебный пример: путь от входных данных до результата

Все данные ниже синтетические. U-017, C-204, P31 и R31-1 — условные идентификаторы, а 100 и 40 — учебные величины, не универсальные правила программы лояльности и не результат клиентского внедрения.

Исходные данные:

• начальный баланс участника U-017 по карте C-204 — 0;
• подтверждённая учебная покупка P31 создаёт начисление 100 баллов;
• повтор P31 имеет тот же ID основания и не создаёт начисление;
• частичный возврат R31-1 относится к P31 и создаёт компенсацию в виде списания 40 баллов.

Промежуточное решение: первая P31 проходит проверку уникальности и попадает в журнал как начисление. Вторая P31 распознаётся как дубликат. R31-1 проходит как новая операция, но ссылается на исходную покупку.

Расчёт воспроизводится по журналу: 0 + 100 + 0 − 40 = 60. Каждая строка имеет основание, поэтому руководитель CRM-маркетинга может объяснить итог без ручной корректировки числа. Пример проверяет арифметику процесса, но не подтверждает работу с конкретной платформой или API.

Как проверить результат перед запуском

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

Дополнительно сверяют четыре условия: арифметика сходится по всем строкам; один ID покупки не создаёт двойное начисление; учебные 100 и 40 нигде не названы правилами всех программ; персональный баланс недоступен другому пользователю.

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

Что согласовать для внедрения

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

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

Switch On AI разрабатывает ИИ-помощника, чат-бота или интеграцию для такой операции после проверки данных и API. Модель ИИ здесь не обязательна: для идентификации, расчёта и защиты от повторов подходят детерминированные правила. ИИ можно обсуждать отдельно только для свободных вопросов пользователя, не передавая ему право самостоятельно менять баланс.

До прототипа нужно согласовать:

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

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

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