SLA в IT-поддержке

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

SLA помогает заранее определить ожидания заказчика и границы ответственности исполнителя. По нему можно понять, когда должна начаться работа над обращением, сколько времени отводится на разные типы инцидентов, в какие часы действует поддержка, как рассчитывается выполнение обязательств и что происходит при нарушении согласованного уровня обслуживания. Исходное ТЗ предусматривает раскрытие именно этих вопросов применительно к IT-поддержке.

Что такое SLA в IT-поддержке

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

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

Для IT-поддержки это особенно важно, поскольку разные проблемы имеют неодинаковое влияние на работу компании. Полная недоступность корпоративной системы и просьба изменить права одного пользователя не должны автоматически обрабатываться с одинаковой срочностью. SLA позволяет заранее установить категории обращений и нормативы для каждой из них.

Как расшифровывается SLA

Аббревиатура SLA расшифровывается как Service Level Agreement. На русский язык термин обычно переводят как «соглашение об уровне обслуживания» или «соглашение об уровне сервиса». В профессиональной среде чаще используют само сокращение SLA.

Если говорить простыми словами, расшифровка SLA показывает его назначение: это соглашение о том, какой уровень обслуживания должен получать заказчик. В русскоязычной практике встречается и написание «СЛА», однако в документации и сфере ИТ обычно сохраняют английскую аббревиатуру SLA. В техподдержке такое соглашение связывает конкретные услуги с измеримыми сроками и показателями.

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

Зачем SLA заказчику и исполнителю

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

Исполнителю соглашение также полезно. Оно фиксирует границы услуги и не позволяет трактовать формулировку «техническая поддержка» без ограничений. Можно заранее определить часы работы, поддерживаемые системы, каналы обращения, обязанности пользователя, правила определения приоритета и ситуации, которые не входят в стандартное обслуживание.

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

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

Универсального набора условий, подходящего для любой компании, нет. Содержание SLA зависит от услуги, критичности IT-систем, режима работы бизнеса, количества пользователей и возможностей исполнителя. При этом документ должен позволять однозначно ответить как минимум на несколько вопросов: что именно поддерживается, какие обращения принимаются, кто за что отвечает и как измеряется качество сервиса.

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

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

Перечень и границы услуг

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

Например, в перечень могут входить:

• приём и обработка пользовательских обращений;
• диагностика и устранение инцидентов;
• восстановление работоспособности поддерживаемых систем;
• предоставление консультаций по установленному программному обеспечению;
• выполнение согласованных типовых запросов;
• передача сложных проблем профильным специалистам.

Одновременно следует определить границы услуги. Если служба поддержки отвечает только за определённое программное обеспечение, рабочие места или инфраструктуру, это нужно зафиксировать. Иначе у заказчика и исполнителя может различаться понимание того, какие работы должны выполняться в рамках договора.

Полезно отдельно указать каналы регистрации заявок. Если SLA рассчитывается только для обращений, зарегистрированных через Service Desk или другой установленный канал, сообщение специалисту в личном мессенджере не должно автоматически запускать тот же норматив. Чем точнее описана точка начала услуги, тем меньше спорных ситуаций при последующем контроле.

Приоритеты заявок и инцидентов

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

На практике можно использовать несколько уровней:

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

Количество уровней и названия могут быть другими. Важнее, чтобы для каждого приоритета существовали понятные критерии. Если определение сводится к словам «важная» и «неважная» заявка, сотрудники и заказчик могут классифицировать один и тот же инцидент по-разному.

Приоритеты затем связывают с целями SLA. В системах управления сервисом правила могут автоматически назначать разные сроки для обращений разных типов и приоритетов. Например, ServiceNow позволяет задавать SLA с конкретными целями Response или Resolution, а Atlassian — группировать цели по типам запросов и условиям.

Обязанности и ответственность сторон

SLA не должен описывать обязанности только службы поддержки. Выполнение сроков часто зависит и от действий заказчика.

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

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

Ответственность также лучше связывать с конкретными обязательствами. Вместо общей фразы «исполнитель отвечает за качество поддержки» документ должен показывать, какие показатели контролируются и что считается их нарушением.

Какие показатели SLA включить в договор

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

