Впровадження Air AI: де ламається автономний телефонний обдзвін
Голосовий агент продажів упевнено проводить перші дві репліки — і розвалюється на третій. Він втрачає контекст: людина вже назвала місто, завдання й термін, а у відповідь знову лунає «а ви з якого регіону?».
Розмова ввічливо закінчується, у базі залишається позначка «нецікаво», хоча інтерес був. Це перше типове місце відмови автономного телефонного обдзвону, і воно повторюється в усіх, хто запускає агента без пам'яті діалогу.
Друге — стик із людьми. Агент доводить розмову до готовності обговорювати угоду і має передати контакт оператору, але передача рветься: клієнт чує тишу або повторне привітання, а співробітник отримує картку без історії розмови.
Відновлювати нитку з пам'яті не виходить, теплий контакт охолоджується за ті хвилини, поки триває перемикання.
Третє — стан бази. Один номер надходить із кількох вивантажень і обдзвонюється по колу, люди зляться й скаржаться, репутація номера падає, частка відмов зростає. Дублі шукають вручну вже після того, як зіпсовано враження.
Четверте — заперечення щодо ціни. На ньому відпадає найбільше діалогів: агент або читає загальний скрипт, або замовкає, замість того щоб уточнити завдання й запропонувати наступний крок.
У всіх чотирьох випадках вузьке місце обдзвону лежить не в якості розпізнавання мовлення, а в логіці діалогу та в стиках між системами. Розбираємо, як це закривається під час впровадження Air AI.
Що змінюється після запуску автономного агента у відділі продажів
Автономний агент продажів на базі Air AI бере на себе передбачувану частину обдзвону: підтвердження заявки, уточнення статусу, повернення до незавершеної угоди. Оператори підключаються лише там, де потрібен нестандартний хід — торг, умови, розбір претензії. Цей поділ змінює структуру зміни сильніше, ніж прискорення набору номера.
Перший ефект оцінюється за навантаженням: помітна частка повторюваних дзвінків знімається з операторів і переходить агенту — типові питання про замовлення, нагадування, повторні дотики.
Людям залишається робота, де вони реально впливають на угоду, тому розвантаження операторів видно і в якості розмов, і в рівному темпі зміни.
Другий — охоплення бази дзвінками. Агент працює паралельними лініями й тримає однаковий темп з ранку до вечора: за зміну опрацьовується більше записів, включно із сегментами, до яких у людей зазвичай не доходять руки. Конверсія обдзвону зростає не від тиску на клієнта, а від того, що до нього нарешті додзвонилися.
Третій — ескалація складної розмови. Коли діалог виходить за межі сценарію, оператор отримує розшифрування й контекст, підхоплення займає секунди, клієнту не потрібно повторювати себе заново.
Заодно зникає цілий клас відмов: недодзвони, скидання після першого гудка, заявки, що залишилися без відповіді наприкінці дня.
Налаштування під конкретний відділ — це правила маршрутизації, умови й формулювання передачі, синхронізація з CRM і журнал розмов. Ефект за кожним пунктом фіксується порівнянням зміни до й після запуску: за цими зрізами видно, де агент уже працює сам, а де ще потрібен оператор.
Режими роботи автономного агента та їхні обмеження
Режим запуску визначає не стільки охоплення, скільки клас збоїв, який доведеться розбирати. Агент упевнено веде діалог, але у вихідному обдзвоні він не знає, хто візьме слухавку, а на вхідній лінії сам дзвінок уже означає інтерес.
Один і той самий сценарій на різних потоках дає різну якість — тому режими ми обираємо до складання гілки розмови, а не після.
Сенс вибору — не «максимум автономії», а ціна помилки: де неправильна кваліфікація дешевша за пропущений лід, а де навпаки. Нижче чотири робочі варіанти та чесні обмеження кожного.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Повністю автономний вихідний обдзвін | Велика база, однотипний офер, короткий цикл угоди | Не розрізняє автовідповідачі та корпоративні лінії, не витягує торг і нестандартні умови |
| Гібридний обдзвін із підхопленням оператором | Дорогий лід, довгий цикл, складний продукт | Потрібен регламент ескалації та чергова зміна; затримка підхоплення ламає тон діалогу |
| Вхідна лінія | Прогрів попиту, запис на консультацію | Пікове навантаження й черги, потрібен запас каналів; емоційні звернення — не її профіль |
| Тільки кваліфікація ліда | Відсіяти нецільових і передати менеджеру | Угоду не закриває: фіксує бюджет, термін, роль. Залежить від повноти полів у картці |
Передача оператору — не аварійний сценарій, а налаштовуване правило. У сценаріях Air AI воно спрацьовує на повторному питанні, тривалій паузі, ознаках роздратування або прямому проханні з'єднати з людиною.
Оператор отримує розшифрування діалогу й уже зібрані поля, тому не перепитує й не втрачає контекст — просідання залишається лише на часі очікування.
Етапи впровадження: від аудиту дзвінків до передачі в підтримку
Етапи йдуть строго від даних до логіки: сценарій, зібраний до аудиту дзвінків, майже завжди переписується після перших тестових прогонів. Тому спочатку розбираємо, що вже відбувається на лінії, і лише потім проєктуємо діалог.
Нижче — маршрут впровадження Air AI; тривалість залежить від кількості ліній, обсягу інтеграцій і глибини опрацювання заперечень.
- Аудит дзвінків і воронки. Вивантажуємо записи, розшифровуємо й розмічаємо: де клієнт охолоджувався, які заперечення повторюються, де губилися готові угоди. На виході — карта діалогів і правила, яких агент зобов'язаний дотримуватися.
- Проєктування логіки. Вирішуємо, що агент веде сам, у який момент передає оператору, як реагує на мовчання, відмову та питання про ціну.
- Інтеграції. Підключаємо телефонію, облікову систему й календар: маршрутизацію, запис розмов, створення угоди та завдання після дзвінка.
- Налаштування сценаріїв діалогу. Збираємо репліки, гілки заперечень, паузи й розпізнавання ключових слів; кожна правка зберігається окремою версією зі швидким відкатом.
- Тестові прогони. Прогоняємо агента на історичних записах і внутрішніх дзвінках, звіряємо з еталонними відповідями й правимо гілки, де логіка розсипалася.
- Пілотний запуск. Вмикаємо агента на частині трафіку й дивимося конверсію в цільову дію, частку коректних передач оператору та кількість обривів.
- Виведення в бій і передача. Розширюємо частку трафіку й віддаємо регламенти: як правити сценарій, що робити при збої, хто відповідає за метрики.
Що залишається в замовника після здачі проєкту
Після впровадження Air AI ми передаємо не «доступ до особистого кабінету», а робочий комплект, за яким ваша команда сама править репліки, додає гілки й розбирає спірні дзвінки без нас.
Кожен артефакт закривається на прийманні: якщо за ним не можна відтворити поведінку агента, пункт вважаємо незданим.
- Карта діалогових гілок — сценарії діалогів із репліками, варіантами відповіді клієнта й точками виходу; під час правки тексту відразу видно, які гілки зачеплені.
- Правила ескалації — кому й у який момент агент передає дзвінок оператору: відмова від розмови, питання поза регламентом, повторний запит.
- Регламент якості обдзвону — як формується вибірка записів, за якими критеріями оцінюється відповідь і що стає приводом для розбору.
- Матриця доступів — хто править сценарії, хто змінює правила ескалації, хто бачить лише статистику; зміни в робочому контурі обмежені ролями.
- Схеми інтеграцій — куди надходить результат дзвінка, які поля обов'язкові та що відбувається при недоступності зовнішньої системи.
- Документація щодо агента — призначення блоків, версії сценаріїв, журнал змін і порядок відкату на попередню версію.
- Інструкції для операторів — що бачить людина при підключенні до дзвінка, як забирає контекст розмови та позначає підсумок.
Усе це зберігається в одному місці й оновлюється разом з агентом: новий сценарій не залишається без правил передачі та критеріїв перевірки.
Кейс: як відділ продажів повернув операторам складні розмови
Перед нами був відділ продажів дистриб'ютора з базою в кілька десятків тисяч контактів: менеджери закривали зміну на коротких дзвінках — підтвердити замовлення, уточнити адресу доставки, нагадати про повторну закупівлю.
Складні розмови про знижку, відстрочку та заміну асортименту відкладалися на «після обдзвону» й часто не відбувалися взагалі: клієнт був готовий обговорювати умови, а вільного менеджера поруч не було.
Вимірювання на зрізі бази показали, що близько 70% вихідних — короткі сценарії з передбачуваним результатом.
Охоплення за зміну впиралося в 120–150 контактів на оператора, а частка покинутих заявок — тих, де додзвонилися, але не передзвонили того самого дня — трималася на рівні чверті.
Що змінили в контурі
Агента збирали на Air AI під три гілки: автономний обдзвін щодо повторних закупівель, підтвердження й перенесення доставки, нагадування про незакриті заявки.
Логіку передачі задали жорстко: щойно клієнт переходить до умов угоди — знижка, відстрочка, обсяг партії — або двічі перепитує, дзвінок переходить живому оператору разом із розшифруванням та історією звернень. Агент не тисне: спірний діалог він закриває передачею, а не скриптом.
Що стало після
Охоплення бази за зміну зросло до 900 контактів на відділ за того самого складу, частка успішних передач на оператора — 84%, решта коректні відмови та прохання передзвонити пізніше.
Навантаження на операторів перерозподілилося: час, що йде на складну розмову, зріс з 20% до 65% зміни. Клас відмов «клієнт згоден, але ніхто не передзвонив» зник майже повністю — намір фіксується й ставиться в чергу.
Чим автономний агент відрізняється від робота за скриптом
Питання не в тому, чи відповідає система голосом, а в тому, хто керує лінією розмови. Сценарний обдзвін — це дерево гілок: на кожну розпізнану відповідь знаходиться заздалегідь прописаний вузол, і наступна репліка береться з нього.
Поки абонент іде очікуваними варіантами, усе працює передбачувано; на першому ж нестандартному формулюванні — «я вже клієнт, але тариф інший» — робот або переходить у гілку за замовчуванням, або скидає виклик.
Автономний агент працює інакше: він не обирає гілку, а веде стан діалогу. Мета дзвінка, зібрані факти, озвучені заперечення й домовленості зберігаються в контексті, і агент на кожному кроці вирішує, що уточнити, що перепитати й до чого повернутися.
Якщо людина перебила на середині, розмова продовжується з тієї самої точки, а не починається заново. Саме утримання контексту розмови відрізняє агента від робота: він може змінити лінію бесіди по ходу, залишаючись у межах заданих правил.
Звідси різні вимоги до сценаріїв. Для сценарного обдзвону проєктують повноту дерева: чим більше гілок закрито, тим менше скидань, а контроль іде за відсотком влучань у вузли.
Для агента описують правила й заборони — межі обіцянок, допустимі знижки та формулювання, політику ескалації — і перевіряють поведінку на наборі еталонних діалогів, включно зі спірними. Тестувати стає не «чи пройдено сценарій», а «чи не вийшов агент за межі».
Передача оператору теж влаштована по-різному. Робот віддає виклик за формальною умовою: натискання клавіші, повторне питання, перевищення часу очікування.
Агент передає за смислом — коли чує намір, який не має права закривати сам, або коли розмова відходить убік від мети дзвінка, і разом із викликом віддає історію діалогу та причину ескалації, щоб людина не починала з нуля.
Сумніви перед запуском: дані, інтеграції, якість
Перед запуском голосового обдзвону в технічної команди виникає один і той самий набір питань: персональні дані клієнтів, стикування з наявною телефонією, розпізнавання мовлення на поганій лінії та поведінка сценарію, коли абонент відходить убік.
Нижче — відповіді за кожним пунктом щодо впровадження Air AI.
Що з персональними даними та записами розмов?
Номери й історія звернень залишаються в обліковій системі замовника, до нашого контуру вони не переносяться. Згода на обробку та запис фіксується окремим кроком на початку діалогу, а сам запис вмикається політикою — за базою або за типом кампанії. Термін зберігання й доступ за ролями задає замовник.
Як це інтегрується в нашу телефонію та облікову систему?
Підключення йде через штатні інтерфейси телефонної станції — хмарної або на власному обладнанні — окремим вихідним маршрутом і тестовим номером. В обліковій системі на кожен дзвінок створюється картка: статус, розшифрування, посилання на запис, підсумок розмови. На час пілоту маршрут обмежується однією кампанією та частиною номерів.
Що буде на поганій лінії та при відході абонента від теми?
Розпізнавання працює з порогом впевненості: якщо він нижчий, питання перепитується або дзвінок передається оператору разом із розшифруванням. Сценарій будується на розгалуженнях за намірами, а не на жорсткій послідовності, тому повернення до найближчого кроку не ламає діалог.
Обговоримо завдання автономного обдзвону й повернемося з планом
Щоб оцінка проєкту спиралася на факти, а не на припущення, достатньо кількох вступних даних — їхній збір займає в замовника менше години, зате знімає половину питань щодо архітектури до старту робіт.
- Записи реальних дзвінків: 20-30 діалогів із різних сегментів і регіонів — за ними видно лексику, довжину реплік і типові заперечення.
- Поточна воронка: звідки приходять ліди, яка частка додзвонів, на якому кроці втрачається найбільше контактів.
- Обмеження щодо даних: де зберігаються номери та історія розмов, що не можна вивантажувати за периметр, чи є згоди на запис.
- Хто відповідає за інтеграції: телефонія, CRM, облікова система — потрібна людина, яка ухвалює рішення щодо доступів.
- Сценарії, які не можна автоматизувати: великі угоди, претензії, юридичні формулювання — їх одразу виводимо на оператора.
- Метрика пілоту: за яким показником ви будете вирішувати, що запуск удався — конверсія в підтверджену зустріч, швидкість опрацювання бази, частка коректно переданих заявок.
Опишіть завдання обдзвону у вільній формі або надішліть те, що є. Повернемося з оцінкою проєкту та планом впровадження Air AI: етапи, терміни, точки контролю й відповідальні інженери за кожним блоком.
