Настройка временных интервалов для SLA

Проблема: SLA-метрики не работают или считаются некорректно

Представьте ситуацию: вы настроили в Telegram-CRM соглашение об уровне обслуживания (SLA), указали временные интервалы для первого ответа и разрешения обращения, но система либо не фиксирует нарушения, либо считает время не так, как вы ожидали. Клиенты жалуются на долгое ожидание, а супервизор не видит объективной картины загрузки агентов. Знакомая картина? Чаще всего корень проблемы — в некорректной настройке временных интервалов и недостаточном понимании того, как SLA-движок обрабатывает рабочие и нерабочие часы.

Причина: непонимание логики временных окон и бизнес-часов

SLA в Telegram-CRM — это не просто «тикет создан — тикет закрыт». Система учитывает множество факторов: рабочие часы команды, праздничные дни, приоритет обращения, а также время, которое тикет провел в статусе «ожидания ответа от клиента». Если вы установили время первого ответа (FRT) 15 минут, но не указали, что это время действует только в будни с 9:00 до 18:00, система начнет отсчет с момента создания обращения, включая ночные часы и выходные. Результат — ложные срабатывания и демотивация агентов.

Пошаговое решение: настройка временных интервалов

Шаг 1. Определите бизнес-часы вашей службы поддержки

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

Стандартный график (пн–пт, 9:00–18:00)
Расширенный (пн–сб, 8:00–20:00)
Круглосуточный (24/7)

В Telegram-CRM для каждого графика создается отдельный календарь. Убедитесь, что календарь назначен правильной очереди обращений. Если у вас несколько команд с разными графиками (например, первая линия работает 24/7, а вторая — только в будни), создайте отдельные календари для каждой очереди.

Шаг 2. Настройте временные интервалы для SLA-метрик

В интерфейсе управления SLA укажите два ключевых параметра:

Время первого ответа (FRT) — максимальное время от создания тикета до первого сообщения агента.
Время разрешения (TTR) — максимальное время от создания тикета до его закрытия.

Важный нюанс: система считает только рабочее время, если вы выбрали соответствующий календарь. Например, при FRT = 1 час и рабочем дне с 9:00 до 18:00, тикет, созданный в пятницу в 17:45, получит дедлайн в понедельник в 9:45 (45 минут пятницы + 15 минут понедельника). Без календаря система посчитала бы 1 час и зафиксировала бы нарушение в пятницу в 18:45, хотя агент физически не мог ответить.

Шаг 3. Настройте исключения для праздничных дней

Отдельная боль — государственные праздники. Если ваша компания не работает 1–8 января, а календарь не учитывает это, система будет считать время, и к 9 января у вас накопится пачка «просроченных» тикетов. В Telegram-CRM можно загрузить список праздничных дней на год вперед или синхронизировать с внешним календарем через webhook-интеграцию. Рекомендую проверять этот список перед каждым длинным уикендом.

Шаг 4. Настройте приоритеты и SLA для разных типов обращений

Не все тикеты одинаково важны. Ошибка платежа требует реакции в течение 15 минут, а вопрос по документации может подождать 4 часа. В Telegram-CRM можно создать несколько SLA-политик и привязать их к приоритетам обращений. Приоритет, в свою очередь, может назначаться автоматически через триггеры автоматизации — например, по ключевым словам в сообщении клиента («срочно», «ошибка», «не работает») или по источнику обращения.

Шаг 5. Проверьте, что SLA не сбрасывается при эскалации

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

Когда проблема требует специалиста

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

SLA не учитывает время ожидания ответа от клиента. Если клиент не отвечает 2 дня, система продолжает отсчет, и тикет «просрочен» по вине заказчика. В Telegram-CRM есть функция «паузы» SLA при ожидании ответа, но ее включение может потребовать доработки триггеров автоматизации или скриптов.
Синхронизация с внешними календарями не работает. Если вы используете Google Calendar или Outlook для учета праздников, а данные не подтягиваются, проверьте webhook-интеграции. Возможно, требуется обновление API-ключей.
SLA-метрики отображаются некорректно в отчетах. Если в дашборде супервизора вы видите странные цифры (например, FRT = 0 для всех тикетов), это может быть связано с ошибкой в конфигурации очередей. Иногда проблема решается пересозданием очереди обращений.

Как проверить правильность настройки

Самый надежный способ — тестовый прогон. Создайте тикет с известным временем создания, дождитесь ответа агента и закройте обращение. Сверьте фактические времена с теми, что показывает система. Повторите тест в разное время суток и в выходной день.

Если вы заметили, что нагрузка на агентов в пиковые часы приводит к массовым нарушениям SLA, возможно, стоит пересмотреть не только временные интервалы, но и принципы распределения обращений. Об этом мы подробно говорим в материале управление нагрузкой агентов в пик.

Заключение-чеклист

Чтобы настройка временных интервалов для SLA прошла успешно, проверьте:

Создан и назначен календарь с рабочими часами для каждой очереди
Учтены праздничные дни (загружены или синхронизированы)
Определены SLA-политики для каждого приоритета обращений
Настроена пауза SLA при ожидании ответа от клиента
Проверено, что таймер не сбрасывается при эскалации
Проведено не менее 3 тестовых прогонов в разных условиях

Если хотя бы один пункт не выполнен, велика вероятность, что ваши SLA-метрики будут давать искаженную картину. Начните с малого — настройте календарь и проверьте FRT на одном тикете. Остальное — дело техники и нескольких часов внимательной работы с интерфейсом Telegram-CRM.