SLA (Service Level Agreement, соглашение об уровне обслуживания) — это приложение к договору поддержки, в котором зафиксированы четыре числа: за сколько подрядчик обязан ответить на обращение, за сколько запустить обходной путь, за сколько восстановить систему полностью и какую долю времени она обязана работать. Всё остальное в документе — определения к этим числам и оговорки, когда они не действуют. Читать SLA нужно именно в таком порядке: сначала найти четыре числа, потом проверить, чем они обставлены.
Путаница начинается с того, что продают обычно одно число — время реакции. «Реагируем за 30 минут» звучит убедительно, но реакция означает только то, что вам ответил живой человек и работа началась. Между ответом инженера и работающей системой может пройти шесть часов, и если в договоре нет второго и третьего числа, эти шесть часов ничем не ограничены.
Ниже — разбор всех четырёх чисел на одном сквозном примере: оптовая компания на 60 человек, контур автоматизации за 1 200 000 ₽, поток 3 000 обращений в месяц, четыре внешние зависимости — Bot API мессенджера, CRM, 1С:УТ и провайдер языковой модели. Это тот же модельный контур, на котором мы разбирали календарь первого года эксплуатации, поэтому цифры сопоставимы. Все расчёты модельные, их можно пересчитать на своих числах.
Четыре числа, за которые вы платите
Первое число — время реакции. Второе — время обхода: срок, за который процесс должен снова пойти, пусть и на ручном или временном решении. Третье — время полного восстановления, когда система работает штатно и накопившиеся данные догнаны. Четвёртое — доступность за месяц в процентах. Первые три измеряются в часах, четвёртое — в процентах, и именно поэтому их постоянно смешивают.
Срок от момента, когда обращение зарегистрировано в согласованном канале, до момента, когда инженер подтвердил приём и начал работу. Ключевое слово — «зарегистрировано»: если заявка ушла в личный мессенджер сотрудника подрядчика, отсчёт не начинается вообще. Реакция не означает решения и не должна продаваться как решение.
Обход — это временное решение, при котором бизнес-процесс снова идёт: ручная выгрузка остатков, переключение приёма заявок на почту, отключение сломанного сценария бота с передачей диалогов оператору. Восстановление — возврат к штатной работе с догнанными данными. В договоре нужны оба числа: без обхода подрядчик имеет право сутки чинить причину, пока у вас стоит отгрузка.
- Время реакции. Норма для критичного уровня — 30 минут при круглосуточном тарифе, до 4 рабочих часов при дневном.
- Время обхода. Норма для критичного уровня — 4 часа с момента реакции. Именно это число защищает выручку, а не время реакции.
- Время полного восстановления. Норма — рабочий день для критичного уровня, до 3 рабочих дней для остальных.
- Доступность за календарный месяц. Норма для контура вроде модельного — не ниже 99,5 %, что даёт до 3,6 часа простоя.
- Пятое, необязательное, но полезное: срок разбора инцидента — 3 рабочих дня на письменный ответ, почему это произошло и что сделано, чтобы не повторилось.
Живой пример: как это выглядит по часам
В среду в 09:10 у модельной компании перестал проходить обмен с 1С:УТ: очередная выгрузка остатков не прошла, менеджеры видят в CRM вчерашние цифры и продают вслепую. Мониторинг зафиксировал две неудачные попытки подряд и отправил оповещение. В 09:26 дежурный инженер подтвердил приём — время реакции 16 минут. В 11:40 запущен обход: остатки выгружены вручную в общий файл, менеджеры работают по нему. В 15:40 обмен восстановлен, накопившиеся заказы догнаны.
Итого: реакция 16 минут, обход 2 часа 30 минут, полное восстановление 6 часов 30 минут. Три разных числа для одного инцидента — и подрядчик, который называет только первое, формально прав, а фактически рассказал вам треть истории. Ущерб при этом делится на две части: пока обхода нет, компания теряет заказы, после обхода — теряет только время людей.
Горизонтальная лента одного рабочего дня с четырьмя отметками: «09:10 сбой обмена», «09:26 реакция — 16 минут», «11:40 обход запущен — 2 ч 30 мин», «15:40 восстановление — 6 ч 30 мин». Отрезок между 09:10 и 11:40 залит плотной штриховкой с подписью «полный простой, 15 816 ₽ в час, итого 39 540 ₽». Отрезок 11:40–15:40 — редкой штриховкой с подписью «работа на обходе, 4 800 ₽ в час, итого 19 200 ₽». Справа итог «58 740 ₽» и рядом маленький прямоугольник «штраф по SLA 5 000 ₽» для сравнения масштаба. Подписи по-русски.
Четыре уровня критичности и кто их назначает
Одно время реакции на все случаи жизни не работает: если чинить опечатку в кнопке за тот же час, что и вставший обмен, вы платите за круглосуточное дежурство ради опечаток. Поэтому инциденты делятся на уровни, и у каждого свои сроки. Четырёх уровней достаточно любой компании до 300 человек.
| Уровень | Что произошло | Пример в модельном контуре | Реакция | Обход или решение |
|---|---|---|---|---|
| 1. Критичный | Процесс встал целиком, обходного пути у сотрудников нет | Обмен с 1С:УТ не идёт, ассистент не отвечает, заявки не создаются | 30 минут (24/7) или 1 час | Обход за 4 часа, восстановление в тот же рабочий день |
| 2. Высокий | Процесс идёт, но теряются или искажаются данные | Часть обращений не попадает в CRM, сделки задваиваются, заказ приходит без строк | 2 рабочих часа | Решение до конца следующего рабочего дня |
| 3. Средний | Данные на месте, но система выдаёт неверное содержание | Бот называет старый срок поставки, отчёт считает не по той формуле | 1 рабочий день | Исправление за 3 рабочих дня |
| 4. Низкий | Неудобство, на бизнес-результат не влияет | Кнопка не на месте, формулировка ответа режет слух, лишнее поле в форме | 2 рабочих дня | В ближайший плановый релиз |
Если право присваивать уровень остаётся у подрядчика, со временем всё становится «средним»: так дешевле дежурство и лучше отчётность. Рабочее правило — уровень назначает заявитель по описанным в договоре признакам, а спор о понижении уровня разбирается в течение часа с владельцем процесса на вашей стороне. Второе обязательное правило: если инцидент 1-го уровня не закрыт обходом за 4 часа, он автоматически эскалируется на руководителя, а не остаётся у того же инженера ещё на день.
Третий уровень выглядит безобидно, но именно он приносит основной ущерб в системах с ИИ. Сервис жив, мониторинг молчит, а ассистент уверенно называет отменённые условия — и находят это по жалобам клиентов через несколько месяцев. Мы разбирали отдельно механику такого расхождения и способ ловить его заранее; в SLA под этот случай нужен явный пункт про исправление содержания ответов, иначе он не подпадает ни под одно определение аварии.
Цена ночи: за что доплата в 1,8–2,5 раза
Круглосуточное покрытие — самая дорогая строка в поддержке, и дорожает она не из-за сложности работы, а из-за календаря. В рабочем месяце примерно 168 рабочих часов и 720 календарных: покрытие 24/7 в 4,3 раза длиннее по времени. Промежуточный вариант — вечера до 23:00 и выходные — закрывает около 400 часов из 720. В цене эта разница отражается мягче, в 1,8–2,5 раза, потому что ночное дежурство пассивное: инженер спит, но обязан ответить. На наших тарифах поддержки это выглядит как 25 000–45 000 ₽ в месяц за реакцию в течение 4 рабочих часов, 50 000–90 000 ₽ за реакцию в течение часа с вечерами и выходными и от 120 000 ₽ за 30 минут круглосуточно.
Сравнение в три колонки. Колонка 1: «Рабочие часы, 168 часов покрытия в месяц», «реакция до 4 рабочих часов», «25 000–45 000 ₽/мес». Колонка 2: «Вечера и выходные, около 400 часов», «реакция до 1 часа», «50 000–90 000 ₽/мес», пометка «×2». Колонка 3: «Круглосуточно, 720 часов», «реакция до 30 минут», «от 120 000 ₽/мес», пометка «×2,4». Внизу общая подпись: «покрытие длиннее в 4,3 раза, цена выше в 1,8–2,5 раза — ночная смена пассивная». Чертёжный стиль, подписи по-русски.
Дальше начинается арифметика, которую подрядчику невыгодно делать за вас. У оптовой компании из примера ночью никто не отгружает и не покупает: если сбой случился в субботу, а обнаружен в понедельник в 09:10, потери начинаются с понедельника и равны разобранным выше 58 740 ₽. Круглосуточное дежурство эти потери снимает — вопрос лишь в том, сколько таких ночных сбоев бывает за год.
А теперь тот же расчёт для склада, работающий в две смены. Ночная остановка системы подбора останавливает не продажи, а людей: 14 человек в смене при полной стоимости 1 100 ₽ в час, четыре часа простоя — 61 600 ₽ за один инцидент. При шести таких инцидентах за год предотвращённые потери составляют 369 600 ₽ против той же доплаты в 300 000 ₽, и круглосуточное дежурство окупается. Разница между двумя компаниями не в размере и не в цене внедрения, а в одном вопросе: идёт ли ночью работа, которая встанет.
Доступность: 99,5 % — это 3,6 часа простоя в месяц
Проценты доступности читаются плохо, часы — хорошо. В календарном месяце 720 часов, поэтому перевод делается умножением: разница между 99,5 % и 99,9 % выглядит как четыре десятых процента, а на деле это три часа простоя против сорока минут. Полезно смотреть в правую колонку таблицы и спрашивать себя, переживёт ли бизнес такой перерыв.
| Доступность | Простой в месяц | Простой в год | Кому это подходит |
|---|---|---|---|
| 99,0 % | 7,2 часа | 3,65 суток | Внутренние отчёты и вспомогательные сервисы |
| 99,5 % | 3,6 часа | 1,83 суток | Типовой контур автоматизации малого и среднего бизнеса |
| 99,9 % | 43,2 минуты | 8,76 часа | Приём заказов на сайте, онлайн-запись, касса |
| 99,95 % | 21,6 минуты | 4,38 часа | Платёжный контур, круглосуточный сервис |
| 99,99 % | 4,3 минуты | 52,6 минуты | Практически не встречается вне крупных платформ |
Малому бизнесу 99,9 % почти никогда не нужны, и вот почему. Каждая девятка после запятой требует резервирования: второй сервер, второй канал связи, дежурная смена вместо одного человека, автоматическое переключение и его регулярная проверка. Это удваивает-утраивает постоянную часть бюджета эксплуатации ради экономии 2,9 часа простоя в месяц — по цене часа из расчёта выше это около 45 900 ₽. Проще и дешевле держать 99,5 % и вложиться в обход: заранее написанную инструкцию, по которой процесс идёт руками, пока систему чинят.
Если в цепочке четыре звена и у каждого 99,5 %, итоговая доступность равна 0,995 в четвёртой степени — это 98,0 %, то есть 14,3 часа простоя в месяц вместо 3,6. В модельном контуре таких звеньев ровно четыре: Bot API мессенджера, CRM, 1С:УТ и провайдер языковой модели. Поэтому цифра в SLA подрядчика относится только к его собственному контуру, и в договоре обязана быть фраза о том, по чему именно считается доступность и что исключается из расчёта.
Горизонтальная столбчатая диаграмма «простой в месяц, часы». Столбики: «99,0 % — 7,2 часа», «99,5 % — 3,6 часа», «99,9 % — 0,72 часа (43,2 минуты)», «99,95 % — 0,36 часа (21,6 минуты)». Отдельно выделенный штриховкой пятый столбик «цепочка из четырёх звеньев по 99,5 % = 98,0 % — 14,3 часа» с пояснением «доступности перемножаются». Ось X — часы простоя за месяц, подписи по-русски.
Штрафы, исключения и то, что стоит писать вместо
Штраф в договорах поддержки почти всегда сформулирован как возврат части абонентской платы: 10 % за нарушение, иногда 1/30 за каждые сутки. По расчёту выше это 5 000 ₽ против 58 740 ₽ реального ущерба — 8,5 %. Требовать компенсации упущенной выгоды бессмысленно: подрядчик либо откажется подписывать, либо заложит риск в цену, и вы оплатите страховку из своего кармана вперёд. Поэтому в хорошем SLA деньги — не главный инструмент.
- Автоматическая эскалация по времени, а не по просьбе: через 4 часа инцидент 1-го уровня уходит руководителю, через 8 — директору. В приложении — имена и телефоны, а не «служба поддержки».
- Компенсация часами, а не рублями: нарушение SLA добавляет 8 часов работ в следующий месяц сверх включённых. Подрядчику это дороже возврата 5 000 ₽, а вам полезнее.
- Право выйти из договора без штрафа и с передачей доступов после трёх нарушений критичного уровня за квартал. Это единственный по-настоящему работающий рычаг.
- Обязательный письменный разбор инцидента за 3 рабочих дня: причина, что сделано, что изменено, чтобы не повторилось. Без разбора одни и те же сбои возвращаются.
- Ежемесячный отчёт с фактом по каждому числу SLA: сколько обращений, сколько уложилось в срок, сколько нет и почему. Без отчёта проверить соблюдение SLA невозможно в принципе.
Отдельный раздел — исключения. Честный подрядчик не отвечает за то, чем не управляет: сбой у оператора связи, недоступность площадки или маркетплейса, отказ провайдера языковой модели, изменения на вашей стороне без предупреждения, истёкшие сертификаты и ключи, которые заводили вы, работы в согласованном окне обслуживания. Всё это нормально и должно быть в документе. Ненормально другое: когда исключение означает «мы ничего не делаем». Правильная формулировка обязывает подрядчика уведомить вас в те же сроки, включить обход, если он возможен, и вести инцидент до восстановления — просто без штрафных последствий для него.
Схема из пяти блоков со стрелками слева направо: «Общий канал приёма заявок (не личный мессенджер)» → «Дежурный инженер, реакция 30 минут» → «Обход за 4 часа» → «Руководитель поддержки, если обхода нет через 4 часа» → «Директор, если нет через 8 часов». Под каждым блоком строка «имя, телефон, кто заменяет». Сбоку отдельная ветка от блока обхода: «Разбор инцидента письменно за 3 рабочих дня». Чертёжный стиль, подписи по-русски.
Как проверить SLA до подписания: шесть действий
Самая частая дыра выглядит так: соглашение подписано, времена реакции красивые, а фактически в субботу вечером заявку никто не увидит до понедельника. Проверяется это за один вечер и до подписания, а не после первого инцидента.
- 1Отправьте тестовое обращение в 21:00 в пятницу или в субботу днём — по тому каналу, который прописан в договоре. Смотрите не на скорость ответа, а на то, ответил ли живой человек и назвал ли себя.
- 2Спросите график дежурств на ближайший месяц и имена дежурных. Если ответ звучит как «у нас вся команда на связи», дежурства нет: за «всех» не отвечает никто.
- 3Уточните канал приёма заявок и момент старта отсчёта. Личный мессенджер инженера каналом не является: он уходит в отпуск вместе с инженером, и в нём нет фиксации времени.
- 4Спросите, что считается решением инцидента — обход или полное восстановление. Если в договоре одно число, оно почти всегда про обход, а срок восстановления не ограничен ничем.
- 5Найдите в договоре определение дефекта и подтверждение, что дефекты исправляются бесплатно. Граница между дефектом и новым требованием — отдельная тема, которую стоит закрыть до подписания акта.
- 6Попросите обезличенный образец ежемесячного отчёта по SLA. Если такого отчёта нет в природе, значит, соблюдение SLA никем не измеряется, и все числа выше — украшение договора.
Ещё один практический пункт: SLA имеет смысл только вместе с мониторингом. Если о сбое подрядчик узнаёт от вашего менеджера, отсчёт времени реакции начинается не в 09:10, а тогда, когда кто-то из сотрудников догадался написать — иногда через полдня. Какие именно сигналы выводить в оповещения и кому они должны приходить, мы разобрали в отдельном материале про мониторинг. Задача контроля сроков в клиентском сервисе решается похоже и вынесена в каталог решений.
Когда SLA не нужен
Соглашение об уровне обслуживания стоит денег каждый месяц, поэтому оно нужно не всем и не всегда. Есть четыре ситуации, в которых мы сами советуем обойтись без него или ограничиться минимальной формулировкой в договоре.
- Система не участвует в деньгах. Внутренний отчёт, который смотрят раз в месяц, переживёт двое суток простоя без последствий. Достаточно записи «работы по обращениям в течение 5 рабочих дней» и оплаты по факту.
- Есть рабочий ручной обход, и процесс терпит день. Если менеджеры умеют принять заявку в блокнот и вечером внести её руками, час реакции не стоит доплаты: считайте цену часа простоя, и она окажется близкой к нулю.
- Контур совсем маленький. Один бот на 200 обращений в месяц: почасовая оплата по факту обращений выйдет в 3 000–8 000 ₽ в месяц против 25 000 ₽ минимального тарифа за готовность. SLA здесь заменяется договорённостью о канале связи и сроке в рабочих днях.
- У вас есть свой инженер, который знает контур и держит доступы. Тогда внешний SLA нужен не на всю систему, а точечно — на те звенья, которые он не может починить сам: интеграцию с учётной системой, доступ к платформе модели.
И обратное, столь же честное: если в вашем контуре есть хотя бы один процесс, остановка которого на четыре часа стоит дороже месячной абонплаты, торг о времени реакции — плохая экономия. Считать надо не абонплату, а цену часа простоя по своим объёмам; в модельном примере она составила 15 816 ₽, и на этом фоне разница между тарифами перестаёт быть главным вопросом.
Время реакции показывает, как быстро вам ответят. Время обхода показывает, как быстро вы снова начнёте зарабатывать. Платить стоит за второе.
