SLA в IT-поддержке — это согласованные сроки, за которые служба отвечает на обращение и решает его. Обычно считают два показателя: время первой реакции и время решения. Сроки зависят от приоритета заявки и учитывают рабочие часы команды.
Ниже — как задать эти сроки так, чтобы они помогали работать, а не только украшали отчёт.
Две основные метрики
Время первой реакции — от регистрации обращения до первого содержательного ответа исполнителя. Автоматическое письмо «заявка принята» реакцией не считается.
Время решения — от регистрации до момента, когда проблема устранена и заявка закрыта.
Разделять их важно: быстрая реакция показывает сотруднику, что обращение не потерялось, даже если решение займёт день. В карточке заявки оба таймера должны быть видны исполнителю постоянно.
Шаг 1. Определите приоритеты
Приоритет складывается из влияния и срочности: скольких людей затрагивает проблема и можно ли работать в обход. Достаточно четырёх уровней.
| Приоритет | Пример | Признак |
|---|---|---|
| Критичный | Недоступна сеть или учётная система | Остановлена работа отдела или компании |
| Высокий | Не работает компьютер сотрудника | Один человек не может работать |
| Средний | Не печатает принтер, есть другой | Работа возможна с неудобством |
| Низкий | Установить дополнительную программу | Плановый запрос |
Шаг 2. Задайте сроки
Сроки должны опираться на реальные возможности команды. Посмотрите, за сколько вы отвечаете и решаете сейчас, и назначьте достижимые значения. Таблица ниже — пример структуры, а не норматив:
| Приоритет | Первая реакция | Решение |
|---|---|---|
| Критичный | 15–30 минут | 2–4 часа |
| Высокий | 1 час | 8 рабочих часов |
| Средний | 4 часа | 2–3 рабочих дня |
| Низкий | 1 рабочий день | 5 рабочих дней |
Шаг 3. Настройте рабочий календарь
Если поддержка работает с 9 до 18 по будням, таймер не должен идти ночью и в выходные. Заявка, созданная в пятницу в 17:30 со сроком реакции один час, просрочится в понедельник в 9:30, а не в пятницу вечером. Проверьте, как система считает время при праздниках и переносах.
Шаг 4. Договоритесь о паузах
Таймер решения разумно останавливать, когда исполнитель ждёт ответа от сотрудника или поставки оборудования. Определите статусы, в которых время не идёт, и следите, чтобы ими не злоупотребляли: заявка «в ожидании» неделями — тоже проблема.
Шаг 5. Добавьте предупреждения и эскалацию
Смысл SLA — заметить риск до просрочки. Настройте уведомление исполнителю, когда осталась, например, четверть срока, и руководителю группы — при нарушении. В очереди заявки с истекающим сроком должны быть видны без открытия карточки.
Типовые ошибки
- Один срок на всё. Запрос на новую мышь и отказ сервера не могут иметь одинаковый SLA.
- Сроки без календаря. Ночные «просрочки» обесценивают отчёт.
- Закрытие ради метрики. Если заявки закрывают, чтобы успеть, а сотрудник открывает их снова, смотрите на долю повторных обращений.
- 100 % как цель. Идеальный показатель чаще означает слишком мягкие сроки или неполный учёт, чем безупречную работу.
- Контроль без разбора причин. Нарушение — повод понять, чего не хватило: людей, доступа, запчастей, информации.
Что смотреть в отчётах
Раз в месяц достаточно четырёх чисел: доля заявок, решённых в срок, по каждому приоритету; среднее время первой реакции; число просрочек с причинами; нагрузка по исполнителям. Сравнивайте периоды между собой — динамика важнее отдельного значения.
Коротко
Начните с двух метрик и четырёх приоритетов, задайте достижимые сроки, настройте рабочий календарь и предупреждения. Через месяц пересмотрите значения по фактическим данным. Как таймеры, эскалации и отчёты устроены в продукте, показано на странице контроль SLA в SC Desk; общий обзор возможностей — на странице SC Desk.
Нужна система для IT-поддержки?
Посмотрите SC Desk: заявки, SLA, база знаний и IT-активы. Сравните возможности и обсудите внедрение.