Один товар, три цены и очередь согласований: чем B2B-маркетплейс отличается от интернет-магазина

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

Привет, я Антон Фокин, CEO Qtim. Запрос на B2B-платформу часто звучит так: «Нужен интернет-магазин, только для компаний». Снаружи продукты действительно похожи — каталог, карточка, корзина, заказ. В разработке B2B-маркетплейса разница скрыта в устройстве сделки. У корпоративной покупки больше участников, условий, документов и систем, которые имеют своё мнение о цене и остатках. Один товар, три цены и очередь согласований — нормальная картина для такого процесса.

Разберём, что меняется в разработке B2B-маркетплейса и какой функционал стоит включить в первую версию.

Сначала проверьте: у вас маркетплейс или корпоративный интернет-магазин

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

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

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

Корзина заканчивается, сделка только начинается

Розничный покупатель обычно действует от своего имени. В B2B пользователь действует от имени организации, филиала или подразделения. Система сначала определяет контекст сделки и только затем показывает доступный ассортимент, цены, адреса, способы оплаты и доставки.

Так устроены и готовые B2B-модули. В Shopify B2B каталог, цены, платёжные условия и оформление заказа настраиваются для компании или её подразделения. В Adobe Commerce B2B отдельными блоками идут аккаунты компаний, закрытые каталоги, быстрый заказ, закупочные заявки, согласования и запросы коммерческих предложений.

В первой версии мы оставляем только нужное и сначала описываем участников и их решения:

1. закупщик собирает заказ;
2. руководитель подтверждает сумму или категорию;
3. финансовый специалист проверяет лимит и условия оплаты;
4. поставщик подтверждает наличие и срок;
5. оператор площадки разбирает исключения.

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

Один SKU, три цены и отдельная упаковка для каждого договора

Публичной цены в B2B часто недостаточно. Стоимость зависит от договора, объёма, региона, валюты, категории покупателя и периода действия прайс-листа. Вместе с ней меняются минимальная партия, кратность упаковки, доступный ассортимент и условия доставки.

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

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

Есть и сделки без готовой цены. Покупатель отправляет запрос на коммерческое предложение, поставщики отвечают условиями, затем выбранный вариант превращается в заказ. Такой маршрут требует сроков действия предложения, версий, комментариев и истории изменений. Обычного поля «цена по запросу» здесь хватает примерно до первого файла КП_финал_точно_последний_v7.xlsx.

У кнопки «Заказать» появляется маршрут согласования

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

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

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

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

Счёт, отсрочка и две отгрузки растягивают оформление заказа

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

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

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

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

Поставщик получает отдельный продукт, а площадка — вторую воронку

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

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

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

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

Цена в витрине ничего не значит, если 1С думает иначе

Кабинет поставщика решает половину задачи — вторая половина в том, откуда система вообще берёт цену и остаток.

B2B-платформу обычно связывают с 1С, ERP для управления ресурсами, WMS для склада, CRM для клиентских данных, ЭДО для документов, банком и сервисами доставки. Состав зависит от процессов компании. До разработки нужно определить источник истины для каждой сущности: где создаётся товар, кто рассчитывает цену, какая система резервирует остаток, откуда приходит статус оплаты и где хранится подписанный документ.

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

Смежный пример из нашей практики — e-commerce-платформа HOTZ. В ней объединили четыре продуктовые линейки, построили сквозной каталог и связали интерфейс с 1С: цены, остатки, варианты фасовки и заказы опираются на данные учётной системы. У нас на сайте этот релиз описан как интернет-магазин, а B2B — как следующее направление развития платформы.

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

В первой версии нужен один сквозной заказ

Мы собираем B2B-маркетплейс вокруг одного приоритетного типа сделки: от авторизованного пользователя до подтверждения поставщиком и записи в учётной системе. Попытка сразу перенести в продукт все исключения отдела продаж растягивает запуск и мешает проверить ядро.

В первую версию обычно входят:

1. организации, пользователи и базовые роли;
2. один рабочий каталог с предложениями поставщиков;
3. подтверждённое правило цены и минимальной партии;
4. один маршрут согласования;
5. один сценарий счёта или оплаты;
6. заказ, статусы и передача в основную учётную систему;
7. кабинет оператора для ошибок и исключений.

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

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

Интернет-магазина достаточно, пока договор помещается в чек

Формат продукта можно выбрать по устройству сделки.

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

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

B2B-маркетплейс нужен при нескольких поставщиках и общих правилах для предложений, модерации, заказов, исполнения и расчётов.

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

Выбрать между интернет-магазином, B2B-порталом и маркетплейсом можно вместе с командой Qtim в направлении e-commerce и маркетплейсов. Разберём путь заказа, роли и интеграции, чтобы оценка учитывала реальный процесс сделки.