Вернуться к статьям В документе важно разделить приоритет обращения, срок подтверждения, порядок обновления статуса и фактический срок восстановления. Тогда владелец сайта понимает, что произойдёт после регистрации инцидента, а техническая команда не принимает новую функцию за аварийную заявку.
Почему общая фраза о поддержке не работает
Формулировка «быстро исправим» не помогает в момент сбоя. В ней нет списка каналов, часов работы, ответственного за решение и признака, по которому обращение считают принятым. Владелец сайта не понимает, когда ждать первый ответ, а исполнитель вынужден каждый раз заново согласовывать срочность.
Из каких частей состоит SLA
Документ начинается с перечня обслуживаемых систем: сайт, административная часть, хостинг в пределах доступов, формы, почтовые уведомления и конкретные интеграции. Для каждого компонента указывают владельца, канал обращения и исключения. Отдельно фиксируют, что не входит в договор: разработка новой функции, исправление стороннего сервиса без доступа, подготовка контента и работы, которые требуют согласования бюджета.
Приоритет нельзя назначать по громкости сообщения
Приоритет описывают по наблюдаемому эффекту. Критичным может быть недоступность сайта или невозможность отправить основную форму; средним — ошибка отдельного раздела с обходным путём; низким — косметическая правка. Такой порядок уменьшает конфликт, когда любое обращение называют срочным.
Разделите реакцию и восстановление
Срок первой реакции означает, что исполнитель принял обращение, проверил исходные данные и сообщил следующий шаг. Он не равен сроку устранения. Для восстановления нужны доступы, логи, резервная копия, ответ от внешнего поставщика или согласование изменения. В SLA полезно отдельно указывать время обновления статуса и основания для приостановки срока.
Как принимать обращения
Обращение должно содержать URL, время ошибки, действие пользователя, ожидаемый и фактический результат, скриншот и контакт для уточнений. Сообщение «ничего не работает» приходится превращать в задачу вручную. Единый канал, например система заявок или выделенная почта, сохраняет историю и не теряет договорённости в личной переписке.
Что проверить перед подписанием
Проверьте, совпадают ли часы поддержки с графиком бизнеса, есть ли порядок аварийного контакта и кто подтверждает завершение задачи. Уточните, как учитывают ожидание доступа, согласования или ответа хостинга. Если на сайте есть личный кабинет, платежи или CRM, эти сценарии должны быть перечислены отдельно.
Часто задаваемые вопросы
Можно ли установить один срок для всех задач?
Можно, но он не покажет, что делать при недоступности сайта и при правке текста. Практичнее разделить обращения хотя бы по влиянию на ключевой сценарий и наличию обходного пути.
Что считать началом срока реакции?
Обычно срок считают после регистрации обращения в согласованном канале с минимально необходимыми данными. Это правило нужно записать явно.
Входит ли развитие сайта в SLA?
Обычно нет: новая функциональность требует отдельной оценки, постановки и приемки. В SLA можно описать только порядок передачи такой задачи.
Нужна ли круглосуточная поддержка?
Только если простой вне рабочего времени создаёт измеримый риск. Для остальных случаев достаточно аварийного контакта и согласованного окна работ.
Кто закрывает инцидент?
Исполнитель сообщает результат, а владелец или назначенный представитель подтверждает проверку ключевого сценария. Это лучше закрепить в регламенте.
Как проверить SLA на рабочей заявке
До подписания SLA полезно взять один недавний инцидент и пройти его по документу. Получится проверить, хватило ли в заявке данных для старта, кто должен был сообщить статус, где остановился отсчёт и по какому условию работу можно было закрыть. Если для этого приходится устно добавлять правила, их стоит перенести в SLA.
В отчёте по заявке фиксируют время регистрации, выбранный приоритет, время первого ответа, изменения статуса, зависимость от внешней стороны и результат проверки. Такой отчёт не доказывает, что любая будущая проблема решится за тот же срок. Он показывает, что договорённый процесс можно воспроизвести.
Итог
SLA поддержки сайта начинается с перечня систем и понятной шкалы влияния, а не с обещания «быстрой реакции». Первую версию можно составить по реальным обращениям за несколько месяцев: выделить повторяющиеся типы инцидентов, определить владельцев и согласовать, какие данные нужны для принятия заявки. Пересматривать документ следует после изменения состава сайта, графика команды или подключённых сервисов.