Как спроектировать B2B-портал, который выдержит реальные процессы

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

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

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

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

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

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

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

В первой версии подключите только критичный обмен. Остальные интеграции добавляйте, когда понятно, какую ручную работу они убирают и как проверять ошибку.

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

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

Разделите оценку на обязательный процесс, рабочую основу и развитие. Обязательный процесс должен пройти от заявки до результата. Рабочая основа включает доступы, статусы, журнал и обработку отказов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Особенно важны границы между организациями: фильтрация по tenant, проверка объекта на сервере и аудит доступа должны работать независимо от того, какой экран открыт пользователем.

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

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