Договор SLA или Service Level Agreement – что это такое?

В условиях высокой конкуренции качество сервиса становится одним из ключевых факторов выбора поставщика.

Но «качество» — это не абстрактное понятие. Его нужно измерять и фиксировать в договорённостях.

Для этого используется SLA.

SLA — что это такое?

SLA (Service Level Agreement) — это соглашение между заказчиком и исполнителем, в котором зафиксированы параметры услуги: сроки, уровень доступности, скорость реакции и ответственность сторон.

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

SLA изначально появился в ИТ-инфраструктуре и до сих пор именно там используется в наиболее формализованном виде.

В ИТ SLA задаёт конкретные параметры работы сервисов: время реакции, доступность систем, время восстановления после сбоев.

Позже этот подход начали применять и в других B2B-услугах, например в обслуживании коммерческой недвижимости, при ремонте специализированного оборудования и т.п.

При этом в ИТ SLA чаще всего формализован и измеряется в цифрах: временем реакции, доступностью сервиса, временем восстановления.

Для чего нужен SLA

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

В документе указываются права и обязанности сторон.

Например, в ИТ SLA определяет:

• время реакции на инцидент — например, 15 минут для критических сбоев и 2 часа для некритичных;
• допустимый простой системы — например, не более 43 минут в месяц (SLA 99,9%);
• время восстановления сервиса — например, до 2 часов для инцидентов уровня P1;
• доступность отдельных компонентов — например, API не ниже 99,95%, база данных — 99,99%.

Если речь идёт не об ИТ, а о сервисном обслуживании, логика остаётся той же — меняются только объекты. 

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

• исполнитель обеспечивает текущий мелкий ремонт (замену лампочек, покраску стен и т.п.), обслуживает системы подачи и отведения воды, но не отвечает за кондиционеры и бытовую технику — их обслуживает сторонняя компания;
• к критичным поломкам относится, допустим, прорванная труба отопления или засор слива раковины, и критичные поломки устраняются в течение нескольких часов;
• а к некритичным относятся грязные пятна на стенах; и на их устранение у исполнителя есть 5 рабочих дней.

Зачем SLA бизнесу

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

Действительно ли сервисная компания реагирует на инциденты так быстро, как обещала? Решаются ли все возложенные на нее проблемы?

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

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

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

Что такое OLA

Для исполнения SLA с внешним клиентом сервисной компании необходимо следить за процессом оказания услуги внутри — устанавливать сроки ответа на обращения и т.п. 

Для этого формируется OLA — Operational Level Agreement — аналогичный SLA внутренний документ компании, определяющий зоны ответственности подразделений.

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

Фактически OLA определяет, как при оказании внешней услуги будут взаимодействовать отдельные группы и сотрудники сервисной компании.

Условия OLA должны соответствовать SLA или быть более жесткими, чтобы выступать гарантией соблюдения последнего, поэтому для формирования SLA сначала лучше продумать OLA, согласовав его с исполнителями. 

Если инженер физически не сможет добраться на объект быстрее, чем за 2 часа, вы не должны обещать клиенту, что решите его проблему за час.

Разница между SLA и OLA

Основное различие SLA и OLA в том, что первый документ описывает взаимодействие с внешним клиентом, а второй — работу подразделений внутри компании.

И если SLA говорит на языке клиента и важных для него параметров сервиса («мы обеспечиваем доступность сервиса 99,8% времени»), то OLA погружается в технические детали и подробности взаимодействия отдельных подразделений и специалистов («диспетчер регистрирует заявку в течение 10 минут, инженер реагирует на нее в течение 2 часов, механик выезжает в течение 5 часов»).

Несмотря на различия в детализации и двунаправленность (определение требований для обеих взаимодействующих сторон), часто OLA называют внутренним SLA. Далее мы также будем использовать этот термин.

Что должно быть в договоре SLA

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

В SLA должны присутствовать:

