Наборы правил для маршрутизации заявок в Telegram-CRM: как настроить распределение обращений между агентами

Организация поддержки в Telegram-топик-группах сталкивается с фундаментальной проблемой: когда на один канал приходит 50–100 обращений в день, ручное распределение заявок между операторами становится узким горлышком. Без автоматической маршрутизации агенты тратят значительное время на сортировку входящих сообщений и выяснение, кто за какой тикет отвечает. Telegram-CRM решает эту задачу через наборы правил — гибкую систему условий, которая определяет, какому агенту или группе агентов направляется новое обращение.

Чем топик-группа отличается от обычного чата для поддержки

Прежде чем настраивать маршрутизацию, важно понимать инфраструктуру. Telegram предлагает три формата коммуникации, и только один подходит для системной поддержки:

Формат	Особенности	Применимость для поддержки
Личный чат	Прямая переписка пользователя с ботом или агентом	Только для первичного контакта или автоматических ответов
Группа (обычная)	Все участники видят все сообщения в одном потоке	Не подходит — сообщения смешиваются, нет разделения на темы
Топик-группа (форум)	Каждое обращение создаётся как отдельная тема	Оптимальный вариант — каждый тикет изолирован, агенты работают параллельно

В топик-группе каждое новое сообщение от клиента может автоматически создавать отдельную тему (тикет), что позволяет реализовать полноценную очередь обращений. Подробнее о механизме очередей — в материале очередь обращений в топик-группе.

Основные типы правил маршрутизации

Telegram-CRM позволяет строить маршрутизацию на нескольких уровнях. Рассмотрим базовые наборы правил, которые покрывают большинство сценариев поддержки.

1. Маршрутизация по тематике обращения

Самый распространённый подход — анализ ключевых слов или фраз в первом сообщении клиента. Правило выглядит так:

Условие: сообщение содержит слова «оплата», «счёт», «платёж»
Действие: направить тикет в группу «Финансовый отдел»
Приоритет: высокий (SLA первого ответа — 15 минут)

Аналогично настраиваются правила для технических вопросов, претензий, запросов на возврат. Ограничение Telegram API: бот может обрабатывать не более 30 сообщений в секунду суммарно (на всех чатов), поэтому для потоков свыше 1000 обращений в час требуется распределённая архитектура.

2. Маршрутизация по загрузке агентов (Round Robin)

Этот механизм распределяет тикеты равномерно между доступными операторами. Принцип работы:

Система ведёт учёт открытых тикетов у каждого агента
Новое обращение направляется агенту с наименьшим количеством активных заявок
Если у всех операторов одинаковое количество — выбирается тот, кто дольше не получал новый тикет

Важно: такой подход работает только при условии, что все агенты имеют одинаковую квалификацию. Для разнородных команд требуется комбинировать с правилами тематики.

3. Маршрутизация по навыкам (Skill-based routing)

Более сложный, но эффективный сценарий — распределение на основе компетенций агента:

Навык	Агент 1	Агент 2	Агент 3	Агент 4
Техническая поддержка	✓	✓	✗	✗
Биллинг	✗	✗	✓	✓
Английский язык	✓	✗	✓	✗
VIP-клиенты	✗	✓	✗	✓

Если приходит запрос от VIP-клиента на английском языке по технической проблеме, система выбирает агента с максимальным совпадением навыков — в данном случае Агента 2.

Пошаговая настройка набора правил

Рассмотрим процесс настройки на примере гипотетической Telegram-CRM-системы (конкретные названия полей могут отличаться в зависимости от вендора).

Шаг 1. Определение источников обращений

Создайте отдельные топик-группы для разных каналов входящих сообщений:

Основная группа для клиентов (публичная ссылка на сайте)
Группа для партнёров (доступ по приглашению)
Внутренняя группа для эскалаций от бота

Шаг 2. Настройка триггеров создания тикетов

Каждое новое сообщение в топик-группе должно автоматически создавать тикет. Для этого:

Подключите бота к группе через Telegram Bot API
Настройте триггер «Новое сообщение → Создать тикет»
Укажите обязательные поля: текст обращения, ID пользователя, время создания

