SLA: как работает соглашение об уровне обслуживания, пример и отличие от OLA

Иван Софронов

Иван Софронов

Product Lead ELMA365 Service Desk

Все статьи автора

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

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

Краткое содержание статьи:

SLA — что это такое простыми словами

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

В этом соглашении участвуют две стороны:

  • Заказчик — тот, кто получает услугу (бизнес-подразделение или внешний клиент).
  • Поставщик сервиса — тот, кто её оказывает (ИТ-отдел, внешняя сервисная компания или провайдер).

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

Термины SLA простыми словами

Термин Что это Зачем нужно
SLA Внешнее соглашение об уровне обслуживания между заказчиком и исполнителем. Чтобы зафиксировать регламент и гарантировать качество услуги для бизнеса.
OLA Внутреннее соглашение между подразделениями в рамках одной компании. Чтобы распределить ответственность между отделами (например, сколько времени есть у ИТ на помощь техподдержке).
KPI Ключевые показатели эффективности конкретных сотрудников. Для оценки личной продуктивности и расчета мотивации (например, сколько заявок закрыл специалист).

Что входит в SLA-соглашение об уровне обслуживания

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

  • Предмет и описание услуги. Четкое определение того, какой сервис предоставляется (например, поддержка ИТ-инфраструктуры, облачный хостинг или обслуживание оргтехники).
  • Границы сервиса. Фиксация зон ответственности: что именно исполнитель берет на поддержку, а какие задачи остаются на стороне заказчика или сторонних подрядчиков.
  • Режим работы и каналы связи. Часы доступности поддержки (например, 24/7 или 9:00–18:00 по будням) и способы подачи заявок (телефон, email, портал самообслуживания).
  • Приоритеты и категории обращений. Классификация заявок по степени их влияния на бизнес (например: «Критическая» — система не работает у всех; «Низкая» — консультационный вопрос).
  • Целевые метрики. Главные цифры соглашения: время реакции (через сколько ответят), время решения (как быстро исправят) и коэффициент доступности системы в процентах.
  • Правила измерения. Описание того, что считается точкой старта и остановки таймера (например, время «замораживается», пока исполнитель ждет уточняющую информацию от заказчика).
  • Порядок эскалации. Алгоритм действий, если задача не решается вовремя: к кому из руководства переходит вопрос и кто подключается для ускорения процесса.
  • Последствия нарушений. Меры ответственности при несоблюдении метрик. Это могут быть штрафы, сервисные кредиты (скидки на будущие периоды) или обязательство составить план улучшений сервиса.

Типовые метрики SLA

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

К основным метрикам относятся:

  • Время первой реакции (First Response Time, FRT). Срок, в течение которого исполнитель подтверждает получение заявки. Это не время исправления ошибки, а показатель того, что заявку клиента взяли в работу.
  • Время решения (Time to Resolve, TTR). Период от момента регистрации обращения до его полного закрытия. Самая критичная метрика для бизнеса, напрямую влияющая на удовлетворенность пользователей.
  • Время восстановления (Recovery Time Objective, RTO). Время, необходимое для возобновления работоспособности системы после сбоя. Оно может быть короче времени решения (например, временные доработки вернули доступ к системе, хотя корень проблемы еще исследуется).
  • Доступность сервиса (uptime). Процент времени, когда система была полностью работоспособна (например, 99.9%). Учитывает как внеплановые сбои, так и регламентные работы.
  • Процент выполненных обращений в срок (SLA Compliance). Отношение общего количества заявок к тем, по которым не были нарушены временные рамки. Помогает оценить стабильность работы команды.
  • Backlog и просрочки. Количество накопленных, но еще не решенных задач. Хотя это чаще внутренний индикатор для руководства, рост бэклога — верный признак того, что в будущем метрики SLA начнут проседать.

Метрики SLA: что измеряем и как выглядит норматив

Метрика Что означает Пример норматива
Время первой реакции (First Response Time, FRT) Период с момента регистрации обращения до первого ответа специалиста. 15 минут для критических инцидентов.
Время решения (Time to Resolve, TTR) Суммарное время, затраченное на полное устранение проблемы или выполнение запроса. 4 рабочих часа для стандартных заявок.
Доступность (Uptime) Доля времени, в течение которого сервис доступен пользователям без сбоев. 99,9% (не более 43 минут простоя в месяц).
Время восстановления (Recovery Time Objective, RTO) Срок, за который работоспособность системы возвращается к норме после аварии. До 2 часов с момента обнаружения критического сбоя.
Процент просроченных задач (SLA Compliance) Доля обращений, по которым были нарушены установленные временные рамки. Не более 5 % от общего объема заявок за месяц.

Контроль SLA: как бизнес понимает, что сервис соответствует

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