• Общая информация — о сторонах, которые заключают соглашение;
• Параметры и границы предоставляемых услуг:
• по территориям — например, только в офисе заказчика, но не в домашних офисах его сотрудников;
• по оборудованию — только кассы, но не рабочие станции с 1С;
• по графику — с 9 до 18 по московскому времени, а не круглосуточно;
• по пользователям — заявлять о проблемах могут только указанные лица или весь коллектив компании.
• Критерии того, что услуги оказаны должным образом. Это должны быть измеримые параметры, которые могут оценить как клиент, так и сама сервисная компания. Можно использовать один или несколько параметров из списка:
• сроки реагирования на заявки — время первой реакции, передачи заявки профильному специалисту или решения вопроса;
• время простоя бизнеса клиента — максимальное время, в течение которого бизнес клиента будет простаивать из-за поломки, которая находится в зоне ответственности сервисной компании;
• доступность бизнеса клиента — минимальное время за период, в течение которого бизнес клиента будет функционировать в штатном режиме.
• Описание отчетности об оказанных услугах и процесса предъявления претензий.
• Ответственность исполнителя, в частности штрафные санкции за нарушения (если они предусмотрены).
• Способы работы с претензиями.

Также в SLA должно быть прописано, при каких условиях услуга считается оказанной (когда ответственность исполнителя прекращается).

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

Мы не рекомендуем указывать в SLA слишком много параметров или использовать какие-то косвенные показатели, слабо коррелирующие с действиями исполнителя. Они только усложняют работу.

Выбор правильных показателей для контроля, как выбор правильных метрик, требует опыта и понимания ситуации. К примеру, нельзя бездумно мотивировать сотрудников решать задачи клиента быстрее — так пострадает качество решения.

Доступность сервиса: что означают «девятки» в SLA

В SLA часто указывают доступность сервиса в процентах: 99%, 99,9%, 99,99%.
Но сами по себе эти значения мало что говорят, пока их не перевести во время простоя.

Фактически речь идёт о том, сколько времени сервис может быть недоступен за месяц или год. В SLA это называют уровнем доступности (availability) или «девятками».

Разница даже в одну «девятку» — это кратное ужесточение требований.

Например:

• 99% — допустимы часы простоя каждый месяц;
• 99,9% — допустимы десятки минут;
• 99,99% — несколько минут в месяц;
• 99,999% — секунды.

Чем выше доступность, тем дороже обходится её обеспечение:
нужны резервирование, отказоустойчивые системы и дежурства 24/7.

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

Без такого перевода SLA остаётся абстрактным и по-разному трактуется сторонами.

SLA и KPI: в чём разница

SLA и KPI часто путают, потому что оба связаны с показателями работы, но это разные уровни управления.

SLA — это обязательства перед клиентом. В нём фиксируются конкретные параметры сервиса: сроки реакции, время решения, доступность.

Если SLA нарушается, это может привести к штрафам, компенсациям или потере клиента.

KPI — это внутренние показатели команды. Они показывают, насколько эффективно работает сервис: скорость обработки заявок, загрузка сотрудников, процент выполненных задач.

Нарушение KPI не имеет юридических последствий, но сигнализирует о проблемах в процессах.

При этом KPI напрямую связаны с SLA.

Если SLA требует ответить за 30 минут, внутри команды может быть установлен KPI — обрабатывать 90% заявок за 20 минут.

Такие показатели дают запас и позволяют удерживать SLA на нужном уровне.

Ключевые метрики SLA и как их считать

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

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

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

Показывает, какая доля заявок была выполнена в пределах заданных сроков. Например, если за месяц обработано 100 заявок, из них 92 закрыты в срок — SLA Compliance = 92%.

MTTR — среднее время восстановления

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

Показывает среднее время, которое требуется на устранение проблемы. Например, если 10 инцидентов решались суммарно 50 часов — MTTR = 5 часов.

First Response Time (FRT) — время первого ответа

FRT = Среднее время от создания заявки до первого ответа специалиста

Показывает, как быстро команда реагирует на обращение клиента. Например, если в среднем первый ответ даётся через 20 минут — FRT = 20 минут.

Availability — доступность сервиса

Availability (%) = (Общее время − Время простоя) / Общее время × 100%

Показывает, какой процент времени сервис был доступен без сбоев. Например, если за месяц сервис не работал 1 час из ~720 часов — доступность составит около 99,86%.

Договор SLA

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

Глазами клиента

В рамках SLA заказчик получает конкретные метрики услуги — понятное описание того, за что именно он платит.

В соглашении фиксируются сроки реакции и решения заявок.
Это снимает ожидание «сделайте как можно быстрее» и переводит его в конкретные договорённости.

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

За счёт этого клиент получает понятный ответ на вопрос:
«Почему задача не решена сразу и в какие сроки она будет выполнена».

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

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

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

Глазами сервисной компании

С точки зрения сервисного отдела или компании SLA — это набор целевых метрик, к которым стремятся исполнители. SLA на самом деле очень полезно, т.к. наводит порядок не только во взаимоотношениях с клиентом, но и (по цепочке) в бизнес-процессах самой сервисной компании.

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

