Очередь операторов

Hand-off живому человеку, когда бот не справляется. Интерфейс, статусы, приоритеты.

Если агент не справился или клиент попросил человека — разговор попадает в очередь, где живой оператор его подхватывает. Без потери истории, без повторных вопросов. Это обязательная часть любого production-бота.

Зачем нужно

Никакой LLM не решит 100% случаев. Примите это как факт и проектируйте с учётом. Типичная статистика на production-ботах:

60-80% случаев — бот решает сам.
10-25% — нужен человек (сложный случай, жалоба, нестандарт).
5-10% — клиент сразу просит человека, ничего не обсуждая.

Hand-off на оператора — не костыль, а обязательный элемент нормальной системы. Без него:

Клиенты с жалобами остаются без решения → репутация компании падает.
Сложные сделки (крупная сумма, нестандартный запрос) — теряются.
Регулируемые кейсы (фин. консультация, мед. советы) — юридически рискованны без участия человека.

Что даёт хорошо настроенный hand-off

Сохранение истории

Оператор видит, что клиент говорил боту — не переспрашивает, не раздражает.

Эскалация без трения

Клиент даже не замечает момент передачи (для голоса — с автоматическим TTS).

Distribution по приоритету

Жалоба в красной зоне → быстро берут. Простое уточнение → в общей очереди.

SLA контроль

Если клиент ждёт дольше 60 сек — карточка становится красной, уведомляет супервайзера.

Возврат боту

Оператор решил главное → отдаёт дальше боту, освобождает руки для следующего клиента.

API-интеграция

Можно использовать не наш интерфейс оператора, а свой help-desk / колл-центр через API.

Три триггера передачи

Во flow есть нода transfer-human. Когда разговор её достигает, сессия помечается waiting_human и всплывает в очереди.

Типичные условия для срабатывания:

Клиент три раза подряд не дал валидного ответа на вопрос.
LLM вернул «не знаю» или признал, что не понимает.
Клиент использовал слова-триггеры: «жалоба», «претензия», «оператор», «человек», «живой» и т.п.
Сработало бизнес-правило: сумма заказа > 100К рублей → только с менеджером.
Специфичные темы: юр-вопросы, жалобы на здоровье, финансовые риски.

Реализация: intent-router или decision-нода во flow → если условие выполнилось → transfer-human с параметрами priority и reason.

Пример:

[intent-router]
  ├─ intent = "complaint" → [transfer-human, priority=9, reason="Жалоба"]
  ├─ intent = "legal_q"   → [transfer-human, priority=7, reason="Юр. вопрос"]
  └─ ...

Кнопка «Соединить с человеком» в чат-виджете. Простой и очевидный выход для клиента.

Для голоса агент распознаёт фразы:

«Дайте мне человека / оператора / живого сотрудника».
«Я хочу поговорить с менеджером».
«Переключите на [имя]».
«Соедините с офисом».

Все эти фразы в системном промпте агента привязаны к немедленному вызову transfer-human с priority=5 (стандартный).

Нюанс: не все просьбы про «человека» должны срабатывать. Если клиент говорит «я человек», «по-человечески объясните» — это не триггер. LLM обычно корректно различает.

Супервайзер видит разговор в live-списке и перехватывает. Это не триггер, а принудительная передача от имени оператора.

Когда полезно:

VIP-клиент зашёл в чат — бот обслужит, но вы хотите лично.
Видите, что бот «завис» на странном диалоге — вмешиваетесь.
Нужно сделать апсейл на конкретной сделке — встреваете в конце разговора бота.
Тренировка операторов — супервайзер смотрит и подстраховывает.

Как работает: в списке активных сессий нажимаете «взять» → статус меняется с ai_active на human_active, бот замолкает, вы начинаете отвечать.

Статусы сессии

Жизненный цикл в одной картинке:

    [ai_active]
       │
       ├─ бот сам или клиент попросил → передача
       │
       ▼
  [waiting_human] ─── оператор берёт ──▶ [human_active]
                                              │
                                              ├─ оператор закрывает ─▶ [closed]
                                              │
                                              └─ оператор возвращает ─▶ [ai_active]

Статусы:

ai_active — общается бот. Основной статус для 70-90% сессий.
waiting_human — ждёт оператора в очереди. Визуально подсвечивается по приоритету и времени ожидания.
human_active — разговор ведёт живой оператор. Бот молчит, но слышит / видит всё.
closed — разговор завершён. Архивная запись, доступна для просмотра и аналитики.

