B2B-портал для дистрибьютора: заказы точек 24/7 без менеджера

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

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

Что клиент делает в портале

Набор функций зависит от отрасли, но ядро у большинства дистрибьюторов одинаковое:

• Каталог со своими ценами — цена считается по прайс-листу клиента, его скидкам и действующим акциям, а не одна на всех.
• Остатки — точные или в градациях, с учётом склада, с которого отгружают эту точку.
• Быстрый заказ — повтор прошлого заказа, ввод по артикулу или штрихкоду, загрузка из Excel, кратность упаковки.
• Статус заказа — принят, собран, отгружен, в пути, доставлен; с датой доставки по графику маршрута.
• Документы — счета, УПД, акты сверки; если подключён ЭДО, ссылка на документ в операторе.
• Финансы — текущий долг, просрочка, доступный кредитный лимит, история оплат.
• Претензии и возвраты — заявка на возврат или недовоз с фото, без звонков.
• Несколько точек и пользователей — владелец видит всё, закупщик конкретного магазина — только свой адрес.

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

Где у портала сложная логика

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

Цены

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

Кредитный лимит и отсрочка

Клиент с просроченным долгом не должен иметь возможность набрать заказ на крупную сумму, пока менеджер спит. Портал проверяет лимит и просрочку в момент оформления и показывает понятное сообщение: «Доступно к заказу 48 000 ₽, для увеличения лимита погасите счёт № …». Какой должна быть политика — блокировать, ставить заказ на согласование или пропускать с предупреждением — решает финансовая служба. Механику контроля дебиторки мы разбирали в статье кредитный лимит и отсрочка платежа в CRM, а автоматизацию напоминаний и стоп-листов — на странице работы с дебиторской задолженностью.

Остатки и резервы

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

Что откуда берётся: портал и 1С

Портал — не учётная система. Он показывает данные и принимает заказы, а документы, проводки и долги живут в 1С:УТ, 1С:КА или 1С:ERP. Схема обмена обычно выглядит так:

Главная ошибка — позволить порталу создавать контрагентов и номенклатуру самостоятельно. Тогда в 1С появляются «ООО Ромашка» и «Ромашка ООО» с одним ИНН. Как этого избежать, — в статье интеграция CRM дистрибьютора с 1С без дублей и на странице интеграции 1С с сайтом.

Портал, агент или бот: не вместо, а вместе

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

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

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

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

1. Начните с группы лояльных клиентов, которые сами жаловались на неудобство заказа. Соберите с ними замечания до массового запуска.
2. Дайте вход без пароля: ссылка в SMS или мессенджере, привязка к телефону закупщика. Каждое лишнее поле на входе снижает долю активаций.
3. Обучайте через агентов: на визите агент оформляет первый заказ вместе с клиентом в его телефоне.
4. Сделайте в портале то, чего нет в других каналах: акт сверки за минуту, историю цен, напоминание «вы обычно заказываете это по средам».
5. Сохраните мотивацию агента: заказ из портала по его точке входит в его план.
6. Измеряйте долю заказов через портал по каждому агенту и каждой категории клиентов, а не только общее число регистраций.

Доступы, безопасность и мобильная версия

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

• Роли внутри клиента. Владелец видит все точки и финансы, закупщик магазина — только свой адрес и каталог, бухгалтер — документы и акты сверки без возможности заказывать.
• Отключение доступа. Когда закупщик увольняется, клиент должен сам отключить его в кабинете, не дожидаясь звонка менеджеру.
• Журнал действий. Кто и когда оформил или изменил заказ — пригодится при спорах о недовозе или «мы этого не заказывали».
• Защита от перебора. Ограничение попыток входа и подтверждение по коду на телефон — минимальный уровень для системы с ценами и долгами.
• Персональные данные. Телефоны и имена сотрудников клиента — персональные данные, на их обработку нужно согласие и соответствующие документы; детали согласуйте с юристом.

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

Что посчитать до старта

Решение о портале удобно проверить на простом условном расчёте. Допустим, у вас 600 активных точек, треть из них делает 2–3 дозаказа в неделю по телефону, каждый звонок с вводом в 1С занимает у менеджера 7–10 минут. Если хотя бы половина этих дозаказов уйдёт в портал, освобождается заметная часть рабочего времени отдела, а ошибок ручного ввода становится меньше. Подставьте свои цифры в калькулятор окупаемости CRM — логика расчёта для портала та же.

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