Мобильные приложения / Блог ontech.pro
Статусы заказа в приложении: что они должны означать для клиента
Статус нужен клиенту, чтобы решить, ждать ли подтверждения, ехать ли за заказом или обратиться в поддержку. Внутренние названия этапов отдела продаж редко отвечают на эти вопросы. Проектировать статусы стоит от наблюдаемого события и обещания, которое оно создаёт.
Подготовила команда ontech.pro · · 3 мин чтенияОпишите значение каждого этапа
Для каждого названия запишите, что уже произошло, чего ждать дальше и требуется ли действие клиента. «Получен» означает доставку заявки, «подтверждён» — готовность бизнеса её выполнить на согласованных условиях. Если эти события не разделены, человек может приехать по заявке, которую никто не принял. Избегайте названий вроде «в процессе», когда за ними скрываются разные ситуации. Количество статусов выбирают по их пользе для клиента, а не по числу внутренних подразделений.
Назначьте источник изменения
Статус может приходить из учётной системы, отмечаться сотрудником или вычисляться по событию оплаты. Для каждого перехода должен быть один понятный порядок. Не разрешайте приложению считать заказ готовым только потому, что истекло расчётное время. Временной прогноз и фактическая готовность — разные сведения. Если сотрудник меняет состояние вручную, ему нужно видеть условия перехода и последствия для уведомлений. Ошибка на рабочем экране не должна автоматически отправлять клиенту необратимое обещание.
Покажите время и неопределённость
Если этап требует согласования замены, назовите нужное действие прямо: проверить предложенный состав и подтвердить его. До ответа не следует показывать обычное ожидание приготовления, поскольку фактически работа остановлена на решении клиента.
Рядом со статусом полезны время обновления и ожидаемый следующий шаг, если его срок известен. При задержке сообщайте, что именно уточняется, и дайте контакт для решения. Не оставляйте бесконечную анимацию загрузки вместо уже полученного состояния. Если нет свежей связи с сервером, обозначьте, что показываете сохранённые сведения. У клиента должна оставаться возможность открыть номер заказа и ранее подтверждённые условия, даже когда новое состояние пока не удалось получить.
Отделите оплату и исполнение
Заказ может быть оплачен, но ещё не подтверждён к выполнению, либо выдан с оплатой при получении. Возврат денег после отмены тоже может обрабатываться отдельно. Не пытайтесь вместить всё в один длинный статус. Покажите состояние исполнения, состояние оплаты и связанные действия. При частичной отмене объясните судьбу конкретных позиций. Общая надпись «отменён» вводит в заблуждение, если часть заказа остаётся действующей и ожидает выдачи.
Примите всю цепочку изменений
Согласуйте допустимые переходы и проверьте их на одном заказе от отправки до завершения. Добавьте повторное событие, запоздавшее обновление и отмену во время обработки. Старый ответ не должен возвращать завершённый заказ в прежнее состояние. При ручном исправлении сохраняйте историю с причиной, чтобы поддержка могла объяснить расхождение. Проверьте, что уведомление открывает актуальную карточку. Хорошая система статусов уменьшает число вопросов о судьбе заказа, поскольку каждый этап сообщает клиенту конкретный следующий шаг.