Не стоит включать десятки метрик только потому, что их можно посчитать. Каждый показатель должен помогать ответить на практический вопрос: насколько услуга соответствует согласованному уровню. Для технической поддержки базовыми обычно становятся время реакции, время решения, доступность и доля обращений, обработанных без нарушения SLA. Официальная документация систем управления сервисом также выделяет response, resolution и availability как типичные цели и обязательства.

Время реакции на обращение

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

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

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

Также требуется определить точку старта. Для обращения через Service Desk это может быть время создания тикета. Для телефонной линии правила будут другими. Если используются несколько каналов, необходимо понимать, одинаково ли они учитываются.

Время первой реакции удобно применять как отдельную SLA-цель. Jira Service Management, например, прямо выделяет Time to first response наряду с Time to resolution.

Время решения проблемы

Время решения показывает период от начала отсчёта до выполнения условий, при которых обращение считается решённым. Это один из наиболее значимых показателей для заказчика, но одновременно один из самых сложных для корректного описания.

Нужно заранее определить, что означает «решить». Для инцидента это может быть восстановление нормальной работы сервиса. Иногда полное устранение первопричины занимает больше времени, а работоспособность можно восстановить раньше временным обходным способом. В таком случае в SLA следует чётко разделить эти результаты, если для бизнеса между ними есть существенная разница.

Не менее важно определить паузы. Время может не учитываться, когда команда ждёт информацию от пользователя, согласованное окно работ или действие третьей стороны — но только если такое правило прямо установлено. Автоматизированные Service Desk-системы позволяют задавать отдельные условия, при которых счётчик SLA приостанавливается и запускается снова.

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

Доступность сервиса

Если исполнитель отвечает не только за обработку заявок, но и за функционирование IT-сервиса, в SLA может быть включена доступность за установленный период.

Для такой метрики одной цифры недостаточно. Необходимо определить:

• какой именно сервис или его часть измеряется;
• за какой период считается показатель;
• что признаётся недоступностью;
• откуда берутся данные о простое;
• учитываются ли плановые технические работы;
• какие события относятся к исключениям.

Microsoft отдельно обращает внимание, что одинаковая цифра доступности может иметь разный смысл в разных SLA из-за способов измерения, области действия и исключений. Поэтому процент нельзя рассматривать отдельно от определения downtime и методики расчёта.

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

Процент выполнения SLA

Процент выполнения SLA позволяет оценить, какая доля учитываемых обращений была обработана в пределах установленных нормативов.

Простейший вариант расчёта для выбранного показателя выглядит так:

Количество заявок без нарушения SLA / общее количество учитываемых заявок × 100%.

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

Показатель можно рассчитывать отдельно по времени реакции и времени решения, а также по приоритетам. Такой подход информативнее одной общей цифры: высокий процент выполнения по всем заявкам может скрыть систематические нарушения именно по критическим инцидентам.

Период расчёта также нужно определить заранее. Например, выполнение SLA можно оценивать за календарный месяц, если именно такой период используется в договорной отчётности. Это позволяет сравнивать результаты между периодами по одинаковым правилам и не смешивать данные с разной продолжительностью.

Для анализа также полезно смотреть не только итоговый процент, но и количество нарушений, их причины и распределение по типам обращений. Тогда отчёт показывает не просто факт отклонения, а проблемы в процессе поддержки.

Показатели качества поддержки

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

В зависимости от услуги можно контролировать:

• долю повторно открытых обращений;
• количество обращений, решённых без повторной передачи;
• соблюдение установленного процесса информирования;
• выполнение отдельных обязательств по конкретным услугам.

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

Как определить сроки SLA для разных заявок

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

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

Критические инциденты

Для критического инцидента обычно устанавливают наиболее короткое время реакции и повышенный приоритет обработки. Но само понятие критичности необходимо определить через влияние на сервис.

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

Для критических обращений полезно отдельно прописывать:

• кто имеет право присвоить или изменить приоритет;
• каким способом уведомляются ответственные специалисты;
• когда запускается эскалация;
• как часто заказчику сообщают статус;
• в какой момент обращение переводится в более низкий приоритет.

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

Обычные обращения и запросы

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

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

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

Как закрепить SLA в договоре

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

В документе желательно связать между собой услугу, категорию обращения, приоритет, целевое значение, календарь, условия запуска и остановки отсчёта, исключения, порядок контроля и последствия нарушения. Microsoft при разборе SLA рекомендует отдельно анализировать область действия, методику измерения, исключения и условия получения предусмотренной компенсации.

