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