Голосовий AI-асистент Speech-to-Speech: розробка та впровадження під ключ

Чому голосовий AI-асистент ламається на реальних дзвінках

На демо голосовий асистент упевнено веде діалог. У телефонії на нього обрушується те, чого немає в тестовому сценарії: шум у каналі, перебивання, паузи «я подумаю», кілька питань в одній репліці та нестандартні формулювання замість гладких фраз зі скрипта.

Асистент або обриває діалог на середині, не дослухавши абонента, або втрачає нитку після третього уточнення — і людина передзвонює вже роздратованою.

Окремий клас відмов — зациклення. Модель не розпізнала намір і повторює те саме уточнювальне питання, доки не покладуть слухавку; у пікові години такі діалоги займають канал і створюють перевантаження першої лінії, через яке живі звернення не дочікуються відповіді.

Збої діалогу тут не поодинокі: вони складаються в десятки зірваних дзвінків за зміну, а навантаження на операторів зростає замість того, щоб падати.

Ще одна точка відмови — втрата контексту розмови під час переведення на оператора. Якщо історія виклику не передана разом із з’єднанням, клієнт заново диктує номер заявки, суть проблеми та свої дані, а співробітник витрачає перші хвилини на відновлення діалогу, а не на рішення. Нижче розбираємо, як це закривається.

Що змінюється після впровадження: ефект у вимірюваних числах

Ефект від голосового асистента видно не у відчуттях, а в чотирьох числах, які знімаються з журналів дзвінків і черги: частка звернень без оператора, час відповіді клієнту в пік, частка діалогів, доведених до результату, і кількість повторних дзвінків з того самого питання.

Вимірюємо ці показники до запуску і через місяць після — на тих самих пікових годинах, інакше порівняння нічого не доводить.

• Частка автоматичних звернень. Асистент на архітектурі Speech-to-Speech на старті закриває 55-65% типових дзвінків, після дообучення на реальних записах — 75-85%. Перша лінія перестає бути вузьким місцем: зміна працює без перевантаження в години пік.
• Час відповіді клієнту. Очікування в черзі скорочується з 45-60 секунд до 2-4: асистент бере слухавку одразу й не залежить від того, скільки операторів на лінії.
• Частка діалогів до результату. Запис, перенесення візиту, статус заявки — 7-8 діалогів із 10 завершуються дією без передання людині.
• Час простою лінії. Уночі та на вихідних приймання звернень більше не зупиняється: черга не зростає, а заявки потрапляють у систему з готовим змістом.
• Повторні дзвінки. Клієнт рідше передзвонює з одного й того самого питання — частка таких звернень падає у 2-3 рази завдяки тому, що відповідь надається одразу й підтверджується записом розмови.

Вважаємо не «в середньому за місяць», а за піковими інтервалами та типами звернень — так видно, які сценарії справді зняли навантаження, а які варто доопрацювати.

Способи підключення мовленнєвого бота: порівняння варіантів

Режим роботи визначається не моделлю, а тим, яку частку звернень ви готові віддати боту і як влаштована маршрутизація на боці телефонії.

Підключення до чинної телефонії робимо без зміни номера й оператора: виклик іде на мовленнєвий сервіс, а далі за сценарієм або обробляється повністю, або повертається в чергу операторів.

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

Режим не фіксується назавжди: той самий бот удень працює фільтром, уночі — автономно, а під вихідні сценарії виділяється окрема лінія.

Етапи впровадження: від аудиту дзвінків до передання в підтримку

Порядок етапів у впровадженні голосового AI-асистента задають залежності, а не регламент: поки не розібрані реальні звернення, схема діалогу залишається гіпотезою, а перевіряти інтеграції ні на чому.

Кожен етап закривається артефактом, який приймається до старту наступного — помилка в проєктуванні не спливає вже на проді.

