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