Работа оператора

Интерфейс «Очередь»

В сайдбаре слева — пункт Очередь. Три колонки:

Ожидают (waiting_human)

Сортировка: приоритет × время ожидания. Самые критичные наверху. Цветовая индикация SLA.

Мои (human_active)

Сессии, которые я взял и активно веду. Параллельно — обычно 2-5.

Завершённые (closed)

Мои сессии за последние 24 часа. Для пересмотра / переоткрытия.

Процесс взятия сессии

Нажмите «Взять» на карточке

Сессия исчезает из «Ожидают» (не может быть взята другим оператором благодаря anti-double-pickup). Переходит в «Мои».

Открывается рабочее окно

Слева: профиль клиента

Имя, телефон, email.
История прошлых сессий (если есть).
Значения слотов, собранных ботом.
Привязанные CRM-данные (если есть интеграция).

Центр: хронология разговора

Все сообщения клиента, бота, ваши.
С момента вашего взятия бот замолкает.
Можно прокрутить вверх и увидеть, что клиент говорил боту.

Справа: инструменты оператора

Подсказки от ИИ (по вашему запросу — «что ответить?»).
Поиск по базе знаний.
Быстрые действия (перевод на коллегу, создание тикета).
Заметки (видны только коллегам, не клиенту).

Ответ клиенту

Печатаете в поле ввода → Enter → сообщение уходит клиенту тем же каналом, что и сессия (чат / голос / SIP).

Для голосовых сессий: ваш текст автоматически озвучивается TTS. Ответ звучит голосом того же бота — клиент не замечает момента передачи. Плавный hand-off.

Закрытие или возврат боту

Когда вопрос решён — выбираете один из трёх вариантов:

«Закрыть» → статус closed. Диалог в архиве.
«Вернуть агенту» → статус ai_active, бот продолжает разговор с того же места.
«Передать коллеге» → сессия идёт в очередь с вашим выбранным приоритетом и заметкой.

Быстрые действия оператора

/note — добавить внутреннюю заметку, не видимую клиенту.
/transfer @sergey — передать коллеге напрямую.
/close — закрыть сессию.
/kb поиск — быстрый поиск в базе знаний.
/suggest — попросить ИИ предложить ответ (AI-assist).

Приоритет в очереди

Сессии в waiting_human сортируются по:

Приоритет (0-9)

Задаётся нодой transfer-human в flow. Примеры:

0-2 — любопытствующие, не срочные вопросы (по умолчанию нет).
3-5 — стандартные эскалации (клиент просто попросил человека).
6-8 — сложные кейсы (юр. вопрос, нестандарт).
9 — критичные (жалоба, конфликт, клиент грозит судом).

Выше приоритет — выше в списке у оператора.

Время ожидания

При одинаковом приоритете — чем дольше ждёт, тем выше. Предотвращает «забытость» сессий в общей массе.

SLA

Если план или канал имеет SLA (например, 60 секунд), карточка становится красной после превышения. Визуальная тревога для оператора и супервайзера.

Отображение причины

На карточке видна причина эскалации (поле reason из ноды transfer-human):

«Жалоба» — красным цветом.
«Юр. вопрос» — оранжевым.
«Не понял после 3 попыток» — жёлтым.
«Клиент попросил человека» — зелёным (не критично).

Оператор сразу понимает контекст до открытия сессии.

Live-обновления

Очередь подключена к SSE-стриму. Новые сессии появляются в реальном времени, без перезагрузки страницы.

Уведомления

Звуковой сигнал при новой сессии (настраивается в личном профиле оператора, можно отключить).
Цветовая индикация превышения SLA.
Счётчик на favicon — количество ожидающих сессий, видно в соседней вкладке браузера.

Мобильный интерфейс

Есть мобильная версия (responsive). Супервайзеры могут мониторить с телефона.

Несколько операторов

Anti-double-pickup

Один оператор взял сессию → она скрывается у всех остальных. Нет ситуации «два оператора одновременно пишут клиенту».

Технически: при клике «Взять» — атомарная операция в БД, владельцем становится один, другие получают свежий список.

Параллельная работа

Оператор может вести несколько сессий одновременно (обычно 2-5). Настраивается лимит в настройках роли оператора.

Типичные лимиты:

Текстовые чаты: 3-5 параллельно.
Голосовые звонки: 1 активный (физически не может параллелить).
Комбинация: 1 звонок + 2-3 чата.

