Что такое SLA и зачем оно нужно бизнесу

Представьте, что вы заказываете услугу, но не знаете, когда её выполнят, кто отвечает за решение проблем и что делать, если что-то пойдёт не так. Такая неопределённость приводит к недопониманию между сторонами. Чтобы этого избежать, компании составляют SLA.

В статье разберём, что это такое, какие задачи решает соглашение об уровне обслуживания и как правильно его составить.

Что такое SLA

Service Level Agreement (SLA) — это соглашение об уровне обслуживания между поставщиком услуги и клиентом. В нём фиксируют требования к качеству и условиям работы сервиса.

Например, если компания поддерживает работу корпоративных сетей, в SLA могут указать:

• Как быстро она должна реагировать на неисправности.
• Сколько времени займёт устранение проблемы.
• Сколько сервис должен работать без перебоев.
• Какую компенсацию получит клиент, если условия не будут выполнены.

Благодаря этому клиент понимает, на что рассчитывать, а поставщик — какие обязательства должен соблюдать.

Чаще всего SLA используют в IT: хостинг-провайдеры, облачные сервисы, техподдержка. Но он полезен и в других сферах — логистике, клининге, сервисном обслуживании — везде, где качество работы можно измерить.

У SLA нет единой установленной формы. Каждая компания составляет такой документ под себя, потому что команды и процессы отличаются.

Отличие SLA от KPI и OLA

Key Performance Indicator (KPI) — это внутренний показатель, по которому компания оценивает эффективность работы сотрудников, отделов или всей команды. Метрика не связана напрямую с клиентами и не является юридическим обязательством.

Operational Level Agreement (OLA) — это внутреннее соглашение между командами внутри компании. В нём закрепляют, кто за что отвечает и в какие сроки выполняет свою работу, чтобы сервис соответствовал уровню обслуживания в SLA-соглашении.

В небольшом бизнесе обычно достаточно SLA и внутренних KPI. Но когда компания растёт и появляются отдельные команды поддержки, разработки и инфраструктуры, OLA помогает разделить ответственность и выстроить работу так, чтобы все отделы действовали согласованно.

Вот как это выглядит на практике:



• Компания запускает облачный сервис хранения данных и составляет SLA для клиентов.
• Чтобы выполнять эти обязательства, внутри компании создают OLA между отделами.
• Дополнительно устанавливают KPI, чтобы оценивать эффективность работы команд.

Зачем нужно соглашение об уровне услуг

Общее понимание, как работает сервис

SLA помогает заранее зафиксировать, как именно будет оказываться услуга: что считается нормальной работой сервиса и как оценивают результат. Это снижает риск недопонимания между заказчиком и исполнителем.

Прозрачная ответственность

SLA описывает, за что отвечает исполнитель, какие отклонения считаются нарушением и как стороны действуют при возникновении проблем. Это упрощает разбор спорных ситуаций и помогает урегулировать инциденты по заранее согласованным правилам.

Контроль качества и улучшение процессов

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

Повышение довери

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

Конкурентное преимущество

В некоторых отраслях SLA — обязательное требование крупных корпоративных клиентов. Без него компанию просто не будут рассматривать как подрядчика. Например, банки, ретейл, логистические компании работают по строгим регламентам, поэтому соглашение должно соответствовать их требованиям.

Ключевые метрики и показатели в SLA

В таблице собрали показатели, которые включают в SLA. По ним оценивают работу сервиса и службы поддержки: что именно измеряется и за что отвечает каждый параметр.

Как рассчитать основные показатели обслуживания

Чтобы SLA работало и приносило пользу, его параметры должны опираться на конкретные цифры. Без точных расчётов вы рискуете либо обещать клиентам невыполнимое, либо занижать планку и потерять доход в конкурентной борьбе. Разберём, как правильно считать ключевые показатели обслуживания.

Доступность сервиса

Что это: доля времени, когда сервис был доступен и работал без сбоев.

Формула:

Доступность сервиса (%) = ((Общее время − Время простоя) / Общее время) × 100

Например, интернет-магазин работает круглосуточно: за месяц — 720 часов. Из них сайт был недоступен 3,6 часа из-за технических сбоев. 

Доступность сервиса = ((720 − 3,6) / 720) × 100 = 99,5%.

Казалось бы, 99,5% — это высокий показатель. Но в реальном времени это означает, что сайт может быть недоступен около 3,6 часа в месяц или примерно 43 часа в год. Для банковского приложения такие показатели неприемлемы, а для небольшого блога — вполне допустимы.

Среднее время первого ответа

Что это: как быстро поддержка отвечает на обращение клиента.

Формула:

Среднее время простоя = Сумма времени до первого ответа по всем заявкам / Количество заявок

Например, служба поддержки за день получила 20 обращений. Для всех этих заявок посчитали, сколько времени прошло до первого ответа, и в сумме получилось 400 минут.

Среднее время первого ответа = 400 / 20 = 20 минут.

Среднее время устранения инцидентов

