Партнёрское вознаграждение в CRM: какое событие создаёт основание

В CRM партнёр указан в сделке, но выплата ещё не положена: нужно проверить источник, право и событие. Без карточки основания спор двух партнёров превращается в переписку, а не в проверяемое решение.

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

Условная сцена: в CRM у сделки появляется партнёр, который первым назвал имя покупателя. Через неделю второй партнёр присылает переписку с тем же контактом и требует вознаграждение. Сделка ещё не принята, сумма не подтверждена, а в чате уже звучит «мы договорились».

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

Партнёр назван в разговоре, но основание ещё не появилось

Условный эпизод 1. Менеджер 3 марта записывает звонок: партнёр A говорит, что «вывел на покупателя» и просит закрепить сделку. В CRM появляется заметка, сделка на 480 000 ₽ и ставка 10%. Арифметика даёт 48 000 ₽, но это только расчёт. 28 февраля партнёр B уже присылал переписку с тем же контактом, однако в базе она не отмечена. Покупатель, по условиям компании, был в базе с прошлого года — правда, по другому подразделению.

В таком разборе компания не выбирает партнёра по громкости. Она оставляет сделку без основания, пока не проверены источник, право и событие. В карточке появляется статус «спор», а расчёт 48 000 ₽ не уходит в выплату. Это неприятно для менеджера, который уже пообещал партнёру деньги, но дешевле, чем потом объяснять, почему одна и та же сделка получила два основания.

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

Рабочий объект: карточка основания, а не заметка о партнёре

Заметка «партнёр A, сделка с покупателем» удобна в чате и бесполезна при споре. Для проверки нужен отдельный объект, который связывает партнёра, сделку, источник, право, событие, расчёт и выплату. Назовём его карточкой основания. Она не заменяет карточку партнёра и не заменяет сделку; она показывает, почему конкретная сумма считается возникшей.

Такая форма полезна ещё и тем, что не даёт смешать «партнёр привёл клиента» и «партнёру положено 48 000 ₽». Первое — источник, второе — расчёт. Между ними лежат проверка права, наступление события и версия условий. Если хотя бы одного звена нет, карточка остаётся в статусе «не готово к выплате», даже когда сумма уже посчитана.

Источник, право на сделку и сумма вознаграждения — три разные записи

Источник отвечает на вопрос «откуда появился контакт». Право отвечает на вопрос «может ли этот партнёр получить вознаграждение именно по этой сделке». Расчёт отвечает на вопрос «сколько». Эти записи удобно хранить раздельно, иначе любая правка ставки выглядит как переписывание истории.

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

Клиент уже был в базе: проверка первенства до обещания

Во втором действии условного эпизода 1 выясняется, что покупатель уже был в базе. Партнёр A настаивает: «Я привёл новое подразделение». Партнёр B отвечает: «Я писал этому контакту раньше». CRM не решает, кто прав, но обязана показать историю: старые сделки, контакты, активности, даты и статус проверки. Без этого сотрудник подтверждает право вслепую.

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

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

Соглашение о продажах задаёт рамку, но не заменяет решение по партнёру

В справочном материале Microsoft по соглашениям о продажах описан слой зафиксированных условий сделки. Для нашей темы полезен сам принцип: условия и конкретное исполнение — разные уровни. Соглашение может задать рамку, но оно не говорит, кто из двух партнёров получил право на вознаграждение. Это внешний справочный материал, а не доказательство наличия таких функций в 404ai.

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

Согласование условия: кто подтверждает право и кто готовит расчёт

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

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

Заказ и его исполнение: событие возникает на строке, а не на карточке клиента

Создание и обработка заказа описаны в материале Microsoft. Для партнёрского вознаграждения важен не весь заказ, а строка и её состояние. Сделка на 900 000 ₽ может выглядеть целой, пока внутри не отменена строка на 300 000 ₽. Если база считается по карточке сделки, отмена останется незамеченной.

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

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

Условный эпизод 2. Партнёр привёл покупателя; сделка на 900 000 ₽, ставка 8%, две строки: 600 000 ₽ и 300 000 ₽. Вторая строка отменена до исполнения. Клиент оплатил 500 000 ₽ частично. Через месяц компания изменила правило для новых сделок, но не для этой. Ранее партнёру уже выплатили 20 000 ₽ авансом. Вопрос звучит просто: «Сколько осталось?» — и распадается на четыре разных вопроса.

Если правило компании привязывает вознаграждение к принятой сделке, база — 600 000 ₽, а 8% дают 48 000 ₽. Если к оплате, база — 500 000 ₽, и расчёт иной. Смешивать эти правила нельзя: одна и та же сделка начнёт давать разные суммы в зависимости от того, кто открыл карточку. Уже выплаченные 20 000 ₽ — не «минус в формуле», а отдельная запись с причиной и ссылкой на исходное основание.

Изменение условий после фиксации: версия основания

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

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

Рекомендация: запретить редактирование полей расчёта в карточке со статусом «согласовано» или «выплачено». Новая сумма оформляется новой версией или корректировкой. Так спор о ставке не превращается в спор о том, кто и когда исправил число.

Выплата уже прошла: корректировка отдельным объектом

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

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

Интерфейс сотрудника: что видно до нажатия «Согласовать»

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

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

Трудные исключения: спор двух партнёров, возврат, смена ответственного

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

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

Тесты процесса на условных данных

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

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

Практикум: один конкретный шаг проверки

Условный практикум. Возьмите одну сделку с партнёром на 250 000 ₽, ставку 5%, одну отменённую строку на 50 000 ₽, частичную оплату 100 000 ₽ и уже выплаченные 5 000 ₽. Не считайте итог. Сначала заполните карточку основания: источник, право, событие, база, версия условий, выплата, корректировка. Если хотя бы одно поле нельзя заполнить без переписки, процесс пока не готов.

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

Соседний вопрос разобран отдельно: AI-агент партнёрской программы: как устроен. Здесь основной предмет — учёт основания вознаграждения по принятой сделке и условиям; не набор агентов партнёрской программы.