SLA — письменное соглашение об уровне сервиса: приложение к договору, где поставщик обещает измеримые параметры работы, а клиент заранее знает, что ему гарантировано и что произойдёт при нарушении. Это не декларация вроде «мы всегда на связи», а набор проверяемых величин: за сколько отвечает поддержка, сколько часов в месяц услуга может быть недоступна, как считается компенсация.
Клиенту такой документ нужен по 2 причинам. Он снимает спор о том, что считать сбоем и когда пора нервничать, — границы описаны заранее. И он позволяет сравнивать поставщиков не по обещаниям на сайте, а по обязательствам в договоре. Поставщику SLA полезен ровно тем же: он ограничивает бесконечные ожидания и переводит эмоциональную претензию в понятный расчёт.
Из чего состоит соглашение об уровне сервиса#
Рабочее соглашение об уровне сервиса состоит из 4 частей: перечень услуг, на которые оно распространяется; метрики с целевыми значениями; способ измерения с указанием источника данных; последствия нарушения. Всё остальное в тексте — дополнения, без которых документ работает.
Перечень услуг пропускают чаще прочего, а он задаёт объём обязательств. Если написано просто «техническая поддержка», непонятно, входит ли туда обучение сотрудников клиента, доработка отчёта или восстановление файлов, удалённых по его же ошибке. Границу проводят списком: вот это покрывает абонплата, вот это — отдельная заявка.
Способ измерения — вторая по важности часть. Метрика без указания, чем и по каким данным её считают, спорна по определению: клиент меряет по ощущению, поставщик — по журналу заявок. Источник фиксируют прямо в тексте: система учёта обращений, мониторинг доступности, письма на служебный адрес.
Документ нужен не только в ИТ. Обслуживание оборудования, уборка, бухгалтерия, доставка — везде, где услуга регулярная и клиент оценивает её по накопленному опыту. Меняются только метрики: вместо доступности сервера появляется срок выезда мастера или дата сдачи отчётности.
Метрики: время реакции, решения и доступность#
Время реакции — срок, за который клиент получает содержательный ответ человека, а не автоуведомление о регистрации заявки. Время решения — срок, за который проблема устранена или предложен обходной путь. Смешивать их нельзя: реакция за 15 минут при неопределённом сроке решения злит клиента в реальной аварии.
Оба срока привязывают к приоритету. Хватает 3 уровней: работа остановлена полностью; работает с ограничениями, обходной путь есть; неудобство, которое терпит до планового обновления. Признаки каждого уровня описывают примерами, иначе все заявки приходят с пометкой «срочно».
Отдельно фиксируют график обслуживания. Обещание «ответ за 1 час» без указания рабочих часов формально означает и ночь субботы. Считать такие метрики вручную нереально, их берут из системы, где живут обращения: как её устроить, разбираем в материале про службу поддержки.
Доступность указывают в процентах от расчётного времени месяца. Разница между 99 % и 99,9 % на бумаге небольшая, а в часах простоя это примерно 7 часов против 45 минут. Прежде чем обещать вторую цифру, стоит проверить, есть ли резервирование и ночное дежурство, которые её обеспечивают.
Как посчитать цифры, которые вы вытянете#
Значения берут из собственной статистики. Порядок такой: выгрузить обращения за 3–6 месяцев, посчитать по каждому фактическое время реакции и решения, построить распределение и найти значение, в которое вы укладываетесь в 90 % случаев. Его и ставят в соглашение, округлив в безопасную сторону.
Среднее для SLA не годится. Обязательство по среднему означает, что половина клиентов обслужена хуже обещанного, и каждый из них прав в претензии. Поэтому пишут не «в среднем 2 часа», а «не более 4 часов в 95 % обращений». Формулировка выглядит скромнее, зато выполняется без героизма и переработок.
Второй фильтр — ресурс. Обещание проверяют на худшей неделе, а не на средней: сезонный пик, отпуск ключевого инженера, релиз с волной вопросов. Если в такие недели норматив не держится, в договор идёт цифра худшей недели, а не привычной. Клиент запоминает именно провал, а не спокойные месяцы до него.
Запас закладывают в обе стороны. Внутренний норматив для команды ставят жёстче внешнего обещания: клиенту обещано 4 часа — внутри работают на 2. Тогда обычная задержка не превращается в нарушение договора. Признак, что запаса нет: сотрудники регулярно закрывают заявки в последние минуты срока.
Исключения, компенсации и разбор спорных случаев#
Список исключений пишут раньше списка гарантий. Обычно в него входят: плановые работы с предупреждением заранее; сбои у поставщиков связи, хостинга и платёжных шлюзов; последствия действий самого клиента; ожидание доступа или ответа от него; форс-мажор. Иначе вы отвечаете за чужую инфраструктуру.
Компенсацию удобнее считать в процентах от абонплаты за период, а не через убытки клиента: убытки надо доказывать, проценты считаются автоматически. Обычная конструкция — за каждое нарушение начисляется доля месячного платежа, сумма за месяц ограничена потолком, выплата идёт скидкой в следующий счёт.
Порядок предъявления важен не меньше суммы. Указывают, кто фиксирует нарушение, в какой срок клиент обязан о нём заявить и по каким данным решается спор. Разумно закрепить, что расчёт делает поставщик по своим журналам и присылает его сам, — так меньше подозрений в подкрученных задним числом цифрах.
Прозрачность снимает половину конфликтов до их начала. Клиенту стоит видеть свои заявки, их статус и статистику за месяц без письма менеджеру. Где это удобнее показывать и что ещё туда выносить, разбираем в материале про личный кабинет клиента.
Вывод: SLA работает только вместе с замером#
Соглашение об уровне сервиса — это обещание, которое можно проверить. Оно ценно не формулировками, а тем, что у обеих сторон появляется одинаковое представление о норме: вот срок ответа, вот срок решения, вот что не покрывается и вот что будет, если норму не выдержали. Красивые цифры без системы учёта дают обратный эффект — клиент получает основание для претензии, которую вам нечем закрыть.
Практический минимум перед подписанием укладывается в 3 шага. Поднять свою статистику за последние месяцы и увидеть реальные сроки. Выписать исключения и приоритеты человеческим языком, без юридического тумана. Настроить регулярный отчёт, который уходит клиенту сам, даже когда месяц прошёл идеально.
Дальше документ живёт вместе с сервисом. Его пересматривают, когда меняется команда, растёт нагрузка или появляется новая услуга. Постоянные нарушения одного и того же пункта — не повод его тихо убрать, а сигнал, что процесс не тянет обещание, и чинить надо процесс.