Голосовий AI-бот у нагадуваннях: де ламається сценарій обдзвону
Завдання «нагадати про заборгованість» на демонстрації звучить як одна репліка. У реальному обдзвоні воно розсипається: абонент перебиває на першому реченні, запитує «про яку суму йдеться», іде в заперечення, слухавку бере автовідповідач або родич.
Робот без розпізнавання мовлення, розрізнення мовців і обробки перебивань втрачає нитку — або повторює завчений текст, або завершує виклик на середині, і абонент передзвонює вже з претензією.
Друга точка відмови — оператори. Додзвін, привітання, звірка особи та уточнення суми з'їдають майже всю зміну, а до складних випадків — спору щодо нарахувань, реструктуризації — доходять одиниці. Звідси вигорання на однотипних контактах і плинність у пулі.
Обмежень додає і ФЗ-230: частота й час контактів щодо прострочення регламентовані, і втримати ці рамки вручну, розмазавши по змінах, не виходить.
Третє — фіксація відповідей боржника. «Оплачу до п'ятниці», відмова, прохання більше не телефонувати, номер іншої контактної особи залишаються в аудіозаписі й доїжджають до облікової системи замовника вручну.
Якщо відповідь не розкладено на поля, а статус не захищено від повторного запису, автообдзвін заборгованості приходить до людини, яка вже домовилася, — і сценарій нагадування втрачає сенс. Розбираємо, як це закривається.
Що змінюється після впровадження: вимірювані ефекти автообдзвону
Автообдзвін змінює саму одиницю виміру: замість «скільки операторів на лінії» рахують час обдзвону бази. Черга контактів розбивається на вікна за розкладом, дзвінки йдуть паралельно на десятки ліній, і база в десятки тисяч номерів опрацьовується за години, а не за тижні. Покриття бази нагадуваннями перестає залежати від того, скільки людей вийшло в зміну.
Частка автоматичних контактів зростає за рахунок того, що розмову цілком веде бот, а оператор підключається лише на заданих сценаріях — спір про суму, прохання про розстрочку, скарга.
Спроби розподіляються на ранок, день і вечір, тому один контакт отримує додзвін у різний час і не впирається в «незручно говорити». На практиці частка контактів виходить на 80–90% проти 30–40% за ручного обдзвону.
Кожна відповідь фіксується: бот розпізнає за ключовими фразами, що людина пообіцяла оплатити, назвала неправильний номер, просила передзвонити або відмовилася, і в момент розмови пише результат у картку amoCRM.
Завдяки цьому зниження повторних дзвінків стає помітним: не потрібно передзвонювати тим, хто вже дав відповідь, а спірні випадки одразу йдуть оператору.
Окремий показник — повнота фіксації. За ручного обдзвону частина контактів губиться: оператор не встигає заповнити картку, і база деградує.
У бота результат записується завжди, тому видно, скільки спроб знадобилося, у який час додзвін вищий і де ламається сценарій — це і є підстава перебудовувати графік і пріоритети обдзвону.
Варіанти голосового AI-бота: який режим вибрати під задачу
Режим контакту вибирають не за зручністю, а за структурою портфеля: чим коротше прострочення й однотипніший привід, тим вища частка розмов, які закриває автоматика.
На довгих строках і в спірних кейсах ціна помилки в діалозі вища, тому там потрібен оператор або гібридна схема з передачею на живу лінію.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повністю автоматичний обдзвін | Масові сегменти з повторюваним сценарієм: нагадування про строк, підтвердження обіцяного платежу, уточнення причини затримки | Не утримує діалог за нестандартних заперечень — у разі виходу за сценарій потрібна ескалація |
| Гібридний обдзвін | Середні строки прострочення, де частина розмов потребує людини, а частина закривається роботом | Потребує вільного оператора на лінії та налагоджених правил ескалації, інакше зростає час очікування |
| Ручний обдзвін операторами | Спірні та чутливі кейси: оспорювання боргу, скарги, домовленості про розстрочку | Обсяг контактів обмежений штатом, а формат розмови залежить від зміни та втоми оператора |
Межу між режимами задають правила ескалації: прохання з'єднати з людиною, спір щодо суми, емоційна мова або повторне запитання щодо одного пункту.
Коли правила описані, автоматичний обдзвін закриває прості контакти й фіксує результат, а оператор підключається лише там, де розмова дійсно цього потребує.
Етапи впровадження: від аудиту бази до передачі сценаріїв
Робота починається з аудиту бази та правил контактів: дивимося, які поля заповнені, де дублі та неробочі номери, як розмічені статуси боргу та згоди на контакт.
На виході — карта даних для черг обдзвону та перелік правил: часові вікна, гранична частота контактів, виходи у разі відписки або скарги.
- Аудит бази та правил контактів. Зводимо джерела в один формат, перевіряємо номери на валідність, прибираємо дублі. Фіксуємо, за якого статусу боргу та на який день прострочення дзвінок доречний.
- Схема інтеграції з телефонією. Визначаємо, як бот підключається до оператора: пул номерів, кількість одночасних ліній, розпізнавання автовідповідача, розрізнення «не відповів», «зайнято», «недоступний». Окремо — поведінка при обриві каналу.
- Налаштування сценаріїв. Збираємо логіку розмови: ідентифікація, сума та строк, гілки відповідей — «оплачу», «це не я», «немає можливості», спір щодо боргу. Кожна гілка веде або до фіксації домовленості, або до переведення на оператора.
- Пілотний запуск обдзвону. Проганяємо бота на обмеженій вибірці та слухаємо записи: де перебиває, де невірно зрозумів відповідь, де спрацювала не та гілка. Правки вносимо за фактом, а не за гіпотезами.
- Масштабування. Розширюємо вибірку, налаштовуємо чергу та пріоритети, стежимо за якістю розпізнавання на різних каналах зв'язку.
- Передача регламентів. Віддаємо опис сценаріїв, правила контактів, порядок правок та інструкції для операторів.
Сценарії та правила контактів далі живуть за статистикою дзвінків: цикл повторюється, а не закривається разовим запуском.
Що залишається у вас: конфігурації, регламенти, документація
Після запуску вся логіка обдзвону залишається у вас у вигляді робочих файлів і налаштувань, а не в листуванні з підрядником. Комплект нижче дозволяє вашій команді або іншому виконавцю змінювати сценарії, пороги та розклад без нашої участі.
- Сценарії діалогу — гілки розмови в редагованому вигляді: репліки бота, формулювання запитань, варіанти відповідей та умови переходів між кроками. Змінюєте текст або порядок — і самі публікуєте нову версію.
- Правила ескалації — за яких умов розмова переходить до оператора: прохання про людину, спір щодо суми, кілька нерозпізнаних відповідей підряд, відмова продовжувати. Пороги задані параметрами, а не зашиті в код.
- Схема інтеграції — карта обміну з вашою системою обліку: які поля йдуть на обдзвін, які повертаються, як фіксується результат додзвону та статус заборгованості.
- Регламент контролю якості — як вибірково прослуховувати записи, які показники дивитися (частка додзвонів, згод, ескалацій), з якою періодичністю і хто за це відповідає.
- Документація з обдзвону — логіка кампаній, розклад дзвінків, обмеження за частотою та повторними спробами, пояснення кожного правила людською мовою.
- Доступи та ролі — хто із співробітників що вправі змінювати: тексти, пороги, списки номерів, запуск і зупинку кампанії.
Передача відбувається з розбором: показуємо, де правиться кожен параметр, і відповідаємо на запитання вашої команди. Далі розвиток обдзвону не вимагає звертатися до нас за кожною правкою.
Кейс: як знизили навантаження на операторів і частку відмов
До пілота нагадування щодо прострочених платежів ішли цілком через операторський обдзвін. Частина бази не додзвонювалася з першої спроби, а формулювання в операторів розходилися, тому частка відмов від оплати трималася на одному рівні незалежно від кількості змін.
Як будували пілот
Запускали не на всьому портфелі: Ритейл-Кредит виділив сегмент з однотипним профілем заборгованості та розвів його на контрольну й тестову групи. Так різниця в показниках пояснюється сценарієм розмови, а не складом бази.
Голосовий AI-бот вів діалог за інтентами, які закривають більшість ситуацій: обіцянка платежу, уточнення суми, запит розстрочки, прохання передзвонити.
| Показник | До пілота | Після пілота |
|---|---|---|
| Додзвін з першої спроби | 4 з 10 | 7 з 10 |
| Частка відмов від оплати | 34% | 21% |
| Контакти, закриті без оператора | 0% | 58% |
| Строк до обіцянки платежу | 2 дні | 1 день |
Без оператора закривалося більше половини контактів: бот підтверджував особу, називав суму та дату, фіксував домовленість, а складні випадки передавав співробітнику разом з історією діалогу.
Оператори стали працювати зі скаргами та проханнями про реструктуризацію, де дійсно потрібна людина.
Що підтверджує замовник
Метрики звіряли за вивантаженням із системи обдзвону, а не за внутрішніми звітами команди. Замовник підтверджує: навантаження на операторів знизилося, а частка відмов від оплати перестала зростати — це й стало підставою масштабувати сценарій на решту бази.
Що робити, якщо у вас уже розгорнуто телефонію та облікову систему?
Якщо телефонія та облікова система вже працюють, міняти їх не потрібно. Голосовий AI-бот добудовується окремим сервісом між викликом і обліком: телефонія віддає лінію, бот веде розмову, результат повертається в облікову систему як звичайний запис про контакт.
Наявна телефонія використовується повторно майже повністю — маршрутизація, додаткові номери, запис розмов, черги та правила додзвону залишаються вашими. Ми додаємо окремий напрямок набору, за яким потрібний сегмент викликів іде в бота; на Asterisk це окремий контекст і черга. Клієнт бачить той самий номер, а оператор підключається лише там, де бот передає діалог людині.
Інтеграція з обліковою системою будується на її штатних інтерфейсах — програмному обміні, вибірках із бази або повідомленнях про події, — тому доопрацювань на боці обліку зазвичай не потрібно.
Бот читає суму, строк і статус заборгованості, а за підсумком пише обіцянку оплати, причину відмови або прохання про розстрочку. Запис ідемпотентний: повторний виклик не створює дубль, кожна дія прив'язана до ідентифікатора клієнта.
Добудовувати доводиться три речі: розпізнавання мовлення, логіку діалогу та фіксацію результатів.
Підключення без заміни систем іде поверх наявної інфраструктури, тому пілот запускаємо на одному сценарії та сегменті — розширення залежить уже від частки діалогів, доведених до результату.
Технічні сумніви: розпізнавання мовлення, затримки, інтеграції
Питання до голосового AI-бота зазвичай упираються в чотири теми: чи розбере він живу мову, чи не стане перебивати, куди йдуть персональні дані та наскільки швидко перебудовується сценарій. Нижче — відповіді по суті, без обіцянок «працює ідеально».
Єдиного «відсотка розпізнавання» не буває: якість залежить від каналу зв'язку, шуму, темпу мовлення та словника конкретної кампанії. Тому в сценарій закладається запас міцності — підтвердження ключових даних, перепитування та передача оператору там, де впевненість моделі низька.
Як бот справляється з поганим зв'язком і фоновим шумом?
Мовлення розпізнається потоково, за проміжними гіпотезами, а не після завершення фрази: бот реагує швидше й не втрачає сенс на обривах. Словник доповнюється предметними термінами — сумами, датами, назвами продуктів, які модель загального призначення плутає.
Критичні поля бот не «вгадує», а промовляє вголос і просить підтвердити; за кількох невдалих спроб розмова переводиться на оператора. Метрика для приймання — частка діалогів, доведених до підтвердженої домовленості, і кількість перепитувань на одну розмову.
Наскільки чутливий бот до пауз і чи можна його перебити?
Кінець репліки визначається за тишею, і поріг налаштовується: для людей, які говорять повільно або обдумують відповідь, очікування збільшується — інакше бот відповідає в порожнечу й розмова розсипається.
Зворотна ситуація теж закрита: людина може перебити, бот зупиняє відтворення й слухає до кінця. Окремо налаштовується максимальна тривалість паузи перед м'якою підказкою та коректне завершення при мовчанні.
Як захищені персональні дані боржників?
Записи та розпізнані тексти зберігаються у виділеному контурі замовника, а не в зовнішньому сервісі.
Чутливі поля маскуються в журналах, доступ розмежовано за ролями, кожне звернення до запису фіксується, строк зберігання задається політикою з автоматичним видаленням після закінчення.
Якщо запис розмови не потрібен, сценарій працює без нього — залишається лише текст для контролю якості.
Чи доведеться перезбирати бота при зміні сценарію?
Ні. Сценарій — це набір розгалужень з умовами та правилами ескалації, він версіонується, і правки — формулювання, порядок запитань, пороги передачі оператору — вносяться без зупинки роботи сервісу.
Нову версію можна включити на частину номерів і порівняти з попередньою за часткою підтверджених домовленостей, перш ніж розгортати на весь потік.
Обговоримо задачу: що потрібно від вас і з чого почнемо
Щоб повернутися з оцінкою та планом робіт, а не із загальними обіцянками, потрібен мінімальний набір вхідних.
Розмову починаємо з поточної схеми обдзвону: хто і в якому порядку потрапляє в роботу, які статуси заборгованості ви розрізняєте і що вважаєте успішним контактом — обіцянку платежу, уточнення дати чи відмову. Цього достатньо, щоб оцінити обсяг і запропонувати архітектуру діалогу.
- Зріз портфеля: скільки контактів на добу, частка додзвонів, розподіл за строками прострочення.
- Сценарії розмови та правила ескалації: у який момент голосовий AI-бот передає дзвінок оператору, а в який коректно завершує діалог.
- Інтеграційні вхідні: система обліку, доступні методи обміну — програмний інтерфейс, файловий обмін або черга подій.
- Обмеження режиму: допустимі години, частота контактів на клієнта, правила повторних спроб.
- Вимоги до фіксації: запис розмови, розшифрування, строк зберігання, розмітка результату.
- Юридична рамка: тексти згод, обов'язкові фрази, що бот не має права промовляти.
- Метрики приймання: частка обіцянок платежу, точність розпізнавання відповідей, кількість помилкових спрацювань на тисячу діалогів.
Стартуємо з пілота на вузькому сегменті та одному сценарії: збираємо реальні діалоги, розбираємо розшифрування, правимо логіку реплік і лише потім розширюємо на весь портфель. Результат порівнюємо з контрольною групою операторів — так видно ефект, а не відчуття. Опишіть задачу — повернемося з оцінкою та планом робіт.
