Клиент звонит и говорит: «У нас не работает касса, нужно срочно починить».
В этот момент почти всегда возникает одна и та же проблема: у клиента есть ожидания по срокам, а у исполнителя — своё понимание того, «как быстро это делается». Если эти ожидания заранее не зафиксированы, начинается конфликт: клиент считает, что всё должно быть «прямо сейчас», а сервисная компания работает по своим внутренним правилам.
Чтобы этого не происходило, используют SLA.
SLA (Service Level Agreement) — это соглашение об уровне обслуживания, в котором заранее прописано, как именно оказывается услуга: в какие сроки, с каким уровнем качества и с какой ответственностью за нарушения.
Проще говоря, SLA переводит «сделайте как можно быстрее» в конкретные договорённости: сколько времени есть на реакцию, сколько — на решение и что будет, если сроки не соблюдены.
Эта статья для руководителей сервиса, владельцев сервисных компаний и инженеров. Разберём, SLA что это, из чего оно состоит, как его правильно составить и как использовать в работе — не только в IT, но и в сервисном обслуживании оборудования.
Что такое SLA простыми словами
SLA (Service Level Agreement) — это соглашение об уровне обслуживания между заказчиком и исполнителем, в котором зафиксированы конкретные параметры услуги.
Проще говоря, SLA отвечает на четыре вопроса:что именно делается;как быстро;в каком объёме;и что будет, если сроки или условия нарушены.
Важно: SLA — это не замена договора, а его дополнение. В договоре обычно написано «исполнитель оказывает услуги», а в SLA — как именно: с какими сроками, приоритетами и метриками.
Сам термин появился в IT — в рамках подхода ITIL, где нужно было формализовать работу с инцидентами и доступностью сервисов. Но сейчас SLA используют в любой B2B-сфере: от хостинга до обслуживания оборудования и коммерческой недвижимости.
Разницу лучше всего видно на примерах.
В IT-аутсорсинге SLA может выглядеть так: на критичный инцидент (например, падение сервера) — реакция в течение 15 минут, время решения — до 2–4 часов. На некритичный (не работает принтер или доступ к системе) — реакция в течение 1–4 часов.
В сервисном обслуживании логика та же. Например, компания, обслуживающая кассовое оборудование в ритейле, фиксирует в SLA: выезд инженера на критичную поломку кассы — в течение 2 часов, плановое обслуживание — по графику, например раз в квартал.
Таким образом, SLA простыми словами — это документ, который переводит «сделайте быстро» в конкретные цифры и правила работы.
Зачем SLA нужно бизнесу
SLA нужен не «для галочки», а чтобы зафиксировать правила работы между заказчиком и исполнителем.
Без него всё держится на устных договорённостях. С ним — на конкретных параметрах: сроках, приоритетах и ответственности.
При этом SLA выгоден обеим сторонам.
Зачем SLA заказчику
Понятные параметры сервиса Клиент видит, за что платит. Не «поддержка оказывается при необходимости», а конкретно: время реакции, время решения, уровень обслуживания.
Контроль качества Все условия можно проверить. Если в SLA указано время реакции 30 минут, всегда видно, укладывается ли сервисная компания в этот показатель.
Прогнозируемость Клиент понимает, через сколько будет решена проблема.
Например, в IT-задачах это критично: если сервер недоступен, важно знать, будет ли он восстановлен за час или за полдня.
Рычаг ответственности Если SLA нарушается, это фиксируется и влечёт последствия: скидки, компенсации или штрафы.
Пример из IT: в SLA указана доступность сервиса 99,9%. Это значит, что допустимый простой — не более ~8,7 часов в год. Если значение превышено, клиент получает компенсацию.
Пример из сервисного обслуживания: в SLA прописано: устранение аварийной поломки эскалатора — не более 4 часов. Управляющая компания понимает, как быстро восстановится работа и может планировать процессы внутри ТЦ.
Зачем SLA исполнителю (сервисной компании)
Чёткие границы ответственности Сразу зафиксировано, что входит в обслуживание, а что нет.
Например, сервисная компания обслуживает кассовое оборудование, но не отвечает за терминалы эквайринга. Это убирает лишние споры.
Основа для процессов внутри компании SLA задаёт ориентиры для команды: по нему распределяются заявки, оценивается работа инженеров и выстраивается приоритет задач.
Защита от необоснованных требований Если в SLA указано, что поддержка работает с 9 до 18, клиент не может требовать решения ночью.
Все ожидания согласованы заранее.
Возможность управлять стоимостью сервиса SLA позволяет продавать разные уровни обслуживания.
Например, сервисная компания предлагает несколько вариантов:«Стандарт» — реакция 8 часов;«Бизнес» — 4 часа;«Премиум» — 1 час.
Клиент сам выбирает уровень обслуживания и соответствующую стоимость.
Что должно быть в SLA
SLA работает только в одном случае — когда в нём всё прописано конкретно. Если формулировки размытые, документ не помогает, а создаёт споры.
Разберём, из чего обычно состоит договор SLA.
1. Описание услуги и сторон
Фиксируется:кто заказчик;кто исполнитель;какая именно услуга оказывается;срок действия соглашения.
Например, в IT это может быть «поддержка серверной инфраструктуры», в сервисном бизнесе — «обслуживание кассового оборудования в торговых точках».
2. Границы предоставления услуги
Это один из самых важных блоков — он отвечает на вопрос «где заканчивается ответственность исполнителя».
Что обычно фиксируют:
по территории: только на объектах заказчика или возможна удалённая работа;по оборудованию: например, только серверы, но не рабочие станции / только кассы, но не терминалы;по графику: с 9 до 18 или 24/7;по пользователям: кто может подавать заявки (все сотрудники или только ответственные лица).
Без этого блока возникают споры в духе «а мы думали, это тоже входит».
3. Измеримые параметры качества (метрики)
Здесь SLA становится рабочим инструментом.
Фиксируются конкретные показатели:время реакции (когда исполнитель должен ответить);время решения (когда проблема должна быть устранена);доступность сервиса (если применимо).
Важно: все параметры задаются в цифрах.
Например:реакция — 30 минут;решение — 4 часа.
Без конкретных значений проверить SLA невозможно.
4. Приоритеты обращений
Не все заявки одинаково важны, поэтому вводится классификация.
Например:критичные — остановка бизнеса;высокие — серьёзные ограничения;средние — частичные проблемы;низкие — некритичные задачи.
Для каждого уровня задаются свои сроки по времени реакции и времени решения.
Это позволяет не тратить ресурсы на мелкие задачи, когда есть аварии.
5. Отчётность
Нужно заранее определить, как контролируется выполнение SLA.
Фиксируется:какие отчёты предоставляет исполнитель;как часто (например, раз в месяц);какие показатели в них включены.
Например: процент заявок, выполненных в срок, среднее время решения, количество просрочек.
6. Ответственность и штрафные санкции
Если SLA нарушается, должны быть последствия.
Это может быть:скидка на услуги;компенсация;штраф.
Важно прописать не только факт нарушения, но и механизм расчёта.
Например: «5% от месячной оплаты за каждый час просрочки по критичным заявкам».
7. Обязанности заказчика
SLA — это двусторонний документ.
Со стороны клиента тоже есть обязательства:предоставить доступ на объект;назначить контактное лицо;вовремя передавать информацию;поддерживать оборудование в зоне своей ответственности.
Если этого нет, исполнитель не сможет соблюдать сроки.
8. Порядок пересмотра SLA
Бизнес меняется: растёт количество заявок, появляются новые услуги, меняется команда.
Поэтому SLA должен регулярно пересматриваться.
Обычно фиксируют:периодичность (например, раз в полгода или год);условия пересмотра.
Без этого документ быстро устаревает и перестаёт работать.
Пункт SLA Пример для IT Пример для обслуживания оборудования
Описание услуги Поддержка серверной инфраструктуры Обслуживание кассового оборудования в торговых точках
Границы (график) Пн–Пт, 9:00–18:00 МСК Ежедневно, 8:00–22:00 (часы работы магазинов)
Время реакции (крит.) 15 минут 1 час
Время решения (крит.) 4 часа 4 часа
Штраф за нарушение Скидка 5% от месячной оплаты за каждый час просрочки Скидка 10% от стоимости обслуживания за месяц
SLI, SLO и SLA — в чём разница
Эти три термина часто используют вместе, но они означают разные вещи. Проще всего запомнить так: измеряем → ставим цель → обещаем клиенту.
SLI (Service Level Indicator) — это фактический показатель. То, что можно измерить.
Например:сколько реально заняла реакция на заявку;какой процент времени сервис был доступен.
Это «сырые данные» о том, как работает сервис.
SLO (Service Level Objective) — это целевое значение. Внутренний ориентир, к которому стремится компания.
Например:95% заявок должны решаться в рамках SLA;время выезда инженера — не более 2 часов.
SLO не показывают клиенту как обязательство, это внутренняя планка.
SLA (Service Level Agreement) — это уже договорённость с клиентом. То, что зафиксировано в документе и за что есть ответственность.
Например:доступность сервиса 99,9%;выезд инженера за 2 часа;при нарушении — компенсация или штраф.
SLA обычно строится на основе SLO, но формулируется чуть мягче, чтобы оставался запас.
Как это связано
Логика простая:
SLI показывает, как вы работаете сейчас;SLO задаёт, как вы хотите работать;SLA фиксирует, что вы обещаете клиенту.
Термин Что это Пример (IT) Пример (сервис оборудования)
SLI Фактический показатель Доступность сервера за январь = 99,8% Среднее время выезда инженера = 1 ч 45 мин
SLO Целевое значение Целевая доступность ≥ 99,9% Целевое время выезда ≤ 2 ч
SLA Обещание клиенту + ответственность «Доступность 99,9%, иначе скидка 10%» «Выезд за 2 часа, иначе штраф 5 000 ₽»
Что такое OLA и чем отличается от SLA
Чтобы выполнить SLA перед клиентом, недостаточно просто прописать сроки в договоре. Нужно, чтобы внутри компании процесс был разложен по шагам и каждый понимал свою зону ответственности. Для этого используют OLA.
OLA (Operational Level Agreement) — это внутреннее соглашение между подразделениями компании, в котором фиксируется, кто и за какое время выполняет свою часть работы. Если SLA — это обещание клиенту, то OLA — это договорённости внутри команды, которые позволяют это обещание выполнить.
Разницу проще всего увидеть на практике. В IT SLA с клиентом может звучать так: «решение критичного инцидента — 4 часа». Но сама по себе эта формулировка ничего не говорит о том, как уложиться в эти 4 часа. Внутри компании это раскладывается через OLA: диспетчер регистрирует заявку за 10 минут, первая линия берёт её в работу в течение 30 минут, при необходимости передаёт на вторую линию не позже чем через час. В сумме это даёт тот самый срок, который обещан клиенту.
В сервисном обслуживании логика такая же. В SLA может быть указано: «ремонт кассы — до 4 часов». Внутри компании это превращается в последовательность действий: назначение инженера — 15 минут, выезд — до 1 часа, работа на объекте — до 2,5 часов. Если один из этапов затягивается, общий срок тоже начинает «плыть».
Главное различие в том, что SLA — это внешний документ между заказчиком и сервисной компанией, написанный на понятном клиенту языке: сроки, уровень сервиса, ответственность. OLA — это внутренний документ, где фиксируются конкретные действия и роли: кто принимает заявку, кто выезжает, кто решает и в какие сроки.
При этом OLA обычно делают жёстче, чем SLA. Это создаёт запас внутри процесса: если где-то возникнет задержка — например, инженер дольше добирается до объекта — команда всё равно сможет уложиться в обещанный клиенту срок.
Если коротко: SLA фиксирует, что вы обещаете клиенту, а OLA — как именно вы это обеспечиваете внутри компании.
Критерий SLA OLA
Между кем Заказчик ↔ Исполнитель Подразделения внутри компании
Язык Понятный клиенту, без техдеталей Технический, с детализацией ролей
Назначение Фиксация обязательств перед клиентом Обеспечение выполнения SLA
Пример формулировки «Решение за 4 часа» «Диспетчер — 15 мин, выезд — 1 ч, работа — 2,5 ч»
Типы SLA
SLA можно строить по-разному — в зависимости от того, как устроен сервис и с кем вы работаете. На практике чаще всего используют три подхода.
Клиентское SLA
Это соглашение между сервисной компанией и конкретным клиентом. В нём учитываются особенности бизнеса заказчика: объём работ, критичность систем, требования к срокам. В IT это может быть договор IT-аутсорсера с заводом на обслуживание всей инфраструктуры: серверов, сетей, рабочих мест. В сервисном бизнесе — договор с сетью кофеен на обслуживание кофемашин, где заранее прописаны сроки выезда, график работ и приоритеты поломок. Это самый распространённый формат, потому что позволяет гибко настроить уровень обслуживания под конкретного клиента.
Сервисное SLA (по услуге)
В этом случае условия одинаковы для всех клиентов, которые получают одну и ту же услугу. Например, облачный провайдер устанавливает доступность сервиса на уровне 99,9% — и это правило действует для всех пользователей. В сервисном обслуживании такой подход используют, когда работают с типовыми объектами и не настраивают SLA под каждого клиента отдельно. Такое SLA проще поддерживать и масштабировать, но оно хуже учитывает особенности конкретного бизнеса.
Многоуровневое SLA
В одном документе задаются несколько уровней обслуживания, которые отличаются по срокам и стоимости. Например: «Стандарт» — реакция 8 часов, «Бизнес» — 4 часа, «Премиум» — 1 час.Клиент выбирает подходящий уровень в зависимости от задач и бюджета. В сервисном бизнесе это удобный способ работать с разными категориями клиентов: кому-то достаточно базового уровня, а кому-то важна максимальная скорость. Важно, что многоуровневое SLA — это ещё и инструмент монетизации: компания может продавать более быстрый и приоритетный сервис дороже, не увеличивая нагрузку на всех клиентов сразу.
Почему SLA нарушается и как этого избежать
SLA чаще всего нарушается не из-за «плохой команды», а из-за проблем в процессах. Одни и те же ошибки повторяются в разных компаниях — их можно заранее предусмотреть и закрыть.
Первая причина — нереалистичные сроки. На этапе продажи обещают реакцию за 15 минут, но инженер физически не может доехать до объекта быстрее чем за час. В итоге SLA начинает нарушаться с первой же заявки. Решение — опираться на реальные данные: сколько занимает дорога, сколько длится диагностика, какая загрузка у команды. SLA должен учитывать фактические возможности, а не ожидания клиента.
Вторая причина — заявки поступают мимо системы. Часть обращений приходит в почту, часть — в мессенджеры, часть — устно. Такие заявки не фиксируются, по ним не считается время реакции и решения. В результате SLA формально «срывается», хотя команда даже не видела часть задач. Решение — зафиксировать правило: все обращения проходят через систему учёта заявок.
Третья проблема — отсутствие приоритизации. Когда у всех заявок одинаковый статус, команда обрабатывает их в случайном порядке. В итоге критичные инциденты могут стоять в очереди вместе с мелкими задачами. Решение — ввести приоритеты: критичные, высокие, средние, низкие — и задать для них разные сроки.
Четвёртая причина — неравномерная загрузка. Один инженер ведёт десятки заявок, другой в это время почти не загружен. Без прозрачной картины по задачам это сложно заметить. Решение — контролировать распределение заявок и перераспределять их по загрузке или географии.
Пятая причина — задержки со стороны клиента. Например, нет доступа на объект, не назначено контактное лицо или не предоставлена информация для диагностики. Формально SLA продолжает «тикать», но исполнитель не может двигаться дальше. Решение — заранее прописывать в SLA обязанности заказчика.
Шестая причина — отсутствие контроля SLA в процессе. Если никто не отслеживает сроки в реальном времени, заявки начинают «зависать», а просрочка обнаруживается уже постфактум. Решение — внедрить систему, которая отслеживает сроки автоматически.
Как выполнять SLA без ручного контроля
Основная сложность SLA не только в том, как грамотно его прописать, а в том, чтобы реально соблюдать.Компании сталкиваются с одними и теми же проблемами:сроки отслеживаются вручнуюо просрочках узнают постфактумзаявки “зависают” между сотрудникамисложно понять, где именно произошёл сбойВ результате SLA формально есть, но на работу сервиса почти не влияет.Решение — автоматизация контроля сроков.Например, в Okdesk SLA встраивается прямо в процесс работы с заявками:для каждой заявки автоматически считается дедлайнсистема уведомляет о риске нарушения сроковзаявки приоритизируются по SLAфиксируются все нарушения и формируется отчётность
Не отпугивает ли SLA клиентов
Частый страх: если прописать SLA, клиент увидит ограничения — и откажется от работы.
Например, в документе указано, что поддержка работает с 9 до 18, а не 24/7. Кажется, что это может «ослабить» предложение.
На практике происходит наоборот.
Если SLA нет, ожидания не зафиксированы. Клиент рассчитывает на быстрый ответ в любое время — в том числе ночью или в выходные. Исполнитель работает по своему графику. В какой-то момент это приводит к конфликту: задача решена, но клиент недоволен.
SLA убирает эту проблему заранее. Сроки, график и условия фиксируются на старте, и обе стороны понимают, как будет работать сервис.
Клиент видит:когда можно обратиться;как быстро получит ответ;в какие сроки решается проблема.
Исполнитель понимает:какие обязательства он берёт;где проходят границы ответственности.
Это не ограничение, а согласование ожиданий.
Более того, SLA можно использовать как инструмент продаж.
Если клиенту нужна поддержка 24/7 или ускоренная реакция, это не проблема — просто другой уровень обслуживания. Например:базовый тариф — работа в рабочее время;расширенный — увеличенные часы поддержки;премиум — круглосуточная реакция.
Клиент сам выбирает, какой уровень сервиса ему нужен и сколько он готов за него платить.
Часто задаваемые вопросы (FAQ)
Заключение
SLA — это не формальность и не «документ для галочки», а рабочий инструмент.Он помогает сервисной компании и клиенту договориться о главном: что делаем, в какие сроки и по каким правилам.Когда параметры зафиксированы, исчезают лишние ожидания и споры.Клиент понимает, на что может рассчитывать, а команда — какие обязательства нужно выполнить.Грамотно составленное соглашение об уровне обслуживания задаёт ориентиры для работы:по нему распределяются заявки, оценивается качество сервиса и принимаются решения по загрузке и ресурсам.При этом не нужно пытаться сразу описать всё.Достаточно начать с базового: зафиксировать время реакции и время решения для нескольких типов обращений.Дальше SLA можно постепенно дорабатывать — по мере роста бизнеса и усложнения процессов.