Дилерский портал: как автоматизировать работу с дилерами и оптовыми клиентами

Оптовый клиент пишет менеджеру: «Пришлите актуальный прайс». Через полчаса уточняет остатки. Потом отправляет заказ в Excel, просит счет, через два дня спрашивает статус отгрузки, а в конце месяца — акт сверки.

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

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

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

Что такое дилерский портал и чем он отличается от обычного интернет-магазина

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

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

Поэтому дилерский портал — это рабочее место оптового клиента, которое учитывает его отношения с поставщиком.

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

Конкретный набор правил зависит от бизнеса. Именно поэтому два внешне похожих дилерских портала внутри могут быть устроены совершенно по-разному.

Что в работе с дилерами стоит автоматизировать

Начинать проект полезно не с вопроса «какие разделы должны быть в личном кабинете», а с работы отдела продаж. Возьмите обращения дилеров за обычную неделю и посмотрите, зачем они обращаются к менеджерам.

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

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

Это хороший пример процесса для автоматизации: сотрудник не принимал решение, а переносил уже принятое клиентом решение из одного места в другое.

Что дилер должен уметь делать самостоятельно

Смотреть свой каталог и цены

Дилер должен видеть не абстрактный прайс компании, а условия, по которым может заказать именно он. Цена может зависеть от договора, категории клиента, объема заказа и других правил конкретной компании.

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

Проверять остатки

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

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

Быстро оформлять и повторять заказ

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

Поэтому в B2B полезны быстрый заказ по артикулу, табличный ввод количества, загрузка из Excel, повтор предыдущего заказа, шаблоны, учет кратности упаковки (или, к примеру, длины рулона), а также минимальной партии.

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

Следить за заказом и отгрузкой

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

Но статус в портале не должен жить собственной жизнью. Если заказ уже отгружен, а клиент по-прежнему видит «в обработке», он все равно позвонит менеджеру — и портал не решит задачу.

Получать документы

Счета, накладные, УПД, акты и другие документы — еще один класс повторяющихся запросов. Вместо «пришлите еще раз, письмо потерялось» дилер заходит в историю и получает доступ к документам, которые ему необходимы.

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

Видеть взаиморасчеты и задолженность

Для одних компаний задолженность — просто информация для клиента. Для других она непосредственно влияет на возможность сделать новый заказ.

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

Здесь портал уже не просто показывает данные. Он автоматически применяет бизнес-правило, которое раньше приходилось контролировать человеку.

Почему оптовый заказ — это не розничная корзина

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

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

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

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

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

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

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

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

Поэтому потребность «нужен личный кабинет с ценами и заказами» — не полная. Крайне важно подробно описать правила и бизнес-процессы.

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

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

Как дилерский портал связан с 1С и CRM

Портал редко становится единственной системой компании. Номенклатура, цены, остатки, контрагенты и взаиморасчеты могут вестись в 1С или ERP. История взаимодействия и работа менеджеров — в CRM. На сайте клиент работает с каталогом и оформляет заказ. Документы могут формироваться еще в одной системе.

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

• учетная система → портал: товары, цены, остатки, договоры, задолженность;
• портал → учетная система: новый заказ, его состав, реквизиты клиента;
• учетная система → портал: подтверждение заказа, изменение статуса, документы;
• портал / учетная система → CRM: информация о действиях клиента и задачи менеджеру.

Это только пример архитектуры. В конкретном проекте источники и направления обмена могут отличаться.

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

Если этого не сделать, портал быстро превращается в еще одну систему, где данные приходится исправлять вручную.

Не пытайтесь автоматизировать всё в первой версии

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

Все они могут быть полезны. Но это не означает, что они нужны в первом релизе.

Для начала лучше определить 2–3 самых дорогих ручных процесса. Например: менеджеры постоянно отправляют цены и остатки, вручную переносят заказы в 1С и отвечают на вопросы о статусах. Тогда первая версия портала может решать именно эти задачи.

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

Для такого подхода хорошо подходит MVP: вместо разработки всей системы сразу создается рабочая первая версия, на которой можно проверить сценарии реальных пользователей. Для проектов на 1С-Битрикс такую версию можно запускать в том числе с помощью быстрой разработки MVP с помощью ИИ: AI ускоряет рутинную часть разработки, а архитектуру решения и результат контролирует опытный разработчик.

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

Почему дилеры могут продолжить писать менеджеру после запуска портала

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

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

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

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

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

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

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

Как понять, что компании уже нужен дилерский портал

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

Смотреть лучше на процесс. Дилерский портал имеет смысл рассматривать, если:

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

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

С чего начать проект дилерского портала

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

Возьмите 50–100 последних обращений дилеров к менеджерам и распределите их по категориям.

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

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

Так появляется список процессов, которые действительно имеет смысл автоматизировать.

Для каждого из них ответьте на четыре вопроса: откуда берутся данные → какое правило применяет сотрудник → что должен увидеть или сделать дилер → куда должен попасть результат.

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

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

Что важно запомнить

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

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

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

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

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

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

Обязательно ли интегрировать дилерский портал с 1С?

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

Можно ли показывать каждому дилеру свои цены?

Да. Источником может быть 1С, ERP или другая система ценообразования. После авторизации портал определяет клиента и показывает условия, которые относятся к нему.

Можно ли работать через портал от нескольких юридических лиц?

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

Что делать, если дилеры привыкли отправлять заказы в Excel?

Не обязательно сразу запрещать Excel. Если это удобный формат для закупщика, портал может принимать файл и автоматизировать его обработку. Цель — убрать ручную работу компании, а не заставить клиента делать то же самое менее удобным способом.

Можно ли запустить сначала простой портал, а потом его развивать?

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

Подойдет ли дилерский портал только крупной компании?

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