B2B-кабинет для оптовой компании: дилеры без WhatsApp

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

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

Разница между «переписываемся в мессенджере» и «работаем через кабинет» — не в удобстве интерфейса. Она в том, где живут данные. В переписке заказ существует как строчка текста, которую кто-то должен перенести. В кабинете заказ сразу существует как документ в вашей системе, с позициями, ценами и статусом. Ниже — что именно перестаёт делать менеджер.

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

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

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

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

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

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

Технически связка делается через API учётной системы: кабинет запрашивает данные, а не хранит их копию как истину. Остатки обычно синхронизируются часто — минуты, а не сутки; прайсы и справочник номенклатуры реже, но по событию изменения. Заказ идёт в обратную сторону: из кабинета в учётную систему создаётся документ. Обмен буферизуется, чтобы недоступность одной из систем не приводила к потере заказа.

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

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

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

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

Технически контур собирается либо на Битрикс24, если вам нужен весь корпоративный набор — воронки, задачи, телефония, бизнес-процессы, — либо на self-hosted CRM, когда принципиален контроль над размещением данных. Обе линии у нас в работе, и на аудите мы честно говорим, какая уместнее вашему масштабу и бюджету.

Если опт уже сидит в чужой CRM и хочет переехать, механику мы показываем на кейсе переноса CRM в мебельном производстве — правда, отрасль там другая, это не дистрибуция. По механике перенос выглядел так: 45 компаний, 2217 контактов, 1541 лид и 668 сделок со сверкой один в один, 66 воссозданных кастомных полей, 2584 записи таймлайна, 10 объединённых стадий двух воронок и 22 источника. Честно про статус: проект в фазе внедрения — перенос файлов и настройка автоматизации ещё не завершены из-за ограничений выгрузки из Bitrix24.

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

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

То же и с электронным документооборотом. Когда накладные и УПД ходят через ЭДО, приёмка перестаёт зависеть от того, доехала ли бумага и не потерял ли её водитель. Для дилера это означает, что документ по отгрузке появляется у него в системе почти сразу, а не через неделю. Для вашей бухгалтерии — что запросы копий накладных в личной переписке менеджера прекращаются: подписанные документы лежат по своему маршруту, а в кабинете дилер видит их перечень и статус.

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

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

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

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

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

И общее правило, которое мы повторяем в любом проекте с AI: человек остаётся в контуре. Агент отвечает на вопросы по данным и рисует график, а решение о цене, отгрузке в долг или расставании с дилером принимает руководитель.

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

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

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

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

Честно про наш опыт в отрасли: опубликованного кейса в оптовой торговле и дистрибуции у нас нет. Есть разработка личных кабинетов и порталов, есть интеграции с учётными системами и CRM, есть BI-контур на естественном языке в демо-статусе и есть опыт переноса CRM со сверкой один в один. Мы предпочитаем сказать это прямо, а не выдавать соседнюю отрасль за отраслевой кейс.

Знакомство устроено просто: 30 минут бесплатного экспресс-аудита без презентаций. Разбираем четыре точки — как сейчас приходят заказы от дилеров, где считается персональная цена, что происходит с остатками и какие документы контрагент запрашивает чаще всего. На выходе вы получаете вывод о составе первой версии, а иногда и совет ограничиться настройкой существующей системы. Стоимость работ называем после этого разбора, когда виден объём экранов и интеграций.