Настройка сценариев маршрутизации обращений
Каждый руководитель службы поддержки сталкивался с ситуацией, когда обращение клиента «зависает» в очереди, переходит от одного оператора к другому или попадает к агенту, не обладающему нужной компетенцией. В Telegram-CRM маршрутизация — это не просто техническая опция, а инструмент, определяющий скорость реакции, качество сервиса и соблюдение SLA. Без правильно настроенных сценариев даже самая мотивированная команда будет работать хаотично, а время первого ответа (FRT) и время разрешения (TTR) останутся неконтролируемыми.
Проблема 1: Обращения «застревают» в очереди из-за неверного распределения
Ситуация: В топик-группе Telegram одновременно поступает несколько запросов. Система не назначает ответственного, и агенты либо игнорируют тикеты, либо каждый считает, что обращение обработает коллега. В результате клиент ждёт ответа 30–40 минут, хотя SLA предполагает отклик в течение 5 минут.
Причина: Отсутствует или некорректно настроен сценарий первичного распределения. В Telegram-CRM маршрутизация строится на основе правил: если обращение попадает в определённый топик, оно должно автоматически назначаться агенту или группе. Чаще всего проблема кроется в том, что сценарий не учитывает статус оператора (онлайн/офлайн) или его текущую загрузку.
Пошаговое решение:
- Проверьте настройки очереди. Зайдите в раздел управления очередями и убедитесь, что для данной топик-группы активирован сценарий распределения. Если очередь пустая или в ней нет активных правил, система не сможет назначить ответственного.
- Настройте триггер «Новое обращение». Создайте правило: при поступлении нового тикета в очередь проверять статус агентов. Если оператор онлайн и его загрузка ниже порога (например, менее 5 активных диалогов), назначать обращение ему.
- Добавьте fallback-действие. Если все агенты в группе заняты или офлайн, настройте автоматическое уведомление супервизору или перевод в резервную очередь. Это предотвратит «зависание» тикета.
- Тестируйте на имитации. Запустите тестовое обращение и отследите, как система его обработала. Если тикет остался неназначенным, проверьте логи триггеров — возможно, условие не сработало из-за несоответствия тегов или категории.
Проблема 2: Сложные запросы попадают к новичкам, а простые — к опытным агентам
Ситуация: Клиент с технической проблемой (например, настройка интеграции) получает ответ от стажёра, который тратит 20 минут на поиск решения, а затем эскалирует запрос. В то же время опытный инженер обрабатывает вопрос «Как восстановить пароль?», на который у него уходит 2 минуты. Это снижает эффективность команды и увеличивает TTR.
Причина: В сценарии маршрутизации не настроено разделение по компетенциям или тегам. Система распределяет обращения случайным образом или по принципу «первый свободный», не учитывая сложность запроса.
Пошаговое решение:
- Внедрите тегирование обращений. При поступлении тикета автоматически присваивайте ему тег на основе ключевых слов или источника (например, «техподдержка», «биллинг», «общие вопросы»). Это можно сделать через триггер, анализирующий текст первого сообщения или выбранный топик. Подробнее о настройке тегов читайте в руководстве управление очередями с помощью тегов.
- Создайте группы агентов по навыкам. Разделите операторов на группы: «Уровень 1» (базовые вопросы), «Уровень 2» (сложные технические запросы), «Уровень 3» (эксперты). В настройках очереди укажите, что обращения с тегом «техподдержка» направляются только в группу «Уровень 2».
- Настройте приоритет внутри группы. Для каждой группы задайте порядок назначения: сначала тикет получает агент с наименьшей загрузкой, но если он отсутствует — следующий по списку. Это равномерно распределит нагрузку.
- Добавьте правило эскалации. Если обращение не было принято в течение заданного времени (например, 10 минут), оно автоматически передаётся супервизору или в группу выше. Это предотвращает «застревание» сложных запросов у неопытных сотрудников.
Проблема 3: Клиенты получают ответы от разных агентов, теряется контекст
Ситуация: Клиент задаёт вопрос, получает ответ от одного оператора, затем уточняет — и тикет автоматически переходит к другому агенту. Новому сотруднику приходится перечитывать всю историю, клиент повторяет информацию, растёт FRT и недовольство.
Причина: В сценарии маршрутизации не настроено правило «закрепления» обращения за первым ответившим агентом. Система каждый раз перераспределяет тикет, если предыдущий оператор освободился или переключился на другой диалог.
Пошаговое решение:
- Включите режим «Закрепление за агентом». В настройках очереди найдите опцию, которая запрещает переназначение тикета после первого ответа. Как правило, это флаг «Удерживать агента до закрытия обращения».
- Настройте исключения для перерывов. Если агент уходит на обед или завершает смену, тикет должен передаваться другому оператору, но только после уведомления клиента. Добавьте триггер: при смене статуса агента на «Офлайн» отправлять клиенту сообщение «Ваш запрос передан другому специалисту, повторите, пожалуйста, суть вопроса».
- Используйте историю переписки. Убедитесь, что в настройках CRM включено сохранение полного контекста диалога. При переназначении новый агент должен видеть не только последнее сообщение, а всю ветку обсуждения. Это частично компенсирует потерю контекста.
- Ограничьте количество переназначений. В сценарии маршрутизации задайте максимальное число передач тикета (например, не более 2). Если обращение достигло лимита, оно автоматически направляется супервизору для ручного распределения.
Проблема 4: Обращения не сортируются по приоритету, срочные запросы теряются
Ситуация: В очереди одновременно находятся запрос «Срочно, не работает оплата!» и «Когда будет акция?». Система обрабатывает их в порядке поступления, и критический инцидент ждёт своей очереди 15 минут, пока оператор отвечает на общий вопрос.
Причина: В сценарии маршрутизации не настроен приоритет обращений. Все тикеты получают одинаковый вес, и система не может отличить срочный запрос от обычного.
Пошаговое решение:
- Определите критерии приоритета. Обычно это ключевые слова («срочно», «ошибка», «не работает»), выбранный топик (например, «Техническая поддержка»), статус клиента (VIP) или время ожидания. Настройте триггеры, которые присваивают обращению приоритет «Высокий», «Средний» или «Низкий».
- Настройте сортировку в очереди. Укажите, что тикеты с высоким приоритетом отображаются в начале списка и назначаются агентам в первую очередь, независимо от времени поступления.
- Добавьте уведомления для срочных обращений. Настройте триггер: при поступлении тикета с приоритетом «Высокий» отправлять push-уведомление всем свободным агентам или супервизору. Это ускорит реакцию.
- Проверьте SLA-метрики. Убедитесь, что для каждого уровня приоритета заданы свои целевые показатели: для высокого — FRT 2 минуты, для низкого — 15 минут. Система будет отслеживать нарушения и автоматически эскалировать просроченные обращения. Детальный разбор метрик доступен в статье аналитика обращений в Telegram-CRM.
Проблема 5: Ошибки при интеграции с внешними сервисами (база знаний, API)
Ситуация: При настройке сценария маршрутизации вы указали, что перед назначением агента система должна проверить базу знаний на наличие готового ответа. Но интеграция не работает: ответы не подгружаются, или тикет уходит в бесконечный цикл проверки.
Причина: Некорректно настроен webhook или API-запрос к внешнему сервису. Telegram-CRM не может получить ответ от базы знаний, и сценарий «зависает» на этапе проверки.
Пошаговое решение:
- Проверьте URL и ключи доступа. Убедитесь, что в настройках интеграции указан корректный адрес API базы знаний и валидный токен. Протестируйте соединение вручную через Postman или curl.
- Настройте таймаут и fallback. В сценарии маршрутизации укажите максимальное время ожидания ответа от внешнего сервиса (например, 5 секунд). Если ответ не получен, система должна переходить к следующему шагу (назначение агенту), а не ждать бесконечно.
- Проверьте формат данных. Убедитесь, что Telegram-CRM отправляет запрос в том формате, который ожидает база знаний (JSON, XML). Часто ошибка возникает из-за несовпадения структуры полей.
- Логируйте ошибки. Включите логирование webhook-интеграции. Это поможет понять, на каком этапе происходит сбой: запрос не отправлен, получен неверный ответ или ответ пришёл, но не обработан.
Когда обращаться к специалисту: сводный чек-лист
| Признак | Действие |
|---|---|
| После настройки всех правил обращения не назначаются | Проверить логи триггеров, webhook-интеграцию с Telegram Bot API |
| Теги не проставляются автоматически | Требуется доработка NLP-модуля или настройка внешнего классификатора |
| Конфликтуют несколько сценариев маршрутизации | Аудит всех активных правил, привлечение специалиста по CRM |
| Интеграция с базой знаний не работает | Проверка API, логирование, обращение к разработчикам внешнего сервиса |
| Обращения «зависают» после эскалации | Проверка правил эскалации, настройка fallback-действий, консультация с супервизором |
Настройка сценариев маршрутизации — это итеративный процесс. Даже после первичной конфигурации рекомендуется регулярно анализировать метрики FRT и TTR, отслеживать «узкие места» в очереди и корректировать правила. Помните, что идеального сценария «из коробки» не существует: каждая команда поддержки уникальна, и маршрутизация должна учитывать её структуру, компетенции и бизнес-процессы. Если вы чувствуете, что самостоятельно не справляетесь с настройкой, — привлекайте специалиста на этапе аудита, это сэкономит время и нервы вашей команды.
