Рынок ITSM-систем в России по итогам 2025 года достиг 20−35 млрд рублей по оценке CNews Analytics, и всё больше компаний переносит сервисный подход из ИТ на остальные подразделения. При этом само соглашение об уровне сервиса — SLA — у большинства живёт в документах: подписано, лежит в папке, а сроки всё равно считаются постфактум.
Разница между SLA на бумаге и рабочей системой — в четырёх элементах: метрики, обязательства, контроль, отчётность. В этой статье разберём, как собрать систему SLA, какие метрики выбрать, как назначить реалистичные пороги и следить за сроком по каждой заявке.
Что такое SLA и из чего состоит соглашение об уровне сервиса
SLA, или Service Level Agreement, — это соглашение об уровне сервиса. В нём поставщик услуги и её заказчик договариваются, какой результат, в какие сроки и на каких условиях должен быть предоставлен.
Поставщиком может быть внешний подрядчик — например, ИТ-компания или сервисный центр. Но не менее полезен SLA и внутри организации: между ИТ и бизнес-подразделениями, HR и сотрудниками, юридической службой и инициаторами договоров.
Что включить в SLA
Содержание соглашения зависит от услуги, но обычно в нём фиксируют:
услугу — что именно получает заказчик;
каналы обращения — портал, электронная почта, телефон, мессенджер;
метрики — какие показатели измеряют;
пороговые значения — допустимое время реакции и решения;
ответственных — кто принимает, исполняет и контролирует заявки;
приоритеты — какие обращения обрабатываются в первую очередь;
время предоставления услуги — например, в рабочие часы или круглосуточно;
последствия нарушения — порядок эскалации, информирования или пересмотра процесса.
Для внутреннего SLA необязательно использовать сложный юридический язык. Важнее, чтобы все участники одинаково понимали, что считается заявкой, когда начинается отсчёт времени и кто должен подключиться, если задача задерживается.
Какие бывают SLA
Чаще всего выделяют три типа соглашений.
Клиентский SLA описывает обязательства перед внешним заказчиком. Например, сервисная компания обязуется принять заявку клиента в течение 30 минут и восстановить доступ к системе в течение четырёх часов при критическом инциденте.
Внутренний SLA регулирует работу подразделений внутри компании. Например, HR-служба берёт в работу заявку на оформление нового сотрудника в день её поступления, а ИТ — предоставляет стандартный набор доступов до первого рабочего дня.
Многоуровневый SLA нужен, когда услуга состоит из нескольких этапов или в ней участвуют разные команды. Например, заявка на подключение нового филиала может проходить через ИТ, безопасность, закупки и АХО. Для заказчика действует общий срок, а у каждой внутренней команды — свой участок ответственности.
Чем SLA отличается от KPI и OLA
SLA и KPI часто используют рядом, но это разные инструменты.
SLA определяет обязательство по услуге: например, «критичная заявка должна быть решена за четыре часа».
KPI показывает результат работы сотрудника или подразделения. Например, доля заявок, выполненных в срок, или среднее время решения обращений за месяц.
OLA, Operational Level Agreement, — внутреннее операционное соглашение между командами, которые участвуют в оказании одной услуги. Оно помогает выполнить внешний или общий внутренний SLA.
Например, клиент ожидает решения инцидента за четыре часа. Чтобы уложиться в этот срок, первая линия поддержки должна зарегистрировать обращение за 15 минут, инфраструктурная команда — подключиться в течение часа, а владелец сервиса — принять решение по сложному случаю без долгого согласования. Эти внутренние договорённости и будут OLA.
Цена SLA на бумаге: куда уходят сроки без автоматического контроля
Если сроки проверяют только по ежемесячной выгрузке, компания видит уже свершившийся факт: обязательство нарушено, клиент или внутренний заказчик недоволен, а команда вынуждена разбирать причины задним числом.
Обычно процесс выглядит так:
Сотрудник отправляет запрос по почте или в мессенджере.
Исполнитель замечает его не сразу или перенаправляет коллеге.
Приоритет заявки остаётся неясным.
Срок приближается, но никто не получает предупреждения.
В конце периода руководитель выгружает данные и видит просрочку.
Проблема здесь не только в дисциплине отдельных сотрудников. У процесса нет единой точки входа, правил маршрутизации и прозрачного контроля.
Особенно заметна асимметрия между внешним и внутренним сервисом. К подрядчику компания предъявляет SLA, требует отчёты и может применять предусмотренные договором меры. При этом внутренние ИТ-, HR- или юридические запросы сотрудников нередко существуют в общей почте и обрабатываются по мере возможности.
В результате:
обращения могут оставаться без ответа неделями;
сотрудники не понимают, кто работает с их заявкой;
руководитель не видит загрузку службы и реальные причины задержек;
команды спорят о том, когда поступил запрос и кто должен был его выполнить;
у компании нет данных, чтобы улучшать процесс.
Автоматический контроль SLA не нужен для того, чтобы искать виноватых. Его задача — вовремя заметить риск, помочь команде среагировать и сохранить предсказуемый сервис для заказчика.
Управляйте SLA, услугами и заявками в Service Desk «Первой Формы»
Реализуйте любые процессы и маршруты, автоматизируйте прием и распределение задач, контролируйте сроки Подробнее
{$co}
Метрики SLA: что измерять и как считать
Не стоит включать в SLA все показатели, которые можно собрать. На старте достаточно четырёх-пяти метрик, связанных с ожиданиями заказчика и работой команды.
Доля заявок, выполненных в срок — SLA compliance. Аоказывает, какую часть обращений команда закрыла без нарушения установленного срока.
Формула: SLA compliance = (количество заявок, выполненных в срок / общее количество закрытых заявок) × 100%
Например, за месяц служба обработала 200 заявок, из них 184 закрыла в пределах SLA. Показатель составит 92%.
Время первого ответа. Это срок от регистрации обращения до первого содержательного действия команды: подтверждения, что заявка принята, уточняющего вопроса или начала работы.
Формула: Время первого ответа = дата и время первого действия исполнителя − дата и время
Время решения. Метрика показывает, сколько времени проходит от создания заявки до её выполнения или закрытия.
Формула: Время решения = дата и время закрытия заявки − дата и время регистрации заявки
MTTR — среднее время восстановления или решения. Ее используют прежде всего для инцидентов и технической поддержки. Показатель отражает среднее время, которое требуется команде, чтобы восстановить сервис или устранить проблему.
Формула: MTTR = сумма времени решения всех заявок / количество решённых заявок
Доля повторных обращений. Эта метрика помогает оценить качество решения и то, устраняет ли команда систематические проблемы. Например, сотрудник несколько раз запрашивает доступ к системе, потому что его права настроены неполностью.
SLA для клиентов и внутренних служб: как выстроить оба контура в едином решении
Внешний и внутренний сервисы используют похожую логику. В обоих случаях компания принимает обращение, определяет его тип и приоритет, назначает исполнителя, контролирует срок и сообщает заказчику статус. Разница в основном в составе услуг и ответственных, вести оба контура можно в едином решении.
«Первая Форма» — платформа для автоматизации процессов, на которой можно настроить клиентский и внутренний контуры обслуживания в едином пространстве. Например, в одной системе могут работать сервисная служба для клиентов, ИТ-поддержка сотрудников, HR Service Desk, юридические заявки и внутренние согласования.
Управление каталогом услуг
Каталог услуг помогает сотрудникам и клиентам быстро понять, с каким вопросом можно обратиться в службу, а команде — заранее задать правила обработки.
В каталоге для каждой услуги можно зафиксировать:
название и описание;
форму подачи заявки;
владельца услуги;
исполнителей или группу исполнителей;
доступные каналы обращения;
категорию и приоритет по умолчанию;
метрики SLA;
нормативные сроки;
маршрут согласования;
инструкции и материалы для заказчика.
Например, в каталоге HR-службы могут быть услуги «Оформить справку», «Изменить персональные данные», «Заказать подбор сотрудника», «Оформить командировку». В ИТ-каталоге — «Получить доступ», «Заказать оборудование», «Сообщить об инциденте», «Запросить консультацию».
В «Первой Форме» каталог можно реализовать через настраиваемые карточки и формы заявок. Сотрудник выбирает услугу на портале, заполняет нужные поля, а система создаёт задачу с подходящими исполнителями, сроком и маршрутом обработки.
Контроль SLA в реальном времени: маршрутизация, таймеры и эскалации в
Главное отличие рабочей системы SLA от документа — контроль происходит во время обработки заявки. В «Первой Форме» процесс можно настроить по следующей логике:
Обращения могут поступать из портала, электронной почты, формы на сайте, мессенджера или через интеграцию с другой системой. Независимо от канала система создаёт карточку заявки и сохраняет историю работы с ней.
В карточке можно видеть автора и заказчика, услугу и категорию, приоритет, ответственных, срок по SLA, статус и все связанные материалы. Это снижает риск потерять запрос в личной переписке и помогает заказчику самостоятельно проверить, что происходит с обращением.
Правила маршрутизации можно задать без разработки: по типу услуги, подразделению, региону, категории, приоритету, теме обращения или другим полям карточки. После регистрации заявки в карточке запускается SLA-таймер. Он учитывает заданные правила: рабочие часы службы, выходные, праздники, приоритет и условия приостановки срока. При приближении дедлайна система отправляет исполнителю и руководителю предупреждение — это позволяет вовремя принять меры.
Если срок приближается или уже нарушен, можно настроить эскалацию: уведомление руководителю, назначение дополнительного исполнителя, создание задачи на разбор причины или перевод обращения на следующий уровень поддержки.
Отчётность по SLA: дашборды вместо месячных выгрузок
Отчётность показывает, где сервис работает устойчиво, а где нужно менять процесс, ресурсы или правила обработки. Ручные выгрузки из разных источников требуют времени и часто дают картину с опозданием. Автоматические отчёты и дашборды позволяют видеть показатели в актуальном состоянии. Их можно подстроить под конкретную роль:
Руководитель службы увидит узкие места и просрочки: количество новых, активных и просроченных заявок, соблюдаются ли SLA и на каких шагах вопрос задерживается.
Руководитель компании видит итог и динамику — общий уровень соблюдения SLA, влияние изменений на результат компании, риски.
Внутренние заказчики услуги получат прозрачность по своим обращениям — какой сейчас статус и успеет ли команда.
В «Первой Форме» данные на дашбордах обновляются по мере движения задач, без ручного объединения таблиц.
Как крупные компании автоматизируют поддержку в «Первой Форме»
Банк Синара. Запросы в службу безопасности поступали из разных каналов, а контроль задач и отчётность велись вручную. В «Первой Форме» создали единое цифровое рабочее место для обращений, проверок, инцидентов, расследований, взыскания задолженности и аналитики. В итоге заявки стали обрабатываться до 90% быстрее, реакция на инциденты выросла на 55%, а отчёты формируются в один клик.
ДРТ. Обращения о нарушениях принимали через разные каналы, без удобного контроля расследований и обратной связи заявителям. На базе «Первой Формы» запустили защищённый портал горячей линии с анонимными обращениями, автоматической маршрутизацией, контролем сроков и уведомлениями. В результате обращения и расследования собрали в едином пространстве, а их обработка стала прозрачнее и удобнее для всех участников.
Как внедрить систему SLA: от пилота на одном сервисе до контура
Необязательно запускать SLA одновременно для всех услуг компании. Надёжнее начать с пилота, проверить правила на практике и затем масштабировать подход.
1. Соберите каталог услуг, кто их предоставляет, кто ими пользуется и что является результатом по каждой услуге. Начните с самых востребованных или критичных сервисов. Например, для ИТ-поддержки это могут быть инциденты, доступы и оборудование.
2. Проанализируйте текущую статистику: сколько заявок поступает, как долго они обрабатываются, какие категории встречаются чаще всего и где возникают задержки. Если данные пока не собраны, на первом этапе можно несколько недель фиксировать обращения в едином процессе. Это даст основу для реалистичных нормативов.
3. Установите каждой услуги определите метрики, приоритеты, сроки и владельца. Владелец отвечает не за выполнение каждой заявки лично, а за работоспособность сервиса: правила, ресурсы, качество и улучшения.
4. Запустите пилот. Выберите один сервис — например, обработку ИТ-заявок. Протестируйте, как работает процесс, и внесите изменения. В «Первой Форме» маршруты, поля карточек, статусы и таймеры можно настраивать в конструкторе без привлечения разработчиков для каждого изменения.
5. Разберите результаты и масштабируйте подход на другие службы: HR, финансы, юристов, АХО, безопасность, закупки и клиентскую поддержку.
Типовые ошибки при внедрении SLA
Установить сроки из ожиданий. Недостижимые пороги быстро превращают SLA в формальность.
Не назначить владельца услуги. Если за сервис никто не отвечает целиком, улучшения не происходят системно.
Сделать отчёт вместо контроля. Месячная статистика важна, но она не помогает спасти заявку за час до дедлайна. Нужны таймеры, уведомления и эскалации в моменте.
Автоматизировать неописанный процесс. Система ускорит маршрут, но не решит неопределённость: кто принимает заявку, кто согласует и что считается готовым результатом.
Не объяснить правила заказчикам. Пользователям должны быть понятны каталог услуг, приоритеты, срок и статус собственной заявки.
Заключение
SLA помогает превратить сервис из набора отдельных обращений в управляемый процесс. Компания заранее определяет, какие услуги предоставляет, в какие сроки и кто отвечает за результат. А команда получает возможность видеть риски до того, как они становятся просрочками.
В «Первой Форме» можно собрать клиентский и внутренний SLA-контур в одной платформе: настроить карточки заявок, формы, маршруты, таймеры, уведомления, эскалации и дашборды. Это помогает командам не ждать конца месяца, чтобы узнать о проблеме, а управлять уровнем сервиса каждый день.