А несоблюдение заявленных условий — причина начать внутреннее расследование и депремировать виновных. 

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

Во взаимодействии с клиентом SLA помогает ограничить зону ответственности.

Почему SLA нарушается?

SLA часто нарушается из‑за ошибок в организации процессов: 

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

Проблемы возникают, когда заявки поступают мимо системы, из-за неполных данных в обращениях, а также задержек со стороны клиентов или подрядчиков.

В ИТ это часто связано с ростом нагрузки на инфраструктуру: увеличивается число пользователей, сервисы становятся сложнее, а SLA остаётся прежним.

Автоматизация помогает решить часть проблем, системы учёта заявок:

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

Автоматизация — не волшебная таблетка. Она работает, только если в компании есть чёткие регламенты (в т. ч. OLA), реальные сроки и достаточные ресурсы — иначе даже самая продвинутая система не исправит ситуацию.

Типичные ошибки при работе с SLA

Даже при наличии SLA компании часто сталкиваются с его нарушениями. Причина обычно не в системе или сотрудниках, а в том, как составили и внедрили соглашение.

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

SLA задают на этапе продаж, не учитывая реальные возможности команды. Например, обещают реакцию за 5 минут 24/7, хотя поддержка работает только в будни с 9 до 18.

В итоге SLA нарушается с самого начала. Сроки нужно задавать на основе фактических данных: загрузки, географии и доступности сотрудников.

Одинаковые сроки для всех заявок

Без приоритизации все задачи попадают в один поток.

В результате:

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

Например, прорыв трубы и косметический дефект не могут иметь одинаковые сроки. Для этого нужна матрица приоритетов (её вы найдете в разделе Как написать хороший SLA).

Игнорирование рабочего времени

Если в SLA не учтён график работы, сроки считаются некорректно.

Например:

• заявка создана в пятницу вечером;
• срок реакции — 2 часа;
• система считает время до субботы, когда никто не работает.

В результате формально SLA нарушено, хотя команда не могла повлиять на ситуацию.

Отсутствие уведомлений и эскалации

Даже при корректно заданных сроках заявки могут «зависать», если за ними нет автоматического контроля.

Например:

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

Решение — уведомление исполнителя до дедлайна и сигнал руководителю при риске просрочки. 

Например, в Okdesk такие уведомления приходят автоматически: система заранее предупреждает о приближении срока, фиксирует просрочки и уведомляет ответственных на разных уровнях.

Слишком много метрик

Иногда в SLA пытаются учесть всё сразу: скорость реакции, время решения, загрузку, качество, дополнительные показатели. В результате сотрудники не понимают, на что ориентироваться в первую очередь, а контролировать десятки метрик становится практически невозможно.

В такой ситуации приоритеты размываются. Инженер может пытаться «уложиться» сразу по нескольким показателям и в итоге не выполнить ни один.

Рабочий подход — оставить 3–5 ключевых метрик, которые действительно отражают качество сервиса и влияют на результат.

SLA не пересматривают

Со временем бизнес меняется: растёт количество клиентов, увеличивается поток заявок, появляются новые услуги. Но SLA при этом часто остаётся таким же, как в момент подписания.

В результате сроки перестают соответствовать реальности, а система фиксирует постоянные нарушения. Это воспринимается как проблема команды, хотя причина в устаревших условиях.

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

Нет ответственного за SLA

Даже при наличии SLA его выполнение может никто не контролировать. Показатели формально есть, но за ними не следят, нарушения фиксируются постфактум, а причины не анализируются.

В такой ситуации SLA существует только на бумаге и не влияет на работу команды.

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

Типы SLA

SLA может строиться по-разному в зависимости от того, как организован сервис и какие задачи нужно решить. На практике используют несколько подходов.

Сервисный SLA

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

Например, облачный провайдер может гарантировать доступность сервиса на уровне 99,9% для всех пользователей.
В сервисном бизнесе аналогичный подход используется, когда компания обслуживает типовые объекты — например, сеть магазинов с одинаковыми условиями обслуживания.

Такой вариант проще в управлении и масштабировании, но не учитывает особенности конкретных клиентов.

Внутренний SLA

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

Они помогают разделить между ними ответственность перед бизнесом за достижение общих целей. 

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

Однако часто их также называются внутренними SLA.

Клиентский SLA

Клиентский SLA настраивается под конкретного заказчика.

В этом случае условия могут отличаться:

