Ми часто бачимо, як клієнти втрачають терпіння, пробиваючись через 4–7 рівнів тонального меню. «Натисніть 1, щоб... натисніть 2...» — такий DTMF-IVR дратує та відсіює до 40% дзвінків. Дослідження показують: 60% користувачів надають перевагу мовленнєвому інтерфейсу. Наш підхід — AI-IVR: система розуміє вільну мову, визначає намір за 1–2 запитання і маршрутизує дзвінок без кнопок. Ми впроваджуємо такі рішення останні 5 років, і замовники відзначають зниження часу обробки дзвінка на 30–50% та зростання задоволеності на 20 процентних пунктів. Це не просто заміна кнопок — це перехід від жорсткого дерева сценаріїв до адаптивного діалогу на основі LLM.
Проблеми, які вирішує AI-IVR
Традиційне тональне меню (DTMF) не справляється з нестандартними запитами, складно оновлюється та вимагає запам'ятовування послідовностей. AI-IVR на базі NLP (Natural Language Processing) та ASR замінює жорстке дерево сценаріїв гнучким діалогом. Клієнт каже: «У мене проблема з оплатою» — система сама розуміє, що потрібно в billing, і переводить.
Порівняння DTMF-IVR та AI-IVR
| Параметр | DTMF-IVR | AI-IVR |
|---|---|---|
| Навігація | 4–7 рівнів, кнопки | 1–2 запитання, мова |
| Покриття сценаріїв | Обмежено деревом | Необмежено (LLM) |
| Оновлення | Складно, потребує розробки | Промпт-файл |
| Для немобільних користувачів | Проблемно | Нормально |
| Вартість розробки | Низька | Середня (окупається за 3–6 міс.) |
Важливо: AI-IVR не вимагає повної заміни інфраструктури — ми інтегруємо його поверх існуючої АТС через SIP або API.
Як AI-IVR розуміє намір клієнта?
В основі — LLM (Large Language Model), наприклад GPT-4o або LLaMA 3, яка отримує розшифровку мовлення (ASR) і визначає намір. Ми використовуємо few-shot prompting: у промпт передаємо список доступних напрямків і приклади фраз. Модель повертає JSON з destination та confidence. Якщо впевненість нижча за 0.75 — система ставить уточнювальне запитання. Цей підхід обробляє 95% запитів без залучення оператора.
class AIIVR:
def __init__(self, routing_config: dict):
self.destinations = routing_config["destinations"]
self.llm = AsyncOpenAI()
async def handle_call(self, call: IncomingCall) -> str:
"""Обробляємо вхідний дзвінок — повертаємо destination"""
# Привітання
await call.say(
"Добрий день! Вас вітає {company}. Як я можу вам допомогти?"
)
# Слухаємо намір (до 8 секунд)
user_input = await call.listen(timeout_sec=8, silence_threshold_ms=800)
if not user_input:
return await self.handle_silence(call)
# Розпізнаємо намір та маршрутизуємо
route = await self.recognize_intent(user_input)
if route["confidence"] >= 0.75:
return await self.route_call(call, route["destination"])
else:
return await self.clarify_intent(call, user_input)
async def recognize_intent(self, user_input: str) -> dict:
destinations_description = "\n".join(
f"- {d['id']}: {d['description']}"
for d in self.destinations
)
response = await self.llm.chat.completions.create(
model="gpt-4o-mini",
messages=[{
"role": "system",
"content": f"""Визнач куди направити дзвінок.
Доступні напрямки:
{destinations_description}
Поверни JSON: {{"destination": "id", "confidence": 0.0-1.0}}"""
}, {"role": "user", "content": user_input}],
response_format={"type": "json_object"}
)
return json.loads(response.choices[0].message.content)
async def route_call(self, call: IncomingCall, destination: str) -> str:
dest = next(d for d in self.destinations if d["id"] == destination)
# Підтвердження маршрутизації
await call.say(dest.get("routing_message",
f"Переводжу вас у {dest['name']}..."))
if dest["type"] == "queue":
await call.transfer_to_queue(dest["queue_id"])
elif dest["type"] == "extension":
await call.transfer(dest["extension"])
elif dest["type"] == "bot":
await call.transfer_to_bot(dest["bot_id"])
return destination
Конфігурація напрямків (YAML/JSON)
Шляхи маршрутизації задаються в простому конфігу — додати новий напрямок можна без передеплою.
destinations:
- id: technical_support
name: "Технічна підтримка"
description: "Проблеми з сервісом, помилки, не працює"
type: queue
queue_id: tech_support_q
routing_message: "З'єдную з технічною підтримкою. Зачекайте, будь ласка."
- id: billing
name: "Оплата та рахунки"
description: "Питання оплати, рахунки, заборгованості, тарифи"
type: bot
bot_id: billing_bot
- id: sales
name: "Продажі та нові підключення"
description: "Підключити послугу, новий договір, тарифи"
type: queue
queue_id: sales_q
Які бізнес-показники покращує AI-IVR?
За даними Gartner, впровадження інтелектуального IVR знижує навантаження на першу лінію підтримки на 40–60%. AI-IVR обробляє до 80% дзвінків без участі оператора — це в 3 рази більше, ніж DTMF. Середній час розмови скорочується вдвічі. Економія на операторах досягає 50% при масштабуванні. За рахунок зниження навантаження ви можете перерозподілити персонал на складніші завдання.
Як AI-IVR інтегрується з існуючою АТС?
Інтеграція виконується через SIP trunk або REST API. Ми підключаємось до Asterisk, 1С-Бітрікс24, Cisco, Genesys та інших без повної заміни інфраструктури. Система працює як проміжний шар: приймає дзвінок, обробляє діалог і передає управління назад до АТС. Для on-premise використовуємо vLLM з квантизацією INT4 — це знижує витрати на GPU до 4 разів порівняно з FP16.
Чому latency критична для AI-IVR?
Якщо ASR + LLM займає більше 3 секунд, користувач кидає трубку. Ми використовуємо streaming ASR (наприклад, Whisper у реальному часі) та кешування інтентів для частих запитів. Типова latency p99 — 1.5–2 секунди. Для зниження затримок застосовуємо квантизацію моделей та інференс на Triton Inference Server.
Процес роботи
Ми впроваджуємо AI-IVR у кілька етапів:
| Етап | Тривалість |
|---|---|
| Аналіз сценаріїв та збір даних | 1–2 тижні |
| Проектування діалогів (prompt engineering) | 1 тиждень |
| Розробка та інтеграція з АТС | 2–3 тижні |
| Тестування (A/B, навантажувальне) | 1–2 тижні |
| Деплой та моніторинг | 1 тиждень |
Загальний термін для типового проекту — 4–6 тижнів. Для пілота з 3–5 напрямками — 2–3 тижні.
Що входить у роботу
- Документація: архітектурна схема, опис промптів, інструкція з додавання напрямків.
- Доступи: до системи логування та моніторингу (Grafana, ELK), до API для самостійного оновлення конфігів.
- Навчання: воркшоп для команди (4 години) з управління AI-IVR та донавчання на нових сценаріях.
- Підтримка: 2 тижні після запуску — щоденні стендапи та фікс багів за пріоритетом.
Типові помилки при впровадженні
- Занадто багато напрямків у промпті (більше 10) — знижує точність. Оптимально 5–7.
- Відсутність fallback-сценарію при тривалому мовчанні — система має перепитувати або переводити на оператора.
- Ігнорування latency: якщо ASR + LLM займає більше 3 секунд, користувач кидає трубку. Ми використовуємо streaming ASR та кешування інтентів.
- Погана обробка неоднозначних запитів — без уточнювального запитання клієнт може потрапити не туди.
Замовте демонстрацію AI-IVR під ваш сценарій — ми оцінимо проект за один день і запропонуємо рішення з гарантією результату. Отримайте консультацію інженера: наші спеціалісти допоможуть підібрати оптимальну архітектуру.