В процессе мониторинга обычно контролируют следующие показатели:

  • Просрочки по времени реакции и решения. Фиксация каждого случая, когда специалист не ответил вовремя или не устранил проблему в рамках норматива.
  • Доля соблюдения соглашений. Итоговый процент заявок, выполненных без нарушений за отчетный период (например, месяц или квартал).
  • Причины срывов. Анализ того, почему произошел выход за границы SLA: нехватка ресурсов, сложные технические зависимости или задержки на стороне заказчика.

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

Что контролировать ежедневно, а что — по итогам месяца

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

В ежедневный цикл контроля входят:

  • Текущие просрочки. Выявление задач, по которым время реакции или решения уже превысило норматив, чтобы оперативно вмешаться в процесс.
  • Заявки «на грани». Мониторинг обращений, дедлайн по которым наступит в ближайшее время. Это помогает правильно расставить приоритеты и не допустить новых нарушений.
  • Эскалации. Проверка инцидентов, которые были переданы на более высокий уровень управления из-за сложности или критичности.

Еженедельно или по итогам месяца анализируются более масштабные показатели:

  • Итоговый процент выполнения SLA. Общая оценка того, насколько качественно оказывалась услуга за весь период.
  • Топ причин срывов. Определение системных проблем (например, регулярные задержки у конкретного подрядчика или нехватка персонала в определенные часы).
  • План улучшений. Формирование списка корректирующих действий на основе собранной статистики для повышения стабильности системы в следующем периоде.

Как реализовать SLA на практике: пример на ELMA365 Service Desk

SLA начинает работать только тогда, когда он «встроен» в процесс: система сама фиксирует сроки реакции и решения, запускает таймеры, поднимает эскалации и показывает, где команда не справляется. Один из понятных способов реализовать это — настроить уровни обслуживания (SLA) в ELMA365 Service Desk и привязать их к услугам и типам обращений.

Что нужно зафиксировать, чтобы SLA был измеримым

Чтобы параметры обслуживания перестали быть декларативными, в систему вносят конкретные настройки:

  • Нормативы времени реакции и времени решения. Установка четких временных рамок для различных приоритетов и сценариев обработки заявок.
  • Целевой процент выполнения SLA. Определение порогового значения (например, 95 %), которое позволяет видеть качество сервиса в целом по итогам периода.
  • Применение SLA по правилам. Настройка различных условий обслуживания в зависимости от состава услуги, категории инцидента, приоритета или принадлежности пользователя к определенной группе.

SLA в ELMA365 Service Desk

Как это выглядит в работе (логика настройки)

Процесс автоматизации контроля строится по прозрачному алгоритму. Сначала вы задаете уровни SLA (например: «Критично», «Высокий», «Обычный») с индивидуальными нормативами реакции и решения для каждого.

Заполнение информации SLA

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

Уровни и услуги SLA

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

SLA пример: как может выглядеть в реальном соглашении

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

Пример распределения нормативов может выглядеть следующим образом:

  • Критический приоритет (Авария). Время реакции — 15 минут, время решения — 2 часа. Применяется, если основная система недоступна для всех пользователей.
  • Высокий приоритет (Сбой). Время реакции — 30 минут, время решения — 4 часа. Применяется, если не работает важная функция у группы сотрудников.
  • Низкий приоритет (Запрос). Время реакции — 4 часа, время решения — 24 часа. Применяется для консультаций или стандартных настроек доступа.

Чтобы расчет времени был справедливым, в соглашении фиксируют правила измерения:

  • Учет рабочего времени. Таймеры SLA активны только в официальные рабочие часы (например, с 9:00 до 18:00 по будням). Если заявка поступила в 17:50, остаток времени переносится на следующее утро.
  • Пауза на стороне клиента. Отсчет времени автоматически останавливается, если решение задачи невозможно без действий заказчика (например, ожидание уточняющей информации или доступа в серверную).
  • Приоритет по типу услуги. Если инцидент касается жизненно важного бизнес-процесса (например, оплата на сайте), система может игнорировать стандартный приоритет и назначать максимально жесткие сроки.

Пример SLA для службы поддержки

Приоритет/тип обращения Время реакции Время решения Комментарий
Критический (Авария) 15 минут 2 часа Круглосуточно (24/7), полная остановка сервиса.
Высокий (Сбой функции) 30 минут 4 часа В рабочие часы (9:00–18:00), сервис работает частично.
Обычный (Запрос на сервис) 2 часа 16 рабочих часов В рабочие часы, консультация или настройка.
Низкий (Вопрос/Предложение) 8 рабочих часов 5 рабочих дней В рабочие часы, не влияет на текущую работу.

SLA и OLA: в чем разница

