← Шаблоны

Регламент техподдержки: что должно быть внутри (образец)

Регламент техподдержки нужен не «для бумаги», а чтобы заявки обрабатывались одинаково независимо от того, кто на смене. Без него каждый оператор работает по-своему, SLA плывёт, а спорные ситуации решаются на эмоциях. Ниже — рабочий каркас регламента: какие разделы обязательны, что в них писать и где чаще всего ошибаются.

11 мин чтения Команда TIQQET
ШаблоныРегламентыПроцессыService Desk
Регламент техподдержки: что должно быть внутри (образец)

Зачем нужен регламент

Регламент техподдержки фиксирует единые правила обработки обращений: как заявка попадает в систему, как классифицируется, в какие сроки и кем решается, когда эскалируется. Это документ для людей (операторов, заявителей, руководителей), а его «исполняемая» часть — настройки в Service Desk: каталог услуг, SLA, маршруты. Хороший регламент и настройки системы описывают одно и то же — иначе документ живёт отдельно от реальности.

Обязательные разделы

Минимальный рабочий состав регламента:

  1. Назначение и область действия — что регулирует, на кого распространяется.
  2. Каналы приёма обращений — портал, почта, телефон, мессенджер.
  3. Классификация и приоритеты — типы обращений, как определяется приоритет.
  4. Маршрутизация — кто и как распределяет заявки по линиям/командам.
  5. SLA — сроки реакции и решения по приоритетам, рабочий календарь, паузы.
  6. Эскалация — когда и кому передаётся при риске нарушения.
  7. Статусы заявки — жизненный цикл от регистрации до закрытия.
  8. Роли и ответственность — кто за что отвечает.
  9. Отчётность — какие метрики и с какой периодичностью.

Каналы, классификация, приоритеты

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

Приоритет определяется по матрице «влияние × срочность», а не на глаз. Пример матрицы:

Влияние \ СрочностьВысокаяСредняяНизкая
Массовое (все пользователи)КритическийВысокийСредний
Групповое (отдел)ВысокийСреднийСредний
Единичное (один человек)СреднийСреднийНизкий

Маршрутизация, SLA, эскалация

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

Два типа эскалации Функциональная1 линия → 2 линия → экспертне хватает компетенции Иерархическаяоператор → тимлид → руководительриск нарушения SLA
Функциональная эскалация — по компетенции, иерархическая — по полномочиям и срокам. Подробнее в статье об escalation management.

Статусы заявки и роли

Опишите жизненный цикл заявки явным списком статусов: Новая → В работе → Ожидает ответа → Решена → Закрыта (+ Отклонена, Отложена). Каждый переход — с условием и ответственным. Роли минимум: заявитель, оператор 1-й линии, специалист 2-й линии, тимлид (эскалация/распределение), руководитель поддержки (отчётность). Разграничение прав закрепляется в системе через ролевую модель (RBAC).

Частые ошибки

В TIQQET «исполняемая» часть регламента настраивается напрямую: каталог услуг, SLA по дереву услуг с календарём и паузами, маршруты согласования, статусы и роли — документ и система остаются синхронными.

Попробуйте TIQQET в деле

On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.

Посмотреть демо

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

Чем регламент отличается от SLA?

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

Насколько подробным должен быть регламент?

Достаточно коротким, чтобы его реально читали (обычно 5–10 страниц). Длинные регламенты на десятки страниц не работают — их не открывают. Главное, чтобы он совпадал с настройками системы и покрывал ключевые разделы.

Как связать регламент с настройками Service Desk?

Каталог услуг, приоритеты, SLA, маршруты и статусы из регламента должны быть один-в-один настроены в системе. Если документ обещает то, чего нет в системе (или наоборот), возникают споры и регламент перестаёт исполняться.

Нужна ли матрица приоритетов?

Да. Без матрицы «влияние × срочность» приоритет ставится субъективно, и одинаковые по сути обращения получают разные приоритеты у разных операторов. Матрица делает приоритезацию воспроизводимой.