• по срокам реакции;
• по приоритетам;
• по уровню доступности сервиса.

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

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

Динамический SLA

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

Например:

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

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

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

Внутренний SLA (OLA)

Отдельно стоит выделить внутренние соглашения — OLA.

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

Например, если в SLA клиенту обещан ответ за 30 минут, внутри компании может быть правило: регистрация — 10 минут, передача инженеру — 10 минут, начало работ — 10 минут.

Многоуровневый SLA

Многоуровневый SLA объединяет несколько уровней обслуживания в одном соглашении.

Например:

• базовый уровень — стандартные сроки и стоимость;
• расширенный — ускоренная реакция;
• премиальный — максимальный приоритет и отдельная линия поддержки.

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

Как написать хороший SLA

Хороший SLA — это документ, по которому обе стороны одинаково понимают, как работает услуга.
Клиент видит, что именно он получает и в какие сроки, а исполнитель — какие обязательства берёт на себя.

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

Определите, что именно вы обслуживаете

Первое, что нужно зафиксировать — саму услугу.

В ИТ это означает чётко обозначить:

• какие системы и компоненты входят в поддержку;
• какие инциденты считаются зоной ответственности;
• какие задачи не входят в SLA.

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

В сервисном бизнесе логика та же: важно сразу определить, какие объекты и работы входят в обслуживание, а какие — нет.

Зафиксируйте границы услуги

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

Важно прописать:

• где оказывается услуга (например, только на территории клиента или удалённо);
• когда она оказывается (график работы, выходные, праздники);
• кто может создавать заявки.

Например, если поддержка работает с 9 до 18, обращения ночью не могут считаться нарушением SLA.

Опишите приоритеты и типы инцидентов

Не все обращения одинаково важны, и SLA должен это учитывать.

В ИТ обычно выделяют уровни инцидентов:

• критические — полная недоступность системы;
• высокие — серьёзные сбои с обходным решением;
• средние и низкие — частичные ограничения или запросы на изменения.

Для каждого уровня задаются свои сроки реакции и решения.

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

Определите роли и зоны ответственности

Важно не только описать услугу, но и зафиксировать, кто за что отвечает.

В ИТ это обычно включает:

• первую линию — приём и регистрацию заявок;
• специалистов — решение инцидентов;
• подрядчиков или вендоров — решение узкоспециализированных задач.

Такая структура помогает избежать ситуации, когда задача «повисает» без ответственного.

Зафиксируйте процесс работы

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

Например:

• как создаётся заявка;
• как она передаётся между специалистами;
• на каком этапе считается выполненной.

Это особенно важно в сложных сервисах, где в решении участвуют несколько команд.

Зафиксируйте метрики качества

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

В ИТ это обычно:

• время реакции на заявку;
• время решения инцидента;
• доступность сервиса;
• процент выполнения SLA.

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

Например, если вы отвечаете только за работу кассового ПО, в SLA логично фиксировать время восстановления кассы, а не доступность всей ИТ-инфраструктуры магазина.

Иначе на результат начнут влиять факторы, которыми вы не управляете.

Делайте метрики реалистичными

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

Если заложить время решения 10–15 минут там, где задача требует диагностики и выезда, SLA будет регулярно нарушаться. В результате теряется доверие к самим показателям.

SLA — это баланс между ожиданиями клиента и реальными возможностями команды.

Чем быстрее сроки, тем больше ресурсов потребуется, и это напрямую влияет на стоимость сервиса.

Разделяйте SLA и внутренние метрики

Если в процессе участвует несколько команд, не стоит выносить все внутренние показатели в SLA.

Для клиента важен итоговый результат — например, время решения инцидента.

А детали того, сколько времени занимает каждый этап внутри компании, лучше фиксировать во внутреннем соглашении (OLA).

Например, SLA может задавать общее время решения — 4 часа, а внутри компании это время делится на этапы: регистрация, диагностика, выезд, устранение.

Так SLA остаётся понятным для клиента, а управление процессом происходит внутри команды.

Матрица приоритетов SLA

В SLA сроки обычно зависят от критичности проблемы.

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

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

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

Пример договора SLA

По ссылке представлен пример договора SLA реальной IT-компании. Вы можете создать его копию или скачать на ПК.

Как работать по SLA?

Схема работы по готовому соглашению:

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

Отметим, что соблюдать SLA проще, если процессы в сервисной компании отлажены, и автоматизированы 5 ключевых этапов:

