Что такое SLA в 1С и как его настроить

SLA (Service Level Agreement, соглашение об уровне сервиса) — это набор договорённостей о сроках и качестве выполнения работ: за какое время нужно отреагировать на заявку, за какое время решить её, кого уведомить при просрочке. В контексте 1С термин используется в двух ситуациях: как функциональность учётных решений (например, в 1С:ITIL, 1С:Документооборот, отраслевых конфигурациях сервис-деска) и как предмет договора между компанией и подрядчиком по сопровождению 1С.

На практике чаще всего с SLA сталкиваются руководители отделов продаж, сервисных служб и ИТ-директора. Менеджер должен перезвонить клиенту в течение 15 минут, сервисный инженер — выехать в течение 4 часов, сопровождающая фирма — исправить критичную ошибку в базе в течение рабочего дня. Все эти обязательства можно формализовать в 1С и автоматически контролировать их выполнение.

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

Где в 1С применяется SLA

Механизмы SLA встроены или добавляются доработкой в несколько типовых сценариев. В сервис-деске и Help Desk (на базе 1С:ITIL, 1C:IT-отрасль и аналогичных решений) SLA управляет заявками пользователей: регистрация, назначение исполнителя, реакция, решение. В CRM-подсистемах (1С:CRM, Управление торговлей с доработками) SLA контролирует скорость обработки лидов и обращений клиентов.

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

Отдельный случай — SLA как раздел договора с франчайзи-партнёром 1С, который сопровождает вашу базу. Здесь соглашение существует «на бумаге», а ваша учётная система служит инструментом проверки: по журналу обращений и датам обновлений можно оценить, соблюдает ли подрядчик обещанные сроки реакции.

Ключевые показатели, которые входят в соглашение

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

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

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

Как настроить контроль SLA в типовых конфигурациях

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

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

1. 1
   Определите перечень услуг или видов заявок и разбейте их по приоритетам
2. 2
   Задайте для каждого приоритета целевое время реакции и решения
3. 3
   Настройте рабочий календарь обслуживания, исключив выходные и нерабочие часы
4. 4
   Свяжите соглашения с клиентами, договорами или видами обращений
5. 5
   Включите автоматическое оповещение о приближении срока и о просрочке
6. 6
   Проверьте расчёт на тестовой заявке: создайте обращение и сверьте вычисленный дедлайн вручную

Если конфигурация дорабатывается, типичная схема — добавить к документу заявки поля «Срок реакции» и «Срок решения», вычислять их при записи через производственный календарь и регистрировать фактические даты взятия в работу и закрытия. Такую доработку стоит поручать разработчику с опытом именно вашей конфигурации: обход штатных механизмов продления и статусов ломает отчётность.

Как проверить, что SLA считается корректно

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

Вторая проверка — статус «ожидание». Если заявка переведена в ожидание ответа клиента, время решения в большинстве методик должно приостанавливаться. Убедитесь, что ваша конфигурация это учитывает, иначе исполнители будут накапливать просрочки по независящим от них причинам и перестанут доверять показателям.

Контрольные точки

Как проверить результат

Дедлайн заявки, созданной в нерабочее время

Норма

Отсчёт начинается с начала следующего рабочего интервала

Тревожный признак

Срок считается от фактического момента создания, включая ночь и выходные

Заявка в статусе ожидания клиента

Норма

Таймер решения приостановлен

Тревожный признак

Время решения продолжает тикать, растёт ложная просрочка

Отчёт по SLA за месяц

Норма

Процент соблюдения сходится с ручной выборкой 5–10 заявок

Тревожный признак

Цифры расходятся, в отчёт попадают отменённые или тестовые обращения

Типичные ошибки при внедрении SLA

Самая частая ошибка — завышенные требования на старте. Если сразу поставить реакцию 15 минут на все приоритеты, система будет показывать массовые просрочки, коллектив привыкнет игнорировать красные индикаторы, и весь механизм обесценится. Разумнее измерить текущие фактические сроки за месяц и установить целевые значения чуть лучше факта, постепенно ужесточая их.

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

SLA в договоре с сопровождающей организацией

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

Контролируйте выполнение по объективным данным: журналу обращений на портале партнёра, датам писем, истории обновлений базы. Если партнёр отчитывается только устно, попросите ежемесячный отчёт с перечнем заявок и временем их закрытия — это стандартная практика, а не признак недоверия.

Какие отчёты использовать для контроля

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

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

Маршрут решения

Как выбрать действие

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

Нужно контролировать скорость обработки клиентских обращений в CRMНастройте сроки по бизнес-процессам и уведомления о просрочке

Требуется проверить работу внешнего сопровождающего партнёраЗафиксируйте SLA в договоре и запрашивайте ежемесячный отчёт по заявкам

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

Частые вопросы

Чем SLA отличается от KPI сотрудника?

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

Можно ли настроить SLA в Управлении торговлей без доработок?

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

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

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

Что делать, если заявка просрочена по вине клиента?

Используйте статус ожидания: при запросе информации у клиента заявка переводится в этот статус, и таймер решения приостанавливается. Если такой возможности нет, фиксируйте причину просрочки в карточке заявки, чтобы при разборе отчёта отделять объективные задержки от вины исполнителя.

Нужно ли включать штрафы в SLA с подрядчиком?

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