1. Аудит дзвінків: вивантажуємо записи звернень, розмічаємо за темами — статус замовлення, зміна умов, повернення, претензія. Рахуємо частку викликів, які асистент закриє без людини, і точки, де обов’язкове передання оператору.
2. Схема діалогу: проєктуємо гілки, формулювання реплік, уточнювальні питання та правила підтвердження даних. Окремо описуємо поведінку при мовчанні, перебиванні, нерозпізнаному мовленні та проханні з’єднати з людиною.
3. Налаштування інтеграцій: зв’язуємо асистента з телефонією, CRM та обліковими системами — приймання виклику, визначення клієнта, запис підсумку розмови, створення заявки. Збій на боці системи не обриває виклик: діалог доводиться до кінця, завдання йде в чергу.
4. Приймальні перевірки: проганяємо сценарії на реальних записах — із шумом, акцентом, поганим зв’язком, перебиваннями. Фіксуємо частку розпізнаних реплік, коректність передання даних і кількість помилкових переведень на оператора.
5. Навчання операторів: розбираємо, як читати розшифровки, де втручатися в діалог і як обробляти спірні випадки. Окремо — що робити з викликами, які асистент завершив з помилкою.
6. Передання в підтримку: віддаємо схему діалогу, налаштування інтеграцій, перелік перевірок і порядок відкату до попередньої версії. Перші тижні супроводжуємо самі, потім передаємо команді замовника з регламентом змін.

Що передаємо вашій команді: конфігурації, схеми, регламенти

Проєкт вважається зданим не тоді, коли асистент упевнено відповідає на тестовому дзвінку, а коли ваша команда може супроводжувати його сама.

Тому передання — це не папка з презентацією, а робочий комплект: за ним новий інженер входить у систему без дзвінків нам, а лінія підтримки розбирає інцидент, не запитуючи доступ до вихідників.

• Описи сценаріїв: які гілки діалогу асистент веде сам, у який момент передає оператору, які формулювання вважає відмовою від обслуговування і що відповідає на них.
• Схема проходження звернення: шлях від вхідного сигналу до закриття з точками логування — за кожним записом відновлюється хід розмови та причина збою.
• Правила обробки даних: що потрапляє в запис, які поля маскуються, скільки зберігаються аудіо та розшифровка, хто має право на вивантаження.
• Інструкції для операторів: як прийняти керування в асистента, як позначити розмову, що робити при невпевненому розпізнаванні.
• Регламент супроводу: що перевіряється щоденно і що щотижня, як оновлюються фрази та пороги, куди надходять оповіщення про збої.
• Передання доступів: облікові записи з ролями, двофакторна автентифікація, реєстр ключів і порядок їх відкликання при звільненні співробітника.
• Схема розгортання та відкату: які вузли за що відповідають, як повернути попередню версію і скільки часу це займає.

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

Кейс: як скоротили зірвані дзвінки та час відповіді

Служба підтримки приймала вхідні на три лінії, і в пікові години черга зростала швидше, ніж оператори встигали закривати звернення. До впровадження асистента 23% дзвінків зривалися до відповіді оператора, а середній час до першого контакту тримався близько 90 секунд. Частина звернень надходила в неробочі години й залишалася лише у вигляді пропущених викликів.

Що змінили в сценарії

Голосовий асистент узяв на себе перший контакт: привітання, ідентифікацію клієнта за номером, уточнення теми та збір контексту до передання людині.

Сценарій розбили на короткі гілки — статус заявки, зміна даних, технічна проблема, — і в кожній асистент або закриває питання сам, або готує оператору вижимку по суті звернення.

Маршрутизація та результат

Маршрутизація будується за типом звернення та пріоритетом клієнта: складні випадки йдуть у профільну групу, повторний дзвінок потрапляє до того самого оператора, а вночі асистент оформлює звернення і ставить його в чергу на ранок.

Зв’язка з Bitrix24 пише картку та розшифровку розмови сама — оператор не витрачає перші хвилини на розпитування.

Частка зірваних дзвінків упала з 23% до 4%, час до першої змістовної відповіді скоротився з 90 до 10 секунд, навантаження на першу лінію знизилося приблизно на третину завдяки питанням, які асистент закриває сам.

Зник цілий клас відмов: звернення, загублені в черзі та в неробочі години, більше не залишаються без відповіді й не перетворюються на повторні дзвінки.

Чим голосовий асистент відрізняється від мовленнєвої аналітики

Різниця підходів — у напрямку роботи. Мовленнєва аналітика розбирає записи розмов, які вже відбулися: розшифровка, розмітка за спікерами, пошук за скриптами.

Голосовий асистент веде діалог у реальному часі та впливає на його результат — перепитує, уточнює, утримує клієнта на лінії.