Что это: сколько в среднем занимает полное решение проблемы — от создания заявки до её закрытия.

Формула: 



Среднее время устранения инцидентов = Сумма времени на устранение всех инцидентов / Количество инцидентов

Например, IT-служба за неделю закрыла 15 инцидентов. Первый решили за 2 часа, второй — за 5 часов, третий — за 30 минут и так далее. Суммарно потратили 60 часов.

Среднее время устранения инцидентов = 60 / 15 = 4 часа.

Процент выполнения SLA

Что это: доля заявок, которые были обработаны в сроки, обещанные в SLA.

Формула:

Процент выполнения SLA (%) = (Количество заявок, выполненных в срок / Общее количество заявок) × 100

Например, за месяц поступило 500 заявок. Из них 475 закрыли в рамках договора SLA, 25 — с нарушением сроков.

Процент выполнения SLA = (475 / 500) × 100 = 95%.

Показатель ниже 90% — это тревожный результат. Если систематически нарушать соглашение, клиенты будут недовольны, придётся платить штрафы и это отразится на репутации компании.

Как собрать данные для расчёта

Прежде чем считать показатели, накопите статистику. Заведите таблицу или используйте систему учёта заявок.

В таблице зафиксируйте:

• Время поступления запроса.
• Время первого ответа.
• Время полного решения проблемы.
• Причину задержки, если сроки нарушены.

Собирайте данные в течение 1–3 месяцев. Это даст реалистичную картину и поможет установить достижимые цели в соглашении об уровне обслуживания.

Если ваша поддержка работает не круглосуточно, обязательно учитывайте это в расчётах. Заявка, которая поступила в пятницу в 18:00, не должна висеть всё воскресенье. Настройте систему так, чтобы она учитывала только рабочие часы.

Как составить эффективное SLA

Шаг 1. Изучите текущее состояние процессов

Для начала стоит собрать статистику за 1–3 месяца. Используйте систему учёта заявок — Битрикс24, ПланФикс, Мегаплан или таблицу в Excel. Фиксируйте каждое обращение: время поступления, время реакции, время закрытия, причину задержки.

Какие показатели собирать:



• Сколько времени в среднем уходит на первый ответ клиенту.
• Как долго решаются разные типы проблем.
• Какой процент заявок закрывается в течение определённого времени.
• Как часто возникают сбои и сколько они длятся.
• Сколько жалоб поступает от клиентов.

Шаг 2. Определите приоритеты и категории заявок

Разделите их по степени критичности и установите для каждой категории свои сроки. Критерии, по которым вы относите заявку к той или иной категории, должны быть подробно прописаны в договоре SLA.

Шаг 3. Установите реалистичные показатели

Ориентируйтесь на собранную статистику и закладывайте небольшой запас. Если сейчас среднее время ответа — 40 минут, в SLA не стоит указывать 30 минут. Безопаснее зафиксировать показатель выше фактического, чем обещать меньше и регулярно срывать сроки.

Шаг 4. Пропишите зоны ответственности

Это защитит от ситуаций, когда клиент требует компенсацию за простой, который произошёл не по вашей вине.

Обычно в SLA прямо перечисляют ситуации, которые не учитываются при расчёте показателей:



• Проблемы на стороне клиента: нет интернета, неправильная настройка оборудования, устаревший браузер.
• Действия третьих лиц: DDoS-атаки, хакерские взломы.
• Форс-мажоры: стихийные бедствия, военные действия, масштабные аварии у интернет-провайдеров.
• Плановые технические работы: если клиента уведомили заранее — как правило, за 24–72 часа.
• Превышение лимитов тарифного плана.

Шаг 5. Определите механизм компенсаций

Компенсации показывают клиенту, что вы отвечаете за качество сервиса, и помогают снизить напряжение в случае нарушений SLA.

Один из вариантов — привязать размер скидки к доступности сервиса за месяц:

• 99,0–99,5% — скидка 10%.
• 98,0–99,0% — скидка 25%.
• Ниже 98,0% — скидка 50%.

Вместо скидок можно предлагать:

• Сервисные кредиты — бесплатное продление подписки или дополнительных услуг.
• Фиксированная компенсация — например, за каждый час простоя сверх нормы клиенту начисляется компенсация в размере 2% от стоимости месячной подписки.

Шаг 6. Опишите процесс обработки заявок

Клиент должен понимать, как устроено взаимодействие:

• Куда обращаться: электронная почта, система тикетов, номер телефона, чат в мессенджере.
• Какие данные предоставлять при создании заявки.
• Кто и как определяет приоритет проблемы.
• Как улаживаются конфликты, если проблема не решается в срок.
• Как отслеживать статус заявки.

Шаг 7. Зафиксируйте режим работы поддержки

Пропишите точное время, когда ваша команда доступна, с учётом часового пояса.

Возможные варианты:



• Круглосуточно 24/7/365 — поддержка работает без выходных и праздников.
• Только рабочие часы — например, с 09:00 до 18:00 по московскому времени, с понедельника по пятницу.
• Расширенный график — например, с 08:00 до 22:00, всю неделю.
• Комбинированный режим — критические заявки обрабатываются круглосуточно, остальные — в установленное рабочее время.

