Дилерский портал: задачи, процессы и автоматизация

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

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

Партнёр видит только свои данные и условия, а компания сохраняет единый процесс исполнения.

Портал как набор сервисов, а не ещё один сайт

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

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

Типовой набор сервисов включает:

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

Один заказ глазами партнёра и компании

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

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

Какие данные нужны

Объект	Что видит дилер	Что контролирует компания	Источник
Профиль партнёра	реквизиты, пользователи, договор	статус проверки, сегмент, права	CRM/MDM и портал
Каталог	доступные позиции и условия	ассортиментная матрица и версия	ERP/PIM
Заказ	состав, сумма, статус	лимит, согласование, исполнение	портал и ERP
Документ	счёт, накладная, акт	версия, подпись, отправка	ЭДО/СЭД
Обращение	тема, переписка, решение	SLA, исполнитель, причина	CRM/ITSM
Платёж и отгрузка	подтверждённый статус	сверка и отклонения	ERP, банк, WMS/TMS

Роли и разграничение доступа

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

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

Портал, CRM и интернет-магазин: в чём разница

Инструмент	Главная роль	Кому доступен	Особенность
Дилерский портал	самообслуживание партнёра	авторизованной сети	персональные условия и сквозные B2B-процессы
CRM	работа сотрудников с отношениями и продажами	внутренним пользователям	воронка, активности, единая история клиента
Интернет-магазин	массовая онлайн-продажа	широкой аудитории	стандартный публичный каталог и оформление
Корпоративный портал	работа сотрудников	персоналу организации	внутренние сервисы и коммуникации

Что автоматизировать в первую очередь

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

Показатели портала

• доля заказов, оформленных без ручного переноса;
• время подключения нового партнёра;
• доля заказов, возвращённых из-за неполных данных;
• время согласования исключений;
• доля документов, доступных в кабинете вовремя;
• число обращений по вопросу «где заказ»;
• соблюдение SLA по сервисным запросам;
• активность пользователей по партнёрам.

Интеграции и актуальность статусов

Портал редко становится авторитетным источником для всех данных. Обычно карточка партнёра и активности связаны с CRM, цены и заказы — с ERP, остатки — с WMS, отгрузка — с логистическим решением, документы — с ЭДО или СЭД. Для каждого поля нужно определить источник, направление передачи, частоту обновления и поведение при недоступности системы.

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

Безопасность партнёрского доступа

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

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

Как развивать портал по этапам

1. Первый релиз: профиль, каталог, заказ и понятный статус.
2. Второй: документы, платежи, отгрузка и уведомления.
3. Третий: рекламации, обучение, материалы и аналитика.
4. Дальше: персональные программы и совместное планирование — при достаточном качестве данных.

Типовые ошибки

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

Чек-лист запуска

1. Выберите 2–3 частых сценария партнёра.
2. Опишите источники данных и владельцев каждого статуса.
3. Разделите внешний и внутренний словарь состояний.
4. Спроектируйте модель ролей и отзыв доступа.
5. Настройте обработку исключений и эскалации.
6. Проверьте мобильный сценарий и доступность.
7. Проведите пилот с небольшой группой дилеров.
8. Соберите причины незавершённых операций и улучшите маршрут.

Частые вопросы

Нужен ли дилерский портал небольшой сети?

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

Можно ли показывать остатки из ERP?

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

Кто создаёт пользователей дилера?

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

Чем портал помогает менеджеру?

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

Нужна ли электронная подпись?

Зависит от вида документов и принятой схемы ЭДО. Портал может инициировать и отображать статус, не подменяя оператора или правила подписи.

Как не допустить утечку цен?

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

Можно ли подключить мобильных пользователей?

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