SLA по заявкам: сроки для инцидентов и запросов

Кратко

SLA по заявкам работает правильно, когда у инцидента и у запроса на обслуживание разные нормативы. Инцидент — что-то сломалось и не работает — требует короткого срока реакции и решения. Запрос на обслуживание — плановая просьба вроде доступа или консультации — можно и нужно обрабатывать по более спокойному графику. Один общий SLA на все типы обращений неизбежно ошибается в одну из двух сторон: либо авария ждёт в общей очереди, либо рутинные просьбы обрабатываются в режиме пожара.

Актуально на 23 сентября 2026 года.

Почему один SLA на все обращения не работает

Инцидент и запрос на обслуживание отличаются не формой, а сутью: инцидент отвечает на вопрос «работало и перестало», запрос — на вопрос «не работало и нужно, чтобы появилось». У них разная цель (восстановить против выполнить) и разная цена промедления. Граничные случаи этого деления разобраны отдельно — инцидент или запрос на обслуживание: в чём разница. Если поставить на оба типа одинаковый срок:

• Срок под инцидент как под запрос (долгий) — авария ждёт в очереди наравне с просьбой поменять email в профиле, и клиент, у которого всё сломано, ждёт столько же, сколько тот, кто просто спрашивает.
• Срок под запрос как под инцидент (короткий) — каждая плановая просьба превращается в пожар, операторы работают в постоянном напряжении, а короткий срок обесценивается: он одинаково «горит» и для аварии, и для рутины.

Пример: два набора правил SLA

Ниже — рабочий пример различия, не готовое решение для копирования: сами сроки зависят от вашей нагрузки и обещаний клиентам.

Разница не только в цифрах, но и в поведении: инцидент с критичным приоритетом обычно поднимает эскалацию при приближении к сроку, запрос с низким приоритетом — нет.

Как настроить разные SLA по типу обращения: пошагово

1. Разделите обращения на инциденты и запросы на входе. Это делает категория или тема заявки, выбранная при создании — не разбор постфактум. Общий порядок оформления и классификации заявки на этом шаге — в статье заявка в Service Desk: как оформить и классифицировать.
2. Создайте отдельные правила SLA для каждой комбинации типа и приоритета. Понятные названия важнее формул: «Инцидент — критичный», «Запрос — обычный».
3. Для каждого правила задайте два числа отдельно: время ответа и время решения. Это разные сроки — ответ не значит решение, и смешивать их в один норматив нельзя.
4. Настройте, чтобы правило подбиралось автоматически по условиям (категория, канал, приоритет), а не выбиралось сотрудником каждый раз вручную — ручной выбор со временем расходится с реальностью на загруженной смене.
5. Включите рабочий календарь, чтобы срок считался в рабочих часах компании, а не в астрономических — иначе пятничное вечернее обращение будет просрочено уже к субботе.
6. Для заявки с фиксированной внешней датой (например, обещанной клиенту датой завершения работ) используйте крайний срок отдельно от норматива SLA — он заменяет только срок решения, на срок первого ответа не влияет.

Как посчитать соблюдение SLA по типу обращения

Доля соблюдения SLA = решено в срок ÷ всего решено обращений этого типа × 100.

Пример: за месяц закрыто 420 инцидентов, из них 386 уложились в срок решения. Доля соблюдения SLA по инцидентам: 386 ÷ 420 × 100 = 91,9 %, округлённо 92 %. Этот процент стоит считать отдельно для инцидентов и отдельно для запросов — общая цифра по всем обращениям сразу прячет провал по одному типу за счётом другого: у запросов срок длиннее и соблюсти его проще, поэтому общий процент почти всегда выглядит лучше, чем процент по одним инцидентам.

Как проверить, что разделение SLA работает

• Выгрузите обращения за месяц и посчитайте процент соблюдения отдельно по инцидентам и отдельно по запросам — они не должны сравниваться друг с другом напрямую, но оба должны быть видны.
• Посмотрите, не переопределяют ли сотрудники правило SLA вручную чаще, чем в единичных случаях — частая ручная замена значит, что автоматические условия подбора настроены неточно.
• Проверьте пять обращений, близких к нарушению срока: видно ли по карточке, какой норматив действует и сколько времени осталось.
• Сравните медианное время решения инцидентов с медианным временем решения запросов — если они почти совпадают, разделение существует только на бумаге.

Частые ошибки

• Один SLA на все типы обращений — самая частая ошибка, из-за которой авария и рутина конкурируют за одно и то же время оператора.
• Смешивание срока ответа и срока решения в один норматив — оператор отвечает формальным «принято в работу» ради соблюдения показателя, а решение откладывается.
• Счёт в астрономических, а не в рабочих часах — вечерние и предпраздничные обращения оказываются просроченными по факту закрытого офиса, а не по вине команды.
• Приоритет и тип обращения путают — критичный приоритет ставят и инциденту, и срочному запросу, из-за чего теряется смысл более короткого норматива именно для поломок. Готовая таблица для разведения приоритета по влиянию и срочности — матрица приоритетов заявок.

Частые вопросы

Какой SLA ставить на инцидент?

Короче, чем на запрос: обычно счёт идёт на минуты для первого ответа и на часы для решения, потому что что-то не работает прямо сейчас. Конкретные цифры зависят от того, что вы обещаете клиентам в договоре или на публичной странице тарифов.

Чем SLA по заявке отличается от SLA по обращению вообще?

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

Как назначить разные приоритеты SLA по типам обращений?

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

Можно ли одной заявке назначить два правила SLA?

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

Как это устроено в TehProf.kz Support

Правила SLA настраиваются в Настройки → SLA и KPI → Правила SLA: для каждого правила задаются отдельно время ответа в минутах и время решения в часах. Приоритет заявки клиент может выбирать сам (если это разрешено) либо получает значение по умолчанию; для отдельной заявки можно установить жёсткий крайний срок — он заменяет только срок решения и не влияет на срок первого ответа. Расчёт сроков учитывает рабочий календарь компании, поэтому обращение вне рабочих часов не превращается в просрочку за ночь.

Связанные статьи

• Что такое SLA в поддержке
• Как разработать SLA для службы поддержки
• Как посчитать процент соблюдения SLA
• Метрики SLA: какие считать
• Система заявок против системы запросов: в чём разница