Реализация голосового AI-бота для подтверждения заказов

Голосовой бот для подтверждения заказов: где рвётся процесс

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

Пиковая нагрузка на смену обнажает вторую проблему — расхождение статусов заказов. Пока дозвон висит в очереди, клиент успевает передумать в чате, изменить адрес или отменить всё; в системе заказ всё ещё «подтверждён», кладовщик его собирает, курьер выезжает. Возврат, повторная доставка и разбор с клиентом стоят дороже самого звонка.

Ещё двумя операторами это не лечится. Нагрузка нелинейна: три часа пика, а дальше простой, и держать смену под пик нерентабельно. Плюс ручной обзвон не даёт одинакового сценария — один оператор уточнит время доставки, другой нет, а часть заказов остаётся неподтверждённой до утра.

Голосовой бот подтверждение заказов закрывает это иначе: автоматический обзвол клиентов идёт параллельно по всей очереди, дозвон повторяется по расписанию с разнесением попыток, а ответ клиента — согласие, перенос, отмена — сразу превращается в одно обновление статуса. Событие уходит в учётную систему один раз, поэтому двойных записей и «дребезга» статусов не возникает; запись разговора и расшифровка остаются привязанными к заказу.

Разбираем, как это устроено на практике: какие сценарии разговора закрывают 90% исходов, как бот ведёт себя при недозвоне и как статусы заказов перестают расходиться с реальностью.

Сценарии автоматического подтверждения: эффект в цифрах

Эффект автоподтверждения видно в четырёх метриках: доля подтверждённых заказов, время до подтверждения, нагрузка на операторов, повторные обращения. Замеряем их на одной и той же неделе до запуска и после — иначе сравнение съезжает на сезонность спроса.

• Доля подтверждённых заказов. В пик ручной обзвон не догоняет поток: операторы закрывают первые позиции очереди, остальные висят до таймаута. Бот обзванивает весь список — прирост 20–25 п.п. и никакого провала в часы нагрузки.
• Время до подтверждения. Звонок уходит через минуту после оформления, пока клиент ещё у телефона, а не через час, когда освободился оператор. Короткая пауза — выше отклик.
• Нагрузка на операторов. Типовые случаи — заказ в наличии, адрес и время без изменений — уходят на автомат, это 60–70% обращений. Оператор остаётся на переносах, заменах и отказах.
• Повторные обращения. Клиент не звонит «что с заказом»: статус подтверждён и виден в Битрикс24. Доля таких звонков падает в разы и освобождает ту же линию.
• Ушедший класс отказов. Заказы, зависшие без подтверждения и отменённые по таймауту, перестают возникать как явление.

Каждую метрику фиксируем в одном отчёте до и после, поэтому расширение сценариев идёт по данным, а не по ощущениям.

Режимы обзвона: сравнение подходов и их ограничения

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

Ограничения сценария — не в качестве распознавания речи, а в ветвлении диалога. Полностью автоматический обзвон держит предсказуемые ответы «да», «нет», «перезвоните позже», но нестандартный вопрос некуда положить — и разговор обрывается. Подключение оператора снимает это, но добавляет регламент передачи и паузу на линии. Ниже — сопоставление режимов по тому, под какую базу заказов каждый подходит.

На практике режимы комбинируются: автоматика проходит основную массу заказов, а на неуверенных ответах или спорных позициях передаёт диалог оператору. При проектировании мы заранее описываем, какие ответы считаются однозначными, а какие уходят на человека, — иначе доля незакрытых заказов растёт вместе с базой.

Этапы внедрения: от аудита звонков до передачи смены

Внедрение голосового бота — не установка готового продукта, а настройка под ваш поток заказов. Этапы внедрения строятся так, чтобы каждый закрывался проверяемым артефактом: картой отказов, схемой сценария, правилами обзвона, отчётом по тестовой выборке заказов.

1. Аудит звонков. Размечаем записи и журналы за период: сколько заказов доходит до подтверждения, на какой реплике обрывается диалог, какие формулировки клиент переспрашивает. На выходе — карта отказов и словарь реальных возражений вместо догадок.
2. Схема сценария. Ветвление по ответу: подтверждаю, не подтверждаю, перенос даты, вопрос по составу. Ветки «не я заказывал» и «перезвоните позже» ведут к передаче оператору с контекстом разговора, а не в тупик.
3. Правила обзвона. Окно дозвона, число попыток и интервалы между ними, тихие часы, поведение при недозвоне. Исчерпали попытки — заказ уходит оператору вместе с историей звонков.
4. Связка с учётной системой. Статус меняется по итогу разговора, а не отдельной выгрузкой. Повторный звонок не создаёт второй статус и не сдвигает заказ из очереди сборки.
5. Тестовая выборка заказов. Прогон на реальных заказах с ручной разметкой: где бот понял неверно — правим формулировки и порог срабатывания, пока расхождения не станут единичными.
6. Передача смены. Регламент правок сценария, панель с метриками, разбор спорных диалогов. Дальше изменения вносим по данным, а не по ощущениям.

Перед запуском фиксируем точку отсчёта: долю корректных подтверждений, время до первого дозвона, долю диалогов, ушедших человеку. Иначе улучшение нечем доказать, а сценарий быстро расходится с реальным потоком заказов.

Правила маршрутизации, сценарии и документация по итогам

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

