Первая версия B2B-кабинета должна закрывать несколько частых задач клиента: увидеть статус работ, получить нужный документ или передать запрос. Состав функций выбирают по реальным обращениям и доступности данных. Роли, разделение компаний и понятные ошибки входят в проектирование вместе с основными экранами.
Если клиенту всё равно приходится писать менеджеру после каждого посещения кабинета, сценарий остаётся незавершённым. Поэтому полезно начинать с обращения, которое вы хотите снять с поддержки, и пройти весь путь до ответа.
Список вопросов важнее списка экранов
Соберите обращения за выбранный период и отметьте тему, частоту, затраченное время и причину ручного ответа. Частые вопросы могут касаться одного и того же объекта: заказа, договора, документа или обращения.
Условный пример: клиенты спрашивают, готов ли заказ. Перед созданием экрана проверьте, где хранится статус и когда он обновляется. Если менеджер узнаёт его вручную по телефону, кабинет потребует работы с внутренним процессом.
Для первого запуска выберите задачи, у которых есть понятный источник данных и завершение. GOV.UK рекомендует на ранней стадии проверять рискованные предположения и использовать исследование потребностей пользователей. Это метод разработки сервисов, который можно адаптировать к B2B-проекту. GOV.UK: alpha phase.
Матрица первого запуска
Оценки ниже условные. Сложность зависит от интеграций, качества данных и существующих правил доступа.
| Функция | Польза клиенту | Зависимость | Относительная сложность |
|---|---|---|---|
| Статус заказа | Понять текущий этап | Актуальный статус в системе | Низкая при готовом источнике |
| Документы по заказу | Самостоятельно получить файл | Версии и права доступа | Средняя |
| Новое обращение | Передать задачу без переписки по адресам | Очередь и ответственный | Средняя |
| Уведомление об изменении | Узнать о следующем шаге | Надёжные события и канал | Средняя |
| Сложная аналитика | Изучить показатели | Проверенная методика и данные | Высокая |
| Совместное редактирование условий | Согласовать изменения | Версии, роли, история | Высокая |
После таблицы напишите, какие функции входят в запуск и что станет доказательством их пользы. Например, клиент самостоятельно получает действующий документ и видит его принадлежность к нужному заказу.
Функция без проверяемого результата требует уточнения. «Удобная история сотрудничества» нужно разложить на конкретные записи, фильтры и действия.
Отделите компанию от пользователя
В одной компании кабинет могут использовать закупщик, бухгалтер и руководитель. У них различаются задачи и доступ. Человек также может работать с несколькими юридическими лицами или подразделениями.
Microsoft описывает многоклиентскую архитектуру через отдельные организации, внутри которых могут находиться несколько пользователей. Такой клиент системы отличается от пользователя. Microsoft: multitenant architecture.
Из этого следует проектное решение: явно связать пользователя с организацией и ролью. При смене компании в интерфейсе следует показывать, чьи объекты открыты. Для сотрудника поддержки отдельно задают пределы доступа к данным клиентов.
Условный набор ролей: просмотр статусов, работа с документами, создание обращений, управление пользователями компании. Право приглашать коллег нужно рассматривать отдельно от чтения заказа.
Доступ проверяют на каждом объекте
Скрытая кнопка не подтверждает защиту данных. Сервер должен проверять разрешение пользователя при открытии заказа, скачивании файла и изменении записи.
OWASP рекомендует проверять права на каждом запросе и учитывать доступ к конкретному объекту. OWASP Authorization. Для кабинета рекомендуем включить проверку чужого заказа и чужого файла в приёмочные сценарии.
Отдельно проверьте ссылки на документы. Ссылка, пересланная другому человеку, не должна неожиданно расширять круг читателей. Если выбран доступ по временной ссылке, обсудите срок, правила выдачи и последствия её распространения.
Техническая роль доступа и юридическое основание обработки данных решаются в разных плоскостях. До подключения реальных записей проверьте состав сведений, цель и условия работы участников проекта.
Статус должен объяснять следующий шаг
«В обработке» может скрывать несколько дней разных работ. Полезный статус отвечает на вопросы: что произошло, когда сведения обновлены, какое действие требуется от клиента и куда обратиться при задержке.
Не показывайте обещанный срок, если источник не даёт надёжного основания. В таком случае можно показывать текущий этап и возможность уточнения. Если данные из внешней системы временно недоступны, сохраните последний известный статус с отметкой времени и объясните ограничение.
Для документов различайте действующую версию, архив и черновик. Подпись «обновлено сегодня» может относиться к загрузке файла, хотя содержание согласовано раньше. Определите смысл каждого поля до разработки интерфейса.
Уведомления и поддержка
Уведомление должно вести к конкретному событию и объекту. Проверяйте, что оно отправлено нужному получателю, открывает правильную компанию и не дублируется при повторе события.
Отделите сообщения по текущему обслуживанию от иных рассылок. Содержание и условия коммуникации следует оценить для выбранного процесса; наличие аккаунта не используйте как универсальное объяснение любых сообщений.
В кабинете нужен путь к человеку при ошибке или неполном статусе. Передавайте в обращение номер объекта и технический идентификатор события. Клиенту не придётся пересказывать всю историю, сотруднику будет проще найти проблему.
Какие показатели смотреть после пилота
Измеряйте долю клиентов, завершивших выбранную задачу, и число обращений по той же теме. Учитывайте размер клиентской базы, изменения продукта и период наблюдения. Простое сокращение писем ещё не доказывает пользу кабинета: клиенты могли реже заказывать.
Полезно отдельно смотреть ошибки входа, недоступные документы, устаревшие статусы и брошенные формы. Эти показатели помогают выбрать следующую доработку.
К первому запуску должны быть готовы несколько законченных клиентских сценариев с работающими данными и доступами. Новые функции добавляют по обратной связи и измерениям. Так кабинет развивается вокруг задач клиента, сохраняя управляемый объём проекта.
Источники
- GOV.UK Service Manual: исследование потребностей и проверка рискованных предположений.
- Microsoft Multitenancy: различие организации и пользователей.
- OWASP Authorization: проверка доступа к конкретным объектам. Матрица функций и показатели предложены редакцией.