AI автообдзвін: де ламається ручна схема інформування
Поки база клієнтів вимірюється сотнями, ручний обдзвін тримається на ентузіазмі: оператор бере список, набирає номер за номером, позначає результат у таблиці.
Щойно йдеться про акцію з обмеженим строком, схема ламається — інформування клієнтів має вкластися у вікно, а не розтягнутися на тижні.
Вузьке місце — не кількість операторів, а профіль навантаження. Інформування про акцію йде хвилею: у перші години потрібне пікове навантаження на лінії, далі потік падає майже до нуля.
Тримати під пік постійний штат безглуздо, а швидко набрати людей не вийде: поки нових операторів вводять у курс, вікно акції вже закривається.
Друга проблема — якість даних. Оператор фіксує додзвін суб’єктивно («не взяв», «передзвонити пізніше»), і повторні спроби йдуть навмання. Частина бази випадає з обдзвону зовсім: зайняті номери, незручний час, відмова на середині скрипта.
Підсумок — охоплення нижче плану й жодної статистики щодо акції: скільки клієнтів реально дізналися про умови, порахувати нічим.
AI автообдзвін знімає цю залежність: автоматичний обдзвін акцій сам розводить базу за часом, повторює недодзвін і доводить інформування до кінця вікна. Нижче розбираємо, як це влаштовано і що саме зникає з ручної схеми.
Що дає AI автообдзвін: швидкість, охоплення, утримання
Швидкість: база йде в обдзвін за зміну, а не за тиждень
Кількість одночасних ліній не прив’язана до розміру зміни операторів, тому кілька тисяч номерів проходяться за години. Розклад спроб задається у сценарії: система додзвонюється у вікно, коли абонент імовірніше візьме слухавку, і не тримає лінію на довгих гудках.
Охоплення: доходять до номерів, які зазвичай відкладали
Оператор за зміну встигає близько сотні діалогів, і першими в чергу потрапляють най«гарячіші» контакти, а решту переносять. Автообдзвін проходить базу повністю, включно з вечірніми годинами та вихідними, а недоступні номери сам ставить на повтор.
Кожен дотик — статус додзвону, відповідь та інтерес до акції — фіксується в amoCRM, тому покриття видно за цифрами.
Точність розпізнавання: діалог не розвалюється на шумі
Мовлення розпізнається потоком, з урахуванням пауз і перебивань, тому короткі відповіді «так», «не зараз», «а які умови» не губляться. Якщо впевненість низька, система перепитує нейтральним формулюванням замість того, щоб обірвати розмову.
Утримання та розвантаження: оператор підключається лише до складного
Типове інформування про акцію закриває автообдзвін, а на операторів переходять ті, хто поставив питання щодо умов або заперечив — уже зібраним контекстом. Клієнт отримує нагадування про акцію або закінчення строку, поки інтерес живий, і частина бази повертається до покупки.
Режими роботи системи: порівняння підходів
Вихідний обдзвін про акції будується у двох базових режимах, і вибір визначає не розмір бази, а джерело приводу до дзвінка. У пакетному режимі список збирається заздалегідь за сегментом, кампанія йде вікнами в дозволені години й розбирається паралельними лініями.
У потоковому дзвінок ініціює подія — старт акції, зміна статусу клієнта в CRM, строк, що спливає — і виходить у набір одразу, поки повідомлення залишається актуальним.
Поверх обох режимів вмикається адаптивний діалог: система обирає наступну репліку за фактичною відповіддю абонента, а не за жорсткою гілкою.
Сценарії обдзвону задають рамки, офери та допустимі уточнення, а не дослівний текст, тому перевіряти доводиться розгалуження та обробку відмов.
| Режим | Коли підходить | Обмеження |
|---|---|---|
| Пакетний режим | Масове інформування за заздалегідь зібраним сегментом, дзвінки в дозволені години, передбачуване навантаження | Список застаріває на момент додзвону, реакція на відповідь надходить із затримкою |
| Потоковий режим | Оповіщення за подією, коли важливий момент: акція стартувала, заявка зависла, строк спливає | Потрібен стабільний канал подій і контроль піків — сплеск перетворюється на чергу та відсіви |
| Комбінований | Пакетна база плюс тригерні наздоганяння тих, хто не відповів | Складніше в налагодженні: дві логіки набору потрібно розвести, щоб абонент не отримав два дзвінки підряд |
На практиці обирають комбінований варіант: пакетний режим закриває основний обсяг, потоковий — наздоганяння та реакцію на події, а адаптивний діалог відповідає за якість розмови в обох.
Етапи впровадження: від аудиту до передачі в підтримку
Впровадження AI автообдзвону — не встановлення готового софту, а послідовність етапів із перевірюваним результатом на кожному.
Порядок міняти не можна: сценарій, написаний до аудиту телефонії, впирається в ліміти оператора, а інтеграція з CRM без налагодженої логіки додзвону плодить дублі.
- Аудит телефонії. Розбираємо нумерацію, ліміт одночасних ліній, якість каналів, роботу запису та правила оператора зв’язку. На виході — схема підключення та гранична швидкість обдзвону, вище якої зростає частка скидань.
- Налаштування сценаріїв. Збираємо логіку розмови: інформування про акцію, відповіді на типові питання, умови передачі живому оператору. Окремо фіксуємо, чого система не повинна казати — обіцянки, строки, персональні умови.
- Інтеграція з CRM. Пов’язуємо дзвінок із карткою клієнта: статуси, теги, запис розмови, заборона повторного додзвону щодо тієї ж акції. Без цього база засмічується дублями, а відписок стає більше, ніж відгуку.
- Тестування обдзвону. Прогін на контрольованій вибірці: дивимося частку розпізнаних відповідей, помилкові спрацювання, точність передачі смислу та коректність розгалужень. Розбіжності правимо до запуску на всій базі.
- Пілот і калібрування. Запускаємо на обмеженому сегменті, звіряємо фактичне навантаження на лінії та якість діалогів із розрахунковими. За підсумками підлаштовуємо темп обдзвону та формулювання.
- Передача рішення. Віддаємо документацію щодо сценаріїв та інтеграцій, регламенти правок, доступи й інструкції для підтримки. Далі систему можна розвивати своїми силами або з нами.
Пакет передачі: конфігурації, сценарії, регламенти
Передача йде не папкою з файлами, а робочою системою: кожен артефакт версіонується, лежить на вашій стороні й дозволяє запускати обдзвін, правити сценарії та підключати нові сегменти без нашої участі. Нижче — що саме входить до пакета і навіщо потрібен кожен документ.
- Сценарії діалогу — гілки розмови під кожну акцію: репліки, умови переходу до оператора, обробка відмови, повторні спроби та правила зупинки обдзвону, щоб не телефонувати повторно.
- Схема інтеграції — як система пов’язана з базою контактів, CRM і телефонією: точки обміну, формати вивантажень і поведінка за недоступності джерела.
- Політики доступу — ролі та області видимості, обмеження на вивантаження номерів і результатів, журналювання дій: видно, хто і коли змінював сценарій або вибірку.
- Регламент оновлення — порядок правок, прогін на обмеженій частині бази перед запуском на весь список і відкат до попередньої версії, якщо якість розмови просіла.
- Регламент супроводу — хто реагує на відмови, в які строки і як передаються зміни між вашою та нашою командою.
- Документація — опис змінних, статусів дзвінка, кодів помилок і типових звернень до підтримки.
- Інструкції для операторів — як розбирати спірні дзвінки, де дивитися зведення по кампанії та як вивантажувати звіт за підсумками акції.
Пакет зібрано так, щоб внутрішня команда могла вести обдзвін сама. Якщо обсяг акцій зростає або змінюється джерело даних — опишіть завдання, повернемося з оцінкою та планом доопрацювання.
Кейс: інформування бази лояльності в пікові години
Як було
Роздрібна мережа з базою лояльності близько 400 тисяч номерів: акції короткі, а вікно інформування — перша доба після старту. Обдзвін ішов із робочих станцій операторів, у два потоки, і в пікові вечори канали впиралися в межу лінії.
Частина бази отримувала дзвінок, коли строк акції вже спливав, а повний обхід займав близько трьох діб — гроші на акцію витрачалися, а до половини адресатів інформація не доходила.
Що змінили
Зібрали автообдзвін на базі телефонії, пов’язаної з amoCRM: черга за пріоритетом сегмента, вікна дзвінків з урахуванням часових поясів, обмеження на кількість паралельних ліній, повтори з інтервалами та розпізнавання автовідповідача, щоб не витрачати спробу на механічний голос.
Окрема політика — не телефонувати повторно тому, хто вже підтвердив участь, і миттєво закривати номер за всіма акціями після прохання «більше не телефонувати».
Що вийшло
| Показник | До | Після |
|---|---|---|
| Додзвін у першу добу | 18% | 64% |
| Повний обхід бази | ~3 доби | 9 годин |
| Відписки від розсилки | зростала від акції до акції | нижче 2% |
Пікове навантаження перестало бути вузьким місцем: потік дзвінків вирівнюється розкладом, оператори підключаються лише до тих діалогів, де потрібна людина.
Частка учасників акції, які здійснили покупку в перші два дні, зросла втричі — завдяки тому, що база дізнається про пропозицію, поки вона ще актуальна.
Чим відрізняється потоковий режим від пакетного?
Різниця режимів — у тому, де ухвалюється рішення про наступну репліку. У потоковому режимі розпізнавання, вибір відповіді та синтез ідуть безперервно, усередині одного з’єднання: система чує фразу й одразу озвучує реакцію, а затримка вкладається в природну паузу розмови.
У пакетному режимі сценарій і репліки готуються заздалегідь, обдзвін іде хвилями за завантаженим списком, а розбір відповідей і повторні спроби запускаються вже після завершення хвилі. Розгалуження закладено до старту — на ходу діалог не перебудовується.
За навантаженням режими поводяться протилежно. Потоковий тримає рівну кількість одночасних розмов і потребує резерву потужностей під пікову кількість ліній: не встиг відповісти — абонент почув паузу й поклав слухавку.
Пакетний прощає піки, черга розбирається за розкладом, але кожна хвиля спирається на заготовлений текст.
Потоковий режим чутливий до каналу: потік, який рушій синтезу на кшталт Yandex SpeechKit віддає порціями, рветься під час обриву зв’язку, тому з’єднання резервують і контролюють окремо. Пакетному обрив хвилі не критичний — непройдені номери просто потрапляють до наступної.
Для інформування про акції зазвичай беруть поєднання: додзвін і масовий прогін по базі — пакетно, вікнами, а зустрічне питання абонента йде в потокову гілку з відповіддю в темпі розмови.
Технічні сумніви: затримки, точність, інтеграції
Сумніви навколо автообдзвону зазвичай зводяться до чотирьох пунктів: чи встигає система відповідати в темпі живої мови, наскільки точно розуміє відповідь абонента, як стикується з поточною телефонією і що відбувається із записами розмов. Розбираємо кожен.
Чи почує абонент паузу перед відповіддю?
Ланцюжок «розпізнати — підібрати відповідь — озвучити» вкладається в природну паузу розмови. Якщо фраза довга і її треба осмислити довше, система подає коротку підтверджувальну репліку — мовчання не виникає. Темп пауз налаштовується під сценарій.
Наскільки точно розпізнаються назви акцій та імена?
Назви акцій, товарів і брендів додаємо до словника домену — без нього модель їх не чує. За низької впевненості система перепитує або переводить виклик на оператора, а не додумує. Частка перепитувань видна у звіті за кожним сценарієм.
Як обдзвін підключається до нашої телефонії?
Через штатний транк вашої АТС або її програмний інтерфейс: номери, маршрутизація та ліміти оператора залишаються вашими. Голосове меню та черги операторів продовжують працювати як раніше. Якщо лінії орендуються в нас, нумерацію погоджуємо окремо.
Що з безпекою даних і навантаженням?
Записи та розшифрування зберігаємо у вашому контурі або в нас із розмежуванням доступу та строком зберігання за вашим регламентом. Навантаження зростає додаванням ліній: сценарій і база контактів не змінюються, збільшується лише кількість одночасних викликів.
Обговоримо завдання: підберемо режим та оцінімо навантаження
Розкажіть, кого і з якою метою потрібно обдзвонити — за базою минулих покупок, за заявками на акцію або за сегментом, який давно не відкривав розсилки. Від цього залежить режим: обдзвін за розкладом, реакція на подію або наздоганяючий повтор через добу.
Далі повернемося з оцінкою навантаження — скільки одночасних ліній тримати, який темп набору витримає ваш оператор зв’язку і як розкласти дзвінки за часовими поясами, щоб не піднімати людей уночі.
- підбір режиму обдзвону під завдання: за базою, за тригером або змішаний, із правилами повторів і відсіканням зайнятих номерів;
- сценарій діалогу з гілками на «не цікаво», «передзвоніть пізніше», автовідповідач і передачу оператору, коли система не впевнена у відповіді;
- оцінка навантаження: пікова швидкість набору, кількість ліній, ліміти оператора зв’язку та поведінка за відмов на його боці;
- план впровадження за етапами — від підключення бази та зв’язку з вашою обліковою системою до тестових прогонів на малій вибірці;
- пілотний запуск на одному сегменті з прослуховуванням записів і правкою формулювань до виходу на повний обсяг;
- правила роботи з відмовами, ведення списку «не телефонувати» та звітність за додзвонами й тими, хто дійшов до акції.
Щоб обговорити завдання предметно, достатньо пари абзаців: обсяг бази, мета дзвінка та що вже налаштовано в телефонії. У відповідь надішлемо оцінку навантаження, план впровадження та склад пілотного запуску — з тим, що знадобиться з вашого боку.
