SLA на заявки: сроки реакции и решения, таймеры, эскалации и отчёт

Что такое SLA и чего в нём обычно нет

SLA (Service Level Agreement) — соглашение об уровне сервиса: какие сроки, доступность и ответственность вы берёте на себя. В ИТ-поддержке и сервисном обслуживании он формализован сильнее всего, потому что там срок измеряется в минутах и по нему считают деньги. Внутри компании аналог называется OLA (Operational Level Agreement): у диспетчера 10 минут на регистрацию, у инженера 2 часа на выезд. Логика одна, но адресат разный — OLA описывает стыки между подразделениями, SLA описывает обещание наружу.

Разница важнее, чем кажется. Внешний SLA можно пообещать, но нельзя выполнить, если внутренние сроки мягче внешних. Если инженер физически добирается до объекта за два часа, обещание решить проблему за час — не смелость, а запланированное нарушение. Поэтому сначала считают, как процесс идёт внутри, и только потом формулируют обещание клиенту.

Чего в типичном SLA не хватает чаще всего: приоритетов (срок один для всего), календаря (считают календарные часы, включая ночь и выходные), владельца (непонятно, кто отвечает за соблюдение) и отчёта (срок есть, но никто не смотрит, выполняется ли он). По разбору Okdesk это и есть набор повторяющихся ошибок: нереалистичные сроки, одинаковые сроки для всех заявок, игнорирование рабочего времени, отсутствие уведомлений и эскалации, слишком много метрик, SLA, который годами не пересматривают.

Два срока: реакция и решение

Время реакции (first response time, FRT) — сколько проходит до первого содержательного ответа: заявку приняли, приоритет присвоили, ответственного назвали, срок решения сообщили. Время решения — когда проблему действительно закрыли. Это разные обязательства: быстрая реакция не означает мгновенного решения, и наоборот — «мы уже работаем» без результата через сутки клиента не устраивает.

Практический вывод: в SLA должны стоять оба срока, и оба — по приоритетам. Один общий норматив «отвечаем в течение суток» никак не различает аварию и вопрос про счёт.

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

Уровни SLA: приоритет вместо одного срока

Уровни нужны не для красоты документа, а чтобы очередь имела порядок. Работает простая конструкция: 3–4 приоритета, у каждого свой срок реакции и свой срок решения, и одно правило, по которому приоритет ставится. Правило должно быть записано, иначе приоритет ставит тот, кто громче кричит.

Три правила, без которых таблица не работает. Первое: приоритет ставит исполнитель по описанным признакам, а не клиент — иначе все заявки становятся критичными. Второе: приоритет можно изменить, и тогда таймер пересчитывается от момента смены, а не от создания заявки. Третье: у каждого приоритета есть цена — если P1 требует реакции за 15 минут круглосуточно, значит, кто-то дежурит ночью, и это заложено в стоимость услуги.

Технически так и устроены зрелые системы: цель задаётся по типу работ, цели группируются по приоритетам, а смена приоритета меняет остаток времени по цели. Это описано в документации Atlassian по настройке SLA-целей. Ручной аналог — таблица в регламенте плюс поле «приоритет» в заявке, но тогда пересчёт при смене приоритета придётся делать человеку, и рано или поздно его сделают неправильно.

Календарь: когда таймер идёт, а когда стоит

Это самая частая причина спора «мы в срок» — «нет, вы опоздали». Если срок «8 часов» считается по календарным часам, заявка, пришедшая в 18:00, просрочена к 2:00 ночи, когда никто не работает. Если по рабочим часам — она просрочена только к обеду следующего дня. Обе трактовки законны, но в SLA должна быть зафиксирована одна, и таймер должен считать именно так.

В системах это отдельная сущность — календарь обслуживания. Atlassian описывает её прямо: календарь задаёт рабочие часы, в течение которых время засчитывается в SLA. Праздники, сокращённые дни и разные графики для разных регионов — тоже часть календаря, и их надо завести до запуска, а не после первого скандала.

Второй элемент календаря — паузы. Таймер разумно останавливать, когда заявка ждёт клиента (нужны данные, доступ, согласование) или внешнего поставщика. Ограничение очевидно: пауза — удобный способ улучшить отчёт. Поэтому основание для паузы должно быть одно, проверяемое, и ставиться письменным ответом клиента, а не кнопкой «подождать». Иначе доля в срок растёт, а клиент уходит.

Таймеры и эскалации: что происходит до нарушения

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

Эскалация — это не «сообщить начальнику», а конкретная лестница: кому уходит сигнал, что он должен сделать, сколько времени у него есть. Например: за 30% до срока — напоминание исполнителю; на 100% — руководителю группы с правом перераспределить заявку; через час после нарушения — ответственному за сервис с обязательством ответить клиенту лично. Чем короче срок (P1), тем короче шаги.

Отчёт: доля в срок, а не среднее

Главная метрика SLA — compliance, доля обращений, закрытых в срок: сколько заявок уложилось в норматив, делённое на все заявки периода. Считать её нужно отдельно по приоритетам и по каналам, иначе один всплеск мелочи на фоне одной аварии даёт красивую общую цифру.

Почему не среднее. Представим десять заявок: девять закрыты за пять минут, одна висит три дня. Среднее — около семи часов, и оно выглядит прилично. Но клиент, чья заявка висела, уже ушёл, а по среднему этого не видно. Доля в срок показывает 90% — уже честнее; а если добавить разрез по приоритету, видно, что провалена именно критичная заявка, и это совсем другой разговор.

• SLA compliance по приоритетам: доля заявок, закрытых в срок реакции и в срок решения — отдельно, это две разные цифры.
• Нарушения по причинам: не хватило людей, ждали клиента, ждали поставщика, заявку не заметили. Без этой разбивки отчёт не лечит.
• Худший хвост: список заявок с наибольшим превышением срока за период — обычно десять строк объясняют больше, чем месяц графиков.
• Нагрузка по часам: когда именно приходят заявки и совпадает ли это с графиком смен — основание для дежурств, а не догадка.
• Пересмотр раз в квартал: если 96% заявок укладываются в срок, норматив, вероятно, слишком мягкий; если 60% — он нереалистичен или процесс не готов.

Цель «100% в срок» в отчёте выглядит красиво и почти всегда означает одно из двух: норматив занизили или паузы расставили там, где удобно. Нормальная цель — 90–95% по массовым приоритетам и отдельный контроль по критичным, с разбором каждого нарушения. Про то, как метрики связаны с деньгами процесса, есть отдельный материал о стоимости ручной операции.

С чего начать внедрение

Порядок важнее амбиций: SLA, введённый сразу «как у крупного подрядчика», обычно отменяют через месяц, потому что процесс его не выдерживает.

1. Шаг 1. Замерить, как есть: время реакции и решения по последним 100–200 заявкам, в разбивке по каналам и часам. Без этих цифр любой норматив — фантазия.
2. Шаг 2. Ввести два приоритета, а не четыре: критичное и всё остальное. Когда процесс выдержит, добавить третий и четвёртый.
3. Шаг 3. Зафиксировать календарь: рабочие часы, выходные, праздники, режим для критичных заявок. Проверить, что таймер считает именно так.
4. Шаг 4. Настроить таймеры и эскалации: напоминание, предупреждение, передача руководителю — с конкретными адресатами.
5. Шаг 5. Включить отчёт по доле в срок и разбирать нарушения раз в неделю, а не раз в год.
6. Шаг 6. Пересматривать сроки по данным: там, где норматив выполняется на 99%, — ужесточить, где не выполняется годами — либо менять процесс, либо честно переписать обещание.

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

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

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

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