AI-автообдзвін для win-back: повертаємо до 20% клієнтів, що пішли

AI автообдзвін: база клієнтів, що пішли, залишається неопрацьованою

Клієнт, який пішов, — це не закрита угода, а відкладений попит. Відмова майже завжди прив’язана до конкретного моменту: не зійшлися в ціні, не влаштував термін, змінився обсяг закупівлі.

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

Механіка провалу майже завжди однакова. Пропускна здатність відділу продажів повністю йде на гарячий вхідний потік, а повернення клієнтів, що пішли, лежить у черзі «коли звільнимося». Звільнитися не виходить: потік не закінчується.

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

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

Без розмітки за причиною відходу, давністю та активністю контакту будь-який дотик перетворюється на перебір наосліп, а втрата клієнтів після відмови виглядає як природний відтік, який нема з чим порівняти.

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

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

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

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

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

Результат кожного контакту падає в CRM карткою зі статусом і записом розмови, тому amoCRM і подібні системи залишаються для відділу продажів єдиним джерелом правди про клієнта.

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

Формати AI автообдзвону: сценарний, діалоговий, гібридний

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

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

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

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

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

Ці рамки ми прописуємо в конфігурації кампанії до запуску, щоб обдзвін не перетворювався на спам і не випалював базу.

Як ми запускаємо обдзвін: етапи інженерної роботи

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

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

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

Матеріальний результат роботи — не «нейромережа, яка телефонує», а набір артефактів, якими ваша команда керує сама.

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

• Сценарії обдзвону за сегментами win-back — розгалужені діалоги під конкретну причину відходу: ціна, простій, переїзд, перехід до конкурента. У кожному прописано репліки, уточнювальні запитання, умови повернення та точки м’якої передачі оператору.
• Правила обробки відмов — стоп-лист номерів, ліміт повторних контактів на один контакт, пауза між спробами та коректна реакція на прохання більше не телефонувати. Відмова фіксується як результат, а не як збій додзвону.
• Матриця доступів — хто із співробітників бачить номери, хто транскрипти, хто вивантажує звіти; окремі ролі для оператора, керівника напряму та підрядника після здачі.
• Журнал звернень — суцільний запис діалогів із розшифровкою, відміткою підсумку (повернення, відмова, недодзвін) та оцінкою якості за чек-лістом. За ним видно, які формулювання сценарію реально повертають клієнтів.
• Регламент ескалації — куди йде скарга, спірний кейс або питання за умовами: таймінг реакції, відповідальний, шаблон відповіді. Помилки розпізнавання не залишаються без розбору.
• Документація з обдзвону — внутрішня інструкція адміністратора: як оновлювати базу, змінювати голос і текст привітання, обмежувати години обдзвону, читати звітність і запускати тестовий прогін перед правкою.

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

Кейс: повернення клієнтів, що пішли, в послугах для бізнесу

До нас прийшла мережа послуг для бізнесу з базою 8 400 клієнтів, які не продовжили обслуговування за останні півтора року.

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

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

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

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

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

За перші два місяці 20% клієнтів, що пішли, повернулися до повторних угод, а сценарій обдзвону залишився в базі як робочий інструмент для наступних сегментів.

Що робити, якщо клієнти, що пішли, вже отримували розсилки

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

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

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

Друге — частота звернень: не частіше одного контакту за кілька тижнів, із наскрізним лічильником за всіма каналами, а не окремо за дзвінками та листами.

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

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

Сумніви перед запуском: що уточнюють наші інженери

Перед стартом кампанії замовники ставлять одні й ті самі запитання — не про модель, а про правову рамку та експлуатацію. Нижче — те, що наші інженери уточнюють і закривають на етапі налаштування, до першого додзвону.

Що робити з якістю бази контактів?

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

Як система розпізнає мовлення та відмови?

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

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

Чи можна зупинити кампанію на ходу?

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

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

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

• Вивантаження бази клієнтів, що пішли — сегмент, дата останньої покупки, історія звернень і ознака згоди на контакт. За нею рахуємо досяжну частку й одразу відсікаємо тих, хто просив не телефонувати.
• Критерій успіху — що вважаєте поверненням: повторна покупка, продовження підписки, запис на консультацію. Від цього залежить логіка діалогу та умова, за якої обдзвін зупиняється.
• Записи 10-20 реальних дзвінків або робочі скрипти менеджерів. На них будується тон мовлення, аргументи та обробка типових заперечень — без цього сценарій вийде збезліченим.
• Точки інтеграції — які системи повинні отримувати підсумок дзвінка й куди писати статус: ваша облікова система, телефонія, сховище записів.
• Правила та обмеження — години обдзвону, ліміт спроб на одного клієнта, вимоги до ідентифікації та строку зберігання записів розмов.
• Відповідальний з вашого боку — хто погоджує сценарій, приймає проміжні результати й підтверджує готовність до запуску.

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