Два дилера присылают запрос на специальные условия для одного заказчика. Первый общается с головным офисом, второй — с руководителем конкретного объекта. Оба считают проект своим. Производитель пытается восстановить переписку и выяснить, кто действительно развивает поставку, а кто просто первым заполнил форму.
Портал регистрации проектов нужен для прозрачного рассмотрения таких заявок. Он сохраняет сведения, доказательства и решения по правилам партнёрской программы. Сам факт регистрации не должен автоматически означать эксклюзивность, подтверждённую продажу или обещание скидки, если это отдельно не предусмотрено.
Сначала определите, что считается проектом
Юридическое лицо заказчика и проект — не одно и то же. У одной компании могут одновременно строиться два объекта, закупаться разные группы оборудования и работать независимые команды.
Опишите границу проекта: конечный заказчик, площадка, назначение, продуктовая группа, предполагаемый объём и период реализации. Укажите, какие изменения создают новый проект, а какие уточняют существующий.
Например, поставка насосов для площадки Север и такая же поставка для площадки Восток могут быть отдельными проектами. Но изменение рабочего названия одной площадки не должно создавать новое закрепление. Для сопоставления нужны устойчивые сведения, а не только название из письма.
Отделите заявку от подтверждённого закрепления
Дилер создаёт заявку, производитель проверяет полноту и пересечения, затем принимает решение. До этого портал показывает состояние рассмотрения и ожидаемое действие.
Рабочая последовательность может включать черновик, отправленную заявку, уточнение, рассмотрение, подтверждение, отказ и завершение срока. Для каждого состояния определите, кто может изменять сведения и что видит партнёр.
Принятая заявка должна содержать область закрепления, срок, условия поддержания актуальности и возможные специальные условия. Эти положения задаёт программа производителя. Интерфейс не должен обещать партнёру больше, чем подтверждено уполномоченным сотрудником.
Учебный пример пересечения двух заявок
Представим условного производителя вентиляционного оборудования. Это модель требований, не кейс ExtentLab. Дилер Альфа заявляет модернизацию системы на заводе М, площадка Север, корпус 2. На следующий день дилер Бета подаёт заявку с названием «Завод М: новый цех».
Совпадение заказчика ещё не доказывает дубль. Ответственный уточняет объект, состав оборудования и закупочную процедуру. Выясняется, что у Беты действительно другой корпус и самостоятельный объём. Обе заявки могут рассматриваться отдельно по правилам программы.
Если бы корпус и объём совпали, система создала бы задачу разбора пересечения. В неё попали бы обе заявки и их материалы. Партнёры получили бы уведомление о рассмотрении без раскрытия чужих контактов, цен и документов.
Решение должно опираться на установленное основание: подтверждённые действия, договорённости или другие критерии программы. Одной отметки времени недостаточно, если правило «кто раньше» не принято явно.
Какие сведения действительно нужны
Для первой версии карточка может содержать:
- дилера и ответственного сотрудника;
- конечного заказчика;
- площадку и описание проекта;
- продуктовую группу и предполагаемый состав;
- ожидаемый период поставки;
- стадию работы и подтверждающие действия;
- необходимые материалы с ограниченным доступом;
- запрашиваемые условия;
- дату следующего обновления.
Не требуйте чувствительные сведения только потому, что их удобно собрать. Определите, зачем поле нужно для решения и кто его увидит. Если достаточно обезличенного подтверждения, не заставляйте партнёра загружать лишнюю переписку.
Обязательность должна зависеть от этапа. На первичном рассмотрении точный объём может быть неизвестен; перед подтверждением специальных условий понадобятся дополнительные данные.
Как разбирать конфликт
Назначьте роль, которая имеет право увидеть пересечение и принять решение. У дилера не должно быть доступа к чужой заявке просто из-за совпадения названия заказчика.
В карточке разбора сохраните причину, сравниваемые границы проекта, запросы уточнений, полученные ответы и итог. Возможны разные результаты: проекты различны, один запрос дополняет другой, область закрепления уточнена или заявка отклонена по определённому правилу.
Если решение пересматривают, прежняя версия остаётся видимой уполномоченным сотрудникам. Нельзя просто заменить победившего партнёра в поле и потерять причину изменения. Согласованные действия по уже выданным условиям нужно рассмотреть отдельно.
Программа организует рассмотрение, но не может объективно определить «настоящего владельца клиента» по совпадению строк.
Срок закрепления и продление
Бессрочное закрепление может превратить портал в список заблокированных заказчиков. Определите срок, событие его начала и требования к подтверждению активности.
Для учебного примера срок действует до конкретной даты. За несколько дней до окончания партнёр получает напоминание и может запросить продление с обновлёнными сведениями. Запрос не равен автоматическому продлению: решение принимает назначенная роль.
Если подтверждение пришло после окончания срока, портал не должен молча менять прошлое состояние. Нужно показать фактическую последовательность и применённое правило. Особенно важно это при конкурирующей заявке, поданной в промежутке.
Стадия «Поставка завершена» также отличается от истечения срока. Первая подтверждает результат проекта, второе завершает действие принятого решения по календарю.
Отдельно предусмотрите смену сотрудника внутри дилерской компании. Закрепление относится к партнёру и установленной области проекта, а не к личной учётной записи менеджера. Новый уполномоченный сотрудник получает доступ по принятому порядку, прежний его теряет. История действий сохраняет исходных авторов. Такая передача не должна автоматически продлевать срок или создавать повторную регистрацию того же проекта.
Регистрация проекта не заменяет CRM
CRM может хранить контакты, действия и прогноз продаж. Портал регистрации отвечает за внешнюю заявку партнёра, область закрепления и решение производителя. Эти объекты можно связать, сохраняя их различия.
Один проект может иметь несколько вариантов предложения, а одна сделка в учёте — уточняться после регистрации. Не считайте все подтверждённые регистрации будущей выручкой. Они показывают разрешённую область работы, а не гарантированную покупку.
Выберите источник актуальных сведений по каждой сущности. Если менеджер исправляет площадку в CRM, определите, нужно ли пересмотреть границу закрепления. Незаметная синхронизация такого изменения может изменить смысл решения.
Когда подходит готовое решение
Готовый партнёрский портал или настроенный модуль CRM может быть достаточным при простых правилах, небольшом числе партнёров и понятных ролях. Проверьте поддержку внешнего доступа, срока действия и истории решений.
Разработку отдельного модуля стоит обсуждать, если проекты пересекаются по нескольким признакам, специальные условия требуют собственных согласований или действующие программы не позволяют безопасно разделить данные дилеров.
Начните с демонстрации конфликта и продления, а не каталога и корзины. Они относятся к другим задачам партнёрского кабинета и могут значительно расширить бюджет без решения основной боли.
Состав первой версии и проверка
Для первого запуска достаточно регистрации, уточнения, поиска вероятных пересечений, решения, срока действия, запроса продления и закрытия проекта. Добавьте разграничение доступа и историю значимых изменений.
Проверьте два одновременных запроса, разные площадки одного заказчика, изменение названия, частичное пересечение состава, увольнение ответственного и запрос продления после срока. Автоматический поиск может находить кандидатов на разбор, но итог должен соответствовать принятому порядку.
Для описания ожидаемых результатов пригодятся критерии приёмки системы. В ExtentLab можно обсудить обезличенные примеры обычной и конфликтной регистрации. Они помогут определить границы модуля, достаточность готовой платформы и правила, которые необходимо согласовать до начала разработки.