Шаг 8. Пропишите процедуру измерения и отчётности

Клиент должен понимать, как проверяется выполнение SLA и на какие данные он может опираться.

Укажите в соглашении:

• Как измеряются показатели: автоматические системы мониторинга, логи (записи о событиях, которые происходят в программе, сервисе или сервере), система тикетов.
• Как часто предоставляются отчёты: ежемесячно, ежеквартально.
• Что входит в отчёт: статистика доступности, количество заявок по приоритетам, процент выполнения SLA.
• Кто имеет доступ к данным мониторинга.

Шаг 9. Предусмотрите механизм пересмотра SLA

Бизнес меняется, нагрузка растёт, сервис эволюционирует, поэтому условия SLA со временем тоже могут потребовать корректировки.

Для таких ситуаций в соглашении стоит заранее прописать:

• Как часто допускается пересмотр SLA: раз в квартал, раз в год или при изменении функций.
• Кто имеет право инициировать изменения: поставщик услуги, клиент или обе стороны.
• Как проходит согласование новой версии: сроки уведомления, порядок обсуждения и формат утверждения.

Шаг 10. Внедрите инструменты контроля

SLA работает только тогда, когда его выполнение можно отслеживать не вручную, а с помощью систем.

Какие инструменты использовать:

• Систему учёта заявок с автоматическим расчётом времени и напоминаниями о дедлайнах — Jira Service Management, Zendesk или Freshdesk. Она помогает фиксировать обращения, назначать приоритеты, считать время обработки и напоминать о приближении сроков.

• Мониторинг доступности сервиса в реальном времени — UptimeRobot, Zabbix. Такие системы проверяют, работает ли сайт или сервис, и сигнализируют о сбоях.

• Автоматические уведомления команде при риске нарушения SLA. Большинство тикет-систем могут отправлять уведомления в мессенджеры или на почту, если срок ответа или решения проблемы близок к лимиту.

• Дашборды с метриками для руководства и клиентов — Power BI, Tableau, встроенные дашборды тикет-систем. Они показывают среднее время ответа, количество инцидентов, процент выполнения SLA и другие ключевые показатели.

Без этих инструментов придётся вручную отслеживать каждую заявку, что повышает риск ошибок и нарушений.

Ошибки при составлении соглашения

Сложный язык

SLA должен быть написан так, чтобы его понял человек без юридического образования и глубоких технических знаний. Избегайте сложных юридических конструкций и профессиональных терминов.

Размытые формулировки

Каждый показатель в SLA должен быть измеримым и однозначным. Формулировки вроде «высокая доступность сервиса», «быстрый ответ» или «оперативное решение проблем» оставляют слишком много пространства для разных трактовок.

Нереалистичные показатели

Не обещайте больше, чем способны выполнить. Например, вы запускаете облачный сервис и заявляете доступность 99,99% — то есть около 4,3 минуты простоя в месяц.

Для клиента это звучит привлекательно, но для такого уровня нужны:

• Резервирование ключевых систем и компонентов.
• Круглосуточный мониторинг.
• Дежурная команда инженеров.

Если этого нет, SLA будет регулярно нарушаться, а вы — платить компенсации.

Перед тем как зафиксировать показатели, соберите статистику: сколько времени уходит на ответ, как часто происходят сбои, какая загрузка команды. Уже на этих данных устанавливайте значения SLA — с запасом 15–20% по времени решение.

Нет градации по приоритетам

Если установить одинаковые сроки для всех заявок, возникнут две проблемы:

• На некритичные запросы будут тратить слишком много ресурсов.
• Критичные инциденты не получат достаточно быстрого отклика.

В SLA важно разделять обращения по приоритетам и для каждой категории задавать свои сроки ответа и решения. Это позволяет сфокусировать усилия на действительно важных инцидентах.

Нереалистичные компенсации

Если компенсаций нет совсем, клиенты будут недовольны. Если они слишком большие, один серьёзный сбой может сильно повлиять на бизнес. Компенсации должны быть соразмерными, но не создавать угрозу для компании.

Не прописаны зоны ответственности 

Вы обещаете доступность 99,9%. Происходит масштабная DDoS-атака, которая обрушивает весь дата-центр. Если в документе об уровне обслуживания не прописаны зоны ответственности — формально вы нарушили обязательства.

В SLA важно указать, за что отвечает исполнитель, что находится в зоне ответственности клиента, а что зависит от третьих лиц.

Нет механизма измерения и отчётности

Прежде чем вводить показатель в SLA, убедитесь, что его можно измерить.

Например:

• Доступность сервиса фиксируется с помощью систем мониторинга.
• Время ответа и решения заявок — через тикет-систему, которая автоматически считает, сколько времени прошло с момента поступления запроса до первого ответа и до закрытия.

Без таких инструментов вы не сможете контролировать выполнение SLA и предоставлять клиентам прозрачные отчёты.