Чат-бот статуса заказа: живой ответ на «где мой заказ?»

«Где мой заказ?» — самый повторяющийся вопрос поддержки

Почти в каждой компании с онлайн-продажами значительная часть обращений в поддержку — один и тот же вопрос: «где мой заказ?». Оператор открывает систему заказов, ищет номер, читает статус и отвечает. Это минута-две, но при ста повторах в день это становится самой затратной по времени работой команды. К тому же клиент задаёт этот вопрос, когда волнуется: чувствует задержку и ждёт быстрого ответа.

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

Почему базы знаний здесь мало

База знаний — для неизменной информации: правила доставки, срок возврата, способы оплаты. Статус заказа у каждого клиента свой и меняется в течение дня. Бот может сказать «доставка 2–3 дня», но чтобы сказать «ваш заказ сегодня передан курьеру», ему нужно прочитать систему заказов.

В Vexvon бот может вызывать собственные API компании как инструменты — именно так на вопрос «где заказ #1234?» приходит живой ответ из системы заказов. API принадлежит компании, и бот отправляет только разрешённые ему запросы.

Сценарий статуса

1. 1НамерениеКлиент пишет: «Где мой заказ?», «Когда привезут?», «Курьер не позвонил». Бот распознаёт это как вопросы о статусе.
2. 2ИдентификацияБот спрашивает номер заказа. Если клиент уже его написал, не переспрашивает.
3. 3Проверка личностиВторой признак, подтверждающий, что заказ принадлежит этому клиенту, — телефон, имя в заказе или email. Одного номера заказа недостаточно.
4. 4ОтветСтатус человеческим языком: «Ваш заказ сегодня утром передан курьеру и будет доставлен до 18:00.» А не системный код вроде «status: SHIPPED_3».
5. 5Следующий шаг«Хотите изменить время доставки?» или «Если есть ещё вопрос — я здесь.»

Проверка личности: насколько и когда

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

1. 1Низкий риск — только статусНомер заказа + последние четыре цифры телефона. В ответе только статус и ориентировочная дата, без адреса и списка товаров.
2. 2Средний риск — изменениеСмена времени или адреса доставки. Нужна дополнительная проверка, и часто этот шаг отдают оператору.
3. 3Высокий риск — оплатаВозврат денег, платёжные данные. Бот такие операции не выполняет, только принимает запрос и передаёт.

В WhatsApp обращение приходит с номером телефона клиента — если он совпадает с номером в заказе, это естественная проверка. В виджете на сайте клиент анонимен, и проверка важнее.

Вопросы о доставке

• «Когда привезут?» — статус и ориентировочная дата из живых данных
• «Отправляете в регионы?» — правило из базы знаний
• «Курьер не позвонил» — проверяется статус, при необходимости передаётся курьерской службе или оператору
• «Можно отправить на другой адрес?» — средний риск, обычно оператор
• «Почему задержка?» — статус и причина задержки, если она есть в системе; если нет — честное «проверяю» и передача

Правило возврата

В вопросе о возврате бот должен разделять две задачи: объяснить правило и начать возврат.

1. 1Объяснить правилоСрок, условия, исключения — из базы знаний, дословно. Это может быть полностью автоматическим.
2. 2Проверить применимостьЕсли дата заказа и тип товара приходят из живых данных, бот может сказать «срок возврата истекает через 5 дней». Он информирует, а не решает.
3. 3Начать возвратПричина, фото и желаемое решение — обмен или возврат денег — собираются и передаются оператору готовой заявкой. Утверждение — за человеком.

Передача оператору

• Заказ не найден в системе или личность не подтверждена
• Статус давно не меняется — вероятно, есть проблема
• Клиент получил повреждённый или не тот товар
• Возврат денег, компенсация, смена адреса
• Клиент недоволен или задаёт тот же вопрос второй раз

В момент передачи оператор должен видеть номер заказа, статус, вопрос клиента и то, что бот уже сказал.

Требования к интеграции

Технически сценарий статуса требует трёх вещей, и их нужно проверить до начала проекта.

• API чтения в системе заказов — статус, дата и данные доставки по номеру заказа
• Поле для проверки личности — телефон или email
• Перевод кодов статуса на человеческий язык — по одной фразе на код
• Сценарий ошибки: если API не отвечает, что говорит бот и кому передаёт

Архитектура интеграции — живое чтение, запись, события и сбои — подробно разобрана в статье об интеграции чат-бота через API и вебхуки. Какие системы можно подключить, показано на странице интеграций.

Таблица перевода кодов статуса

В системе заказов статус — короткий код. Клиенту нужна фраза: что произошло, когда привезут и нужно ли ему что-то сделать. Таблица пишется заранее:

1. 1Принят«Ваш заказ принят и готовится. Обычно передаётся курьеру в течение 1 рабочего дня.»
2. 2У курьера«Ваш заказ у курьера и будет доставлен сегодня. Курьер позвонит перед приездом.»
3. 3Не доставлен — клиент недоступен«Курьер не смог с вами связаться. Передаю вас оператору, чтобы выбрать новое время.» — бот сам время не назначает.
4. 4Отменён«Заказ отменён.» Если причина есть в системе, она называется; если заказ был оплачен, диалог уходит оператору.

Когда появляется новый статус, которого нет в таблице, бот не должен показывать клиенту код — он говорит «уточняю статус» и передаёт разговор.

Что измерять

• Сколько вопросов о статусе бот закрыл полностью
• Диалоги, остановившиеся на проверке личности, — не слишком ли она сложна
• Диалоги, переданные оператору из-за ошибки API
• Клиенты, написавшие оператору после ответа о статусе, — ответ был неясен
• Изменение общего числа вопросов о статусе — иногда проблема в самой доставке

Ограничения

Бот может сообщить только тот статус, который есть в системе. Если данные курьерской службы попадают в систему заказов с задержкой, бот тоже будет сообщать устаревшие данные — честно показывать в ответе «время последнего обновления». Бот не возвращает деньги, не меняет адрес без проверки риска и не гарантирует время курьера.

Итог: самый частый вопрос требует живого ответа

Чат-бот для статуса заказа может закрыть самый повторяющийся вопрос поддержки, но только при наличии живых данных, правильной проверки личности и текста статуса на человеческом языке. В возвратах бот объясняет правило и готовит заявку, а решение оставляет человеку. Такой сценарий снимает с оператора самую затратную по времени часть дня.

Поэтапный запуск бота поддержки — в статье о чат-боте поддержки клиентов, остальные материалы — в этой рубрике. Чтобы обсудить подключение вашей системы заказов, свяжитесь с нами.

Частые вопросы

1. 1Какая система нужна чат-боту для статуса заказа?API, который по номеру заказа возвращает статус. Он может быть в платформе интернет-магазина, в CRM или в собственной системе компании.
2. 2Может ли бот изменить адрес?Технически — да, через интеграцию, но это рискованно. Обычно этот шаг делают с дополнительной проверкой или поручают оператору.
3. 3Что бот может без API?Назвать общие правила, собрать номер заказа и суть проблемы и передать оператору.