Нужен ли B2B-компании личный кабинет: какие задачи оправдывают разработку

1. Найдите операцию, которую действительно стоит упростить

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

В учебном примере за месяц получено 80 повторных заказов. Менеджер тратит на перенос позиций и сверку реквизитов в среднем 9 минут: 80 × 9 = 720 минут, или 12 часов. Это исходная нагрузка, а не обещанная экономия. Часть клиентов не перейдёт в кабинет, нестандартные заказы останутся у менеджера, а новые обращения по использованию интерфейса добавят работу.

Перед разработкой проверьте более простое решение: понятный шаблон заказа по артикулам или исправление обмена с учётной системой. Кабинет оправдан, когда повторяемая задача достаточно частая, клиенту удобен самостоятельный путь, а данные можно поддерживать актуальными. Все компании, числа и результаты в этой статье условные; это образец проектирования, не кейс ActiveLab.

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

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

В документации Shopify B2B компании, подразделения и контакты представлены разными сущностями, а каталоги задают доступные товары и цены. Это полезный пример разделения данных, но не рекомендация платформы и не утверждение, что любая CMS предоставляет такие возможности без доработки.

Документация: Shopify Help: компании, подразделения и контакты B2B; Shopify Help: каталоги и цены B2B;

3. Разделите пользователя, компанию и его полномочия

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

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

Документация: OWASP: проверка прав, минимальные привилегии и запрет по умолчанию;

4. Договоритесь, кто отвечает за цену и статус заказа

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

У каждой отправки есть устойчивый идентификатор. Если внешняя система не ответила вовремя, кабинет не должен автоматически создавать ещё один заказ: сначала нужно выяснить результат предыдущей операции или безопасно повторить её по согласованному правилу. Пользователь видит статус «передаётся» либо понятную ошибку; менеджер — необработанную очередь.

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

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

5. Зафиксируйте минимальную версию с критериями приёмки

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

Если таблица не помещается на экране, прокрутите её по горизонтали.

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

6. Проверьте пользу на пилоте и только потом расширяйте

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

Учебный результат за сопоставимый месяц: из 80 повторных заказов 30 прошли через кабинет. На обработку этих 30 до внедрения уходило 30 × 9 = 270 минут; после — 30 × 3 = 90 минут. На помощь пользователям потрачено ещё 60 минут. Чистое сокращение этой нагрузки: 270 − 90 − 60 = 120 минут, или 2 часа. Это не экономия всей зарплаты и не доказанная окупаемость разработки.

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