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