Timeout и возврат

Если оператор «исчез» (закрыл вкладку, уснул, отвлёкся):

После таймаута (по умолчанию 3 минуты без ответа) сессия возвращается в очередь с пометкой «возвращена от оператора».
Клиенту в это время виден индикатор «Собеседник печатает…» чтобы не думал, что его забыли.

Метрики

Ключевые показатели здоровья очереди. Смотрите в Очередь → Статистика или на дашборде.

KPI для супервайзера

AWT (Average Wait Time) — среднее время ожидания в очереди. Цель: <60 сек.
AHT (Average Handling Time) — средняя длительность разговора с оператором. Цель: 3-5 мин (дольше — оператор не эффективен, короче — может быть недорешённый вопрос).
Эскалации/день — сколько раз за день бот передавал человеку. Растёт = бот деградирует. Падает = бот улучшается.
SLA compliance — процент сессий, взятых в SLA. Цель: 90%+.
CSAT (после разговора, если настроен опрос) — оценка клиента. Цель: 4+ из 5.

KPI для отдельного оператора

Сессий в день — сколько обработал.
Среднее AHT — скорость.
CSAT по его сессиям.
% возвратов боту — сколько отдал обратно (хороший показатель — 30-50%, меньше — оператор «за всё отвечает», больше — уходит в лень).
% повторных обращений — если клиент вернулся в течение 7 дней с той же проблемой → оператор не решил в первый раз.

Интеграция с внешним колл-центром

Если у вас уже есть help-desk / колл-центр (Zendesk, ServiceNow, Freshdesk, самописный) — можно использовать его вместо встроенного интерфейса оператора.

Как это работает

Платформа отдаёт события очереди через SSE-стрим (GET /operators/queue/stream). Ваша система подписывается, получает:

Новую сессию в очереди (с полной историей).
Обновление статуса сессии.
Новое сообщение клиента.

Ваши операторы работают в знакомом интерфейсе. Платформа — только «движок» для AI-части.

REST API

GET /operators/queue/stream — live-стрим новых событий.
GET /operators/queue — снапшот текущей очереди.
POST /operators/sessions/:id/claim — взять сессию.
POST /operators/sessions/:id/send-message — ответить клиенту.
POST /operators/sessions/:id/close — закрыть сессию.
POST /operators/sessions/:id/return-to-ai — вернуть боту.
POST /operators/sessions/:id/transfer/:userId — передать коллеге.

Подробные OpenAPI-спеки — в разделе Архитектура.

Типичная интеграция

Ваш help-desk подключается к SSE-стриму AG0NTS.

При появлении новой сессии — создаётся тикет в help-desk с полным контекстом (история, слоты, метаданные).

Оператор отвечает в вашем интерфейсе.

Ответ через API уходит обратно в AG0NTS, клиент получает.

Закрытие тикета в help-desk → автоматическое закрытие сессии в AG0NTS.

Права

Роли в воркспейсе (см. раздел Основные понятия):

Viewer — только смотрит статистику очереди.
Operator — видит очередь, берёт сессии, отвечает.
Engineer — всё выше + настраивает flow-эскалации.
Admin — всё выше + настраивает приоритеты, SLA, лимиты параллельности.

Отладка типичных проблем

Паттерны для эффективной работы команды

Паттерн 1: двухуровневая поддержка

Уровень 1: бот + простые операторы (2-3 мин на сессию).
Уровень 2: опытные специалисты (сложные случаи, 10+ мин на сессию).

Бот передаёт L1. L1 решает типовое или эскалирует L2.

Экономика: L1 = $10/час, L2 = $25/час. Если 80% L1 справляется сам, а 20% идёт на L2 — средняя стоимость разговора снижается на 40% по сравнению с «все операторы L2».

Паттерн 2: тематические очереди

Очередь «Продажи» — приоритет на новых клиентов.
Очередь «Поддержка» — действующие клиенты.
Очередь «Жалобы» — только жалобы, берут опытные.

Разделение через reason ноды transfer-human. Разные операторы видят разные очереди.

Очередь операторов

Сохранение истории

Эскалация без трения

Distribution по приоритету

SLA контроль

Возврат боту

API-интеграция

Ожидают (waiting_human)

Мои (human_active)

Завершённые (closed)

Сессии не появляются в реальном времени

Оператор ответил, клиент не получил

Сессия не передаётся на оператора из flow

Операторы жалуются «неудобно»

CSAT падает

Биллинг →

On this page