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