Доставка еды: ИИ для статуса заказа и поддержки в час пик

Самый частый вопрос требует данных

Клиент спрашивает, где заказ, когда уже ждёт еду. Общий ответ о средней скорости доставки мало полезен. Помощнику нужен текущий статус конкретного заказа и понятное действие, если статус давно не обновлялся.

Источник таких сведений – система заказов и доставки. Модель формулирует ответ, но не вычисляет положение курьера по настроению клиента. Если подтверждённого времени прибытия нет, она должна сказать об этом и направить запрос оператору.

Приём заказа из свободного текста

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

Сведения	Откуда брать
Блюдо и цена	Действующее меню
Наличие	Текущий перечень доступных позиций
Адрес и зона	Правила доставки
Состав и аллергены	Утверждённая информация кухни
Срок	Подтверждённые данные заказа

При аллергии нельзя угадывать состав или обещать отсутствие следов ингредиента. Неясный вопрос передают сотруднику по заранее заданному маршруту. Ошибка здесь имеет другую цену, чем неточность в рекламном описании блюда.

Изменения после подтверждения

Удаление позиции из уже готовящегося заказа требует проверки возможности кухни и правил оплаты. Бот не должен обещать изменение только потому, что сумел переписать корзину в сообщении. Сначала операция в системе, затем подтверждение клиенту.

Повторная доставка сообщения не должна создавать новый заказ. Сохраняйте связь диалога и заказа, проверяйте статус операции. При недоступности сервиса клиенту нужен ясный запасной способ связи, а оператору – уведомление с контекстом.

Жалоба требует решения, а не защиты рейтинга

Холодная еда, неверная комплектация и задержка относятся к разным сценариям. Помощник может собрать номер заказа и описание проблемы, затем передать сотруднику. Право предложить возврат или замену должно быть явно утверждено компанией.

Не заставляйте клиента повторять историю после передачи. Не скрывайте отрицательные отзывы и не просите удалить их как условие рассмотрения жалобы. Задача процесса – разобраться с проблемой, сохранив корректную историю обращения.

Границы автоматических сообщений

Уведомления о статусе заказа и рекламные предложения имеют разную функцию. Не включайте клиента в постоянные рассылки только потому, что он однажды заказал ужин. Для повторных сообщений учитывайте разрешения, отказ и правила выбранного канала.

Опрос после доставки должен быть коротким и необязательным. Если клиент сообщил о проблеме, остановите рекламную цепочку до её рассмотрения. Иначе следующий автоматический призыв заказать снова будет выглядеть как игнорирование жалобы.

Проверьте сообщение «повторите прошлый заказ». Помощник должен показать состав и текущие цены до подтверждения, поскольку меню и доступность могли измениться. Для адреса лучше запросить актуальность, чем отправить курьера по старому месту. Если в прошлой корзине была пометка об аллергии, её нельзя терять при повторе. Такой запрос требует проверки утверждённой информации кухни. Добавьте случай частичной отмены и сохраните историю, чтобы оператор видел, что уже согласовано. Возврат денег нельзя считать выполненным по одному сообщению модели. Клиент получает подтверждение только после результата соответствующей операции или решения сотрудника, которому компания дала такие полномочия.

Проверка пилота

Протестируйте пик нагрузки, неизвестный адрес, отсутствующее блюдо и заказ с двумя частями доставки. Затем проверьте, что видит оператор при передаче. Считайте время ответа по реальным данным и долю запросов, где пришлось исправлять обещание.

Экономику считайте по завершённым обращениям и нагрузке поддержки, не по количеству сообщений бота. Настроить связь заказов, чата и операторов можно через АГЕНСТВО ИИ TRUE.