Разработка личного кабинета для B2B-клиентов: кейс модернизации портала

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

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

На первый взгляд решение очевидное: обновить дизайн и переписать фронтенд. Но в таких проектах проблема редко ограничивается интерфейсом.

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

Поэтому разработку личного кабинета начали с разбора процесса и данных.

Почему старый портал создавал работу вместо самообслуживания

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

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

У медленной работы может быть несколько причин:

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

И вот здесь начинается основная работа.

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

Без этого техническое задание быстро превращается в список страниц и кнопок. Для B2B-системы этого недостаточно.

Сначала клиентский сценарий, затем интерфейс

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

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

Поэтому проектирование начиналось не с макетов, а с вопросов:

1. Кто пользуется порталом?
2. Какой результат человек хочет получить?
3. Какие данные ему нужны для принятия решения?
4. Какая система является источником этих данных?
5. Может ли пользователь изменить информацию?
6. Кто должен увидеть изменение внутри компании?
7. Что произойдёт при ошибке или задержке?

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

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

Архитектура нового клиентского портала

Для проекта разработали современное веб-приложение на React и Node.js, связанное с внутренними источниками данных. Подтверждённый результат кейса — клиенты получают актуальную информацию в интерфейсе, а команда сокращает часть ручных обращений. Точные проценты и сроки проекта не раскрываются.

React в такой архитектуре отвечает за пользовательский интерфейс и состояние экранов. Node.js используется в серверной части, где находятся прикладная логика и взаимодействие с внутренними системами.

Но сам по себе выбор React или Node.js ничего не гарантирует.

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

Между ними нужен контролируемый интеграционный слой, который:

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

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

Технически это усложнение.

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

Что означает синхронизация данных в реальном времени

В описании проекта указана синхронизация в реальном времени. Но для бизнес-системы этот термин нужно превратить в конкретное требование.

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

Для разных сценариев подходят разные механизмы.

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

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

Поэтому требование «сделать всё в реальном времени» обычно вредно. Оно увеличивает сложность и стоимость эксплуатации, но не всегда даёт клиенту дополнительную ценность.

Рациональнее разделить данные на категории:

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

Последний пункт особенно важен. Иногда честная подпись «данные обновлены пять минут назад» полезнее, чем иллюзия абсолютной актуальности.

Как заменить старый портал без большого отключения

Полная замена системы за один запуск выглядит проще только на схеме.

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

В подобных ситуациях имеет смысл переносить систему по частям.

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

Такой подход подходит не всегда.

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

Скорость портала нужно измерять, а не обсуждать

Фраза «портал работает медленно» слишком неопределённа для технической задачи.

Нужно разделить скорость на несколько показателей:

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

Для пользовательской части можно ориентироваться на Core Web Vitals. Google относит к основным показателям скорость появления главного содержимого, отклик на действия и визуальную стабильность страницы. Рекомендуемые границы — LCP до 2,5 секунды, INP до 200 миллисекунд и CLS не выше 0,1 для 75-го процентиля загрузок.

Но у B2B-портала есть ещё один слой производительности.

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

Права доступа нельзя проверять только в интерфейсе

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

Скрыть кнопку или раздел в React недостаточно. Проверка прав должна происходить на сервере при каждом обращении к объекту.

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

Для проекта это означает, что модель доступа нужно проектировать вместе с бизнес-процессом:

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

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

Что нужно журналировать

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

Для этого система фиксирует:

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

Microsoft отдельно рекомендует предусматривать структурированные журналы, корреляционные идентификаторы, мониторинг задержек и контроль согласованности данных в интеграционном слое.

Логирование не делает систему надёжной само по себе. Оно сокращает время между ошибкой и пониманием её причины.

А это напрямую влияет на нагрузку команды.

Результат проекта

После модернизации клиенты получили новый портал на React и Node.js с актуальными данными из внутренних источников.

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

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

Для оценки подобных проектов стоит заранее собрать собственную базовую линию:

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

После запуска те же показатели сравниваются с исходным состоянием.

Когда индивидуальная разработка не нужна

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

Но не каждой компании нужен портал на React и Node.js.

Готового решения может быть достаточно, если:

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

Сначала нужно определить задачу. И только потом выбирать между готовым модулем, доработкой существующего кабинета и разработкой отдельного веб-приложения. Подробнее о выборе минимально достаточной архитектуры — в статье «Автоматизация с помощью ИИ: какие процессы ему поручать».

Вывод

Медленный клиентский портал редко исправляется одной заменой интерфейса.

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

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

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

Частые вопросы

Чем B2B-портал отличается от обычного личного кабинета?

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

Что нужно подготовить перед разработкой личного кабинета?

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

Обязательно ли использовать React и Node.js?

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

Нужно ли менять внутренние системы вместе с порталом?

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

Как понять, что новый портал работает лучше старого?

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