Від IVR для прийому показань лічильників до платформи голосових AI-агентів

Ще кілька років тому ми працювали над доволі типовим для українського ринку проєктом — системою прийому показань лічильників через телефон для енергетичної компанії.

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

Але реальність виявилась значно цікавішою.

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

І мова не лише про літніх людей.

Ми були здивовані, наскільки великим залишався відсоток дзвінків. А ще більше — коли дізналися, що в Україні досі є абоненти з дисковими телефонами.

Так, справжніми дисковими телефонами!)

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

Проблема піковості

Основна проблема полягала навіть не в самих дзвінках, а в їхній нерівномірності.

90% навантаження припадало буквально на кілька останніх днів місяця, коли абоненти масово передавали показання лічильників.

Це створювало класичну проблему call-центрів:

  • або тримати великий штат операторів «про запас»,
  • або отримувати величезні черги й незадоволених клієнтів.

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

Тому частину навантаження намагались перекласти на IVR.

Той самий:

«Натисніть 1...

Введіть особовий рахунок...

Введіть показання...»

Але, чесно кажучи, користувацький досвід у таких систем був доволі болючим.

Особливо коли:

  • люди помилялись при вводі,
  • губились у меню,
  • телефон не підтримував тоновий набір,
  • або просто кидали слухавку після третього рівня меню.

І саме тоді виникла думка:
а що як людина зможе просто говорити? Спочатку це був банальний Record(), який зберігав запис, потім ці записи прослуховувалися операторами поза піковий час, робилось внесення «заднім числом» що псувало деяку бізнес логіку. Ще, у деяких випадках, це породжувало додаткові дзвінки, клієнти переживали що через IVR показники не «дійдуть» і вони всерівно дзвонили «про всяк випадок».

Тут були перші спроби автоматизації аналізу цих записів транскрипції через Google STT і т.п.

Перші голосові AI-агенти: «конструктор» із кількох API

На той момент «класичний» voice AI виглядав приблизно так:

Телефонія → STT → LLM → TTS → телефонія

Де:

  • Asterisk або інший SIP-сервер приймав дзвінок,
  • STT (speech-to-text) перетворював голос у текст,
  • LLM генерувала відповідь,
  • TTS озвучував її назад абоненту.

Звучить просто.

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

Проблем вистачало:

  • latency між компонентами,
  • «рвана» розмова,
  • накопичення затримок,
  • нестабільність сторонніх API,
  • проблеми з interruption handling,
  • потрібно враховувати що у нас в країні є Україно та російськомовні люди, що впливає на якість STT
  • складність масштабування.

Особливо помітно це було саме у телефонії, де навіть зайві 500-700 мс затримки вже роблять діалог неприродним.

Проте навіть попри це результати виглядали дуже перспективно.

Люди значно краще взаємодіяли з голосовим агентом, ніж із класичним IVR.

Що змінив OpenAI Realtime API

Ситуація кардинально змінилась після появи OpenAI Realtime API.

Realtime API фактично прибрав необхідність «склеювати» окремо:

  • STT,
  • LLM,
  • TTS,
  • синхронізацію діалогу.
  • Нарешті можна було знизити навантаження з серверів телефонії. Тепер «голос» можна передавати без AudioSocket інтерфейсів напряму в OpenAI з сигналізацією SIP.

Натомість з’явилась єдина realtime-сесія з можливістю:

  • вести живу розмову,
  • переривати агента на ходу,
  • змінювати поведінку під час дзвінка,
  • викликати функції (логічно програмні виклики — обожнюю їх, де вже змішується і логіка функції програмування і prompt-інструкції)
  • інтегруватись із CRM та внутрішніми системами.

І головне — усе це стало звучати вже не як IVR, а як майже повноцінний оператор. Ще, з досвіду хочу додати що клієнтам комфортніше коли підчас розмови чути фонові шуми, що реалізували засобами Asterisk. Клієнти сприймають краще агента коли на фоні клацає клавіатура, є приємний шум робочого колл-центру.

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

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

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Доброго дня.
Чи проводили якісь порівняльні тести по навантаженню сервака якщо працювати з «першими голосовими АІ» та «Realtime API» ?

Тут слід розуміти що при realtime реалізації дзвінок взагалі направляється по SIP-у на openai сервер (так так прямо по SIP), а управління ним відбувається вже вебхуками.
Тому по факту, навантаження з серверу телефонії знімається взагалі, навантаження від дзвінка рівно таке ж, як від любого іншого простого дзвінка.

Класне рішення, ai вже до кожної бабці з дисковими телефонами добереться )

Наскільки ai agent вивозить діалог? Можна зробити «колцентр банку» і телефонувати що картка заблокована?

А ножем можна порізати хліб, а можна відрізати собі щось)
А так, діалог абсолютно природній, подібне відчуваєш коли говориш з ChatGPT чи Gemini в live режимі.

Підписатись на коментарі