Мы столкнулись с ситуацией: клиент чат-бота трижды переспрашивает одно и то же, бот выдаёт шаблоны, клиент раздражён. Вместо того чтобы передать диалог оператору с полным контекстом, система закрывает чат или предлагает позвонить. Результат — потеря клиента. Наш 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-интеграций.