База знаний Практический материал

Что нужно предусмотреть в B2B-сайте до разработки: каталог, аудитории, заявки и интеграции

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

О материале
  1. Практическая статья
  2. Mercury RUS
  3. Обновлено: 10.08.2026

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


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


Каталог начинается не с
карточки товара


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


В B2B-магазине «Снабженец Юг» проект
связан с электронной коммерцией и большим ассортиментом. В href="/portfolio/155/">проекте НПО «ЗТМ» сайт был связан с задачей
автоматизации работы отдела продаж и интеграцией с 1С. Это разные
проекты, но вместе они показывают одну закономерность: продуктовая
структура сайта должна быть понятна не только посетителю, но и тем
процессам, которые стоят за публикацией и обработкой данных.


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


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


Аудитория — это не
абстрактный «пользователь»


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


В проекте официального дилера КАМАЗ
«Волготехснаб»
отдельно учитывалась специфика B2B-аудитории и
необходимость простого, понятного взаимодействия с сайтом. Это важный
ориентир: сложность бизнеса не должна автоматически превращаться в
сложность интерфейса.


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


Такая проверка даёт больше, чем абстрактная дискуссия о «современном
UX»: она связывает структуру сайта с конкретными действиями.


Заявка — это часть процесса
продаж


На B2B-сайте форма обратной связи важна не сама по себе. Важно, что
происходит после нажатия кнопки «Отправить».


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


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


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


Интеграцию нельзя
оставлять «на потом»


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


В проекте НПО «ЗТМ» сайт создавался в
связке с системой 1С и задачей автоматизации работы отдела продаж. Сам
факт такой связки означает, что веб-проект уже нельзя проектировать
только как набор экранов. Нужно заранее определить границу между данными
сайта и данными учётной системы.


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


Для отдельной темы интеграции сайта с 1С в Knowledge уже существует
материал href="/knowledge/integraciya-saita-s-1c-do-nachala-razrabotki/">«Интеграция
сайта с 1С: что нужно предусмотреть до начала разработки». В
B2B-проекте этот вопрос нужно рассматривать как часть более широкой
архитектуры: каталог, обращения и внутренние системы должны
проектироваться согласованно.


Сайт должен
иметь понятное место в бизнесе компании


Ещё один полезный ориентир даёт проект
завода «Аврора ЭЛМА»
, где сайт описывался как инструмент,
интегрированный в бизнес заказчика. Не следует расширять эту
формулировку до неподтверждённых технических деталей, но сам принцип
важен: веб-ресурс оценивается не только по тому, насколько он аккуратно
выглядит, а по тому, насколько понятна его функция в работе
компании.


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


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


Что зафиксировать до
интерфейсов


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



  • продуктовые направления и логика каталога;

  • основные пользовательские сценарии;

  • путь обращения от формы до ответственного сотрудника;

  • контекст, который должен сопровождать заявку;

  • внутренние системы, связанные с сайтом;

  • границы и источники данных;

  • приоритет первой версии и то, что можно развивать позже.


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


Главное


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


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