Голосовий AI-бот: де ламається холодний обдзвін
Холодний обдзвін ламається не в діалозі, а раніше — на спробі додзвонитися. Значна частка бази не бере слухавку з першого разу: зайнято, скидання, незручний час.
Недодзвони накопичуються, повторні спроби з'їдають години менеджера, а частина контактів так і не отримує жодного дотику.
Коли розмова все ж почалася, спрацьовує друга точка збою — зрив на першому запитанні. Скрипт не підлаштовується під репліку, менеджер зачитує блок і не чує відповіді. Абонент кладе слухавку через кілька секунд, і в систему не потрапляє навіть факт розмови.
Кваліфікація лідів у такому режимі перетворюється на лотерею: хтось доводить до кінця, хтось кидає після третього заперечення.
Третя втрата — між дзвінком і записом. Підсумок фіксують з пам'яті наприкінці зміни, частина діалогів не доходить до системи, контакти дублюються, а статус у Битрикс24 розходиться з реальністю. Відділ працює за неповною базою і повторно телефонує тим, хто вже відмовився.
Далі — навантаження на відділ продажів. Основний час іде на нецільові контакти та додзвони, а не на гарячі заявки. Голосовий AI-бот знімає цю рутину: обдзвін іде всією базою паралельно, діалог підлаштовується під відповідь, результат іде в систему відразу після розмови. Розбираємо, як це закривається.
Що дає автоматизація обдзвону на практиці
Робот набирає базу паралельно по кількох лініях, фіксує додзвін, недодзвін і відмову від розмови, а передзвін тим, хто не відповів, ставить у чергу за розкладом.
З ручного обдзвону йде головна втрата — менеджер витрачає годину на два десятки номерів, з яких розмова трапляється у трьох. Частка додзвонів на тій самій базі зростає з 20–30% до 60–70% просто за рахунок того, що перебір номерів іде фоном і не залежить від зайнятості людини.
Швидкість першого дотику перестає залежати від зміни: заявка з сайту або з реклами обробляється протягом хвилини, включно з ніччю та вихідними. Лід не остигає, поки чекає ранку, а про факт розмови відразу з'являється запис у системі, а не в чужій пам'яті.
Кваліфікація будується на графі сценарію з обов'язковими полями: бюджет, термін, роль у компанії, поточне рішення. Репліки розпізнаються на льоту, потрібні сутності витягуються з мовлення, і менеджеру передається картка із заповненими полями, а не сухий номер.
Точність кваліфікації вимірюється часткою карток, що дійшли до зустрічі або рахунку без ручної перевірки.
Менеджери перестають бути фільтром холодної бази: їм залишаються дзвінки тим, хто вже відповів на запитання й підтвердив інтерес. Усі звернення збираються в єдиний журнал дзвінків — запис, розшифрування, позначки про пройдені кроки сценарію та статус угоди в amoCRM. Журнал дає розбір реальних заперечень і правку сценарію за фактами, а не за спогадами.
Порівняння режимів обдзвону та їхні обмеження
Вибір режиму обдзвону визначає не «розум» моделі, а ціна помилки в живій розмові. Скриптовий діалог іде деревом реплік: відповідь клієнта веде в описану гілку, тому результат відтворюваний і масштабується на всю базу.
Вільний діалог тримає контекст і переформульовує запитання під співрозмовника, але без обмежувачів іде від теми кваліфікації.
Гібридний режим знімає цей розрив: сценарій задає рамку та точки розгалуження, модель відповідає всередині них. Обробка заперечень стає керованою — заперечення потрапляє у свою гілку, бот відпрацьовує його за правилами й фіксує підсумок у CRM.
| Режим | Коли підходить | Де впирається |
|---|---|---|
| Скриптовий діалог | Масовий обдзвін холодної бази, короткі кваліфікаційні запитання | Фраза поза сценарієм ламає розмову, заперечення — лише заготовками |
| Вільний діалог | Тепла база, довгий цикл угоди, потрібні уточнення | Потребує обмежувачів теми та перевірки фактів |
| Гібридний режим | Змішані бази, різна глибина дотиків | Дорожче в підтримці: сценарій і гілки живуть разом |
| Автододзвін із тональним меню | Нагадування, підтвердження зустрічі, коротке опитування | Діалогу немає: відхилення від меню — скидання або очікування оператора |
Інтеграція з телефонією задає, що доступно на практиці: запис розмови, переведення на оператора в момент сумніву, розпізнавання ключових фраз для маршрутизації. Обмеження автоматизації лежать не в якості мовлення, а в контексті — згода на запис, чутливі теми, емоційний клієнт. Тому в будь-якому режимі закладаємо точку переведення на людину.
Етапи впровадження: від аудиту до передачі в підтримку
Порядок робіт тут не формальність: кожен наступний етап спирається на артефакт попереднього, і пропуск будь-якого з них повертає нас на крок назад уже з готовою системою.
Послідовність робіт
- Аудит обдзвону. Розбираємо записи та вивантаження: частка додзвонів за часом, типові заперечення, місця, де розмова обривається. На виході — перелік конкретних місць, де скрипт заважає, а не допомагає.
- Карта сценаріїв. Збираємо діалог як дерево: гілки за відповідями, формулювання, умови переведення живому оператору. Кожна гілка прив'язана до заперечення з аудиту, а не вигадана в переговорній.
- Налаштування інтеграцій. Двосторонній обмін із CRM: картка заводиться під час розмови, статус і запис підтягуються після, у разі збою — повторна спроба. Окремо закриваємо доступи та розмежування прав.
- Тестовий запуск. Обдзвін обмеженої вибірки та порівняння з групою операторів за часткою кваліфікованих лідів і кількістю помилок розпізнавання мовлення.
- Калібрування. За логами правимо репліки, паузи та пороги передачі — зазвичай дві-три ітерації до стабільного результату.
- Приймання та навчання. Регламенти, розбір спірних діалогів, навчання команди роботі з новою воронкою.
- Передача в підтримку. Залишаємо моніторинг, точки відкату та зрозумілий порядок правок сценарію.
Завершення кожного етапу підтверджується не звітом, а перевірюваним результатом: деревом діалогу, записом тестового дзвінка, записом у CRM. Так до приймання у замовника вже є робоча система, а не обіцянка її запустити.
Комплект постачання: сценарії, інтеграції, регламенти
Голосовий AI-бот іде в експлуатацію не як чорний ящик підрядника, а як набір артефактів у вашому контурі. Через місяць ви самі правите формулювання та правила переведення на живого оператора — і не ламаєте зв'язку з CRM, бо межі змін описані заздалегідь.
Передаємо за актом, із зазначенням власника кожного файлу: конфігурації, регламенти й тексти лежать у вашій системі версіонування, а не в листуванні з виконавцем.
- Сценарії діалогу — дерево гілок із критеріями кваліфікації, репліками на заперечення та умовами завершення; правляться в текстовому вигляді, без виходу в код.
- Схема інтеграції — зв'язки з телефонією, CRM і календарем: які поля та в якому напрямку йдуть, де точки збою та як вони обробляються.
- Матриця прав доступу — хто редагує сценарій, хто слухає записи, хто вивантажує журнал звернень.
- Регламент ескалації — за яких фраз або низької впевненості моделі діалог іде менеджеру, за скільки секунд і що той бачить у момент передачі.
- Інструкція для менеджера — як читати розшифрування, розбирати передачі та пропущені дзвінки, куди вносити правки у формулювання.
- Журнал звернень — розшифрування, мітки якості діалогу, причини відмов і поля для вивантаження у зовнішню звітність.
- Порядок оновлень — прогін нової версії сценарію на тестовому наборі, подання на частину трафіку, відкат до попередньої.
Кожен артефакт версіонується, тому видно, яка правка сценарію зрушила частку кваліфікованих лідів.
Кейс: обдзвін бази після виставки
Після виставки у замовника залишилася база на 4 200 контактів, і вона остигала швидше, ніж її встигали обдзвонювати. Два менеджери робили близько 90 дзвінків на день — повний прохід займав три тижні, і до третього тижня інтерес до розмови вже зникав.
Паралельно з ними обдзвін бази запустили через голосового AI-бота, пов'язаного з amoCRM: люди працювали за теплими контактами, бот — за залишком і повторними спробами.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Частка додзвонів за базою | 38% | 71% |
| Кваліфіковані ліди | 11% із тих, хто додзвонився | 26% |
| Конверсія в зустріч | 4% | 9% |
| Обробка всієї бази | 19 днів | 4 дні |
Зростання додзвонів дало не текст привітання, а повернення до недодзвонів: бот ставить контакт у чергу повторних спроб і пробує в різний час — ранок, обід, вечір. Ті, хто не бере слухавку в кабінеті вдень, відповідають з особистого телефону ввечері.
Кваліфікація йшла за фіксованим набором критеріїв — термін, роль у прийнятті рішення, чинний підрядник; відповіді падали в поля угоди, а менеджер отримував картку з розшифруванням розмови та оцінкою.
Швидкість обробки бази — наслідок того ж: бот не втомлюється і не переносить залишок на завтра. Звільнені години менеджери витрачали на зустрічі з кваліфікованими контактами, а не на перші дотики за холодною базою.
Чим голосовий AI-бот відрізняється від автоінформатора?
Автоінформатор — це односторонній обдзвін: він відтворює заздалегідь записаний текст і чекає одного — натискання клавіші. Розгалуження сценарію в ньому є, але будується лише на цифрі тонального набору: «натисніть один — дізнаєтеся про умови, два — з'єднаємо з менеджером». Сенс сказаного вголос система не розбирає взагалі.
Голосовий AI-бот працює з мовленням: розпізнавання мовлення йде в потоці, відповідь перетворюється на текст, а далі модель визначає намір — згоду, відмову, уточнювальне запитання, прохання передзвонити пізніше.
Різниця принципова: автоінформатор реагує на факт натискання, діалогова система — на зміст відповіді.
Звідси й різне розгалуження сценарію. В автоінформатора воно статичне: усі гілки намальовані заздалегідь, і якщо людина відходить убік від скрипта, дзвінок просто обривається.
Бот тримає стан діалогу — ставить уточнювальне запитання, перепитує погано почуте, повертає розмову до потрібної гілки, якщо клієнт відволікся або відповів не по темі.
Відповідь на запитання клієнта — другий вододіл. «Скільки це коштує», «у мене вже є система обліку, як це зв'язати», «я за кермом, передзвоніть» — для автоінформатора такі репліки шум, він їх пропускає повз. Діалогова система відповідає за базою знань і продовжує кваліфікацію з того місця, де зупинилася.
Практичний підсумок видно в структурі дзвінка.
В одностороннього обдзвону до кваліфікації доходять лише ті, хто готовий слухати запис до кінця й натискати кнопки; у діалогової системи розмова адаптується під темп і формулювання співрозмовника, тому до передачі в CRM доходить помітно більша частка контактів — і в картку йде не позначка «додзвонилися», а розшифрування з відповідями за критеріями кваліфікації.
Сумніви перед запуском: розбираємо по пунктах
Заперечення до голосового AI-бота майже завжди технічні, а не «робот це взагалі». Інженера цікавить, що відбувається, коли абонент говорить із машини, перебиває або кладе слухавку на середині кваліфікації — і як це відображається на даних, які доїдуть до CRM.
Саме тому в пілоті ми спершу перевіряємо поведінку на поганих лініях, а не якість мовлення на студійному записі.
Що робити з шумом і сильним акцентом на лінії?
Обробка йде до розпізнавання: придушення постійного фону, відсікання відлуння та розділення голосів, якщо в приміщенні говорять поруч. Далі — перепитування замість угадування: бот уточнює поле, якщо впевненість нижча за поріг, і не підставляє в CRM значення «на око». Модель налаштовується на реальні записи замовника, а не лише на еталонне мовлення.
Як бот реагує на перебивання та паузи?
Визначається кінець репліки за тишею та інтонацією, а не за фіксованою паузою, тому бот не говорить поверх абонента і не зависає на роздумах. Якщо людина перехопила ініціативу — бот дослуховує, повертає сценарій і продовжує з найближчого незаповненого поля.
Коли розмова передається оператору?
Передача спрацьовує за правилами: запит людини, складне запитання поза сценарієм, повторне перепитування на одному кроці, негативна реакція. Оператор отримує дзвінок разом із уже зібраним контекстом та історією реплік — йому не потрібно починати діалог з нуля.
Що потрапляє в CRM і як оновлюється сценарій?
Кожен дзвінок залишає запис, розшифрування, заповнені поля та причину закриття — статус ліда проставляється за підсумком розмови, а не вручну. Сценарій змінюється в конструкторі: нова гілка, формулювання або правило передачі йдуть у роботу без перезбирання рішення. Контроль якості — вибіркове прослуховування та метрики за кроками сценарію.
Обговоримо задачу: план обдзвону під ваш потік лідів
Щоб повернутися з оцінкою та планом, а не із загальними формулюваннями, нам потрібен склад вхідних даних за вашим потоком лідів. Нижче — те, що ми запитуємо на першій розмові: за цими даними готуємо технічне завдання та рахуємо обсяг робіт.
Частина пунктів закривається на дзвінку, частина — вивантаженням із CRM і записами поточних обдзвонів.
- Мета обдзвону та критерії кваліфікації: які відповіді переводять контакт у цільовий, а які коректно закривають розмову.
- База та її стан: звідки надходять номери, як часто оновлюються, чи є згода на обробку та як враховуються відмови.
- Сценарій діалогу: типові гілки, ключові запитання, часті заперечення та поведінка голосового AI-бота при автовідповідачі, скиданні або мовчанні.
- CRM і маршрут даних: система, обов'язкові поля картки, правила створення угоди, хто отримує повідомлення про цільового ліда.
- Телефонія та навантаження: оператор, виділені номери, скільки викликів на годину потрібно тримати одночасно і в якому вікні за часовими поясами.
- Голос і подача: чи потрібен запис вашого диктора, мова та звертання, що бот промовляє в перші секунди розмови.
- Критерії приймання: на якій вибірці перевіряємо якість, що вважаємо успішним дзвінком, які звіти потрібні за підсумками зміни.
Зібраних даних достатньо, щоб зафіксувати етапи, порядок запуску та точки контролю. Опишіть задачу — повернемося з оцінкою та планом, а після погодження одразу почнемо зі збірки сценарію та зв'язки з CRM.