Аналітика влаштована як пакетний процес: записи надходять із телефонії, розмічаються, перевіряються за чек-листом контролю якості. На виході — бали операторів, частка перебивань, довгі паузи, відхилення від скрипта. Рішення все одно ухвалює людина: інструмент лише підсвічує проблемні дзвінки у вибірці.

Асистент розв’язує зворотну задачу: розпізнає репліку на льоту, виділяє сенс, формує відповідь і озвучує її, не збиваючись на перебиваннях і неповних фразах.

Критична затримка — якщо відповідь запізнюється хоч на частки секунди, людина вирішує, що її не почули, і завершує розмову.

Перетинаються обидва контури на даних. Асистент залишає ту саму розшифровку й розмітку, тому його розмови можна прогнати через мовленнєву аналітику — для контролю якості та розбору збоїв.

Зворотний потік теж працює: аналітика показує типові заперечення та місця обривів, за якими доналаштовують сценарії бота.

Вибір залежить від задачі. Потрібно вимірювати якість операторів і знаходити втрати в скриптах — достатньо розбору записів. Потрібно закривати типові звернення без людини — потрібен діалоговий бот зі зв’язним мовленням.

У гібридній схемі асистент тримає перший контур, складне передає оператору, а аналітика оцінює обидві сторони.

Технічні сумніви, які знімаємо до старту робіт

Сумніви щодо голосового AI-асистента спливають на захисті рішення і майже всі закриваються на етапі проєктування, а не після запуску. Нижче — чотири питання, які задають найчастіше, з відповідями інженерів по суті.

Діалог зайшов у глухий кут — абонент повторює одне й те саме

У сценарії є явні точки виходу: після двох невдалих уточнень розмова передається оператору разом із розшифровкою та історією гілки — якість після передання тримається, бо діалог не починають заново. Такі діалоги йдуть у розбір, а не в архів.

Правила зміняться — доведеться перезбирати інтеграції?

Логіка діалогу відокремлена від інтеграційних точок: сценарій правиться у візуальному редакторі, а запис, календар, облікова система та передання оператору підключаються як дії з параметрами.

Зміна гілки або порядку кроків не чіпає обв’язку — правиться граф, проганяється регрес і викладається версія.

Як проходять доопрацювання після запуску і що з відкатом?

Версії сценарію зберігаються окремо, відкат займає хвилини. Регрес-набір із записаних діалогів, включно зі збійними, проганяється автоматично: порівнюємо частку завершених сценаріїв і кількість уточнень на діалог, тому правка, що ламає сусідню гілку, видна до викладки.

Обговоримо задачу: що потрібно від вас для оцінки та плану

Щоб повернутися з оцінкою проєкту та планом робіт, а не з широким діапазоном «від і до», нам потрібні реальні дані про ваш трафік звернень.

Точність розрахунку напряму залежить від якості вхідних даних: чим раніше ми побачимо записи розмов і схему маршрутизації, тим менше припущень залишиться в плані.

• Записи звернень — 30–50 діалогів із різних каналів, включно з шумними лініями, сильним акцентом і нестандартним мовленням: за ними рахуємо частку коректно розпізнаних реплік і обсяг словника під ваш предмет.
• Схема маршрутизації — поточне дерево автовідповідача, правила переведення на оператора та групи, куди потрапляють складні випадки.
• Перелік облікових систем — CRM, довідник клієнтів, білінг, служба підтримки: що асистент має читати і що записувати за підсумками розмови.
• Логи звернень — тривалість діалогів, частка перерваних, причини переведення на людину: на цих метриках будується контрольна вибірка для перевірки.
• Межі автономії — які дії асистент виконує сам, а де обов’язкове переведення на живого оператора.
• Вимоги до контуру — хмара або закрита мережа замовника, політика зберігання записів, доступи та ролі учасників.
• Критерії приймання — цільова частка успішно завершених сценаріїв і перелік діалогів, на яких її перевіряємо.

Цього набору достатньо, щоб розкласти оцінку за етапами, визначити склад команди — інженер із мовленнєвих моделей, розробник інтеграцій, тестувальник діалогів — і запропонувати порядок робіт із точками контролю. Опишіть задачу в зручному вигляді: розберемо вхідні дані та повернемося з оцінкою і планом.