Настройка SLA для каждого типа тикетов в Telegram-CRM

Зачем различать SLA по типам обращений

Когда в службу поддержки поступают десятки запросов в день, невозможно обрабатывать их с одинаковой скоростью. Срочная проблема с оплатой требует реакции в течение 5 минут, а вопрос по документации может подождать пару часов. Если не настроить разные SLA для разных типов тикетов, вы либо перегружаете агентов ложной срочностью, либо теряете клиентов из-за медленного ответа на критичные обращения.

Telegram-CRM позволяет настраивать SLA-метрики для каждого типа тикетов в топик-группах. Это значит, что вы задаёте отдельные целевые показатели времени первого ответа (FRT) и времени разрешения (TTR) для технических сбоев, запросов на возврат, консультаций и других категорий.

Шаг 1: Определите типы тикетов в вашей поддержке

Прежде чем настраивать SLA, составьте классификатор обращений. В Telegram-CRM типы тикетов обычно задаются через категории или теги, которые присваиваются при создании заявки. Вот типичные категории для B2C-поддержки:

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

Важно: Не пытайтесь создать 20+ категорий — это усложнит настройку SLA и запутает агентов. Оптимально 4–6 типов.

Шаг 2: Настройте SLA-метрики для каждого типа

В интерфейсе Telegram-CRM (обычно раздел «SLA» или «Метрики») вы задаёте для каждого типа тикетов:

Время первого ответа (FRT) — сколько минут/часов клиент может ждать первого сообщения от агента.
Время разрешения (TTR) — максимальное время до закрытия тикета.
Действие при нарушении SLA — уведомление супервизора, эскалация обращения, автоматическое повышение приоритета.

Пример настройки:

Критический сбой: FRT = 5 минут, TTR = 30 минут. При нарушении — уведомление в отдельный чат супервизоров.
Финансовый запрос: FRT = 15 минут, TTR = 2 часа. При нарушении — автоматическое создание задачи в CRM.
Консультация: FRT = 1 час, TTR = 24 часа. При нарушении — только запись в отчёте.

Ограничение Telegram API: Учтите, что бот Telegram не может гарантировать доставку уведомлений быстрее, чем это позволяет API (задержки могут варьироваться в зависимости от нагрузки). Для критических SLA с короткими сроками потребуется дополнительный мониторинг через webhook-интеграции с внешними системами.

Шаг 3: Настройте автоматическое присвоение типа тикету

Чтобы SLA работал корректно, каждый тикет должен автоматически получать правильный тип при создании. В Telegram-CRM для этого используются триггеры автоматизации:

По ключевым словам в первом сообщении. Например, если клиент пишет «не работает», «ошибка», «сломалось» — тикет автоматически получает тип «Техническая проблема» с соответствующим SLA.
По выбранной теме в топик-группе. Если вы используете топики Telegram как категории, можно настроить триггер: «при создании тикета в топике "Возвраты" → присвоить тип "Финансовый запрос"».
По отправителю. VIP-клиенты из отдельного списка могут получать тип «Критический сбой» независимо от содержания запроса.

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

Шаг 4: Настройте эскалацию для просроченных SLA

Когда SLA нарушен, система должна не просто записать это в лог, а предпринять действия. Типичная цепочка эскалации в Telegram-CRM:

Первое нарушение FRT — уведомление агенту в личный чат или в топик группы.
Повторное нарушение FRT или нарушение TTR — создаётся задача для супервизора, тикет переводится в отдельную очередь «Просроченные».
Систематические нарушения (например, 3+ тикета от одного агента за смену) — автоматическое уведомление руководителю смены с данными из отчётов по нагрузке.

Совет из практики: Не делайте эскалацию слишком агрессивной. Если агент задерживается из-за технического сбоя Telegram (например, задержка доставки сообщения), вы получите ложное срабатывание. Установите буфер в 10–20% от целевого SLA.

Шаг 5: Используйте шаблоны ответов для быстрого реагирования

Для типов тикетов с жёстким SLA (критические, финансовые) критически важна скорость первого ответа. В Telegram-CRM можно привязать canned response к типу тикета:

При создании тикета «Критический сбой» автоматически подставляется шаблон: «Мы уже начали проверку, ожидайте уточнения в течение 5 минут».
Для «Финансового запроса» — «Ваш запрос на возврат принят. Средний срок обработки — 2 часа».

Это позволяет агенту ответить быстро, не тратя время на формулировки.

Шаг 6: Мониторьте и корректируйте SLA

Настройка SLA — не разовое действие. Раз в неделю анализируйте отчёты по нагрузке агентов и метрики SLA. Обращайте внимание на:

Какие типы тикетов чаще всего нарушают SLA. Возможно, вы занизили целевые показатели или на этот тип не хватает агентов.
Среднее время ответа по каждому типу. Если реальный FRT для консультаций — 45 минут, а вы поставили 1 час, у вас есть запас. Если 2 часа — SLA нужно пересмотреть.
Количество эскалаций. Слишком частые эскалации говорят о неправильной настройке приоритетов или нехватке персонала.

Ограничение Telegram API: При большом количестве тикетов (сотни в день) учитывайте лимиты Telegram на отправку сообщений. Если уведомления об SLA будут генерировать лавину сообщений, часть может потеряться. Используйте webhook-интеграции для отправки критических уведомлений во внешние системы (например, Slack или email).

Чеклист: что проверить после настройки

Каждому типу тикета присвоен свой SLA (FRT и TTR).
Настроены триггеры автоматического присвоения типа.
Созданы шаблоны ответов для быстрого первого отклика.
Настроена эскалация при нарушении SLA.
Уведомления о нарушениях приходят супервизору.
Проведено тестирование — создайте тестовый тикет каждого типа и проверьте срабатывание SLA.
Агенты знают свои целевые показатели и понимают, как их отслеживать.

Итог: Правильная настройка SLA по типам тикетов превращает Telegram-CRM из простого чата в управляемую систему поддержки. Вы не просто отвечаете быстрее — вы отвечаете с нужной скоростью именно на те запросы, которые этого требуют. А регулярный мониторинг метрик позволяет вовремя заметить проблемы и скорректировать процессы.

Для более детального изучения — читайте о настройке SLA для тикетов в целом и о том, как анализировать отчёты по нагрузке агентов.