SLA поддержки сайта: что требовать и как проверять

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

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

Что такое SLA

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

SLA не гарантирует, что проблема будет решена за 15 минут. Он гарантирует, что подрядчик начнёт разбираться и будет держать вас в курсе.

Что фиксировать

• Категории задач: авария, ошибка, доработка, консультация.
• Время реакции для каждой категории.
• Время решения или ориентир.
• Часы работы и дежурство.
• Каналы связи.
• Порядок эскалации.
• Отчётность.
• Компенсации при нарушении.

Время реакции и решения

Реакция и решение — разные вещи. Подрядчик может ответить через 10 минут, но исправление займёт часы. Это нормально, если ожидания зафиксированы.

• Авария: реакция 15–30 минут.
• Критичная ошибка: реакция до часа.
• Обычная задача: в течение рабочего дня.
• Доработка: по бэклогу.

Категории задач

Часы работы

Для интернет-магазина «с 10 до 18 по будням» может быть недостаточно. Решите, нужен ли ночной и выходной дежурный.

• Рабочие часы.
• Ночное дежурство.
• Выходные.
• Праздники.

Эскалация

Как проверять SLA

Штрафы и компенсации

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

Типичные ошибки

• SLA только на бумаге.
• Нет категорий задач.
• Не указаны часы работы.
• Нет эскалации.
• Не ведётся отчётность.
• Компенсации не описаны.

SLA для разных типов сайтов

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

• Магазин: checkout, оплата, остатки, интеграция с 1С.
• Корпоративный сайт: доступность, формы, публикация.
• Портал: авторизация, реестры, документы, роли.
• Лендинг: формы и скорость.
• Маркетплейс: заказы, кабинеты продавцов, выплаты.
• Интеграции: обмен заказами и статусами.

Как составить SLA

Начните не с цифр, а со сценариев. Выпишите, что должно работать в первую очередь и сколько стоит час простоя.

Пример таблицы SLA

Таблица должна помещаться на одну страницу. Если её невозможно объяснить сотруднику за пять минут, она не будет работать.

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

Что не входит в SLA

SLA не покрывает развитие продукта, если это не отдельный пакет. Иначе аварии и новые функции начинают конкурировать за одни и те же часы.

• Новые функции и разделы.
• Маркетинговые задачи.
• Контент и тексты.
• Обучение сотрудников.
• Работа с чужими подрядчиками.
• Восстановление после действий заказчика.

SLA и поддержка на Bitrix или Laravel

Платформа влияет на состав работ. На Bitrix больше обновлений модулей и рисков конфликтов. На Laravel — зависимостей и требований к дисциплине релизов.

• Обновления ядра и модулей.
• Проверка совместимости.
• Мониторинг очередей.
• Резервные копии.
• Логи и ошибки.
• Регламент отката.

Как перейти на SLA

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

• Соберите историю заявок за 1–3 месяца.
• Определите реальные сроки реакции.
• Согласуйте критичные сценарии.
• Запустите пилот на 30 дней.
• Сверьте результаты.
• Подпишите финальную версию.

Как связать SLA с мониторингом

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

• Доступность сайта.
• Время ответа каталога.
• Работа checkout.
• Очередь заказов.
• Ошибки оплаты.
• Обмен с 1С.

SLA и внутренняя команда

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

• Владелец процесса поддержки.
• Человек, который принимает заявки.
• Тот, кто проверяет восстановление.
• Контакт для эскалации.
• Ответственный за коммуникацию с клиентами.
• Тот, кто следит за отчётами.

Как фиксировать инциденты

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

• Дата и время обращения.
• Кто сообщил проблему.
• Симптом и критичность.
• Время реакции.
• Время решения.
• Что сделали.
• Причина и профилактика.

SLA в договоре

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

• Категории задач.
• Сроки в часах и рабочих днях.
• Часы работы и дежурство.
• Каналы приёма заявок.
• Порядок эскалации.
• Отчётность.
• Компенсации.

Что обсудить до подписания

Финальная встреча нужна не для формальности. На ней стороны проверяют, одинаково ли понимают критичность, сроки и порядок действий.

• Кто принимает заявки и в каком канале.
• Что считается аварией.
• Какие сценарии проверяются в первую очередь.
• Как действовать, если нет доступа.
• Кто сообщает клиентам о проблеме.
• Как фиксируется результат.

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

SLA и сезонность

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

• Увеличить дежурство.
• Заранее проверить сценарии.
• Зафиксировать приоритеты.
• Подготовить план отката.
• Согласовать дополнительные часы.

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