Для того чтобы итоговое качество сервиса соответствовало ожиданиям заказчика, внутри компании-поставщика должна быть выстроена четкая цепочка ответственности. Здесь на сцену выходят два ключевых понятия: SLA и OLA. Главное различие между ними заключается в векторе направленности и сторонах договора.

  • SLA (Service Level Agreement) — это внешнее обязательство перед клиентом или бизнес-заказчиком. Оно фиксирует, какой уровень сервиса получит конечный пользователь и что будет, если этот уровень не будет достигнут.
  • OLA (Operational Level Agreement) — это внутренняя договоренность между командами внутри одной организации. Соглашение OLA нужно для того, чтобы гарантировать выполнение общего SLA. Оно описывает, как подразделения взаимодействуют друг с другом, чтобы вовремя решить задачу клиента.

Примеры взаимодействия:

  • 1-я линия (SLA) и 2-я линия (OLA). По SLA техподдержка должна решить проблему за 4 часа. Но чтобы это случилось, по внутреннему OLA у второй линии (профильных инженеров) есть только 2 часа на выполнение своей части работы, иначе первая линия просто не успеет закрыть заявку в срок.
  • Инфраструктура (OLA) и поддержка (SLA). Если для работы сервиса требуется серверная мощность, системные администраторы по OLA гарантируют службе поддержки доступность серверов. Без этого внутреннего фундамента поддержка не сможет выполнить свои внешние обещания по аптайму системы.

Сравнение SLA и OLA

Критерий SLA OLA
Стороны Поставщик услуг и внешний заказчик (бизнес). Внутренние подразделения одной компании.
Цель Установить стандарты качества сервиса для клиента. Обеспечить слаженную работу отделов для выполнения SLA.
Где применяется Во внешних контрактах или между ИТ и бизнесом. Внутри ИТ-департамента или между бэк-офисом и поддержкой.
Что фиксирует Общее время решения проблемы для пользователя. Время передачи задачи между отделами и этапы работ.
Ответственность Финансовые штрафы или замена поставщика. Административная ответственность, KPI руководителей.
Примеры метрик Доступность сервиса 99,9 %, решение за 4 часа. Передача заявки за 15 минут, ответ инженера за 1 час.

KPI, SLA и OLA: как они связаны

Для эффективного управления сервисом важно различать инструменты контроля. Если SLA и OLA — это документы, фиксирующие правила игры, то KPI (Key Performance Indicators) — это конкретные измерители того, насколько успешно эти правила соблюдаются. Связка KPI OLA и SLA позволяет превратить сухие цифры отчетов в инструмент мотивации персонала и улучшения рабочих процессов.

Основные отличия и связи между ними:

  • KPI — это показатель, а не соглашение. В отличие от SLA, который является обязательством перед клиентом, KPI служит метрикой управления. Он помогает оценить производительность конкретного сотрудника или целого отдела.
  • SLA и OLA включают в себя KPI-подобные показатели. Сами нормативы (например, время решения задачи) часто становятся базой для расчета KPI. Если команда стабильно укладывается в SLA, ее показатели эффективности растут.

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

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

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

Почему нельзя путать KPI и SLA

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

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

Основные различия между KPI и SLA:

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

Частые ошибки при внедрении SLA (и как их избежать)

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

Наиболее распространенные ошибки включают:

  • Размытые формулировки. Использование фраз типа «быстро реагировать» или «решать в кратчайшие сроки» делает невозможным объективный контроль. Все нормативы должны быть выражены в конкретных минутах или часах.
  • Отсутствие четких правил измерения. Если не зафиксировано, когда именно запускается и останавливается таймер (например, старт при создании заявки или при взятии в работу), данные отчетов будут искажены.
  • SLA не поддержан OLA. Когда внешнее обязательство перед клиентом существует, но внутри компании подразделения не договорились о сроках взаимодействия, выполнение SLA становится делом случая, а не системы.
  • Отсутствие контроля и отчетов. Без регулярного анализа статистики и разбора инцидентов SLA остается «бумажным» документом, который никак не влияет на реальное качество сервиса.
  • Слишком жесткие нормативы без ресурсов. Установление нереальных сроков (например, решение любой проблемы за 15 минут) при нехватке персонала ведет к выгоранию команды и массовым подлогам в отчетности.

Чек-лист проверки SLA

  1. Сроки измеримы и понятны каждой стороне.
  2. Система автоматизирована (таймеры запускаются и останавливаются без участия человека).
  3. Учтены графики работ и условия паузы (ожидание ответа клиента).
  4. Отработаны внутренние OLA между командами.
  5. Руководство регулярно анализирует процент выполнения нормативов и причины отклонений.

FAQ про SLA

SLA — это договор или приложение к договору?

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

Можно ли использовать SLA вне IT?

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

Что делать при систематических нарушениях SLA?

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

OLA обязательно нужен?

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

KPI — это часть SLA?

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

Читать далее

Рецензент: Ольга Михеева

Поделиться:

Все статьи

Все статьи