Автообдзвін боржників: де ламається ручне стягнення
Ручний обдзвін портфеля впирається в арифметику: боржник бере слухавку в одні години, а оператор працює зміну.
Спроби концентруються в першій половині дня, коли доступність нижча, тому недодзвон під час стягнення з'їдає до половини набору, а статус «не додзвонилися» часто маскує номер, до якого просто не дійшла черга.
Портфель у десятки тисяч записів за зміну відділ не обходить — частина карток не отримує жодного дотику тижнями.
Друге вузьке місце — людський фактор у скриптах. Під кінець зміни оператор прискорюється, скорочує обов'язкові блоки, по-різному фіксує обіцянку платежу, а розкид за часткою домовленостей між сильним і слабким співробітником сягає двократного. Порівняти такі дотики між собою не можна: немає однакового входу, отже немає й керованої конверсії.
Третє — втрата історії дотиків. Нотатки живуть у вільній формі та в різних місцях, єдиного журналу немає: клієнта, який уже погодив дату, обдзвонюють заново, а тими, кому не телефонували місяць, не займається ніхто.
За нерівномірного покриття портфеля дотиками прострочена заборгованість старіє — чим далі строк, тим нижча частка повернення, і наздоганяти її дорожче, ніж працювати вчасно.
Автообдзвін боржників закриває саме ці три місця: обдзвонює весь портфель за розкладом, додзвонюється в години максимальної доступності, тримає однаковий скрипт і пише кожен дотик у спільну історію. Розбираємо, як це влаштовано і з чого починається впровадження.
Що дає голосовий бот стягнення: вимірювані ефекти
Перше, що змінюється, — частка додзвону. Оператор фізично встигає одну-дві спроби за зміну, а голосовий бот стягнення проходить масив паралельно і телефонує в ті вікна, коли абонент частіше бере слухавку.
На зіставній базі частка контактів, що відбулися, зростає з 25–35% до 55–70%, і «телефонували — не взяв» перестає бути основною причиною нульового дотику.
Другий ефект — кратність повторних дотиків до боржника. Розклад спроб задається правилами: скільки разів на добу і на тиждень, з якими інтервалами, як розводяться будні та вихідні; ліміти частоти дотримує система, а не пам'ять оператора.
За кожним номером ведеться журнал дотиків, тому чотири-шість спроб замість однієї не перетворюються на нав'язливість і не створюють приводів для скарг.
Навантаження на операторів зміщується в бік складного. Бот закриває типові сценарії — нагадування, уточнення суми та строку, фіксацію обіцяного платежу, — а людина підключається там, де є заперечення або готовність обговорювати графік.
Частка рутинних дотиків у зміні падає приблизно втричі, а час, що вивільнився, іде на спірні та великі сегменти портфеля.
Третій пласт — класи відмов, які раніше просто губилися: «незручно говорити», «передзвоніть пізніше», «не туди потрапили», «немає часу». Бот фіксує причину, ставить завдання на новий дотик і повертає номер у чергу за потрібним правилом.
Історія та статуси синхронізуються з обліковою системою (1С та аналогічними), тож ефект автоматизації стягнення видно не на словах, а у звітах за сегментами: скільки контактів, які причини, яка частка дійшла до оплати.
Порівняння режимів контакту: бот, гібрид, оператор
Режим контакту — це не вибір «бот чи людина», а налаштування того, які стадії розмови автоматизовані, а де в діалог входить оператор.
У сценарії дзвінка це описується правилами: умови переведення, поріг упевненості розпізнавання мовлення, обсяг контексту, який бачить оператор при підключенні.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Автоматичний | Масові нагадування на ранніх строках прострочення: підтвердження особи, сума та дата платежу, посилання на оплату | Не веде спір про суму і не фіксує юридично значущі заяви — такі репліки одразу переводять на людину |
| Гібридний | Робочий варіант за замовчуванням: бот проходить скрипт і за заперечення чи низької впевненості розпізнавання підключає оператора | Без прописаних умов передачі оператор отримує дзвінок без контексту і починає розмову заново |
| Тільки оператор | Спірні нарахування, повторне прострочення, конфліктні випадки | Охоплення обмежене пропускною здатністю зміни: вручну обробляється лише частина бази |
Гібридний обдзвін дає керований компроміс: автоматичний режим контакту знімає з лінії до 80% типових розмов, а переведення на оператора спрацьовує за заданими умовами.
Оператор отримує розшифрування діалогу й уже названі дані — боржникові не доводиться повторюватися, розмова продовжується з тієї самої стадії.
Обмеження бота тут важливіші за його можливості: список стоп-фраз і заборона на обіцянки щодо суми боргу прописуються у сценарії окремо, щоб автоматика не виходила за межі дозволеного.
Етапи впровадження голосового бота стягнення
Впровадження голосового бота для стягнення починається не із запису голосу, а з розбору портфеля та правил контакту. Спочатку інженери визначають, які сегменти боргу автоматиці віддавати не можна, і лише потім проєктують діалоги — інакше бот масштабує помилки на весь обсяг.
- Аудит портфеля заборгованості та правил контакту. Розбираємо строки прострочення, суми, історію додзвону, обмеження за частотою та часом викликів. На виході — сегменти, де бот дає результат, і ті, що залишаються людям.
- Проєктування сценаріїв обдзвону. Гілки під кожен сегмент: підтвердження особи, сума та строк, обіцянка платежу, часткова оплата, відмова, спір. Для кожної гілки — правило зупинки та передачі оператору.
- Інтеграція із системою обліку. Бот отримує картку боргу та історію, повертає підсумок дзвінка, статус обіцянки платежу та запис розмови. Черга викликів розводиться за пріоритетами, щоб повторний обдзвін не йшов по закритих боргах.
- Правила ескалації. Фіксуємо, коли бот замовкає і кличе людину: конфлікт, скарга, юридичний запит, нестандартна реструктуризація. Окремо — ліміти спроб і паузи між ними.
- Перевірка на пілотній вибірці. Прогін на обмеженому сегменті під ручним контролем якості: частка коректно розібраних відповідей, частка обіцянок платежу, кількість помилкових спрацювань і причини зривів.
- Передача в експлуатацію. Регламенти, панель моніторингу, відповідальний за сценарії, порядок правок формулювань і відкат до попередньої версії діалогу.
Далі зміни йдуть тим самим циклом: гіпотеза, прогін на частині портфеля, замір, розкочування на весь сегмент. Так якість обдзвону зростає, а не деградує з часом.
Що передаємо після впровадження: артефакти та регламенти
Впровадження закінчується не демонстрацією бота, а передачею комплекту, з яким ваша команда працює без нас. Усе перелічене залишається у вас — у репозиторії та внутрішній базі знань, з версіонуванням та історією змін.
- Конфігурація сценаріїв — файли реплік, розгалужень і умов передачі на оператора: формулювання, паузи, реакція на заперечення правляться без участі розробника.
- Схема маршрутизації викликів — правила розбиття портфеля, вікна додзвону, ліміти спроб і частоти, порядок ескалації на живу лінію.
- Правила доступу до даних боржників — ролі, маскування персональних даних, журналювання звернень, строки зберігання та порядок відкликання доступу.
- Звітність — зрізи за додзвоном, часткою тих, хто дійшов до діалогу, обіцяними платежами та причинами відмов, з вивантаженням у вашу систему обліку.
- Документація щодо бота — опис логіки, точок інтеграції, словник намірів, інструкції для оператора й адміністратора.
- Регламент експлуатації — хто і коли змінює сценарії, як викочується нова версія, як відкочується невдала, що робити при збої інтеграції.
- Чек-лист приймання — сценарії перевірки на тестовому контурі, доступи, навчання вашої зміни.
Передача йде за цим чек-листом: ви самі вносите правку в сценарій, проганяєте її та відкочуєте. Після приймання бот обслуговується силами вашої команди — супровід підключаємо окремо, якщо це потрібно.
Кейс: зниження прострочення та зростання додзвону за портфелем
Точка старту
Портфель раннього стягнення обробляли вручну: оператори телефонували лише в робочі години та за актуальними номерами. До двох третин денного списку залишалося недоторканим, а повторні спроби впиралися в зайнятість — боржник перестав брати слухавку.
Додзвон тримався близько третини портфеля, обіцянки оплати підтверджували 8–10% додзвонених, і було не видно, на якому кроці абонент перериває розмову.
Що змінили
Частину портфеля перевели на автообдзвін боржників («Портфель раннього стягнення»): бот обходить весь список за вечір, розмічає відповіді за статусами — «не додзвонилися», «відмова», «готовий обговорювати» — і операторам віддає лише останній. Скрипт називає суму та дату, фіксує обіцянку оплати, а нагадування йде за день до строку.
Що стало
Додзвон зріс із третини портфеля до двох третин: спроби йдуть увечері та на вихідних, а кількість повторів підбирається за історією відповідей, а не за розкладом зміни. Частка обіцянок оплати серед додзвонених зросла приблизно вдвічі.
Частка портфеля, що йшла на глибшу стадію стягнення, скоротилася приблизно на чверть — за рахунок дотиків у перші дні прострочення.
Витрати ресурсів на один дотик перестали зростати разом із портфелем: до 70% контактів закриває бот, оператор займається лише результативними розмовами.
Чим автообдзвін боржників відрізняється від робота-нагадування?
Робот-нагадування програє заздалегідь записану фразу і на цьому закінчується. Він не слухає відповідь: натискання клавіші або мовчання в слухавці — єдиний сигнал, який він уміє розібрати. Такий обдзвін вирішує одне завдання — повідомити про борг, але не рухає розмову до оплати.
Автообдзвін боржників — це сценарій стягнення з розгалуженням діалогу. Система розпізнає мовлення і утримує контекст: пам'ятає, що людина вже сказала про строк, суму та причину прострочення, і повертається до цієї лінії через кілька реплік.
Репліки «оплачу після зарплати» і «це не мій борг» ведуть у різні гілки — з різними аргументами, тональністю та наступними кроками.
Головна розбіжність — у реакції на заперечення. Робот-нагадування скидає виклик або передає оператору за першого відхилення від сценарію. Повноцінний бот відпрацьовує типові заперечення сам: уточнює дату, пропонує розбити платіж, фіксує обіцянку і призначає контрольний дзвінок. Оператор підключається там, де діалог вийшов за межі — спір про суму, претензія, запит документів.
Друга розбіжність — фіксація результату розмови. У нагадування в системі обліку залишається позначка «додзвонилися», у сценарію стягнення — структурований підсумок: причина прострочення, названа дата платежу, досягнуті домовленості, посилання на запис і розшифрування.
Ці дані йдуть у CRM (інтегруємо сценарій із Salesforce та іншими системами обліку) і стають основою для наступного дотику й звітності за обіцянками.
Частка діалогів, доведених до конкретної дати оплати, відрізняється в рази — саме тому примітивне нагадування економить хвилини, а сценарій стягнення закриває заборгованість.
Технічні сумніви: законність, розпізнавання, облік
Сумніви щодо автообдзвону боржників поділяються на правові, технічні та облікові. Відповіді на чотири найчастіші — нижче.
На якій підставі бот узагалі телефонує боржнику?
Підстава — чинний договір і згода на обробку даних з інформуванням каналами зв'язку, закріплена в оферті або окремим пунктом.
Бот працює в тих самих межах, що й людина-стягувач: ліміти за частотою та часом контакту, ідентифікація того, хто телефонує, заборона на тиск і введення в оману. Скрипт і мовленнєві сценарії вичитує юрист до запуску.
Наскільки надійно розпізнається мовлення?
Модель навчена на реальних діалогах: тримає побутове мовлення, перебивання та різний темп. За низької впевненості — сторонній шум, поганий зв'язок, сильний акцент — бот не вгадує навмання, а перепитує нейтральним формулюванням. Після другої невдалої спроби дзвінок іде оператору разом із розшифруванням уже сказаного.
Що відбувається зі спірними репліками?
Бот розпізнає повороти поза скриптом: оспорювання боргу, заяву про банкрутство, прохання про розстрочку, погрозу скаргою. Такий діалог зупиняється і передається фахівцю з міткою причини, а не дограється за шаблоном. Репліки, де бот ризикує бути зрозумілим неправильно, у сценарій за замовчуванням не зашиваються.
Як результати обдзвону потрапляють у систему обліку?
Підсумок дзвінка — статус (додзвон, відмова, обіцянка платежу, невірний номер), аудіозапис і текстова розшифровка — іде в систему обліку за подією, без ручного перенесення.
Історія контактів залишається в картці, тому наступний дзвінок ураховує попередню розмову, а спірний запис можна підняти й переслухати.
Обговоримо задачу: як перевести стягнення на бота
Розмову про автообдзвін боржників продуктивніше починати не з опису бота, а з даних про портфель. На першій зустрічі ми розбираємо, з яких сегментів він складається, як розподілені строки прострочення і що вже дає поточна робота кол-центру. Так за одну розмову видно, де голосовий бот закриває обсяг, а де, як і раніше, потрібен оператор.
Підготовка до обговорення займає небагато часу, якщо відомості вже зібрані в одному місці. До розмови варто принести:
- вивантаження портфеля: строки прострочення, суми, історія контактів, канали, якими боржники виходять на зв'язок;
- чинні правила контакту з боржником: допустима кількість дзвінків, часові вікна, обмеження за частотою, заборонені формулювання;
- схему обліку: куди пишуться результати діалогу — облікова система, база стягнення, звітність;
- скрипти та часті заперечення: що оператори чують найчастіше і які відповіді вважаються коректними;
- очікувані метрики: частка додзвонів, частка обіцянок оплати, частка фактичних платежів після діалогу;
- обмеження щодо даних: де зберігається запис розмов, хто має доступ і скільки вона живе;
- точки ескалації: за якими ознаками діалог передається живому фахівцю.
За підсумками зустрічі ми повернемося з оцінкою та планом впровадження: сценарії обдзвону, схема стикування з обліковою системою, порядок запуску на одному сегменті та контрольні метрики.
Опишіть задачу в зручному вигляді — дзвінок, лист або вивантаження — і ми запропонуємо, з чого почати.
