Личный кабинет B2B: остатки, цены под клиента и повторные заказы

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

Что именно решает личный кабинет B2B в оптовых продажах

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

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

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

Чем кабинет отличается от розничного магазина

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

Что кабинет не заменяет

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

Какие данные кабинет должен показывать клиенту

Минимальный набор, без которого кабинет не примут пользователи:

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

В типовых решениях для B2B (например, на 1С-Битрикс) часто реализованы блоки: статус партнёра, документы по заказам, задолженность. Это ориентир по составу, а не готовый список для вашего проекта — состав уточняется под ваш процесс.

Что показывать не нужно

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

Документы и взаиморасчёты

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

Как понять, что состав данных верный

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

Как устроены цены под клиента

Цена в кабинете — не поле в карточке товара, а результат правил. Прежде чем что-то показывать, нужно ответить на вопросы:

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

В описании B2B-подхода на 1С-Битрикс упоминается возможность настройки нескольких типов цен и разграничения прав доступа. Это подтверждает, что модель «несколько ценовых колонок и права доступа» реализуема настройкой, но конкретный набор правил всё равно определяется вашим договорным процессом. Возможности текущих версий платформы стоит проверять отдельно.

Ценовые колонки и права

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

Скидки, акции и специальные условия

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

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

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

Остатки и сроки: откуда брать данные

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

Ключевые решения:

• показывать точное количество или диапазон («в наличии», «под заказ»);
• учитывать резервы и уже оформленные заказы;
• показывать срок поставки, если товара нет на складе;
• решить, как часто обновляются данные и что видит клиент в момент обновления.

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

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

Резервы и чужие заказы

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

Повторные заказы: сценарии и что для них нужно

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

Рабочие сценарии:

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

Что нужно, чтобы повтор работал

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

Сохранённые списки и шаблоны

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

Минимальная партия и кратность

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

Роли и несколько юрлиц в одном кабинете

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

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

Что стоит определить заранее:

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

Согласование закупок внутри клиентской компании — отдельная тема, её стоит разбирать отдельно, чтобы не смешивать с базовым кабинетом: Согласование закупок в B2B-кабинете.

Почему роли важны для доверия

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

Интеграция с учётной системой: что синхронизировать

Кабинет без связи с учётом быстро расходится с реальностью. Синхронизировать нужно как минимум:

• номенклатуру и характеристики;
• цены по клиентам и группам;
• остатки и резервы;
• заказы из кабинета в учёт;
• статусы заказов обратно в кабинет;
• документы по заказам.

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

Что уточнить до старта

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

Поведение при сбое обмена

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

Кто отвечает за данные

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

Сравнение вариантов реализации

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

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

Учебный пример: проверка сценария повторного заказа

Учебный пример. Данные условные.

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

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

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

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

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

Что показывает этот пример

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

Чек-лист приёмки кабинета

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

Типичные ошибки и ограничения

Ошибки, которые чаще всего мешают кабинету работать:

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

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

Ошибки в ролях

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

Почему нельзя запускать без плана возврата

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

С чего начать

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

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

Следующий шаг — собрать требования в один документ и проверить их на тестовых клиентах до запуска.