Граница запуска
Нужно явно разделить публичный MVP, закрытый B2B-контур и развитие. Публичный MVP отвечает за бренд, каталог, поиск, заявки и аналитику. B2B-контур отвечает за регистрацию, роли, персональные условия и подготовку заказа.
Как снизить риск разработки B2B-сайта: сначала спроектировать каталог, роли, заявки, CRM, 1С и границы первого запуска.
Когда компания запускает новый B2B-канал, сайт с каталогом редко бывает просто сайтом.
Внутри задачи быстро появляются товарные данные, роли пользователей, закрытые цены, заявки, CRM, 1С, документы, статусы наличия и будущий личный кабинет.
Если сразу уйти в разработку экранов, команда почти неизбежно начнет принимать архитектурные решения по ходу проекта.
Это повышает риск переделок, срыва сроков и конфликта ожиданий между маркетингом, продажами, ИТ и операционным контуром.
У публичного сайта цель обычно понятна: объяснить предложение, собрать лид, дать контакты. У B2B-сайта с каталогом цель шире.
Пользователь должен найти товар, подобрать совместимые позиции, получить документы, сформировать запрос, а менеджер - получить структурированную заявку, которую можно обработать в CRM и дальше связать с учетной системой.
Проблема начинается там, где каталог становится базой данных.
Если в карточках нет единой модели характеристик, фильтры быстро превращаются в ручной список.
Если не описана совместимость товаров, менеджеры продолжают проверять комплектность в переписке.
Если закрытые цены и статусы наличия не привязаны к источнику данных, личный кабинет остается красивой оболочкой без операционной ценности.
До
После
Нужно явно разделить публичный MVP, закрытый B2B-контур и развитие. Публичный MVP отвечает за бренд, каталог, поиск, заявки и аналитику. B2B-контур отвечает за регистрацию, роли, персональные условия и подготовку заказа.
Для ассортимента нужны категории, характеристики, документы, совместимые товары, статусы, правила показа и связи с внутренними справочниками. Это фундамент фильтров, поиска, сравнения и будущих интеграций.
Заявка должна быть пригодна для обработки: с обязательными полями, источником, составом подборки, комментарием, файлами при необходимости и понятным маршрутом в CRM.
До разработки нужно понять, что является источником цен, статусов, документов и клиентских условий. Для 1С, CRM и сайта надо описать направления обмена, обязательные поля, частоту обновления, ошибки и резервный сценарий.
Кто пользуется сайтом, какие решения принимает, какие данные ожидает увидеть и какое действие должен совершить: запросить КП, собрать подборку, зарегистрироваться, отправить сервисное обращение.
Категории, характеристики, документы, правила совместимости, источники данных и качество текущих справочников. Здесь становится видно, какие фильтры реальны, а какие пока нечем наполнить.
Какие поля обязательны, как модерируется B2B-доступ, где показываются персональные условия, как быстро ввести товары по артикулам и что попадает менеджеру.
CRM, 1С или ERP, сайт и аналитика должны иметь понятные направления передачи данных, статусы, ошибки, повторную отправку и ответственных за поддержку.
Ключевые экраны и план разработки нужны не для красоты, а для проверки логики: сможет ли пользователь решить задачу, а бизнес - обработать результат.
| Система / слой | Зона ответственности |
|---|---|
| Scope запуска | Утвержденные границы MVP, B2B-контура и развития; список функций, которые сознательно не входят в первый релиз. |
| Модель каталога | Категории, поля товара, документы, совместимость, правила фильтров, статусы и источник каждого типа данных. |
| UX-прототипы | Категория, карточка, подборка, запрос КП, регистрация, личный кабинет и сервисные сценарии. |
| Интеграционное ТЗ | CRM, 1С или ERP, направления обмена, обязательные поля, ошибки, повторная отправка, резервный маршрут и логирование. |
| План разработки | Этапы, зависимости, риски, критерии приемки и оценка следующего этапа. |
Команда знает, какие товары продает, но не знает, какие поля обязательны для фильтров, сравнения, документов и совместимости.
В MVP пытаются включить портал, CRM, 1С, статусы, документы и аналитику без проверки готовности данных и внутренних владельцев.
Разработка сайта идет быстрее, чем согласование обмена с CRM и 1С. В итоге проект упирается в переделку полей, статусов и ошибок.
Подрядчик не может за бизнес решить, кто отвечает за товарные данные, цены, статусы, документы и обязательные поля заявок.