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