Чем меньше неоднозначных формулировок останется, тем проще заказчику и исполнителю одинаково интерпретировать отчётность.

Правила расчета показателей

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

Например, для первой реакции логика может выглядеть так: время начинает считаться после регистрации корректной заявки в Service Desk и останавливается после первого содержательного ответа специалиста.

Для времени решения правило будет сложнее. Счётчик может стартовать одновременно с регистрацией, приостанавливаться на время ожидания обязательной информации от заказчика и завершаться после восстановления услуги либо выполнения запроса.

Кроме того, следует определить календарь. Если SLA действует только в рабочие часы, заявка, созданная вечером, не должна автоматически считаться просроченной к утру. Современные системы Service Desk позволяют использовать отдельные календари с рабочими днями, временными интервалами, часовыми поясами и исключёнными праздниками.

Исключения и периоды недоступности

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

В зависимости от услуги такими условиями могут быть:

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

Формулировки должны быть проверяемыми. Условие «другие причины, не зависящие от исполнителя» оставляет слишком широкое пространство для трактовки. Лучше определить, какие события исключаются и какими данными они подтверждаются.

Важно также не путать исключение из SLA и паузу конкретного таймера. Например, ожидание ответа пользователя может временно остановить отсчёт по заявке, после чего он продолжится. Atlassian прямо предусматривает подобную модель через Pause conditions.

Эскалация нарушений

Эскалация определяет, что происходит, если заявка приближается к нарушению SLA или уже вышла за установленный срок.

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

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

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

Штрафы и компенсации

Если стороны предусматривают финансовые последствия нарушения SLA, их следует связывать с конкретными измеримыми условиями. Это могут быть штрафы, уменьшение стоимости услуги, сервисные кредиты или другой согласованный механизм.

Если договор предусматривает штрафные санкции, их лучше привязать к конкретным нарушениям и прозрачной методике расчёта. Формулировка должна позволять определить, какое отклонение считается основанием для штрафа или компенсации и как оно подтверждается данными отчётности.

Нужно заранее определить:

• за нарушение какого показателя возникает компенсация;
• как рассчитывается её размер;
• за какой период оценивается SLA;
• существуют ли минимальные пороги;
• есть ли ограничения по максимальному размеру;
• каким образом подтверждается нарушение.

Не любой SLA обязательно предусматривает денежные санкции. Формат ответственности зависит от договора и характера услуги. В облачных SLA распространён, например, механизм сервисных кредитов при невыполнении определённого уровня доступности, однако конкретные условия всегда задаёт поставщик. Microsoft отдельно указывает, что последствия и процедура получения компенсации являются частью условий конкретного SLA.

Как контролировать выполнение SLA

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

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

Мониторинг сроков и уведомления

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

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

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

Atlassian описывает SLA-таймеры как инструмент, позволяющий агентам видеть оставшееся время и выбирать, какие обращения нужно обрабатывать раньше. ServiceNow поддерживает условия, длительности и события для SLA-задач.

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

Отчеты по выполнению SLA

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

В полезный отчёт могут входить:

• количество обращений за период;
• доля заявок, обработанных в рамках SLA;
• выполнение целей по первой реакции;
• выполнение целей по времени решения;
• результаты по разным приоритетам;
• количество и причины нарушений;
• динамика показателей по периодам.

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

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

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

Пересмотр показателей и условий

SLA не обязательно должен оставаться неизменным на весь срок сотрудничества. Изменяются IT-системы, количество пользователей, режим работы, критичность сервисов и возможности команды поддержки.

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

Менять SLA только ради улучшения отчётности не следует. Новые значения должны соответствовать реальным требованиям бизнеса и возможностям сервиса. Изменения также необходимо согласовывать и фиксировать так же однозначно, как первоначальные условия.

Чем SLA отличается от KPI и OLA

SLA, KPI и OLA связаны с оценкой и организацией работы, поэтому термины иногда смешивают. Однако они решают разные задачи.

Термины SLA и OLA также используются в практике управления IT-услугами, в том числе в подходах ITIL. Для понимания статьи достаточно различать внешний уровень обязательств перед заказчиком и внутренние договорённости между командами, которые помогают эти обязательства выполнять.

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

