Автоматизация реферальной программы: учёт приглашений и подтверждение вознаграждения

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

Ниже — способ описать такой процесс до настройки инструмента. Все идентификаторы, даты, суммы и правила учебного примера условны. Это не данные клиента, не результат проекта Switch On AI и не обещание дохода.

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

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

1. Какой партнёр считается пригласившим?
2. Создаёт ли покупка начисление?
3. Можно ли выплатить бонус сейчас?
4. Что произойдёт с начислением после возврата?

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

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

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

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

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

До разработки полезно составить словарь статусов. Например, pending означает «проверки ещё не завершены», confirmed — «условия выполнены и начисление допущено к выплате», canceled — «начисление отменено». Эти значения должны одинаково пониматься во всех участвующих системах.

Как определить событие вознаграждения

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

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

• у заказа есть уникальный order_id;
• customer_id заказа совпадает с приглашённым клиентом;
• платёж подтверждён источником события;
• код прошёл проверку и связан с клиентом серверной записью;
• заказ не признан самообращением по согласованным правилам;
• такой event_id или order_id ещё не создавал операцию вознаграждения.

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

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

Как связать приглашение и результат

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

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

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

Повторная доставка того же event_id или order_id не создаёт новую операцию. Система должна найти существующий reward_operation_id и вернуть её текущий статус. Если действительного кода нет, результат проверки — «без атрибуции», а не догадка по имени клиента.

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

Отчёт по выплатам включает операции со статусом confirmed и учитывает связанные с ними отмены или возвраты. Pending в сумму выплаты не входит. Отменённое начисление полезно показывать отдельным контрольным показателем, но не превращать его в отрицательную выплату.

Такой отчёт отвечает на вопрос «сколько подтверждено к выплате», но сам по себе не доказывает выручку, прибыль или эффективность реферальной программы. Для этих выводов нужны отдельные правила расчёта и проверенные данные.

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

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

• pending → confirmed, если период ожидания закончился и возврата либо другого основания для отмены нет;
• pending → canceled, если до подтверждения зарегистрирован возврат или проверка отклонила начисление.

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

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

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

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

Ниже приведён синтетический пример. Имена, идентификаторы, даты, суммы, ставка и период ожидания условны.

Партнёр P-101 передал клиенту C-001 код ALFA-01. Серверная запись подтвердила код 1 сентября 2026 года в 10:00. Позже тот же клиент использовал код BETA-02 партнёра P-202; этот код подтверждён 3 сентября в 12:00. Оба события находятся в условном окне атрибуции.

5 сентября клиент совершил покупку O-501 на 10 000 условных рублей. Платёж подтверждён. По учебному правилу система выбирает P-101: его подтверждённый код был первым. Код BETA-02 сохраняется в истории как более поздний и не создаёт отдельной комиссии.

Условная ставка — 10%. Расчётная сумма бонуса: 10 000 × 10% = 1 000 условных рублей. Система создаёт одну операцию RW-001 со статусом pending. До конца условного периода ожидания в 14 дней выплата равна нулю.

10 сентября зарегистрирован полный возврат. Он произошёл до перехода операции в confirmed, поэтому RW-001 получает статус canceled. Атрибуция не меняется, новая операция не создаётся, итог к выплате остаётся равным нулю.

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

В отчёте этого примера подтверждённые начисления равны нулю. Возвраты, вычитаемые из ранее подтверждённых операций, также равны нулю, потому что RW-001 не успела получить статус confirmed. Итог к выплате — ноль. Отменённые 1 000 условных рублей показываются отдельно для контроля, но не как отрицательная выплата.

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

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

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

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

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

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

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

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

Правила бухгалтерского, юридического, кадрового и отраслевого учёта задаёт и проверяет специалист заказчика. Работа с 1С в этот объём не входит. Статья также не предлагает внедрение PIM, WMS, ITAM, ЭДО, электронного архива, Process Mining, полноценного B2B-портала, управления запасами, маршрутизатора или системы корпоративного обучения.

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

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