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