Как разработать SLA: состав и согласование
Кратко
SLA разрабатывают не с текста договора, а с трёх решений: какие услуги входят в поддержку, какие классы обращений существуют и какие сроки на них назначить исходя из фактических данных, а не из желаемого. Согласование с заказчиком идёт в обратном порядке приоритета: сначала — что НЕ входит в услугу, потом — исключаемые периоды, и только потом — цифры сроков. Ниже — состав документа по разделам и порядок его сборки.
Актуально на 23 сентября 2026 года.
Из чего состоит SLA
| Раздел | Что в нём | Кому в первую очередь важен |
|---|---|---|
| Охват услуг | Что входит в поддержку, что нет | Обеим сторонам — источник половины споров |
| Каналы и режим обслуживания | Как принимаются обращения и в какие часы | Заказчику — планирует, когда обращаться |
| Классы обращений | Определения уровней срочности с примерами | Обеим — на этом строятся все сроки |
| Целевые показатели | Срок первого ответа и срок решения по каждому классу | Обеим — предмет самого соглашения |
| Исключаемые периоды | Что не засчитывается в срок: ожидание клиента, форс-мажор | Исполнителю — без этого раздела любой срок формально нарушаем |
| Доступность сервиса | Целевой процент и способ расчёта | Заказчику, если поддерживается инфраструктура, а не только заявки |
| Отчётность | Что и как часто предоставляется заказчику | Заказчику — единственный способ проверить показатели |
| Последствия нарушения | Что происходит при невыполнении показателей | Обеим — определяет цену обещания |
Документ без раздела «Охват услуг» технически не является SLA — это просто список сроков без границ, к которому применимо любое требование заказчика.
Порядок разработки: сначала факты, потом цифры
- Опишите охват услуг — что входит в поддержку, а что оформляется отдельным запросом на развитие. Это должно появиться раньше сроков: без границ услуги любой срок можно оспорить, сославшись на то, что случай «тоже должен быть покрыт».
- Определите классы обращений тремя-четырьмя уровнями с конкретными примерами для каждого — «недоступность системы целиком» звучит понятнее, чем «критичный уровень».
- Возьмите фактические сроки за последние несколько месяцев — медиану времени ответа и решения по каждому классу — и от неё стройте целевой показатель с небольшим запасом. Срок, скопированный из чужого шаблона, не подтверждён вашей реальной численностью и нагрузкой.
- Опишите исключаемые периоды: ожидание ответа заказчика, плановые работы, недоступность сторонних сервисов. Без этого раздела первое же долгое молчание заказчика само превратится в нарушение исполнителя.
- Согласуйте последствия недостижения показателей — не заводите раздел со скидками или компенсацией, если не готовы считать их автоматически и без напоминаний. Что именно считается нарушением и как с ним работать дальше — в статье что считается нарушением SLA и что делать с просрочкой.
- Пропишите способ отчётности и проверки — заказчик должен иметь возможность выгрузить свои обращения с датами и посчитать показатель самостоятельно, а не верить отчёту на слово.
Как считать целевую доступность: пример с настоящими числами
Доступность считается по формуле: (общее время периода − время недоступности) ÷ общее время периода × 100%. Для месяца в 30 дней общее время — 720 часов, или 43 200 минут. Отсюда легко получить допустимый месячный простой для разных целевых значений:
| Целевая доступность | Допустимый простой в месяц |
|---|---|
| 99,9% | 43 минуты |
| 99,5% | 3 часа 36 минут |
| 99,0% | 7 часов 12 минут |
| 98,0% | 14 часов 24 минуты |
Разница между 99,5% и 99,9% — это разница между «час на ремонт раз в месяц допустим» и «резервирование и дежурство ночью обязательны». Указывать 99,9%, не имея второго дежурного и резервной инфраструктуры, — обещание, которое не выполнить в первую же серьёзную ночь.
Согласование с заказчиком: с чего начинать разговор
Обсуждение SLA лучше начинать не со сроков, а с раздела «что не входит» — это снимает большинство будущих претензий заранее. Дальше — с исключаемых периодов: заказчик должен заранее понимать, что время его собственного молчания не считается временем исполнителя. И только после этого переходить к цифрам целевых сроков — на этом этапе спор идёт предметно, а не в целом.
Не обещайте сроков, которые не проверены собственной статистикой хотя бы за пару месяцев работы. Обещание на веру со стороны исполнителя выглядит так же, как обещание на веру со стороны продавца: красиво до первого нарушения.
Как проверить готовый SLA
- Есть ли раздел, явно описывающий, что НЕ входит в услугу.
- Есть ли раздел исключаемых периодов — без него любой срок формально нарушаем.
- Указан ли способ, которым заказчик может сам проверить показатели (выгрузка обращений с датами), а не только полагаться на отчёт исполнителя.
- Соответствуют ли назначенные сроки фактической численности команды, а не желаемому уровню сервиса.
- Учитывает ли расчёт срока рабочие часы, а не календарное время — иначе пятничный вечер превращается в нарушение уже к понедельнику.
Что делать после согласования — перенести сроки в систему учёта, провести пилот, обучить команду, — описано в статье Внедрение SLA: как запустить соглашение в работу.
Частые ошибки
Один срок вместо двух. SLA только по времени решения позволяет молчать двое суток перед первым ответом. Нужны оба показателя одновременно: срок первого ответа и срок решения.
Целевые показатели без исключаемых периодов. Три дня ожидания доступа от заказчика засчитываются как просрочка исполнителя, и через квартал показателю просто перестают верить.
Матрица приоритетов без утверждения. Если разные уровни срочности не закреплены документом и системой, приоритет присваивается «на глаз» и расходится с тем, что обещано заказчику.
Доступность без определения простоя. Если не написано, что именно считается недоступностью — полный отказ или просто замедление, — стороны посчитают её по-разному ровно тогда, когда это станет важно.
Частые вопросы
Из чего состоит SLA как документ?
Из восьми обязательных смысловых частей: охват услуг, каналы и режим, классы обращений, целевые показатели, исключаемые периоды, доступность, отчётность и последствия нарушения. Готовый текст со всеми разделами — в статье Соглашение об уровне услуг (SLA): готовый образец.
Чем SLA отличается от регламента поддержки?
Регламент описывает порядок работы для сотрудников — кто и как обрабатывает обращение. SLA — соглашение с заказчиком про итоговые сроки и последствия их нарушения. Регламент может меняться внутри компании без согласования с заказчиком, SLA — нет.
На каких принципах строится SLA?
На двух: сроки должны быть измеримы и проверяемы обеими сторонами, и они должны опираться на факт, а не на желаемое. Соглашение, которое нельзя проверить выгрузкой данных, работает только до первого спора.
Нужен ли SLA компании, у которой нет формального договора с клиентами?
Внутренний ориентир по срокам полезен в любом случае — он задаёт дисциплину команде. Но формальные последствия нарушения имеют смысл только там, где есть подписанный документ с заказчиком.
Как это устроено в TehProf.kz Support
Приоритеты, правила SLA и рабочие часы настраиваются в разделе заявок и применяются автоматически к каждому обращению — вручную выбранное правило действует как явное обещание срока по конкретной заявке, а не выбранное — назначается по условиям сверху вниз (Настройка SLA, приоритетов и крайнего срока). Стартовые значения сервиса для примера: срочный приоритет — 60 минут на первый ответ и 24 часа на решение, обычный — 480 минут и 48 часов; раздельные правила по приоритетам доступны не на всех тарифах (Тарифы).
Связанные статьи
- Что такое SLA в технической поддержке простыми словами
- Как считать процент выполнения SLA
- Какие метрики SLA стоит вести кроме процента
- Соглашение об уровне услуг (SLA): готовый образец
- Система заявок или таблица: что выбрать для учёта обращений
Нужна поддержка, которая так и работает?
TehProf.kz Support собирает обращения из WhatsApp, Telegram, почты и виджета в одну очередь, считает сроки по SLA и показывает, где служба проседает.