B2B-портал для оптовых продаж: SaaS или собственная разработка

Почему B2B-портал стал частью продаж, а не вспомогательным сайтом

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

В исследовании McKinsey Global B2B Pulse 2026 говорится, что B2B-покупатели используют в среднем десять каналов на пути к покупке, а электронная коммерция уже есть у 71% опрошенных компаний. Gartner сообщает, что 61% опрошенных B2B-покупателей предпочитают общий путь без участия продавца, но обращаются к специалисту там, где нужно понять применимость решения к конкретной компании. Практический вывод прост: повторный заказ лучше отдавать self-service, а экспертизу менеджера сохранять для решений, где она действительно влияет на выбор.

Что именно автоматизирует портал для оптовых продаж

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

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

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

Когда выбирать готовый SaaS B2B-портал

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

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

• процессы близки к типовым и не являются конкурентным преимуществом;
• нужен быстрый MVP без формирования собственной продуктовой команды;
• достаточно доступных API, вебхуков или штатного обмена с 1С;
• компания принимает ограничения тарифов, roadmap и модели хранения данных;
• провайдер заранее описывает SLA, экспорт данных, резервное копирование и условия выхода.

Когда собственная разработка экономически оправдана

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

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

Гибридная модель: готовое ядро и собственный продуктовый слой

Между SaaS и полностью собственной системой есть гибрид. Компания может оставить в готовом решении каталог, авторизацию или базовый заказ, а собственными сделать интеграционный слой, мобильный интерфейс, аналитику, роли или отраслевые модули. Это снижает объём разработки, но создаёт зависимость между двумя roadmap и двумя зонами поддержки.

Гибрид работает, если граница проведена по данным и ответственности: известно, какая система является источником правды, кто обрабатывает сбой, как тестируются обновления SaaS и что произойдёт при смене провайдера. Без этого гибрид превращается в набор труднообъяснимых исключений.

SaaS, собственный или гибридный портал: матрица выбора

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

Интеграция с 1С: сначала определить владельцев данных

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

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

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

Что включить в MVP, чтобы клиенты действительно начали пользоваться порталом

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

Функции второй очереди выбираются по данным после запуска. Рекомендации товаров нужны, если портал уже получает качественную историю покупок. Сложная аналитика оправдана, если показатели ведут к управленческому действию. AI-помощник не компенсирует неточные остатки или непонятный процесс согласования.

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

Как портал влияет на выручку — и какие показатели измерять

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

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

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

Как считать совокупную стоимость и окупаемость

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

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

Безопасность SaaS: ответственность не передаётся провайдеру целиком

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

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

Как внедрять: от диагностики до перевода клиентов

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

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

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

Практический пример: почему для DWG Platform понадобился собственный продукт

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

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

Чек-лист перед выбором решения

Если на вопросы ниже нет ответов, сравнивать тарифы и сметы рано. Сначала проведите короткую диагностику вместе с продажами, операционной командой, IT и несколькими реальными клиентами. Так список функций превратится в проверяемый продуктовый запрос.

• какой один процесс должен стать быстрее или дешевле;
• какие клиенты и роли будут работать в портале;
• какие данные они должны видеть и кто ими владеет;
• какие правила нельзя адаптировать под стандартный SaaS;
• какие API, экспорт, SLA и условия выхода обязательны;
• какие показатели фиксируются до запуска;
• кто отвечает за поддержку, обучение и развитие после релиза.