• Автоматический расчёт метрик SLA — с учётом приоритета заявки, графика обслуживания, типа договора и раздельного учёта времени реакции и решения. 
• Таймеры до просрочки — система должна отслеживать этапы выполнения и рассылать уведомления ответственным ещё до нарушения дедлайна.
• Фиксация 100% обращений — все заявки должны попадать в систему автоматически, независимо от канала поступления (почта, телефон, Telegram, портал и т. д.).
• Контроль загрузки инженеров — система должна показывать количество активных заявок у инженеров и географическое распределение исполнителей и обращений.
• Автоматическая эскалация — если время истекает, система последовательно уведомляет инженера, руководителя и директора.

Помогают этому различные инструменты автоматизации, в частности, Help Desk.

Не отпугивает ли SLA клиентов?

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

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

Но в SLA компания пишет, что горячая линия работает с 9 до 18 по МСК, причем только в рабочие дни.

Очевидно, что в такой ситуации сотрудничество не складывается из-за завышенных ожиданий клиента. Однако если договор все-таки был бы подписан, ничего, кроме головной боли, сервисной компании он бы не принес. 

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

В отличие от обычного договора, SLA на старте фиксирует все параметры, распределяя ответственность.

Плюсы SLA для заказчика и исполнителя

Соглашение об уровне сервиса выгодно как заказчику, так и исполнителю.

Заказчик:

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

Исполнитель:

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

Чек-лист: важные моменты SLA

При составлении SLA рекомендуем обратить внимание на следующие моменты:

• Начните с частей сервиса и малых групп пользователей. Составляя SLA с нуля, не пытайтесь охватить необъятное. Рассмотрите небольшую группу пользователей и только критичные для них сервисы. Этот первый документ даст базу для дальнейшего развития многоуровневого SLA.
• При выборе KPI постарайтесь посмотреть на ситуацию глазами клиента — выбрать понятные и удобные ему KPI, позволяющие составить представление о характеристиках услуги.
• Информирование о SLA. Не забудьте сообщать о SLA всем пользователям, которых он касается.
• Контроль соблюдения SLA. Не полагайтесь на клиента — контролируйте соблюдение SLA со своей стороны.
• Пересмотр SLA. Соглашение надо регулярно пересматривать, т.к. бизнес заказчика и исполнителя эволюционирует — могут эволюционировать и основные параметры услуг.

Как Okdesk контролирует SLA?

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

Система оперативно уведомляет ответственных о риске просрочки или нарушении SLA, фиксирует просроченные заявки, формирует отчёты и рассчитывает процент просрочек. 

Кроме того, Okdesk предоставляет аналитику по загрузке сотрудников и динамике качества обслуживания.

Часто задаваемые вопросы про SLA

Что такое SLA простыми словами?

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

Чем SLA отличается от обычного договора?

Обычный договор фиксирует сам факт оказания услуги и общие условия сотрудничества.

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

Чем SLA отличается от OLA?

SLA описывает обязательства перед клиентом.

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

Проще говоря: SLA — «что обещаем клиенту», OLA — «как будем это делать внутри».

Что такое SLO и SLI?

SLI (Service Level Indicator) — это измеряемый показатель качества сервиса, например время ответа или доступность.
SLO (Service Level Objective) — это целевое значение этого показателя, к которому стремится компания.

SLA обычно включает в себя SLO и фиксирует их в договоре с клиентом.

Какой процент доступности выбрать для SLA?

Зависит от критичности сервиса и бюджета.

Для большинства задач достаточно 99–99,9%, что означает допустимый простой от нескольких часов до десятков минут в месяц. 

Более высокие значения (99,99% и выше) требуют серьёзных затрат на инфраструктуру и поддержку.

Обязателен ли SLA?

Нет, SLA не является обязательным документом.

Но в B2B-сервисе он фактически становится стандартом, потому что позволяет зафиксировать ожидания и избежать споров по качеству услуг.

Как часто нужно пересматривать SLA?

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

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

Полезные материалы

Дважды в месяц о развитии и автоматизации сервиса, техподдержки и выездного обслуживания.

⁣

Подписаться

Нажимая на кнопку «Подписаться», вы даете согласие на обработку своих персональных данных.

Кирилл Федулов

Сооснователь и директор по развитию Okdesk. Около 10 лет проработал в компании Naumen, где занимался внедрением ITSM и service desk систем в крупнейших российских компаниях: Полюс, Тинькофф, ЛСР и др. Эксперт в области организации и автоматизации процессов техподдержки, сервиса и выездного обслуживания.