Голосовой AI-бот вместо тонального меню: где рвётся сценарий
Тональное меню проектировалось под кнопочные телефоны и логику «выберите из пяти пунктов». Сегодня абонент слушает приветствие и дерево опций 40–70 секунд, держит в голове номера пунктов и всё равно попадает не туда: формулировки в меню не совпадают с тем, как человек описывает свою задачу. Чем длиннее дерево, тем выше доля тех, кто дослушал до конца — но так и не нажал ни одной цифры.
Основные потери сосредоточены на входной линии. Обрывы вызовов происходят ещё до соединения с оператором: абонент бросает трубку на третьем уровне вложенности, не понимая, к какому пункту относится его случай. Отдельная категория — зависшие ветки, где вызов висит в ожидании нажатия, а человек молчит, потому что не расслышал вариант или отвлёкся. В сумме это даёт заметную долю обращений, которые вообще не доходят до исполнителя.
Маршрутизация обращений страдает и после соединения. Тональное меню умеет только одну ось классификации — выбранную цифру, поэтому ложные переводы на оператора идут потоком: клиент жмёт «прочее», чтобы не слушать меню дальше, и занимает живую линию тривиальным вопросом. Речевой сценарий в этой схеме не участвует вообще — он сводится к набору подсказок, а не к разбору формулировок абонента.
Жёсткая привязка к клавишам лишает входную линию гибкости: добавить новый сценарий можно только перезаписью голосового приветствия, а понять, где именно люди отваливаются, — почти нельзя, потому что в логах видно выбранный пункт, но не причину ухода. Разбираем, как это закрывается голосовым ботом, который принимает речь в свободной форме и держит маршрутизацию на смысле сказанного.
Что меняется после перевода линии на речевого бота
До перевода линии гость проходит тональное меню: не помнит, какая цифра отвечает за нужную услугу, ошибается на втором уровне и сбрасывает вызов ещё до очереди. Речевой бот принимает цель словами — «узнать статус заявки», «перенести визит», «соединить с мастером» — и сразу разворачивает нужный сценарий. Сдвиги после этого считаются по метрикам, которые снимаются с той же телефонии: доля автоматизации, нагрузка на операторов, время ожидания, доступность линии.
Доля автоматизации. На типовых сценариях — справочные вопросы, статусы, подтверждения, переносы — без оператора закрывается 60–70% обращений. Остальное не отказ, а осознанный перевод на человека, который уже получил распознанное намерение и контекст разговора.
Нагрузка на операторов. Первая линия перестаёт работать фильтром: оператор не тратит первые минуты на выяснение цели, а сразу ведёт предметный разговор. В пиковые часы это разница между очередью и разбором потока — нагрузка выравнивается, а не растёт ступенькой.
Время ожидания. Маршрутизация идёт по цели, навыку группы и текущей загрузке, поэтому соединение с профильным специалистом происходит с первого перевода, а не после блуждания по уровням меню. Отдельно считаем долю брошенных до соединения — она падает вместе с глубиной меню.
Доступность линии в пиковые часы. Бот держит параллельные вызовы и не отдаёт «занято»: если свободных операторов нет, он остаётся на линии, досчитывает запрос, ставит в очередь или закрывает его сам. Подключаем речевой слой к вашей телефонии — от Asterisk до облачной АТС — без замены номера и ломающих изменений.
Режимы диалога: сравнение подходов и ограничений
Прежде чем выбирать, где бот встаёт в голосовой сценарий, стоит разделить уровни: распознавание речи, логику диалога и передачу вызова человеку. Режим диалога определяет, сколько шагов клиент проходит сам, а где подключается оператор. Ниже — рабочие конфигурации, которые мы собираем на телефонных платформах вроде Avaya: они различаются не «умом» модели, а ценой ошибки и глубиной связки с учётной системой.
| Режим | Когда подходит | Ограничения |
|---|---|---|
| Полная замена меню | Однотипные обращения: баланс, статус заявки, запись, отмена | Сложные формулировки распознаются с ошибками, нужен аварийный выход на человека |
| Гибридная схема | Меню для коротких путей, бот перехватывает всё, что не совпало с пунктом | Нужна синхронизация двух логик, иначе клиент объясняет проблему дважды |
| Бот только на входе | Классификация обращения и маршрутизация до нужной группы | Не снимает нагрузку с операторов, только сокращает число переводов |
| Свободный диалог | Запись на услугу, консультации с ветвлениями и уточнениями | Чувствителен к шуму и отраслевой терминологии, дольше настраивается |
| Быстрая эскалация на оператора | Пиковые нагрузки, сложные продукты, жёсткие сроки ответа | Выигрыш на входе теряется, если правила передачи настроены широко |
Ограничения режима — это не приговор, а набор параметров: порог уверенности распознавания, число переспросов, фразы-триггеры для эскалации и правило передачи контекста вместе с вызовом. Каждый перевод на оператора мы логируем, поэтому видно, какие формулировки бот не разобрал и что стоит дообучить.
Как идёт внедрение: от аудита звонков до передачи
Порядок работ здесь не формальность: каждый следующий шаг опирается на данные предыдущего. Если сразу проектировать схему диалога без аудита записей, бот закрывает 10–15% потока вместо половины — просто потому, что ветки построены под выдуманные вопросы, а не под то, как люди звонят на самом деле.
- Аудит обращений: выгружаем записи, размечаем по темам, считаем доли — сколько звонков решается без оператора и где люди бросают трубку на тональном меню. На выходе — список тем с потенциалом автоматизации и те, что роботу отдавать нельзя.
- Схема диалога: ветки строим под реальные формулировки из аудита, отдельно описываем поведение при непонимании и эскалацию на оператора с передачей контекста.
- Настройка и подключение: связываем бота с телефонией и учётной системой, настраиваем распознавание под вашу лексику — названия услуг, артикулы, имена.
- Тестовый прогон: гоняем схему на записях из аудита и на сценариях с помехами — плохая связь, перебивание, диалект. Правим до выхода на живые звонки.
- Проверка на реальном трафике: включаем на части потока, сравниваем с контрольной группой операторов, спорные диалоги разбираем вручную. Расширяем долю только при стабильных метриках.
- Приёмка: фиксируем критерии — доля диалогов без оператора, доля ошибочных переводов, время до ответа. Проверяем на выборке вместе с вашей командой, а не по своей отчётности.
- Передача в поддержку: отдаём документацию по веткам, регламент правок и панель мониторинга, обучаем вашу команду менять сценарии и формулировки самостоятельно.
Документация, схемы диалогов и регламенты передачи
Передача голосового бота — это не только работающий сервис, но и набор артефактов, по которым ваша команда сможет самостоятельно его вести. Мы фиксируем состав документации до старта работ, а при сдаче проверяем, что каждый пункт актуален текущей версии сценария. Ниже — что остаётся у заказчика на руки.
- Схема веток диалога — все развилки с условиями переходов: куда идёт вызов при нераспознанной фразе, при молчании, при повторном уточнении, на какой глубине подключается человек. Схема ведётся в едином формате, пригодном для правок без разработчика.
- Правила эскалации — триггеры перевода на живого оператора: сколько неудачных попыток распознавания считается отказом, как обрабатывается эмоциональная лексика, какие темы сразу уходят на человека, как вызов встаёт в очередь по приоритету.
- Настройки распознавания и маршрутизации — словари терминов, названий продуктов и должностей, пороги уверенности, при которых бот переспрашивает, а не действует наугад, правила распределения по навыкам операторов и календарь рабочих часов.
- Инструкция оператора — что видит сотрудник при переводе вызова: расшифровку речи, уже собранные данные, историю попыток; как принять разговор, как вернуть его боту и как пометить причину ручного вмешательства.
- Регламент изменений — порядок правки сценария: кто согласует новую ветку, на каком контуре она проверяется на записях реальных звонков, как выполняется откат к предыдущей версии, если правка ухудшила результат.
- Журнал обращений и отчётность — разметка причин завершения вызова, доля маршрутов, закрытых ботом без оператора, список фраз, которые чаще всего не распознаются, — основа для плановых доработок словаря и веток.
Документация обновляется вместе со сценарием: правка, не отражённая в схеме и регламенте, не проходит приёмку. Так решение остаётся управляемым вашими силами, а не только нашей командой.
Кейс: сократили обрывы на входной линии и разгрузили операторов
До проекта входная линия держалась на тональном дереве в четыре уровня. Разбор записей показал: 18% звонков обрывались прямо на меню — абонент не дожидался четвёртого уровня и не понимал, какую цифру нажимать. Среднее время до живого специалиста — 3 минуты 40 секунд, в пиковые часы очередь доходила до 11 минут, и часть этих звонков терялась совсем.
Что перестроили
Тональное дерево заменили одним открытым вопросом: абонент формулирует причину обращения голосом, модель определяет намерение и ведёт по нужной ветке. Оставили шесть сценариев, которые покрывают большинство обращений — статус заявки, блокировка, подключение услуги, смена тарифа, оплата, претензия.
Каждая ветка заканчивается либо автоматическим решением, либо передачей оператору с уже собранным контекстом: тип обращения, номер договора, история. Оператор не переспрашивает заново — сразу работает по сути.
Метрики до и после
- Обрывы на входной линии: 18% → 4%
- Время до специалиста: 3:40 → 0:50
- Доля обращений, закрытых без оператора: 0% → 62%
- Нагрузка на операторов в пик: минус треть
Разговоры и заявки складываются в Битрикс24: оператор видит историю обращений до того, как поднял трубку, а руководитель линии — отчёт по доле автоматических решений. Обрывы перестали быть узким местом: линия держит пиковую нагрузку без расширения смены, а освободившееся время операторов ушло на сложные случаи, где автоматика пока уступает человеку.
Что делать, если меню уже работает и ломать его нельзя?
Работающее меню — не технический долг, а действующий контур обслуживания: номер напечатан на визитках, в рекламе и договорах, и замена «в лоб» обернётся потерянными вызовами в пиковые часы. Поэтому речевой слой ставится поверх дерева, а не вместо него, и первым шагом переносим в него только те ветки, где сценарий предсказуем.
Точка входа остаётся прежней: вызов приходит на тот же номер, но принимает его уже бот. Он распознаёт намерение и, если уверенность выше заданного порога, ведёт диалог сам; если ниже — передаёт управление в существующую ветку меню, и абонент продолжает нажимать те же клавиши, что и раньше.
Поэтапный переход держится на параллельной работе двух контуров. Правила маршрутизации делят трафик: сначала через речевой слой идёт узкая группа сценариев — статус заявки, запись, уточнение баланса, — остальное уходит на привычные ветки. Долю вызовов поднимаем по мере того, как поддержка снимает замечания по формулировкам и логике диалога.
Запасной маршрут сохраняется и после запуска: старые ветки не удаляются, а остаются аварийным путём. Переключение между ботом и меню — это настройка на работающей системе, без релиза и разрыва линии: если сценарий мешает, его отключают для нужной группы, и следующий звонок идёт по прежней схеме.
Миграция без простоя получается как следствие: начатые разговоры доводятся до конца по той логике, с которой стартовали, а новые идут уже по новым условиям. Обратный откат остаётся в одну настройку, а доля диалогов, закрытых без оператора, показывает, какую ветку речевой слой готов забрать целиком.
Технические сомнения: распознавание, шум и перебивания
Сомнения перед запуском голосового бота обычно инженерные: как распознавание держится на шумной линии, что происходит при перебивании, где хранятся персональные данные и как ответ бота попадает в учётную систему.
Как распознавание ведёт себя на шуме, с акцентами и быстрой речью?
Поток нарезается на короткие кадры: постоянный фон снимает шумоподавление, эхоподавление убирает отражение голоса самого бота, автоусиление выравнивает тихие реплики. Модель настроена на телефонную полосу, а не на студийную запись. Под задачу собирается словарь — названия услуг, городов, кодов, — а номера заявок и суммы распознаются посимвольно. На настройке мы прогоняем записи реальных звонков и считаем долю верных ответов по критичным полям, а не среднюю по диалогу.
Абонент перебивает или молчит — что делает бот?
Определитель конца реплики отличает паузу для вдоха от окончания фразы, поэтому бот не вклинивается в середину ответа. При перебивании он замолкает и слушает, не договаривая заготовку. Для молчания задаются время ожидания и правило передачи оператору — диалог не зависает.
Где хранятся записи разговоров и персональные данные?
Записи и расшифровки остаются в согласованном контуре заказчика, доступ разграничен по ролям, срок хранения задаёт политика. Номера карт, коды подтверждения и другие чувствительные фрагменты маскируются до записи. Для отдельных сценариев запись можно отключить.
Как бот стыкуется с учётной системой?
Обмен идёт через программный интерфейс: абонент опознаётся по номеру, бот проверяет статус обращения, создаёт заявку и записывает итог разговора в карточку. Если система недоступна, бот фиксирует обращение и передаёт оператору — абонент не слышит ошибку и не остаётся без ответа.
Обсудим задачу: какие данные нужны для оценки
Скорость, с которой мы возвращаемся с оценкой, зависит не от объёма описания, а от полноты входных данных. Достаточно одного разговора и того, что уже есть в работе линии, — записи мы разберём сами и покажем, где голосовой бот закроет обращение без оператора, а где разговор придётся переводить на человека.
- Записи обращений — 20–30 реальных диалогов из разных часов и дней, включая те, где абонент бросил трубку или дождался оператора. По ним видно словарь, фоновый шум, длину реплик и долю нестандартных формулировок.
- Схема маршрутизации — какие линии и номера обслуживаются, по какому признаку вызов уходит в конкретный отдел и что считается корректным переводом, а не потерянным клиентом.
- Ограничения линии — сколько вызовов канал держит одновременно, есть ли очередь, как ведёт себя телефония при перегрузке и что происходит с вызовом при отказе узла.
- Состав справочников — перечень услуг, адресов, сроков, статусов заявок и частых вопросов, к которым бот должен обращаться. Если справочник ведётся таблицей — пришлите как есть, разберём формат сами.
- Что меняется после звонка — запись на приём, оформление заявки, передача данных в учётную систему, отправка подтверждения абоненту.
- Критерии приёмки — какой доле абонентов бот помогает без оператора, что считаем сбоем распознавания и куда возвращаем вызов в этом случае.
Если части данных нет, обсуждение задачи всё равно стоит начать: по записям и схеме маршрутизации мы восстановим остальное и вернёмся с оценкой проекта и планом работ по этапам — с проверяемым результатом на каждом.