• Правила маршрутизации — таблица «условие → действие»: при каком ответе клиента заказ подтверждается, при каком бот переспрашивает, при каком сразу передаёт звонок оператору; отдельно описаны повторный дозвон и обрыв связи.
• Схема эскалации — уровни передачи (бот → оператор → руководитель смены), таймаут ожидания и число попыток дозвона, критерий недозвона и момент, когда заказ уходит на ручной обзвон.
• Тексты реплик — набор фраз под каждый шаг диалога: приветствие, подтверждение, уточнение, отказ, завершение. Помечено, где формулировка фиксирована, а где допустимы варианты.
• Словарь ответов клиента — синонимы «да», «подтверждаю», «не заказывал», «перезвоните», а также перечень фраз, на которых бот обязан замолчать и позвать человека. Пополняется по спорным звонкам.
• Регламент спорных заказов — кому передаётся обращение, если клиент отрицает заказ, какие поля фиксируются и в какой срок.
• Схема обмена с учётной системой — какие поля заказа записываются, что происходит при ошибке записи и как бот ведёт себя, если система недоступна.
• Журнал разбора — как читать записи диалогов и распознанные ответы, чтобы находить проблемные реплики и обновлять словарь без нас.

Комплект передаём с версионированием: правка фиксируется, предыдущая версия остаётся доступной для отката.

Кейс: как автоматический обзвон снизил нагрузку на смену

До внедрения подтверждение заказов полностью держалось на смене операторов. В вечерний пик очередь росла, среднее время до подтверждения доходило до 40 минут, а часть заказов закрывалась отменой просто потому, что до клиента не дозвонились с двух попыток. Нагрузка распределялась неравномерно: половина звонков приходилась на два часа, остальное время смена простаивала.

Процесс разложили на два маршрута. Голосовой бот подтверждение заказов ведёт по сценарию с ветками — подтвердить, перенести доставку, изменить состав, отказаться. Телефонию и маршрутизацию вызовов собрали на Twilio, распознавание и синтез речи вынесли в отдельный сервис, чтобы менять модель, не переписывая логику диалога. Ключевой элемент — порог уверенности: если ответ не разобран, клиент перебивает или уходит в тишину, диалог не дожимается, а переводится оператору вместе с расшифровкой и историей попыток.

Метрики до и после: доля подтверждений без участия человека выросла до 78%, среднее время до подтверждения сократилось с 40 минут до 2. Пиковая очередь перестала быть узким местом — та же смена закрывает вечерний объём и параллельно разбирает эскалации, а не обзванивает всех подряд.

Отдельно разобрались с классом отказов. Раньше недоступный номер, ошибочный ввод и осознанный отказ падали в одну метрику «отмена», и было непонятно, что чинить. Теперь недозвон уходит в повторный обзвон по расписанию, ошибочный номер помечается и не тратит попытки, явный отказ фиксируется с причиной. Потери от «не дозвонились» сократились втрое, а отказы стали различаться по причинам, а не по факту.

Чем отличается обзвон автоинформатором от диалогового сценария?

Автоинформатор — односторонняя запись: он зачитывает текст, максимум просит нажать клавишу и завершает вызов. Слова клиента он не разбирает — если человек говорит «я ничего не заказывал» или «давайте завтра», система этого не слышит и повторяет фразу по кругу. В отчёте остаётся «дозвон состоялся», хотя заказ не подтверждён, и список возвращается оператору на ручной обзвон.

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

Отличие от контакт-центра не в том, кто «лучше» говорит, а в том, что забирает бот, а что уходит людям. Подтверждение заказа — короткий разговор с предсказуемым набором ответов, и он закрывается целиком: десятки параллельных линий, обзвон в нужном окне, одинаковый набор вопросов на каждом вызове.

Спор по сумме, жалоба, смена состава заказа — эти случаи сценарий распознаёт и сразу отдаёт оператору, не пытаясь доиграть реплики. Бот берёт объём, человек — исключения.

Сложные случаи: плохая связь, диалекты, отказы от звонка

Реальный звонок редко похож на студийную запись: шум и эхо в линии, обрыв, быстрая речь, местный говор. Бот, который в такой ситуации пытается угадать, подтверждает заказ наугад — и это дороже, чем честно передать вызов человеку. Поэтому логика строится вокруг порога уверенности: пока распознавание не набрало нужных признаков, бот переспрашивает, а не додумывает.

Обработка идёт потоком, без ожидания конца фразы: шумоочистка отсекает фон, номер заказа и ответ «да» или «нет» проверяются отдельно от остальной речи. Если после двух переспросов ответа нет, вызов помечается причиной и уходит оператору вместе с расшифровкой. Ниже — типовые сомнения, которые снимаем до запуска.

Поймёт ли бот диалект или сильный акцент?

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

Клиент отказывается разговаривать с ботом — что тогда?

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

Куда попадает спорный заказ?

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

Обсудим задачу: какие данные нужны для оценки

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

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

• Объём обзвона: заказов в сутки, пиковые дни и часы, доля недозвонов и повторных попыток.
• Записи разговоров: 10–20 звонков с разными исходами — подтверждение, отказ, перенос, молчание в трубке.
• Правила отмены заказа: в какие сроки отмена возможна, кто её согласует, что считается частичным отказом.
• Сценарий разговора или регламент: что бот обязан проговорить, какие данные покупателя подтвердить, когда звать оператора.
• Требования к хранению результатов: сколько держать записи и расшифровки, кому давать доступ, нужна ли обезличенность.
• Точки интеграции: куда бот пишет статус заказа и есть ли тестовый контур для прогонов.
• Ограничения обзвона: часовые пояса, недопустимое время звонка, отказы от звонков.

Если чего-то из списка нет — не критично, недостающее снимаем на созвоне. После разбора фиксируем план: число линий под пик, этапы настройки сценария, прогон на ваших записях и порядок приёмки.