Автоматизація обробки дзвінків: ШІ для Mango Office, Zadarma і Sipuni

Інтеграція AI в хмарну АТС: де ламається обробка дзвінків

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

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

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

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

Інтеграція AI в хмарну АТС закриває це не «роботом на вході», а зв'язкою подій. У хмарних АТС — Mango Office, Zadarma, Sipuni — є повідомлення про кожен виклик: скидання в черзі, очікування довше сценарію, повторний дзвінок із того самого номера.

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

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

Що змінюється після підключення бота до телефонної лінії

Інтеграція AI в хмарну АТС працює на рівні лінії та сценарію маршрутизації, тому перший вимірюваний зсув — час першої відповіді. Бот піднімає виклик на першому гудку, а не після того, як звільнився оператор: у пікові години це різниця між «відповіли одразу» і «передзвонимо».

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

Приймання викликів цілодобово перестає бути окремою зміною.

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

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

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

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

За цими даними дописуються сценарії — тому частка пропущених і час відповіді продовжують покращуватися після запуску, а не фіксуються на старті.

Порівняння режимів підключення бота до телефонії

Режим підключення визначає, що почує абонент у момент дзвінка і як поводитиметься бот у разі збою. Він же задає обмеження телефонної лінії: скільки одночасних з'єднань тримає номер і чи залишаться вільні канали під операторів. Нижче — три схеми, між якими реально вибирають під час інтеграції AI в хмарну АТС.

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

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

Етапи впровадження: від аудиту лінії до передачі в підтримку

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

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

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

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

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

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

4. Перевірка на тестових викликах. Проганяємо сценарії живими викликами: слухаємо записи, відзначаємо, де асистент не розпізнав намір або передчасно завершив діалог. Рахуємо частку коректно визначених запитів і частку звернень, закритих без оператора.

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

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

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

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

• Конфігурації сценаріїв — дерева діалогів з умовами переведення на оператора, обробкою мовчання й перебивань, гілками під нестандартні відповіді. Окремим переліком — фрази, на яких сценарій зупиняється і кличе людину.
• Схеми маршрутизації — розподіл за чергами, навичками та розкладом, резервні маршрути в разі недоступності групи або перевантаження лінії, окремо нічні й святкові вікна.
• Правила доступу до записів розмов — хто і на якій підставі слухає, терміни зберігання, знеособлення записів для тестових прогонів, журнал прослуховувань.
• Документація по лінії — карта обміну з обліковою системою, перелік тестових номерів, порядок відкату до попередньої версії сценарію.
• Регламент для операторів — як прийняти переведений дзвінок, що видно на екрані до підняття слухавки, як позначати підсумок розмови і куди передавати спірні випадки.
• Перелік приймання — контрольні дзвінки з очікуваною поведінкою за кожним сценарієм і умови, за яких лінія вважається не зданою.

Кейс: скорочення втрачених дзвінків і часу відповіді

До впровадження лінія працювала на межі: у ранковий пік частка прийнятих викликів падала до 71%, середній час відповіді тримався на 38 секундах, а кожен сьомий абонент скидав дзвінок, не дочекавшись оператора.

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

Розбір записів показав, що 4 з 10 звернень типові: статус заявки, перенесення візиту, адреса, години роботи. До хмарної АТС на Mango Office ми підключили шар обробки мовлення — без заміни провайдера й номерів.

Як працює маршрутизація

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

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

Після запуску частка прийнятих викликів зросла до 96%, середній час відповіді скоротився до 7 секунд, 41% звернень закривається без оператора.

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

Чим AI-бот на лінії відрізняється від голосового меню?

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

Ламається на першому ж нестандартному зверненні. Абонент не розуміє, до якого пункту віднести свій випадок, тисне нуль або першу-ліпшу цифру — виклик переходить не до того спеціаліста, і його переадресовують другий і третій раз.

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

AI-бот на лінії працює не за гілками.

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

Інженерно це переносить роботу зі схеми меню на модель: замість перемальовування дерева під новий привід достатньо доповнити набір намірів і правила пріоритету.

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

Далі розбираємо, як така інтеграція AI в хмарну АТС збирається на практиці — від підключення до потоку викликів до правил передачі діалогу оператору.

Технічні сумніви перед впровадженням

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

Складна розмова переходить до оператора?

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

Де зберігаються записи розмов і розшифровки?

У вашому контурі. Аудіо залишається у сховищі телефонії або у вашому об'єктному сховищі, текст — у базі з розмежуванням доступу. Терміни зберігання та правила видалення задаються політикою під ваші вимоги, а не налаштуванням за замовчуванням.

Що буде при збої зв'язку або розпізнавання?

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

Хто відповідає за систему після запуску?

Ми. Стежимо за метриками розпізнавання, оновлюємо словники під нові продукти й кампанії, розбираємо спірні дзвінки разом із вашою командою. Регламент реакції та точки контролю фіксуємо в договорі.

Обговоримо вашу задачу з обробки дзвінків

Опишіть задачу — скільки ліній і операторів, яка хмарна АТС використовується, що відбувається з пропущеними й короткими дзвінками зараз.

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

Що ви отримаєте з розмови:

• Розбір поточної схеми: черги, групи операторів, правила переадресації, нічні та святкові сценарії.
• План впровадження за етапами: що робимо першим, що після пілота, де точки контролю на кожному кроці.
• Оцінку строків за кожним етапом і список даних, які потрібні від вас.
• Порядок пілотного запуску на одній лінії: обмежений потік дзвінків, зрозумілі критерії приймання результату.
• Метрики пілота — частка коректно оброблених звернень, час до з'єднання з оператором, кількість втрачених викликів.
• Варіанти розвитку: повернення клієнта в чергу, передача оператору з готовим контекстом, звіт за причинами звернень.

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