Что такое SLA в технической поддержке простыми словами

Кратко

SLA (Service Level Agreement, соглашение об уровне сервиса) — письменная договорённость о том, за какое время поддержка отреагирует на обращение и за какое доведёт его до решения. Это обещание сроков, а не обещание, что проблем не будет. SLA без названной точки отсчёта и без рабочих часов не является SLA — это пожелание.

Что такое SLA на самом деле

Расшифровка мало что объясняет, поэтому проще через отрицание.

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

SLA — это не описание того, что умеет продукт. Функции живут в договоре и документации, сроки — в SLA.

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

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

Из чего состоит рабочий SLA

Соглашение на тридцать страниц читают юристы, а исполняют операторы, которые его не открывали. Рабочий SLA отвечает на шесть вопросов и умещается на страницу.

  • Что покрывается. Перечень услуг или систем, на которые распространяются сроки. Всё, что не названо, сроками не покрыто — и это нормально, если сказано прямо.
  • Рабочие часы. В какие часы и дни действуют сроки. Обращение в 23:40 при режиме 9:00–18:00 начинает свой отсчёт в 9:00 следующего рабочего дня, и это должно быть написано, а не подразумеваться.
  • Приоритеты. Два–три уровня, у каждого свой срок. Признак назначения приоритета описан, а не оставлен «на усмотрение».
  • Два срока на каждый приоритет. Время первого ответа и время решения. Один срок всегда обманывает: служба, которая отвечает за минуту и решает неделю, по «среднему времени реакции» выглядит образцовой.
  • Точка отсчёта и паузы. От какого события идёт время и что из него вычитается. Обычно вычитают ожидание ответа клиента — иначе показатель наказывает поддержку за чужое молчание, и им перестают пользоваться.
  • Что при нарушении. Уведомление, эскалация, компенсация — что-то одно как минимум. Пункт без последствий не исполняется никогда.

Разумные сроки: с чего начинать

Ниже не замер рынка, а нормы, от которых удобно отталкиваться и которые потом подвигать под себя. Сроки указаны в рабочих часах.

ПриоритетПризнакПервый ответРешение
КритичныйСервис недоступен или недоступен всем пользователям15 минут4 часа
ОбычныйРаботает, но неправильно; есть обходной путь1 час8 часов
НизкийВопрос, консультация, пожелание4 часа3 рабочих дня

Три правила, которые делают эту таблицу пригодной к жизни:

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

Где SLA ломается

Точка отсчёта не названа. Обращение сначала полежало в личной переписке сотрудника, потом попало в очередь — и отсчёт начался с опозданием. Формально срок соблюдён, фактически человек ждал втрое дольше. Лечится одним правилом: обращением считается только то, что попало в общую очередь, и время идёт от момента попадания.

Автоответ считают первым ответом. «Ваша заявка принята, номер 4412» не отвечает на вопрос и не снимает тревогу. Если засчитывать его, время первого ответа падает до секунд и перестаёт что-либо означать. Первый ответ — это ответ человека по существу.

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

Календарные часы вместо рабочих. Если в SLA написано «8 часов», а система считает календарные, то пятничная заявка в 17:00 будет просрочена к субботнему утру, хотя никто не нарушал. Режим работы и способ счёта должны совпадать.

Частая ошибка: SLA как оружие, а не как инструмент

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

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

Если SLA — инструмент, нарушения обсуждают, а не прячут. Практический признак здорового соглашения: в нём есть пункт об уведомлении до истечения срока, а не только о санкции после. Уведомление за 30 минут до дедлайна спасает больше обращений, чем любой штраф.

Как проверить свой SLA за десять минут

  • Найдите в тексте, от какого события считается время. Не нашли — SLA нет.
  • Найдите рабочие часы. Не нашли — сроки означают календарные, посчитайте, устраивает ли вас это.
  • Посчитайте число приоритетов. Больше трёх — посмотрите в системе, сколько обращений реально попало в четвёртый.
  • Найдите пункт о нарушении. Нет — SLA не исполняется, независимо от того, что показывает отчёт.
  • Выгрузите обращения за месяц и посчитайте долю просроченных в процентах, а не в штуках. Больше 5 % — сроки либо нарушаются, либо изначально нереальны.

Настройка сроков и приоритетов в системе описана отдельно: Настройка SLA, приоритетов и крайнего срока. Чем внутреннее соглашение между отделами отличается от клиентского — в статье SLA, OLA и UC: чем отличаются три соглашения об уровне сервиса.

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

Нужна поддержка, которая так и работает?

TehProf Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.