Личный кабинет для клиентов: как показывать статус заказа

Клиенту редко помогает название вроде «Этап 4.2». Ему нужно понять, принят ли запрос, согласован ли документ и кто должен ответить следующим. Личный кабинет клиента должен отвечать на эти вопросы и показывать нужные ему сведения.

Какие статусы заказов видит клиент

Для условной проектной услуги можно показать «Запрос принят», «Согласуем детали», «В работе», «Ждём вашего решения» и «Готово». Названия зависят от реального порядка работы. Если услуга не предполагает доставку, не стоит добавлять этап отправки только ради привычного шаблона.

Каждому этапу нужны пояснение и ответственное действие. Например, «Ждём вашего решения» сопровождается актуальным файлом и возможностью оставить комментарий. Если для продолжения нужен ответ сотрудника, экран не должен намекать, что задержка зависит от клиента.

Срок показывают только тогда, когда компания следит за его актуальностью. Если договорённость изменилась, прежняя дата остаётся в истории, а новая появляется с пометкой.

Что ещё разместить рядом со статусом

Состав небольшой карточки может быть таким:

• номер и название заказа или обращения;
• текущий этап с коротким объяснением;
• дата последнего обновления;
• следующий шаг и его участник;
• актуальные документы;
• способ задать вопрос по этой работе.

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

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

Откуда поступает обновление

Первую версию можно вести вручную: сотрудник меняет клиентский статус в своём интерфейсе. Это рабочий вариант, если ответственный назначен и команда справляется с объёмом обращений.

При подключении CRM нужно описать соответствие этапов. Один внутренний статус может нести несколько разных смыслов для клиента. Иногда несколько стадий CRM объединяют в один понятный внешний этап.

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

Как проверить доступы

Создайте два тестовых клиента и несколько заказов. Каждый должен видеть только связанные с ним записи и разрешённые файлы. Проверьте прямые ссылки на карточку и документ после выхода из аккаунта.

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

ИИ помогает объяснить статус, если факты уже собраны

В кабинете можно предложить сотруднику черновик ответа на вопрос клиента «почему сдвинулся срок?». На вход помощнику передаются только разрешённые события этого заказа: утверждённые даты, запросы согласования и опубликованные комментарии. На выходе получается короткое объяснение со ссылками на эти события. Менеджер проверяет его перед публикацией.

Если в истории нет причины переноса, ответ должен сообщать, что причина уточняется. Фраза «задержка из‑за поставщика» не становится допустимой только потому, что она правдоподобна. Внутреннюю переписку, закупочные цены и чужие заказы в такой сценарий не включают.

Для поиска по разрешённым материалам существуют готовые инструменты, например File Search в Yandex AI Studio. Разграничение клиентов и перечень доступных сведений проектируют отдельно.

Пример приёмки кабинета

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

Теперь отключите обмен. На экране остаются последние полученные сведения с отметкой об их актуальности; обещание «данные в реальном времени» не показывается. После восстановления изменения доходят без повторного запроса от клиента.

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

Как измерять пользу

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

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

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

Смежные разборы: Обмен данными между системами: как не терять заявки при сбоях; Сопровождение автоматизации: что нужно после запуска.