SLA фиксирует, за какое время и с каким качеством исполнитель обрабатывает обращения. Документ переводит размытое «решим как можно быстрее» в конкретные числа: срок первой реакции, срок решения, процент доступности услуги, приоритеты заявок и порядок эскалации. По этим числам обе стороны проверяют сервис и разбирают спорные ситуации по фактам, без опоры на ощущения. Ниже — расшифровка термина, набор измеримых параметров, порядок составления и контроля соглашения, а также сценарии работы SLA в Service Desk на платформе BPMSoft.
Что такое SLA простыми словами
SLA расшифровывается как Service Level Agreement — соглашение об уровне сервиса. Документ описывает услугу через измеримые показатели: как быстро исполнитель берёт заявку в работу, за какой срок закрывает её по каждому приоритету, какую долю времени услуга доступна.
SLA задаёт договорённость между поставщиком услуги и её получателем. Поставщиком выступает ИТ-отдел, сервисная служба, подрядчик или внешний провайдер. Получателем — бизнес-подразделение, клиент или партнёр. Соглашение работает и как внешний документ с клиентом, и как внутренний регламент между отделами одной компании.
SLA редко существует как самостоятельный юридический договор. Чаще соглашение входит в договор оказания услуг отдельным приложением или живёт внутри сервисного процесса как набор операционных правил. Сила SLA — в измеримости: каждый пункт проверяется по таймеру и отчёту, поэтому формулировки строятся вокруг цифр и сроков вместо общих обещаний.
Рядом с SLA в сервисной практике применяют ещё два типа договорённостей. OLA (Operational Level Agreement) описывает внутренние обязательства между подразделениями исполнителя — например, между первой и второй линией поддержки. UC (Underpinning Contract) фиксирует обязательства внешнего подрядчика, на которого опирается услуга. Вместе три документа закрывают всю цепочку ответственности за сервис.
Где используют SLA
SLA нужен там, где услугу получают регулярно и оценивают по срокам. Документ убирает разногласия о том, что считать нормой обслуживания, и даёт обеим сторонам общую систему координат.
IT и техподдержка
В ИТ SLA фиксирует доступность сервисов и сроки обработки инцидентов. Для критичных систем — почты, биллинга, ядра CRM — соглашение задаёт высокий процент доступности и короткие сроки восстановления. Заявки на доступ или консультацию получают более мягкие нормы.
Польза для бизнеса: ИТ-служба планирует нагрузку и дежурства под зафиксированные сроки, а руководитель видит, какие услуги недотягивают до согласованного уровня. Пример: SLA на восстановление почтового сервиса — 2 часа, на настройку нового рабочего места — 1 рабочий день.
Клиентский сервис
В клиентской поддержке SLA задаёт скорость ответа и закрытия обращений по каналам: телефон, почта, чат, форма на сайте. Соглашение помогает держать единый стандарт сервиса при росте числа обращений и при работе нескольких смен.
Результат: клиент понимает, когда получит ответ, а компания управляет ожиданиями и сокращает повторные обращения. Пример: первый ответ в чате — до 5 минут, письменный ответ по почте — до 4 рабочих часов.
Внутренние сервисные подразделения
SLA работает не только наружу. Бухгалтерия, HR, АХО, юристы и закупки оказывают услуги другим отделам и тоже выигрывают от понятных сроков. Соглашение об уровне сервиса между подразделениями убирает очередь «по знакомству» и делает нагрузку прозрачной.
Действие для бизнеса: оформите внутренние услуги как каталог с нормами обработки — согласование договора, подбор кандидата, выпуск пропуска. Каждая услуга получает срок, приоритет и ответственного.
Основные параметры SLA
Параметры SLA — это те самые числа, по которым проверяют сервис. Минимальный рабочий набор включает пять показателей. Каждый из них задаётся отдельно для разных приоритетов и типов услуг.
Время реакции
Время реакции — срок, за который обращение взято в работу: назначен ответственный, заявка подтверждена, клиент получил уведомление о приёме. Реакция не равна решению. Показатель отвечает на вопрос «когда заявкой займутся»; срок закрытия описывает уже время решения.
Короткое время реакции снижает тревогу заявителя и удерживает обращение от эскалации по таймауту. Пример нормы: реакция на критичный инцидент — 15 минут, на обычную заявку — 1 час.
Время решения
Время решения — срок от регистрации заявки до восстановления услуги или выполнения запроса. Показатель считают в рабочих часах с учётом графика обслуживания: для службы 8×5 ночные и выходные часы в срок не входят, для режима 24×7 учитывается всё время.
Время решения — основной критерий качества сервиса для бизнеса. По нему видно, укладывается ли служба в обещанные сроки. Пример: решение критичного инцидента — 4 часа, стандартного запроса — 8 рабочих часов.
Приоритет заявки
Приоритет определяет, какие сроки применяются к обращению. Приоритет рассчитывают из двух факторов: влияние (сколько пользователей или процессов затронуто) и срочность (как быстро нужен результат). Сбой ядра системы для всей компании получает высший приоритет, вопрос одного сотрудника — низкий.
Корректная матрица приоритетов защищает от двух крайностей: когда мелкие заявки тормозят критичные и когда срочное теряется в общем потоке. Приоритет задаёт связку «насколько важно → за какой срок решаем».
Доступность услуги
Доступность — доля времени, когда услуга работоспособна, выраженная в процентах за период. Показатель критичен для систем непрерывной работы: интернет-магазина, биллинга, платёжного шлюза. Доступность 99,9% за месяц допускает около 43 минут простоя, 99,5% — около 3,6 часа.
Доступность переводит надёжность в число, по которому планируют резервирование и регламентные работы. Чем выше процент, тем дороже инфраструктура и поддержка, поэтому уровень выбирают под реальную критичность услуги.
Эскалации
Эскалация — заранее описанный порядок действий, когда заявка близка к нарушению срока или превышает компетенцию исполнителя. Различают два вида. Функциональная эскалация передаёт заявку на более компетентную линию поддержки. Иерархическая подключает руководителя для решений и ресурсов.
Правила эскалации не дают заявке зависнуть. Срабатывание привязывают к таймеру: при достижении 80% срока система уведомляет ответственного, при превышении — поднимает заявку выше. Пример: критичный инцидент без движения 30 минут автоматически уходит руководителю смены.
Как составить SLA
Рабочий SLA собирают из понятных бизнесу услуг и проверяемых сроков. Документ не перегружают: лишние параметры усложняют контроль и снижают исполнимость.
- Опишите услуги. Составьте каталог: что именно поддерживается, для кого, в каком графике (8×5, 24×7). Услуга без чёткой границы не поддаётся измерению.
- Задайте приоритеты. Постройте матрицу влияния и срочности, привяжите к ней уровни приоритета от критичного до низкого.
- Установите сроки. Для каждого приоритета пропишите время реакции и время решения. Берите цифры из реальной статистики обращений, без оглядки на желаемое.
- Определите доступность. Для непрерывных сервисов укажите процент доступности и период расчёта, перечислите исключения (плановые работы).
- Пропишите эскалации и отчётность. Зафиксируйте триггеры эскалации, ответственных, формат и периодичность отчётов о соблюдении SLA.
- Согласуйте ответственность сторон. Опишите обязанности заявителя: как подавать заявку, какие данные прикладывать. Срок останавливается, пока служба ждёт информацию от заявителя.
Критерий хорошего SLA: каждый пункт можно проверить таймером и отчётом. Если показатель нельзя измерить, его убирают или переформулируют в число.
Как контролировать соблюдение SLA
Контроль SLA вручную не масштабируется: при сотнях заявок отследить сроки в таблице нереально. Соблюдение соглашения держат на автоматизации сервисного процесса.
- Таймеры на реакцию и решение. Система запускает отсчёт при регистрации заявки и учитывает график обслуживания, паузы и ожидание ответа заявителя.
- Автоуведомления о приближении срока. При достижении порога (например, 80% времени) ответственный получает предупреждение и успевает вмешаться до нарушения.
- Автоэскалации. При превышении срока заявка поднимается на следующую линию или к руководителю по заданным правилам.
- Отчёты и дашборды. Сводки показывают процент заявок в срок, число просрочек, узкие места по группам и услугам. По ним корректируют процессы и сами нормы.
Пример матрицы приоритетов и сроков
| Приоритет заявки | Пример проблемы | Время реакции | Время решения | Эскалация |
|---|---|---|---|---|
| Критичный | Недоступна основная система для всей компании | 15 минут | 4 часа | Руководителю смены при 30 мин без движения |
| Высокий | Сбой у отдела или ключевого пользователя | 30 минут | 8 рабочих часов | На вторую линию при 50% срока |
| Средний | Частичное неудобство, есть обходное решение | 2 рабочих часа | 1 рабочий день | На профильную группу при 80% срока |
| Низкий | Консультация, запрос на доступ или настройку | 1 рабочий день | 3 рабочих дня | Стандартная очередь без авто-эскалации |
Жизненный цикл заявки с SLA-таймером
SLA-таймер сопровождает обращение на всех стадиях обработки и фиксирует, на каком шаге сервис теряет время. Схема цикла:
Создана → Назначена → В работе → Решена → Закрыта
- Создана. Заявка зарегистрирована, определён приоритет, таймеры реакции и решения запущены.
- Назначена. Выбран ответственный или группа — здесь закрывается срок реакции.
- В работе. Идёт диагностика и решение; при ожидании ответа заявителя таймер ставится на паузу.
- Решена. Услуга восстановлена или запрос выполнен — фиксируется срок решения.
- Закрыта. Заявитель подтвердил результат, обращение уходит в историю и в отчётность по SLA.
SLA в Service Desk и ITSM-системе
Service Desk — единая точка приёма и обработки обращений. Именно в нём SLA превращается из текста соглашения в работающий механизм: система сама считает сроки, предупреждает о рисках и собирает отчётность.
BPMSoft Service Desk ведёт обращения по правилам SLA от регистрации до закрытия. Решение совмещает сервисный процесс с BPM-технологией и опирается на практики ITIL, поэтому процессы настраиваются под регламенты конкретной компании на low-code, без тяжёлой разработки. Система поддерживает три типа сервисных договорённостей — SLA, OLA и UC, — закрывая всю цепочку ответственности за услугу.
Сценарии контроля SLA в BPMSoft Service Desk:
- Приоритеты. Приоритет рассчитывается из влияния и срочности, к нему автоматически применяются нужные сроки реакции и решения.
- Таймеры. Отсчёт идёт по календарю обслуживания, с паузами на ожидание ответа заявителя и плановые работы.
- Автоматические уведомления. Ответственный получает оповещение при приближении к сроку и при риске просрочки.
- Эскалации. Заявка передаётся на следующую линию или руководителю по заданным триггерам без ручного контроля.
- Отчёты и дашборды. Сводки показывают долю заявок в срок, отклонения по SLA и узкие места службы поддержки.
Service Desk входит в продукт «Управление ИТ-услугами» (ITSM) на базе ITIL 4 — это свыше 20 процессов управления услугами, ИТ-активами и конфигурациями в единой среде. Платформа обрабатывает обращения из разных каналов, работает в браузере и в мобильном приложении, ведёт базу знаний и аналитику по качеству сервиса.
Частые ошибки
Типовые провалы при работе с SLA повторяются из компании в компанию. Их проще предупредить на этапе составления соглашения.
- Недостижимые сроки. Нормы взяты «с потолка», без статистики обращений. Служба систематически нарушает SLA, документ теряет смысл. Берите сроки из реальных данных.
- Один срок на все заявки. Без приоритетов критичный сбой и запрос на доступ обрабатываются одинаково. Стройте матрицу приоритетов.
- Нет учёта графика и пауз. Таймер считает время ожидания ответа клиента и нерабочие часы как просрочку службы. Настройте календарь обслуживания и паузы.
- SLA только реакция, без решения. Служба быстро берёт заявку и месяцами не закрывает. Контролируйте оба показателя.
- Нет отчётности. Соблюдение SLA нигде не видно, разбор инцидентов идёт по памяти. Заведите регулярные отчёты и дашборды.
- Соглашение не пересматривают. Бизнес и нагрузка меняются, а нормы остаются прежними. Пересматривайте SLA по итогам отчётных периодов.