Партнёрский кабинет: регистрация сделок, закрепление клиента и расчёт вознаграждений

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

Каким партнёрам нужен такой кабинет?

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

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

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

Что партнёр регистрирует: клиента или конкретную сделку?

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

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

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

Как проверять совпадения и решать спор о принадлежности?

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

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

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

Какие состояния должна проходить сделка?

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

Событие	Что видит партнёр	Что проверяет компания	Что происходит с начислением
Партнёр зарегистрировал клиента	Заявка принята на проверку	Полнота данных и возможное совпадение	Начисления пока нет
Найдена открытая сделка другого источника	Требуется решение, причина без чужих данных	Правило принадлежности и подтверждения	Автоматическое начисление остановлено
Компания закрепила сделку	Срок и область закрепления	Ответственный и версия правил	Зафиксировано правило будущего расчёта
Получена подтверждённая частичная оплата	Основание и рассчитанная сумма	Какая часть входит в расчётную базу	Создана отдельная запись
Подтверждён частичный возврат	Корректировка со ссылкой на исходное основание	Связь возврата с оплатой и правило уменьшения базы	Добавлена корректировка; исходное начисление сохранено
Начисление включено в пакет выплаты	Пакет подготовлен, факт выплаты ещё не подтверждён	Состав пакета и разрешение на исполнение	Начислено и подготовлено к выплате показаны раздельно
Получено подтверждение фактической выплаты	Выплата с датой и основанием	Связь подтверждения с нужным пакетом	Только подтверждённая операция отмечена как выплаченная

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

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

1. 01Регистрация

   Заявка принята на проверку; начисления ещё нет.

2. 02Проверка совпадений

   Компания проверяет данные и принадлежность сделки.

3. 03Закрепление

   Зафиксированы срок, область и версия правил расчёта.

4. 04Подтверждённая оплата

   Создаётся отдельная запись по согласованной расчётной базе.

5. 05Пакет выплаты

   Начисление подготовлено к выплате, но ещё не считается выплаченным.

6. 06Фактическая выплата

   Статус меняется после подтверждения с датой и основанием.

Спор о принадлежности останавливает автоматическое начисление. Возврат оформляется отдельной корректировкой: исходное начисление сохраняется.

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

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

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

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

Как проверить частичную оплату, повтор и возврат?

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

1. Компания закрепляет сделку за партнёром и сохраняет применимую версию правил.
2. Источник подтверждает частичную оплату. Расчёт учитывает только разрешённую правилами часть этой оплаты; неоплаченный остаток сделки пока не создаёт начисление.
3. То же подтверждение поступает повторно. Система узнаёт уже обработанное основание, поэтому история передачи дополняется, а начисление не удваивается.
4. Источник подтверждает возврат части этой оплаты. Возникает отдельная корректировка, связанная с оплатой и прежним начислением; исходные записи остаются видимыми.
5. Ответственный открывает итог и видит, из каких оснований он сложился. Партнёр видит ту же расшифровку в пределах согласованного доступа, без чужих сделок.

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

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

Что показывать в кабинете партнёра?

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

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

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

Какую информацию брать из CRM и учётной системы?

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

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

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

Какие действия должна уметь команда программы?

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

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

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

С чего начать первую версию и как её принять?

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

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

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

Сколько стоит разработать партнёрский кабинет?

Ориентир Roboweb по личным кабинетам — от 160 000 ₽ и от 10 дней для компактной первой версии. Цена конкретной программы зависит от правил закрепления, расчётов, источников данных и административных действий. Нестандартная финансовая логика не считается автоматически включённой в базовую сумму.

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

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

Короткие ответы на частые вопросы

Чем этот кабинет отличается от дилерского портала?

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

Достаточно ли промокода или реферальной ссылки?

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

Можно ли начислять вознаграждение автоматически?

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

Как не потерять старую ставку после её изменения?

К начислению привязывают версию правила и событие, которое определяет её применение. Изменение справочника не должно без объяснения пересчитывать прошлые результаты.

Сколько стоит партнёрский кабинет?

Для компактной первой версии ориентир Roboweb — от 160 000 ₽ и от 10 дней. Полный цикл расчётов и выплат не включается автоматически: правила, источники и административные действия оценивают по заданию.

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