Заявка ждёт человека
- Недоступность замечают поздно
- Клиент не получает понятный ответ
- Передача зависит от памяти команды
Поддержка и обращения · fallback
Оператор не отвечает — обращение так и ждёт его?
Fallback начинается не с догадки системы, а со статуса, таймера и понятной очереди для следующего человека.
Короткий ответ
Обращение можно переназначить, если оператор не принял его за согласованное время, недоступен или очередь требует вмешательства. Передача должна сохранить причину и нового владельца. Для этого достаточно статусов и правил; AI нужен лишь там, где сначала надо разобрать неясный текст обращения.
- Таймер привязан к понятному статусу
- Причина и новое назначение остаются в истории
- Клиент не получает два параллельных ответа
Сбой процесса
Обращение застревает не из-за отсутствия AI
Оператор ушёл со смены, занят или просто не увидел новое обращение — а оно остаётся закреплённым за ним. Клиент ждёт, а команде приходится вручную искать, кто может подхватить задачу.
Недоступность нужно считать обычным сценарием: заранее назначить таймер, резервный маршрут и человека, который увидит исключение.
Правила и AI
Статусы и таймеры работают без AI
Проверка доступности, ожидание реакции, резервная очередь и повторное назначение — это понятные правила. Их можно проверить и объяснить команде.
AI может предложить категорию, если обращение написано свободно. Он не должен сам закрывать обращение, отменять назначение или решать, что клиенту отвечать.
Граница решения
Если нет договорённости о дежурном, сначала нужен регламент
Когда команда не решила, сколько ждать и кто подхватывает обращение, автоматизировать пока нечего. Сначала нужен рабочий порядок действий.
После этого технический fallback помогает не забывать обращения, но не подменяет ответственность человека.
Схема процесса
Fallback при недоступном операторе
Передача происходит только после проверяемого условия.
- 01
Проверить статус
Система видит назначенного владельца и текущий статус обращения.
- 02
Запустить таймер
Ждём согласованное время для реакции или возврата в работу.
- 03
Передать по правилу
Назначаем резервного сотрудника или общую очередь.
- 04
Зафиксировать результат
Сохраняем причину, новое назначение и статус уведомления.
Два сценария эскалации
Выбор зависит от доступности резервной роли.
| Критерий | Резервный сотрудник | Общая очередь |
|---|---|---|
| Подходит, когда | Есть дежурный или заместитель | Нужна видимость всей команде |
| Плюс | Быстро понятен новый владелец | Не зависит от одного человека |
| Риск | Резерв тоже может быть недоступен | Нужен механизм забора из очереди |
До и после: отсутствие оператора
Fallback по правилу
- Статус доступности проверяется заранее
- Заявка уходит в резервный маршрут
- Неясные случаи остаются видимыми
Сценарий
Назначенный оператор не взял обращение в работу
После заданного таймера обращение получает статус «требует переназначения» и уходит дежурному. История сохраняет исходного и нового владельца.
- Статус
- Ожидает реакции
- Таймер
- Согласованный командой
- Fallback
- Дежурный или очередь
Таймер и состав резервной очереди определяются в регламенте команды.
FAQ
Частые вопросы
Нужно ли переносить обращение сразу?
Не всегда. Сначала задают понятное условие: статус, рабочее время и таймер. Мгновенный перенос может создать два параллельных ответа.
Кто должен видеть историю?
Как минимум руководитель процесса и сотрудники, принимающие обращения. История нужна для контроля, а не для наказаний.
Нужен ли AI?
Нет, если решение зависит от доступности и статуса. AI может быть вспомогательным для классификации текста, но не заменяет правила эскалации.
Когда автоматизация не нужна?
Если один оператор стабильно обрабатывает небольшой поток и отсутствие легко покрывается вручную по согласованному регламенту.
Следующий шаг
Покажите, где обращения остаются у недоступного сотрудника
Разберём статусы, рабочее время и текущий путь эскалации, чтобы определить понятный fallback.
Разобрать fallback обращений