Подробнее об автоматическом создании — в статье автоматическое создание тикетов.

Шаг 3. Создание правил маршрутизации

В интерфейсе CRM создайте набор правил со следующей структурой:

``` Правило 1: Приоритет 100 Условия:

Сообщение содержит "срочно" ИЛИ "пожалуйста, помогите"
Клиент в списке VIP (по ID)

Действие:

Назначить группе "VIP-поддержка"
Установить SLA первого ответа: 5 минут

Правило 2: Приоритет 50 Условия:

Сообщение содержит "ошибка" ИЛИ "баг"

Действие:

Назначить группе "Техническая поддержка"
Установить SLA первого ответа: 30 минут

```

Правила проверяются по порядку приоритета. Если сработало правило 1 — остальные игнорируются.

Шаг 4. Настройка очереди и SLA

После маршрутизации тикет попадает в очередь группы агентов. Здесь критически важны метрики:

Время первого ответа (FRT): должно быть одинаковым для всех тикетов в пределах одной группы
Время разрешения (TTR): зависит от сложности; для простых запросов — до 2 часов, для сложных — до 24 часов

SLA-метрики настраиваются индивидуально под продукт. Конкретные значения зависят от специфики бизнеса и не могут быть универсальными.

Шаг 5. Эскалация при нарушении SLA

Если агент не отвечает в течение установленного времени, система должна автоматически повышать приоритет тикета:

``` Триггер: Время первого ответа превышено на 50% Действие:

Уведомить супервизора в отдельный чат
Изменить приоритет тикета на «Критический»
Добавить тикет в очередь супервизора

```

Механизмы эскалации подробно описаны в руководстве эскалация сложных запросов.

Ограничения Telegram API, которые влияют на маршрутизацию

При проектировании системы маршрутизации необходимо учитывать технические ограничения платформы:

Лимит сообщений: бот может отправлять не более 30 сообщений в секунду суммарно (на все чаты). Для групп с топиками действуют те же ограничения.
Хранилище медиа: файлы, отправленные через бота, имеют ограниченный срок хранения (file_id доступен до 2 недель, file_path — до 1 часа); для долгосрочного хранения требуется интеграция с внешним хранилищем.
Ограничение на количество участников: супергруппа может содержать до 200 000 участников. Для топик-групп (форумов) лимит может отличаться, для поддержки с высокой нагрузкой рекомендуется разделять на несколько групп.
Задержки Webhook: при использовании webhook-интеграции время ожидания ответа по умолчанию — 30 секунд (параметр настраивается); для сложных правил маршрутизации может потребоваться асинхронная обработка.

Таблица сравнения подходов к маршрутизации

Подход	Сложность настройки	Гибкость	Нагрузка на систему	Рекомендуемый размер команды
Round Robin	Низкая	Низкая	Минимальная	2–5 агентов
По тематике	Средняя	Средняя	Средняя	3–10 агентов
По навыкам	Высокая	Высокая	Высокая	5–20+ агентов
Гибридный (тематика + навыки + загрузка)	Очень высокая	Максимальная	Высокая	10+ агентов

Для команд до 5 человек достаточно Round Robin с базовой фильтрацией по ключевым словам. Для распределённых команд из 10+ операторов — гибридный подход с учётом навыков и текущей загрузки.

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

Начинайте с малого: настройте 2–3 правила по тематике, протестируйте неделю, затем добавляйте новые
Используйте тестовые тикеты: создайте отдельную топик-группу для отладки маршрутизации, чтобы не засорять рабочую очередь
Мониторьте метрики: если FRT растёт — правило слишком узкое или не хватает агентов в группе
Документируйте правила: каждое изменение должно фиксироваться — это поможет при аудите и обучении новых сотрудников

Настройка маршрутизации — итеративный процесс. Идеальный набор правил для конкретной команды находится экспериментально, через анализ статистики обработки тикетов и обратной связи от агентов. Подробнее о распределении тикетов между агентами — в материале распределение тикетов между агентами.