Зачем разделять поддержку на уровни
Идея многоуровневой поддержки появилась в крупных IT-компаниях 1990-х, когда стало очевидно: платить высококвалифицированному инженеру за то, чтобы он сбрасывал пароли, экономически неразумно. Разделение поддержки на уровни решает три задачи:
- Оптимизация стоимости. Дешёвые операторы закрывают массовые типовые обращения, дорогие специалисты занимаются тем, что действительно требует экспертизы.
- Ускорение решения. 60–80% обращений — типовые, для них достаточно скрипта и базы знаний. Их решает L1 за минуты, не перегружая L2.
- Управление компетенциями. На L1 попадает человек без глубоких знаний — и постепенно растёт. L2 — средний уровень, L3 — эксперты. Понятная карьерная лестница.
Модель L1/L2/L3 — не догма. Для небольших команд (до 5 операторов) разделение может быть избыточным: все делают всё, а специализация — неформальная. Строгое разделение по линиям оправдано обычно начиная с 10+ операторов и 500+ заявок в месяц.
Первая линия поддержки (L1)
L1 — точка входа в поддержку. Её задачи:
- Принять обращение (телефон, почта, чат, веб-форма)
- Зарегистрировать в системе с корректным описанием
- Задать уточняющие вопросы пользователю
- Классифицировать по типу, услуге и приоритету
- Решить самостоятельно, если обращение типовое
- Эскалировать на L2, если требуется более глубокая экспертиза
- Отслеживать статус эскалированных заявок и информировать пользователя
Что L1 должна решать сама
Типовой набор задач первой линии:
- Сброс паролей и разблокировка учётных записей
- Базовые настройки почтового клиента и мобильных устройств
- Установка стандартного ПО по заявке
- Выдача стандартных доступов (по типовому согласованию)
- Помощь с интерфейсом корпоративных систем («как найти кнопку»)
- Регистрация заявок на поставку канцелярии и расходных материалов
- Первичная диагностика инцидентов по скрипту
Показатель хорошо работающей L1 — FCR (First Contact Resolution): доля обращений, закрытых без эскалации. Нормальные значения — 60–75% для внутренней поддержки, 70–85% для массовой B2C. Подробно про FCR и другие метрики — в статье о KPI поддержки.
Компетенции L1-оператора
- Уверенный пользователь Windows/Linux/macOS
- Базовые знания сети (IP, DNS, Wi-Fi)
- Работа с Active Directory (сброс пароля, разблокировка)
- Основы почтовых протоколов (SMTP, IMAP, Exchange)
- Коммуникативные навыки, терпение, умение писать понятно
L1 — это позиция для развития. Через 6–12 месяцев хороший оператор уже готов переходить в L2, администрирование или мониторинг. Планируйте замену заранее, чтобы не терять компетентных людей из-за отсутствия роста.
Вторая линия поддержки (L2)
L2 получает заявки, эскалированные с L1, или те, что сразу помечены как сложные. Задачи:
- Углублённая диагностика инцидентов (логи, дампы, трассировка)
- Работа с конфигурациями серверов, сетевого оборудования, СУБД
- Администрирование специализированных систем (ERP, CRM, 1С)
- Решение нестандартных сервисных запросов
- Написание статей в базу знаний для L1
- Обучение L1 по мере появления новых типов обращений
- Участие в разборе проблем (Problem Management)
Специализация внутри L2
В крупных компаниях L2 делится по компетенциям:
| Команда | Зона ответственности |
|---|---|
| Сетевые инженеры | Маршрутизаторы, коммутаторы, VPN, firewall, Wi-Fi-инфраструктура |
| Системные администраторы | Windows-серверы, Active Directory, Exchange, файловые системы |
| Linux-инженеры | Linux-серверы, веб-серверы, PostgreSQL, MySQL, контейнеризация |
| DBA | Производительность баз данных, бэкапы, репликация, оптимизация запросов |
| Прикладные инженеры | 1С, SAP, специфическое корпоративное ПО |
| Информбезопасность | Инциденты ИБ, аудит доступов, вирусы, фишинг |
В небольших компаниях L2 — это 2–5 «универсалов», каждый из которых покрывает несколько направлений.
Третья линия поддержки (L3)
L3 — высшая экспертиза, вовлекаемая только для нестандартных и редких проблем. В разных компаниях она устроена по-разному:
- Собственные разработчики — если у вас есть in-house разработка, L3 — это команда, написавшая систему. Они чинят баги, делают патчи, пишут обходные решения.
- Вендор — если вы используете коммерческое ПО, L3 — это техподдержка поставщика.
- Архитекторы и ведущие инженеры — для инфраструктурных задач, требующих переработки архитектуры.
- Внешние подрядчики (UC) — узкие специалисты, которых держать в штате нерентабельно (криптография, специфические интеграции).
Типичная доля заявок, доходящих до L3: 2–5% от общего объёма. Если выше — значит, L2 недоукомплектована или плохо обучена. Если ниже 1% — возможно, L2 сама тянет то, что должно было уйти выше, перегружая себя.
У L3 должен быть отдельный SLA с L2 — это OLA (Operational Level Agreement). Без этого L3 всегда будет «в фоновом режиме», и заявки застрянут. Без формализованных OLA трёхуровневая модель разваливается: всё превращается в «я им написал, жду когда ответят».
Правила эскалации
Эскалация — момент передачи заявки с одного уровня на другой. Бывает двух типов:
Функциональная эскалация
Передача по компетенции: «я не могу решить — передаю тому, кто может». Типовые критерии:
- L1 → L2: решение не найдено в базе знаний за 15–30 минут; требуется доступ к системе, которого нет у L1; проблема с несколькими пользователями одновременно.
- L2 → L3: задача требует изменения кода или архитектуры; подозрение на баг; необходимо участие вендора.
Иерархическая эскалация
Передача по уровню ответственности: «вопрос требует руководителя». Триггеры:
- Приближается просрочка SLA (обычно за 20% времени до дедлайна)
- Обращение от VIP-пользователя или критичный инцидент
- Конфликт между командами
- Требуется решение о выделении дополнительных ресурсов
В хорошей ITSM-системе обе эскалации автоматизированы: при приближении к SLA система сама оповещает руководителя, при смене приоритета — переназначает исполнителя. В TIQQET это настраивается на уровне каждой услуги.
Маршрутизация заявок: как направить в нужное русло
Чтобы модель работала, заявки должны попадать куда надо с первого раза. Правила маршрутизации обычно строятся по нескольким критериям:
- По услуге. «Заявки на услугу Электронная почта» → команда Exchange-администраторов.
- По типу. «Заявки-инциденты» → L1 (триаж), «сервисные запросы с типовыми шаблонами» → автоматически в очередь выполнения.
- По приоритету. «Критичные» → сразу в дежурную смену L2.
- По локации. В филиалах может быть своя L1, принимающая местные заявки.
- По пользователю. VIP-группа → отдельная очередь с сокращёнными SLA.
Правила маршрутизации описываются на этапе внедрения ITSM. Подробно — в статье о внедрении.
Что нужно от ITSM-системы для работы L1/L2/L3
Теоретическая модель поддерживает себя только в инструменте, где это удобно сделано. Пять функций, без которых трёхуровневая модель теряет смысл:
- Очереди команд с правами. L1 видит все свои заявки, L2 — заявки своей специализации, руководитель — всё. Пользователь видит только свои обращения.
- Правила назначения заявок. Автоматическая маршрутизация по услуге, типу, приоритету — без ручного перекидывания.
- Явная эскалация. Оператор L1 одним действием передаёт заявку на L2 с сохранением истории и причины. SLA-таймер продолжает работать.
- Внутренние комментарии. Операторы должны иметь возможность обсуждать заявку между собой, не показывая эти сообщения пользователю.
- Статистика FCR и Escalation Rate. Без этих двух показателей невозможно понять, работает ли модель.
Если ваша система не различает «передал заявку другому оператору на том же уровне» и «эскалировал на следующий уровень» — это большая проблема. Они должны регистрироваться отдельно, чтобы отчёт об эскалациях не превращался в кашу. В TIQQET эти действия разделены и отдельно фиксируются в истории заявки.
Альтернативы трёхуровневой модели
С распространением DevOps и продуктовых команд появились альтернативные модели:
Swarming-модель
Вместо последовательной передачи между уровнями — одновременная работа нескольких специалистов над сложной заявкой. Подходит для нестандартных инцидентов, где диагностика важнее скорости. Минус — дорого, все эксперты вовлечены одновременно.
«You build it, you run it»
Продуктовая команда, которая написала сервис, сама и поддерживает его в продакшне. Снимает классическое разделение на разработчиков и эксплуатацию. Подходит в компаниях с зрелой DevOps-культурой.
На практике обе альтернативы часто сосуществуют с L1/L2/L3, а не заменяют её. Для массовых типовых обращений всё равно нужна первая линия.
Типовые ошибки
- L1 используется как диспетчер. Операторы просто пересылают заявки в L2, ничего сами не решая. Результат — дорогая «почтовая машина».
- Нет формальных критериев эскалации. Каждый оператор решает по-своему — когда передавать выше. Нагрузка на L2 непредсказуема.
- L2 выполняет работу L1. Если L2-инженер регулярно сбрасывает пароли, значит, у L1 нет прав или компетенций — устраняйте причину.
- База знаний не обновляется. L2 решил нестандартную проблему, но не задокументировал решение. В следующий раз L1 снова эскалирует, а L2 снова решает вручную.
- Нет метрик FCR. Без измерения доли решённого на L1 нельзя понять, работает ли модель.
Вывод
Трёхуровневая модель поддержки — проверенный способ управлять нагрузкой и стоимостью. Но она работает только если три вещи настроены: чёткие критерии эскалации, постоянно обновляемая база знаний и измерение FCR. Без этого любая модель превращается в бумажку.
Для небольших компаний — не усложняйте преждевременно. Лучше начать с одной линии, измерять метрики и вводить L2 тогда, когда один специалист физически не успевает справиться с эскалированными задачами.
Попробуйте TIQQET в деле
On-premise ServiceDesk с полным циклом заявок, SLA-контролем и мобильными приложениями. Развёртывание за 1 день.
Посмотреть демоЧастые вопросы
В чём разница между L1 и L2?
L1 принимает все обращения и решает типовые по скрипту или из базы знаний. L2 — специализированные инженеры, которые подключаются к сложным техническим задачам: администрирование серверов, сетей, СУБД, работа с логами. L1 — 60–80% заявок, L2 — оставшиеся 15–35%.
Когда эскалировать заявку с L1 на L2?
Формальных универсальных правил нет, но типовые триггеры: решение не найдено в базе знаний за 15–30 минут; требуется доступ к системе, которого нет у L1; несколько пользователей одновременно сталкиваются с одной проблемой; в любой момент оператор не уверен в корректности своих действий.
Сколько процентов заявок должна закрывать L1?
60–75% для внутренней корпоративной поддержки, 70–85% для массовой B2C. Если меньше 50% — L1 используется как диспетчер без реального решения. Если больше 85% — возможно, L1 берётся за то, что должно было уйти выше, перегружая себя.
Обязательна ли третья линия (L3)?
Нет. В небольших компаниях достаточно L1 + L2. L3 оправдана, когда есть собственная разработка или нужна специализированная экспертиза (например, по криптографии, по конкретному вендорскому продукту). В среднем 2–5% заявок должны доходить до L3.
Можно ли объединить L2 и L3?
Можно, если у вас нет in-house разработки и внешнего вендора. В таком случае «продвинутая» часть L2 фактически выполняет роль L3 — решает редкие сложные задачи. Разделение остаётся концептуальным, а не организационным.
Что делать, если L1-операторы выгорают?
Две основные причины выгорания — рутина и отсутствие перспектив. Решается двумя способами. Первый: ротация задач, возможность брать сложные заявки под наставничеством L2. Второй: планирование карьеры — через 6–12 месяцев хороший L1 должен переходить в L2 или смежные роли (администрирование, мониторинг).