Клиент открывает личный кабинет, видит «В обработке» и звонит менеджеру. Заказ давно собран, водитель назначен, но страница сообщает только одно состояние. Сам кабинет работает, однако человек по-прежнему ищет ответ по телефону.
Страница статуса заказа полезна, когда объясняет происходящее и следующий шаг. Для этого нужно договориться о названиях состояний, источнике данных и действиях при задержке. Дизайн помогает прочитать эту информацию, но не заменяет её.
Ниже разобран учебный пример поставщика офисной мебели. Он принимает заказы на сайте, собирает часть позиций со своего склада и заказывает остальные у производителя. Пример вымышленный, сроки используются для объяснения логики. Семь деталей страницы пригодятся и другим компаниям с несколькими этапами исполнения заказа.
1. Назовите состояние словами клиента
Сотрудники могут понимать код «Отбор завершён». Покупателю полезнее сообщение «Товары со склада собраны». Если часть мебели ещё едет от производителя, общее состояние заказа должно учитывать и её. Иначе страница обещает готовность, которую менеджер затем вынужден опровергать.
Составьте список реальных состояний вместе с человеком, который ведёт заказ. Возле каждого напишите условие перехода и объяснение для клиента. Например, «Заказ принят» означает, что заявка сохранена. «Состав подтверждён» появляется после проверки доступности всех позиций и согласования с покупателем.
Отдельно выделите ожидание действия клиента. Фраза «Нужно подтвердить замену стула» полезнее очередной надписи «В обработке». Рядом должны быть сама замена, причина и способ ответить. Пользователю не придётся выяснять по телефону, чего ждёт компания.
Слишком подробная шкала тоже мешает. Внутренние перемещения между зонами склада можно оставить сотрудникам, если они ничего не меняют для покупателя. Показывайте этапы, от которых зависят ожидания, сроки или действия человека.
На обсуждение возьмите несколько законченных заказов и восстановите их путь по документам. Это поможет найти состояния, которые команда пропустила в идеальной схеме. Возврат на предыдущий этап, замена позиции и частичная отгрузка заслуживают отдельного решения ещё до отрисовки страницы.
2. Разделите заказ и отдельные позиции
В учебном заказе четыре стола есть на складе, а шесть кресел изготовят позже. Единственная общая дата скрывает эту разницу. Клиенту нужно понимать, можно ли получить столы отдельно и изменится ли стоимость доставки.
Покажите состояние каждой группы товаров, если компания действительно умеет отгружать их раздельно. Возле группы укажите ожидаемое событие и доступное действие. Например, покупатель может согласовать частичную доставку или сохранить общий выезд после поступления кресел.
При этом заказу всё равно нужен общий итог. Сообщение «Часть заказа готова к отправке» связывает отдельные позиции с общей картиной. Оно должно открывать подробности. Посетителю будет проще понять ситуацию без сравнения всех строк таблицы.
Если компания отправляет только полный комплект, скажите это до оформления заказа и повторите в кабинете. Тогда готовые позиции не создадут ложного ожидания скорой доставки. Условия частичной отгрузки относятся к бизнес-процессу: разработчик не должен придумывать их по ходу работы над экраном.
Такая связь интерфейса с фактической операцией обсуждается и в материале о заказной разработке для работы с клиентами. Для кабинета полезно начать с одной повторяющейся ситуации, например с заказов, где товары поступают в разные дни.
3. Объясните, когда обновились данные
Увидев статус, клиент предполагает, что он актуален. Но кабинет может получать сведения из учётной системы по расписанию. Если обмен задержался, внешне страница остаётся исправной: фотографии и кнопки открываются, старый статус выглядит убедительно.
Храните время последнего успешного обновления данных заказа. Его можно показать рядом с состоянием, особенно когда задержка превышает согласованный срок. Текст должен описывать фактическую ситуацию, например «Данные заказа обновлены сегодня в 10:20 по Москве».
Часовой пояс нужен там, где клиенты и сотрудники находятся в разных регионах. Простое «10:20» оставляет место для ошибки. Для сроков доставки уточняйте, чьё местное время имеется в виду: адреса получения или офиса поставщика.
Заранее установите правило устаревания. В учебной схеме команда может решить, что после двух неудачных циклов обмена страница показывает предупреждение и способ уточнить данные. Конкретный порог выбирают по обещанной частоте обновления и характеру операции. Для срочной доставки и заказной мебели эти требования различаются.
Разобраться в источниках задержки поможет материал о сбоях обмена между 1С и сайтом. В кабинете важно отделить отсутствие изменений от отсутствия свежих данных. Эти ситуации могут выглядеть одинаково в базе, но требуют разного сообщения клиенту.
4. Дайте каждой дате понятный смысл
«Доставка 20 октября» звучит как обещание. Если сотрудник ввёл предварительную оценку, страница должна так её и назвать. Иначе клиент распланирует рабочий день, а менеджеру придётся объяснять внутренние оговорки.
В учебном заказе можно использовать несколько дат: ожидаемое поступление кресел, подтверждённый день отгрузки и согласованный интервал доставки. Не складывайте их в одну колонку «Срок». Возле каждой даты укажите событие, к которому она относится.
Изменение даты тоже нуждается в объяснении. Достаточно короткой причины, времени изменения и следующего действия. Например, «Производитель перенёс поступление кресел. Менеджер согласует новую дату доставки до конца рабочего дня». Такое сообщение допустимо, если команда действительно приняла эту обязанность.
Историю изменений храните отдельно от текущего состояния. Она пригодится при обращении в поддержку и поможет сотруднику восстановить разговор. Клиенту можно показывать существенные изменения, не перегружая экран каждым внутренним пересчётом.
Если сайт пока не получает причины переноса, начните с ручного заполнения ответственным менеджером. Для разработки личного кабинета необязательно сразу автоматизировать каждую операцию. Важнее определить, кто отвечает за поле и когда обязан его обновить. Пустой автоматический блок не даёт посетителю нужной информации.
5. Покажите доступное действие рядом с проблемой
Кнопка «Связаться с нами» в подвале сайта помогает мало, когда клиенту нужно подтвердить замену товара. Разместите действие там, где возник вопрос. Возле замены подойдет кнопка подтверждения или отправки замечания, возле адреса доставки нужна возможность исправить его по правилам компании.
Не давайте менять сведения, которые уже ушли в исполнение, без явной обработки запроса. Если машина выехала, новый адрес должен пройти согласование. Интерфейс может принять просьбу и показать её состояние, пока сотрудник оценивает возможность изменения.
Для каждого действия запишите ожидаемый результат. Нажатие «Подтвердить замену» должно создать проверяемую запись с автором и временем. После успешного сохранения клиент видит подтверждение. При ошибке форма объясняет, что произошло с запросом и как его повторить.
Особенно внимательно проверяйте повторные нажатия. На слабой связи человек может нажать кнопку несколько раз. Одна просьба не должна превращаться в несколько разных задач менеджеру. Это требование относится к обработке запроса на сервере. Внешнего изменения кнопки для этого недостаточно.
Если сайт отдаёт такие события другой системе, заранее согласуйте правила доставки. В статье о собственных вебхуках для партнёров объясняется сам подход к передаче событий. В кабинете конечный критерий простой: сотрудник должен найти то действие, которое клиент только что совершил.
6. Сохраните контекст обращения
Когда клиент всё же пишет в поддержку, сотруднику нужны номер заказа и текущая проблема. Подставляйте номер автоматически в форму обращения со страницы заказа. Человеку останется описать обстоятельства и при необходимости приложить файл.
При этом нельзя полагаться только на номер, переданный браузером. Сервер должен проверить, что заказ принадлежит вошедшему пользователю или его организации. Иначе подмена значения в запросе способна открыть доступ к чужой информации.
У компании-клиента могут быть разные сотрудники. Закупщик оформил мебель, бухгалтер проверяет оплату, администратор согласует доставку. До разработки определите, кто имеет право видеть документы и менять адрес. Общая ссылка на заказ не заменяет правила доступа.
Сотруднику поддержки полезно видеть последнее обновление, историю важных действий и незавершённый запрос. Тогда он продолжит разговор с того места, где остановился клиент. Просьба повторно прислать уже загруженный документ раздражает сильнее, чем сама задержка заказа.
Для вложений договоритесь о допустимых форматах, размере и сроке хранения. Эти условия зависят от вашей системы и политики компании. Покажите их возле поля загрузки, чтобы пользователь узнал ограничение до попытки отправить файл.
Согласуйте ручное исправление статуса
Менеджер иногда знает о заказе больше, чем система успела получить. Например, производитель подтвердил готовность по телефону, но документ поступит вечером. Решите, может ли сотрудник добавить комментарий и кто проверит его актуальность. Сам статус, который управляет отгрузкой, стоит менять только по согласованному правилу.
У ручного комментария полезно хранить автора, время и срок действия. Сообщение «Уточним поступление завтра» быстро устаревает. Если оно осталось на странице через неделю, клиент увидит обещание, которое команда уже забыла. Назначьте сотрудника, который просматривает незакрытые обещания, и сделайте их доступными в рабочем списке.
Когда автоматический обмен восстановится, проверьте совместимость ручного текста с новым состоянием. Комментарий об ожидании производителя должен исчезнуть или попасть в историю после поступления товара. Такие правила можно проверить на тестовом заказе: сначала остановить обновление, затем добавить пояснение и возобновить обмен.
7. Проверьте страницу на неудобных заказах
Проверка одного успешно завершённого заказа не покажет слабые места. Подготовьте набор ситуаций, которые менеджеры встречают в работе. Каждая ситуация должна иметь ожидаемый текст и допустимые действия.
| Ситуация |
Что проверяет команда |
| Одна позиция задержана |
Общий статус объясняет частичную готовность |
| Срок ещё не подтверждён |
Страница явно называет дату предварительной |
| Обмен остановился |
Клиент видит, что сведения могут быть устаревшими |
| Клиент подтвердил замену дважды |
В системе осталось одно согласованное действие |
| Заказ другой организации |
Пользователь не получает его данные |
| Адрес меняют после отправки |
Просьба проходит согласование |
Проверяйте сценарии вместе с сотрудником, который отвечает за исполнение. Он заметит неверный переход состояния, даже если разработчик считает техническую часть законченной. Маркетолог оценит понятность текста, но не всегда знает, в какой момент склад может изменить состав отправки.
После запуска соберите обращения по конкретным страницам заказа. Если люди продолжают спрашивать о готовности, изучите несколько примеров целиком. Возможно, статус написан ясно, но обновляется слишком поздно. Или срок доступен только внутри закрытой вкладки.
Для оценки эффекта сравнивайте сопоставимые периоды и типы заказов. Сезонный рост обращений может скрыть улучшение страницы, а изменение состава клиентов способно дать обратную картину. Считайте вопросы по теме статуса и отмечайте, какую информацию человеку пришлось уточнять.
Начните проект с таблицы состояний и пяти реальных обезличенных заказов. По ним можно спроектировать первый экран и проверить логику до подключения всех источников. Команда Feature IT поможет разработать кабинет, связать его с вашей системой учёта и подготовить сценарии приёмки вместе с сотрудниками.
Читайте также
