Ми зіткнулися з ситуацією: клієнт чат-бота тричі перепитує одне й те саме, бот видає шаблони, клієнт роздратований. Замість того щоб передати діалог оператору з повним контекстом, система закриває чат або пропонує зателефонувати. Результат — втрата клієнта. Наш handoff-модуль вирішує це: оператор бачить історію, емоційний фон і причину ескалації за секунду. Handoff AI-бота до оператора забезпечує збереження контексту діалогу та створює безшовний handoff. Чат-бот з підтримкою оператора стає ефективним інструментом обслуговування.
Один із проєктів — інтернет-магазин з 50 000 звернень на місяць. Після впровадження handoff з контекстом час обробки скоротився на 35%. Оператори перестали витрачати час на з'ясування обставин, NPS зріс на 12 пунктів. Економія на FTE операторів склала до 40%. Бюджет інтеграції обговорюється індивідуально і залежить від складності сценаріїв та кількості інтеграцій.
Як визначити момент ескалації?
Використовуємо два типи тригерів: явні та автоматичні. Явні — коли клієнт пише «оператор», «жива людина» або натискає кнопку виклику. Автоматичні тригери запускаються на основі поведінки:
- Низька впевненість моделі (confidence < 0.6) за трьома послідовними повідомленнями.
- Негативний сентимент з погіршенням (score < -0.7, trend=worsening) — детекція frustrated customer.
- Тема потрапляє до списку «ескалувати завжди»: юрпретензії, погрози, VIP-клієнти.
- Циклічний діалог — користувач повторює питання різними словами, бот зациклився.
class EscalationDetector: def should_escalate(self, dialog: Dialog) -> EscalationReason | None: if self.explicit_request_detected(dialog.last_message): return EscalationReason.EXPLICIT_REQUEST if dialog.bot_confidence_history[-3:] == [low, low, low]: return EscalationReason.LOW_CONFIDENCE sentiment = self.sentiment_analyzer.analyze(dialog.last_5_messages) if sentiment.score < -0.7 and sentiment.trend == "worsening": return EscalationReason.FRUSTRATED_CUSTOMER return None Згідно з документацією Zendesk Handoff API, комбінація ML-моделі та правил підвищує точність ескалації до 92%.
Порівняння підходів: ML-модель з confidence і sentiment дає точність 92%, тоді як правила на регулярних виразах — лише 70%. Це на 31% вище. Модель краще розпізнає приховану незадоволеність.
| Підхід до тригерів | Точність | Складність впровадження | Приклад використання |
|---|---|---|---|
| Правила (regex, keywords) | 70% | Низька | Прості запити «оператор» |
| ML-модель (confidence + sentiment) | 92% | Висока | Детекція прихованої незадоволеності |
Що входить до пакету контексту?
Пакет контексту містить:
| Компонент | Вміст |
|---|---|
| Історія діалогу | Всі повідомлення з timestamps, метадані (канал, мова) |
| Профіль клієнта | Ім'я, історія замовлень, відкриті тікети, сегмент (VIP/звичайний) |
| Причина ескалації | Який тригер спрацював, значення confidence, сентимент |
| Пропозиція бота | Остання відповідь, яка не вирішила проблему |
| Детектована тема | Класифікована сутність (повернення, гарантія, скарга) |
| Зведення | Згенероване LLM коротке резюме діалогу |
В інтерфейсі оператора дані візуалізуються: дашборд з кольоровим кодуванням емоцій, картка клієнта, таймлайн діалогу. Оператор бачить проблему за секунду.
Маршрутизація виклику та очікування
При ескалації бот ставить клієнта в чергу до оператора з потрібними навичками та пріоритетом. Поки клієнт чекає:
- Бот повідомляє приблизний час очікування (оцінка за історією черги).
- Пропонує залишити контакти для callback — оператор передзвонить.
- Продовжує відповідати на прості питання, щоб клієнт не пішов.
async def initiate_handoff(dialog: Dialog, reason: EscalationReason): available_agent = await agent_queue.find_available( skills=classify_required_skills(dialog), priority=get_customer_priority(dialog.user_id) ) wait_time = await agent_queue.estimate_wait(available_agent) await bot.send(dialog.channel, f"З'єдную з оператором. Зачекайте ~{wait_time} хв.") await agent_dashboard.notify(available_agent, { "dialog": dialog, "reason": reason, "customer_profile": await crm.get_profile(dialog.user_id), "summary": await ai.summarize_dialog(dialog) }) Зворотна передача боту
Після завершення розмови з оператором бот може підхопити діалог з оновленим контекстом: що вирішив оператор, які дані уточнено. Це скорочує навантаження на підтримку при повторних зверненнях. Накопичується статистика ескалацій — регулярний аналіз причин дозволяє оновлювати базу знань, донавчати моделі та усувати прогалини у функціоналі бота.
Інтеграція з helpdesk-системами
Ми підключаємо handoff до будь-якої популярної платформи:
- Zendesk: Handoff API, створення тікету з контекстом.
- Freshdesk: Agent SDK для передачі контексту оператору.
- Bitrix24: Live Chat API, черги операторів, єдина CRM.
- Кастомні платформи: WebSocket + REST API.
Що входить у роботу з впровадження?
- Аудит поточних сценаріїв бота та налаштування тригерів ескалації.
- Розробка детектора (правила + ML-модель) під ваш use case.
- Інтеграція з CRM та helpdesk, налаштування дашборду оператора.
- Покриття тестами: юніт-тести детектора, інтеграційні тести handoff flow.
- Документація процесу та навчання операторів роботі з контекстом.
- Підтримка після запуску — моніторинг якості handoff та доналаштування.
В результаті ви отримуєте повністю налаштований handoff-модуль, документацію та навчену команду.
Приклад реалізованого проєкту
Для інтернет-магазину з 50 000 звернень на місяць ми впровадили handoff, який скоротив час обробки на 35% та підвищив NPS на 12 пунктів. Економія на FTE склала до 40%. Ключовий фактор успіху — точне налаштування тригерів та візуалізація контексту в дашборді оператора.Замовте консультацію з handoff-інтеграції. Отримайте демонстрацію функціоналу на вашому сценарії. Наш досвід — 5+ років в AI-рішеннях, понад 20 успішних handoff-інтеграцій.