Разница между SLA и KPI

KPI сам по себе является показателем. Например, доля обращений, решённых вовремя, среднее время ответа или количество повторных обращений могут использоваться как показатели эффективности команды.

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

Простой пример:

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

Некоторые внутренние KPI могут быть жёстче условий SLA. Команда, например, способна поставить себе внутреннюю цель отвечать быстрее, чем обещано клиенту. Это создаёт запас для выполнения внешнего обязательства.

Разница между SLA и OLA

SLA связывает поставщика услуги и заказчика. OLA — Operational Level Agreement — описывает операционные договорённости между внутренними командами одной организации. Такое разграничение прямо используется в ServiceNow: SLA определяется как соглашение с внешним клиентом, а OLA — как соглашение между внутренними командами организации.

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

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

Типичные ошибки при составлении SLA

Одна из основных ошибок — использовать расплывчатые формулировки. «Быстрая реакция», «высокая доступность» или «оперативное решение» невозможно однозначно проверить. SLA должен переводить ожидания в измеримые правила.

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

Третья ошибка — фиксировать время реакции или решения, не определяя правила отсчёта. Нужно заранее установить рабочий календарь, момент старта, условия паузы и момент завершения. Иначе заказчик и исполнитель могут получить разные результаты расчёта одной заявки. Документация Atlassian показывает, что календарь и условия Start, Pause и Stop являются самостоятельными элементами настройки SLA.

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

Пятая — считать первую реакцию решением проблемы. Быстрое подтверждение получения заявки ещё не означает восстановления сервиса. Если для бизнеса важны оба показателя, их лучше измерять отдельно. Такой подход применяется и в Service Desk-платформах, где Response и Resolution существуют как самостоятельные цели.

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

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

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

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

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

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

Часто задаваемые вопросы

Можно ли устанавливать разные SLA для разных клиентов?

Да. Уровень сервиса может зависеть от условий договора, состава услуг, режима поддержки и критичности систем конкретного заказчика. При этом различия должны быть заранее зафиксированы, чтобы для каждой заявки было понятно, какие показатели SLA и сроки к ней применяются.

Обязательно ли устанавливать SLA для каждого вида обращения?

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

Может ли у одной заявки быть несколько показателей SLA?

Да. Для одного обращения можно одновременно контролировать, например, время первого ответа и время решения. Эти показатели отражают разные этапы работы службы поддержки, поэтому выполнение одного из них не означает автоматического выполнения другого.

Что делать, если решение заявки зависит от стороннего поставщика?

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

Нужно ли пересматривать SLA после изменения IT-инфраструктуры?

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

Можно ли использовать SLA без автоматизированной Service Desk-системы?

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

Источники

Service Level Agreements — IBM — документация IBM определяет SLA как соглашение между поставщиком и заказчиком, фиксирующее услуги, согласованный уровень сервиса и способы его измерения.

Service level agreements (SLAs) on tickets — IBM — документация IBM по работе SLA с заявками раскрывает целевые показатели времени реакции и решения, доступности, приоритетов, а также эскалации и уведомления при нарушениях.

Set up SLA conditions — Atlassian — официальная документация Jira Service Management описывает условия запуска, приостановки и завершения SLA-таймера, включая паузу на время ожидания ответа клиента.

Set up SLA calendars — Atlassian — документация Atlassian показывает, как при расчёте SLA учитывать рабочие дни, временные интервалы, часовой пояс и праздничные дни.

Create SLA goals based on customer details — Atlassian — официальное руководство подтверждает возможность задавать разные цели SLA для отдельных типов клиентов и организаций, например с учётом уровня поддержки.

SLA API — ServiceNow — документация ServiceNow разграничивает SLA для внешнего заказчика и OLA между внутренними командами, а также выделяет время первой реакции и время решения как отдельные цели.

How to Read a Service-Level Agreement (SLA) — Microsoft Learn — материал Microsoft раскрывает роль точных определений, условий и исключений SLA, правила измерения доступности и возможные последствия невыполнения обязательств, включая сервисные кредиты.

Нужна консультация?

Оставьте заявку и мы подробно ответим на все Ваши вопросы!

Отправляя сообщение, Вы разрешаете сбор и обработку персональных данных.. Политика конфиденциальности

Δ