Как разработать SLA: состав и согласование

Кратко

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

Актуально на 23 сентября 2026 года.

Из чего состоит SLA

РазделЧто в нёмКому в первую очередь важен
Охват услугЧто входит в поддержку, что нетОбеим сторонам — источник половины споров
Каналы и режим обслуживанияКак принимаются обращения и в какие часыЗаказчику — планирует, когда обращаться
Классы обращенийОпределения уровней срочности с примерамиОбеим — на этом строятся все сроки
Целевые показателиСрок первого ответа и срок решения по каждому классуОбеим — предмет самого соглашения
Исключаемые периодыЧто не засчитывается в срок: ожидание клиента, форс-мажорИсполнителю — без этого раздела любой срок формально нарушаем
Доступность сервисаЦелевой процент и способ расчётаЗаказчику, если поддерживается инфраструктура, а не только заявки
ОтчётностьЧто и как часто предоставляется заказчикуЗаказчику — единственный способ проверить показатели
Последствия нарушенияЧто происходит при невыполнении показателейОбеим — определяет цену обещания

Документ без раздела «Охват услуг» технически не является SLA — это просто список сроков без границ, к которому применимо любое требование заказчика.

Порядок разработки: сначала факты, потом цифры

  1. Опишите охват услуг — что входит в поддержку, а что оформляется отдельным запросом на развитие. Это должно появиться раньше сроков: без границ услуги любой срок можно оспорить, сославшись на то, что случай «тоже должен быть покрыт».
  2. Определите классы обращений тремя-четырьмя уровнями с конкретными примерами для каждого — «недоступность системы целиком» звучит понятнее, чем «критичный уровень».
  3. Возьмите фактические сроки за последние несколько месяцев — медиану времени ответа и решения по каждому классу — и от неё стройте целевой показатель с небольшим запасом. Срок, скопированный из чужого шаблона, не подтверждён вашей реальной численностью и нагрузкой.
  4. Опишите исключаемые периоды: ожидание ответа заказчика, плановые работы, недоступность сторонних сервисов. Без этого раздела первое же долгое молчание заказчика само превратится в нарушение исполнителя.
  5. Согласуйте последствия недостижения показателей — не заводите раздел со скидками или компенсацией, если не готовы считать их автоматически и без напоминаний. Что именно считается нарушением и как с ним работать дальше — в статье что считается нарушением SLA и что делать с просрочкой.
  6. Пропишите способ отчётности и проверки — заказчик должен иметь возможность выгрузить свои обращения с датами и посчитать показатель самостоятельно, а не верить отчёту на слово.

Как считать целевую доступность: пример с настоящими числами

Доступность считается по формуле: (общее время периода − время недоступности) ÷ общее время периода × 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 часов; раздельные правила по приоритетам доступны не на всех тарифах (Тарифы).

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

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

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