Клиент просит прислать документ, уточняет статус заказа и снова ищет номер менеджера. Если такие задачи повторяются, их можно перенести в личный кабинет. Но форма регистрации сама по себе не делает обслуживание удобнее. Человеку нужен понятный ответ и возможность закончить дело.
В Гуси-Лебеди мы предлагаем проектировать кабинет от повседневных действий клиента: что он хочет проверить, получить или изменить. Разберём функции, права доступа, вход, интеграции и порядок проверки. Примеры ниже условные: состав кабинета нужно согласовать под процессы вашей компании.
Зачем нужен личный кабинет на сайте
Личный кабинет представляет собой персональную часть сайта, где пользователь работает со своими данными и доступными ему действиями. Это может быть история заказов, документы, обращения, обучение или управление услугой. Главное отличие от публичной страницы: содержание связано с конкретной учётной записью и её полномочиями.
Чтобы понять, нужен ли кабинет, соберите повторяющиеся вопросы клиентов. Для каждого запишите, где находится ответ и кто сейчас его предоставляет. Если сведения приходится вручную искать в нескольких системах, сначала потребуется договориться об источниках данных. Красивый интерфейс не устранит противоречия между складом и CRM.
Не закрывайте входом действие, которому не требуется персональный доступ. Посмотреть описание услуги или скачать общую инструкцию обычно можно на публичной странице. Регистрация оправдана, когда помогает сохранять историю, работать с закрытыми документами или выполнять действия от имени пользователя.
Пользу кабинета оцените после запуска: удаётся ли получить документ, найти заказ и решить вопрос без повторной переписки. Число зарегистрированных аккаунтов не показывает, насколько удобным получился сервис. Обещать снижение нагрузки на поддержку до измерения было бы преждевременно.
Какие функции включить в первую версию
Начните со сценариев, которые имеют понятное завершение. Формулировка «добавить документы» слишком общая. Лучше: «пользователь находит документ по заказу и скачивает нужную версию». В такой задаче уже видны поиск, связи с заказом, актуальность файла и ограничения доступа.
| Сценарий | Что требуется | Как проверить результат |
|---|---|---|
| Узнать статус заказа | Состав, состояние и время обновления | Клиент понимает, что происходит и что делать дальше |
| Получить документ | Поиск, связь с заказом, доступ к файлу | Нужная версия скачивается для разрешённого пользователя |
| Повторить покупку | История и текущие условия | Новый состав проверяется по актуальному ассортименту |
| Создать обращение | Тема, описание и подтверждение сохранения | Обращение доступно для дальнейшего отслеживания |
Не копируйте прошлый заказ в новый без проверки. Товар может стать недоступным, цена и условия могут измениться. Покажите отличия до подтверждения действия. Аналогично, сохранённые реквизиты должны иметь понятный порядок изменения и согласования.
Оформите сценарии в техническом задании на сайт, затем проверьте их на прототипе интерфейса. На этом этапе полезнее пройти задачу от начала до конца, чем обсуждать цвет каждого элемента. Готовый модуль тоже проверяют по сценариям: какие функции он покрывает, где потребуется доработка и кто будет её сопровождать.
Как разделить пользователей, компании и права
В B2B-кабинете учётная запись человека и организация не всегда совпадают. У компании могут быть закупщик, бухгалтер и администратор, а один сотрудник может представлять несколько организаций. Если такая модель нужна вашему бизнесу, опишите членство в компании отдельно от входа пользователя.
Для каждого действия укажите область данных: свои заказы, заказы своей компании или назначенные обращения. Правило «пользователь видит документы» неполно. Нужно уточнить, какие документы и при каких условиях. Удобно составить матрицу до разработки личного кабинета.
| Действие в условном B2B-кабинете | Закупщик | Бухгалтер | Администратор компании |
|---|---|---|---|
| Просмотр заказов своей компании | Да | Да | Да |
| Получение финансовых документов | По отдельному правилу | Да | По отдельному правилу |
| Приглашение сотрудников | Нет | Нет | В свою компанию |
| Доступ к другой организации | Нет | Нет | Нет |
Вход в аккаунт и разрешение на действие являются разными проверками. Ограничения должны действовать на сервере при каждом запросе, включая выдачу файла. Скрытая кнопка или непредсказуемый адрес не заменяют контроль доступа. Принципы минимальных полномочий и запрета по умолчанию описаны в рекомендациях OWASP по авторизации.
Согласуйте жизненный цикл доступа: приглашение, смену роли, увольнение сотрудника и передачу управления. Продумайте, что произойдёт с открытой сессией после отзыва полномочий. Эти правила должны распространяться и на поиск, выгрузки и фоновые операции.
Как сделать вход и восстановление доступа понятными
Выберите механизм входа с учётом аудитории и требований проекта: пароль, одноразовый код или корпоративную систему авторизации. Не стоит выбирать его только по числу полей на экране. Проверьте доставку сообщений, повторные попытки и действия пользователя при потере доступа к почте или телефону.
Восстановление пароля требует отдельного сценария. OWASP рекомендует одинаковое сообщение для существующего и неизвестного аккаунта, защиту от чрезмерных запросов и одноразовые коды или токены с ограниченным сроком. После смены пароля необходимо определить правила для действующих сессий. Подробнее: рекомендации по восстановлению пароля.
Сообщение об ошибке должно помогать действовать: повторить отправку после указанного ожидания, проверить контакт или обратиться в поддержку. Внутренний ответ API и техническая трассировка не подходят для этого. Специалисту поддержки можно передать номер события, по которому он найдёт диагностику.
При приглашении в организацию покажите, куда человек присоединяется и какую роль получает. Предусмотрите истечение срока приглашения и его отзыв. Не просите клиента передавать пароль менеджеру для проверки проблемы: для помощи нужны отдельные полномочия и учёт действий.
Как связать кабинет с CRM, заказами и документами
Определите источник каждого поля: статус заказа из учётной системы, обращение из сервиса поддержки, документ из согласованного хранилища. Укажите идентификаторы связи и правила обновления. Кабинет должен объяснять состояние данных, включая задержку получения ответа.
При проектировании API-интеграций предусмотрите неудачный запрос, повтор и частичное выполнение. Если обращение сохранено, повторное нажатие не должно бесконтрольно создавать ещё одно. Если внешний сервис недоступен, сохранённую историю и ошибку обновления следует показывать как разные состояния.
Для заказа различайте создание, оплату, сборку и доставку, если эти этапы есть в процессе. «Запрос принят» не означает «оплата подтверждена», а «документ готовится» не означает «файл доступен». Согласуйте, какие события меняют статус и кто отвечает за разбор расхождений.
При передаче данных сайта в CRM проверяйте результат в обеих системах. Сохранение формы на сайте ещё не подтверждает появление нужной записи у сотрудника. Для приёмки нужны тестовые данные, ожидаемое состояние и возможность найти операцию в журнале.
Как проверить кабинет и оценить работу после запуска
Во время проектирования интерфейса предусмотрите пустую историю, загрузку, ошибку и готовые данные. У нового клиента ещё нет заказов, а у другого временно не загрузился список. Сообщение «Ничего не найдено» не должно скрывать разницу между этими ситуациями.
Сохраняйте введённые данные при исправимой ошибке. После долгой операции покажите её состояние и объясните следующий шаг. На телефоне человек должен пройти задачу целиком: открыть заказ, найти действие, получить результат и вернуться к списку.
- Проверьте основные сценарии обычным аккаунтом, а не только администратором.
- В согласованном тестовом окружении используйте две организации с разными заказами и файлами, проверьте разделение данных.
- Проверьте отзыв роли, истёкшее приглашение, восстановление доступа и повторную отправку.
- Проверьте прямое открытие документов, поиск и выгрузки в рамках разрешённой области.
- Пройдите ключевые действия на телефоне и с клавиатуры, включая сообщения об ошибках.
После запуска отслеживайте завершённые сценарии, ошибки, повторные попытки и причины обращений в поддержку. Спрашивайте клиентов, что мешает закончить действие. Если люди часто открывают страницу статуса, это может означать интерес к заказу или непонятное описание. Одного счётчика просмотров недостаточно, чтобы выбрать причину.
Первая версия хороша, когда решает согласованные задачи и её можно сопровождать. Мы предлагаем расширять кабинет после проверки: добавлять функции, которые нужны клиентам, и исправлять препятствия, обнаруженные в реальном использовании.