Что дилеру нужно от кабинета на самом деле
Оптовый канал ломается не на переговорах, а на рутине. Дилер звонит менеджеру, чтобы узнать остаток. Пишет в мессенджер, чтобы уточнить свою цену на позицию. Присылает заявку таблицей, где половина артикулов записана по-своему. Менеджер переносит это в учётную систему руками, ошибается в одной строке, и дальше по цепочке едут не те количества, не та отгрузка и разбирательство на неделю.
Личный кабинет дилера закрывает именно эту дыру. Он снимает с менеджера роль ручного шлюза между партнёром и учётной системой: дилер видит свои условия, свой каталог, свои остатки и сам оформляет заказ. У менеджера появляется время заниматься каналом, а не набирать строки в заказе.
Разница между таким кабинетом и обычным B2B-разделом сайта существенная. У нас есть отдельный материал про личный кабинет B2B-клиента на 1С-Битрикс, там речь про корпоративного покупателя, который приобретает для себя. Дилер покупает, чтобы перепродать, и это меняет всю логику. Появляются уровни партнёрства, планы закупок, защита сделок, маркетинговая поддержка и отчётность по каналу.
Почему для дилерского портала берут 1С-Битрикс
Ключевой аргумент прозаичен: в платформе уже есть механика разных цен для разных покупателей, и её не нужно писать с нуля. Редакция «Бизнес» продукта «1С-Битрикс: Управление сайтом» позволяет вести несколько типов цен, включая розничную, оптовую и дилерскую, и раздавать группам покупателей права доступа к этим ценам. Один и тот же товар показывается разным группам по разной стоимости, а переключение происходит автоматически по типу покупателя.
Сверху ложатся остальные штатные механизмы: правила работы с корзиной для скидок и наценок, накопительные скидки, купоны, многоскладовость с учётом остатков, документооборот с поэтапной публикацией документов. Обмен с 1С идёт по протоколу CommerceML в формате XML, то есть по стандартному каналу для товаров, заказов и контрагентов, а не через самописную синхронизацию.
Отсюда простой вывод про бюджет. Основная часть работ на таком проекте приходится на настройку правил конкретного бизнеса и стыковку с учётной системой, а не на разработку самого движка цен и заказов. Поэтому дилерский портал на 1С-Битрикс в первый год обычно обходится дешевле, чем портал с нуля на фреймворке, где всю эту логику пишут руками. О сравнении подходов мы писали в материале про разработку B2B-портала на 1С-Битрикс.
Оговорка тоже нужна. Редакция «Малый бизнес» под задачу не подходит, она рассчитана на розничный магазин. Если у вас несколько групп покупателей с разными ценами на одну и ту же позицию, стартовой точкой будет «Бизнес». Это стоит проверить до старта разработки: переезд между редакциями на середине проекта неприятен и по срокам, и по деньгам.
Уровни дилеров и персональные условия
Дилерская сеть почти никогда не бывает плоской. Есть крупный партнёр, который берёт вагонами, есть региональный дилер со скромным оборотом, есть новичок на испытательном сроке. Условия у них разные, и кабинет должен это отражать без ручного вмешательства.
Базовая схема выглядит так. Каждому уровню партнёрства соответствует группа пользователей, каждой группе назначен свой тип цены. Дилер авторизуется, платформа определяет его группу и показывает каталог с его ценами. Никаких «позвоните менеджеру, он скажет вашу цену».
Дальше начинаются нюансы конкретного бизнеса, и вот их проектируют отдельно:
- Индивидуальные условия поверх уровня. У части партнёров цена отличается от их группы по историческим причинам. Такие исключения удобнее держать в учётной системе и передавать на сайт обменом, чтобы не заводить их руками в двух местах.
- Скидки за объём внутри заказа. Правила работы с корзиной пересчитывают стоимость по мере наполнения заказа, и дилер видит, что при добавлении ещё одной коробки цена за единицу опускается.
- Ограничение ассортимента. Не каждому партнёру доступна вся матрица, часть брендов закрывают под конкретные уровни или регионы.
- Кредитный лимит и дебиторка. Если у партнёра просрочка, кабинет должен либо предупреждать, либо блокировать оформление. Данные о задолженности живут в учётной системе, кабинет их только показывает.
Последний пункт чаще всего забывают на старте и добавляют потом в спешке. А ведь он даёт кабинету финансовую пользу помимо удобства: дилер сам видит свой баланс и не оформляет заказ, который всё равно не отгрузят.
Остатки, резервы и честность цифр
Самая частая претензия дилеров к порталам звучит одинаково: «у вас на сайте было пять штук, я оформил, а мне отгрузили две». После двух таких историй партнёр возвращается к звонкам менеджеру, и весь проект теряет смысл.
Лечится это честной договорённостью о том, что именно показывать. Вариантов немного:
- Точное количество. Прозрачно, но требует частого обмена и резервирования при оформлении, иначе два дилера успевают заказать один и тот же остаток.
- Градации: «много», «мало», «под заказ». Снимает вопрос точности, но раздражает крупных партнёров, которым нужна конкретика для планирования.
- Точное количество с оговоркой о подтверждении. Компромисс: цифра показана, но заказ считается подтверждённым после проверки на складе.
Выбор зависит от оборачиваемости. При быстрой оборачиваемости и редком обмене первый вариант превращается в источник конфликтов. При обмене раз в несколько минут и резерве на момент оформления он работает нормально.
Отдельно стоит договориться про многоскладовость. Если товар лежит на нескольких складах, дилер должен понимать, откуда поедет его заказ и как это влияет на срок. Общая сумма остатков по всем складам без указания логистики почти гарантирует претензию по срокам доставки.
Заказ, который не нужно перебивать руками
Кабинет окупается в тот момент, когда заказ дилера попадает в учётную систему без участия менеджера. До этого момента вы просто заменили один канал приёма заявок другим.
Первое, что нужно предусмотреть, это быстрый ввод по артикулам. Дилер, который заказывает каждую неделю, знает свою номенклатуру наизусть, и красивый каталог с фильтрами ему только мешает. Ему нужна форма, куда можно вставить список артикулов с количествами и получить готовую корзину. Загрузка заказа из файла закрывает ту же потребность для тех, кто формирует заявку в своей учётной системе.
Дальше по важности идёт повтор прошлого заказа. Регулярные закупки совпадают между собой на 70–80%, и кнопка «повторить» экономит партнёру больше времени, чем любой поиск по каталогу. Рядом с ней просятся шаблоны и именованные списки закупок: сезонный ассортимент, ходовые позиции, наборы под конкретную точку продаж.
Статусы заказа стоит писать словами, понятными дилеру: «принят», «собирается», «готов к отгрузке», «отгружен» с номером накладной. Внутренние статусы вашей учётной системы партнёру ничего не говорят и вызывают ровно те звонки, ради отмены которых кабинет и делался.
Последний блок, который сильно снимает нагрузку, это документы. Счёт, накладная, счёт-фактура, акт сверки. Половина обращений в бухгалтерию сводится к просьбе переслать документ, который уже был отправлен, и архив в кабинете убирает этот поток целиком.
Обмен заказами с 1С настраивается условиями выгрузки. Можно выгружать только оплаченные заказы, только заказы с разрешённой доставкой или заказы начиная с определённого статуса. Так учётная система не засоряется черновиками и корзинами, которые дилер бросил на середине.
Регистрация сделок и защита дилера
Эту функцию в универсальных B2B-кабинетах не встретишь, а для дилерского канала она бывает критичной. Смысл в следующем: партнёр вложил силы в проработку клиента и хочет гарантий, что тот же клиент не уйдёт к соседнему дилеру по более низкой цене.
Механика простая. Дилер регистрирует проект: конечный клиент, объём, ориентировочный срок. Вендор проверяет, что проект не занят, и закрепляет его за партнёром на согласованный период. На время закрепления дилер получает специальные условия по этой сделке.
В кабинете это выглядит как отдельный раздел со списком заявок и их статусами. Технически перед вами набор пользовательских сущностей и правил доступа, а не коробочная функция, поэтому закладывайте её в смету осознанно. Зато эффект на лояльность партнёров заметный: там, где регистрация сделок работает прозрачно, дилеры перестают воспринимать вендора как конкурента.
Смежный сюжет — маркетинговая поддержка. Раздел с логотипами, каталогами, фотографиями товаров, шаблонами презентаций и правилами использования бренда снимает с маркетинга поток однотипных просьб «пришлите картинку». Заодно решается проблема, когда партнёры годами используют устаревшие материалы.
Разграничение доступа: сотрудники дилера
У дилера тоже есть внутренняя структура. Закупщик оформляет заказы, бухгалтер смотрит документы и сверки, руководитель хочет видеть общую картину по своей компании. Один общий логин на всех работает плохо: непонятно, кто что заказал, а увольнение сотрудника превращается в срочную смену пароля для всех.
Рабочая модель другая. Контрагент с несколькими учётными записями и ролями внутри. Заказы видны в разрезе сотрудников, руководитель дилера может ограничивать своим людям сумму заказа или требовать согласования. Администрирование при этом отдаётся самому дилеру, ваш менеджер не должен заводить чужих сотрудников руками.
Про безопасность скажем без нагнетания. Кабинет содержит коммерчески чувствительные данные: дилерские цены, объёмы закупок, дебиторку. Минимальный набор мер понятен. Доступ только по HTTPS, разграничение прав на уровне групп пользователей платформы, отсутствие лишних данных в открытых частях сайта, регулярные обновления. Конкретную политику паролей и журналирования обсуждают с вашей ИТ-службой, универсального рецепта тут нет.
Интеграция с учётной системой: узкое место проекта
По нашему опыту, на дилерских порталах примерно половина трудозатрат приходится на обмен данными. И почти все срывы сроков случаются там же.
Причина при этом редко бывает технологической. CommerceML — стандартный протокол, товары и заказы по нему ходят предсказуемо. Проблемы возникают в данных и в договорённостях:
- Номенклатура не готова к выгрузке. Дубли, товары без артикулов, разные единицы измерения у одной позиции, характеристики в названии вместо свойств. Всё это вылезает на первой же выгрузке.
- Контрагенты не сопоставлены. Дилер в учётной системе и пользователь на сайте — разные записи, и связать их нужно надёжным идентификатором, а не наименованием организации.
- Не решено, кто хозяин данных. Если цену можно поменять и в 1С, и в админке сайта, рано или поздно значения разойдутся. Для каждого поля должен быть один источник истины.
- Частота обмена не согласована с бизнесом. Остатки раз в сутки при быстрой оборачиваемости дают гарантированные конфликты по резервам.
Практический совет: начинайте проект с аудита данных в учётной системе, а дизайн кабинета отложите на потом. Неделя на разбор номенклатуры в начале экономит месяц разбирательств в конце. Если внутри компании такого ресурса нет, это ровно та работа, которую разумно отдать подрядчику: заказать разработку сайта вместе с аудитом обмена дешевле, чем чинить рассинхронизацию на живом канале.
Ещё одна деталь. Обмен пользователями и контрагентами идёт своими файлами, и доступность товаров с торговыми предложениями определяется типом цены для конкретного контрагента. То есть настройка прав на цены и настройка обмена связаны между собой, их нельзя делать разными людьми в разное время без общей карты.
Как это выглядит на практике
Пример ниже иллюстративный. Он типовой для казахстанского оптовика, но собран из нескольких похожих ситуаций и не описывает конкретного клиента.
Дистрибьютор строительных материалов, около 60 активных дилеров по стране, три уровня партнёрства, ассортимент порядка четырёх тысяч позиций. До кабинета три менеджера принимали заявки по WhatsApp и почте, вручную переносили их в 1С и тратили на это большую часть рабочего дня. Пиковые дни в начале месяца превращались в очередь, дилеры ждали подтверждение по полдня.
Что сделали. Развернули каталог с тремя типами цен по группам партнёров, подключили обмен с 1С каждые пятнадцать минут по остаткам и раз в час по заказам, добавили быстрый ввод по артикулам и повтор прошлого заказа. Дебиторку вывели в шапку кабинета: сумма долга и ближайшая дата платежа. Документы за последние два года выложили в архив.
Результат через квартал. Около 70% заказов стали приходить через кабинет без участия менеджера. Освободившееся время менеджеры направили на работу с неактивными партнёрами, теми, кто не заказывал больше двух месяцев. Поток обращений в бухгалтерию за документами заметно упал, потому что дилеры перестали просить дубликаты.
Чего не произошло. Оставшиеся 30% заказов так и остались ручными. Часть дилеров принципиально работает через менеджера, часть заказов слишком нестандартна для формы. Это нормальный итог: кабинет снимает рутину, а не обнуляет ручную работу полностью.
Ошибки, которые дорого обходятся
Кабинет делают красивым, а не быстрым. Дилер заходит по несколько раз в день и работает в нём как в рабочем инструменте. Анимации и крупные карточки товаров ему мешают, плотная таблица с быстрым поиском полезнее эффектной витрины.
Запускают без обучения партнёров. Дилеры годами звонили менеджеру и сами в кабинет не перейдут. Нужны короткая инструкция, показ на встрече и период, когда менеджер мягко возвращает партнёра в кабинет вместо приёма заявки по телефону.
Делают мобильную версию по остаточному принципу. Значительная часть дилеров смотрит остатки и статусы с телефона, часто прямо у клиента. Если каталог на смартфоне открывается плохо, кабинетом просто не будут пользоваться.
Не планируют развитие. Кабинет живёт дольше, чем разовый проект. После запуска приходят пожелания от партнёров, и без выделенного бюджета на доработки портал за год превращается в мёртвый раздел.
Дают одинаковый интерфейс всем уровням. Крупному партнёру нужны отчётность и планирование, мелкому достаточно простого оформления заказа. Одна и та же перегруженная страница отпугивает вторых и не удовлетворяет первых.
С чего начать, если решение принято
Порядок действий, который на практике даёт наименьшее число сюрпризов:
- Опишите текущий процесс. Как заявка проходит путь от дилера до отгрузки сейчас, сколько людей её касается, где теряется время. Без этой картины автоматизировать нечего.
- Проверьте данные. Аудит номенклатуры, единиц измерения, контрагентов и типов цен в учётной системе. Это фундамент всего остального.
- Зафиксируйте матрицу условий. Уровни партнёров, типы цен, исключения, лимиты. Именно этот документ определяет сложность проекта и его смету.
- Определите минимальный первый релиз. Каталог с ценами по уровням, остатки, оформление заказа, статусы, документы. Регистрация сделок, планы закупок и отчётность идут вторым этапом.
- Договоритесь про обмен. Что, откуда, куда, с какой частотой и кто хозяин каждого поля.
- Запланируйте вывод партнёров. Пилот на нескольких лояльных дилерах, сбор замечаний, потом остальные.
Автоматизация оптовых продаж через кабинет даёт эффект не в момент запуска, а через два-три месяца, когда партнёры привыкают и перестают дублировать заказы звонком. Заложите этот период в ожидания руководства, иначе проект успеют признать неудачным как раз тогда, когда он начнёт набирать обороты.
Частые вопросы
Чем личный кабинет дилера отличается от кабинета обычного B2B-клиента?
Корпоративный клиент покупает для собственных нужд, дилер — для перепродажи. Отсюда дополнительная логика: уровни партнёрства с разными ценами, планы закупок, регистрация сделок с конечными клиентами, маркетинговые материалы, отчётность по каналу. Технически база общая, но набор функций и приоритеты отличаются.
Какая редакция 1С-Битрикс нужна для дилерского портала?
Ориентируйтесь на «Бизнес». Именно эта редакция даёт работу с несколькими типами цен, включая оптовые, дилерские и розничные, и распределение прав доступа групп покупателей к ценам каталога. «Малый бизнес» рассчитана на розничный магазин и под несколько групп покупателей с разными ценами не подходит.
Обязательно ли подключать обмен с 1С сразу?
Технически кабинет запускается и без обмена, с ручным ведением каталога в админке. Практически смысл проекта теряется, потому что заказы всё равно придётся перебивать руками. Разумный компромисс на старте: обмен по товарам и остаткам сразу, выгрузка заказов следующим этапом, но по заранее спроектированной схеме.
Сколько времени занимает разработка такого кабинета?
Диапазон широкий и зависит в основном от состояния данных и сложности матрицы условий, а не от количества экранов. Проект с чистой номенклатурой и тремя уровнями цен идёт заметно быстрее, чем проект, где номенклатуру предварительно приводят в порядок. Оценку дают после аудита учётной системы, до него любые сроки будут гаданием.
Что делать, если часть дилеров откажется пользоваться кабинетом?
Это нормальная ситуация, и её стоит принять заранее. Оставьте ручной канал для нестандартных заказов и для партнёров, которым принципиально важен живой менеджер. Наращивайте долю кабинета мягко: повтор заказа в один клик, актуальные остатки и доступ к документам обычно убеждают лучше административных требований.