30% тикетов возвращаются с L2 на L1. Клиенты в ярости. SLA горит. А в чатах техподдержки чёрт ногу сломит.
Знакомая картина? Первая линия передаёт запросы «наверх», вторая возвращает их назад с комментарием «добавьте подробностей», клиент ждёт неделю, а проблема остаётся нерешённой. Клиент злится, SLA горит. В итоге инциденты ходят между уровнями по кругу — просто потому, что изначальная передача была неполной или не по делу.
Эта статья — про то, как выстроить систему эскалации на второй и третий уровень поддержки так, чтобы сложные запросы решались быстрее, первая линия не выгорала, а клиенты не чувствовали себя отфутболенными.
Кто за что отвечает: роли в процессе эскалации
Чтобы передача тикетов не превращалась в хаос, важно не только написать регламент, но и разделить ответственность по RACI‑логике (кто делает, кто отвечает, кто консультирует, кто в курсе). Для простоты остановимся на четырёх ключевых ролях.
Оператор первой линии (L1) — главный ответственный (R — Responsible) за сбор информации, первичную диагностику и корректное оформление запроса на эскалацию. Его задача — либо решить инцидент по готовым сценариям, либо так «упаковать» обращение, чтобы L2/L3 могли сразу начать работу, не задавая уточняющих вопросов. Если тикет ушёл наверх «пустым», это ошибка L1, а не L2.
Специалист второй линии (L2) — ответственный (R) за приём эскалаций, технический анализ и решение в своей зоне компетенции. Он не должен «молчать в ответ»: L2 информирует L1 о статусе, пересекает эскалации, даёт обратную связь по качеству входящих запросов («не хватает шагов воспроизведения», «нет логов»).
Тимлид / третья линия (L3) — часто совмещает роль тимлида и эксперта, который занимается багами, архитектурными проблемами, нестандартными ситуациями. В RACI‑логике он ответственен за результат (A — Accountable) за соблюдение SLA по сложным случаям и качество финального решения: именно он принимает решение, когда нужно привлекать разработчиков, менять приоритеты, договариваться с продуктом.
Руководитель поддержки — ответственный за процесс в целом, но не за каждый конкретный тикет. Он должен быть инфор��ируемым (Informed) о системных сбоях, массовых инцидентах, росте очередей, нарушении SLA и повторяющихся проблемах, которые говорят о дырках в процессах или продукте.
За рамками осталась буква C — Consulted, консультируемый. Это место для эксперта, чьё мнение должно быть получено ДО начала выполнения работ. Пока «Мистер Си» пусть побудет в тени.
Если роли не прописаны, эскалация всегда выглядит как «я кинул в чат ребятам из техподдержки, а дальше — как получится».
Диагностика как начало улучшений: как эскалации происходят сейчас
Прежде чем строить новую систему, стоит честно посмотреть, что происходит у вас сейчас. Обычно картина повторяется из компании в компанию.
Каналы эскалаций:
Основной канал, как правило — переназначения тикетов в сервис‑деске, но без единого стандарта, причём носят они чисто формальный характер. И, коли так, начинается:
Личные сообщения в мессенджерах.
Случайные сообщения в общих чатах: «ребята, помогите, у клиента не работает».
Письма на общую почту «техподдержка@».
Дёргания L3 и руководителя поддержки по каждому эскалированному тикету.
Типичные боли L1
Мы не понимаем, что писать в эскалации, каждый L2 хочет по‑своему.
Нам не отвечают или отвечают через несколько часов, клиент злится и ругается матом, а мы мычим «Ждите ответа».
Нас ругают за срывы SLA, хотя мы вовремя передали наверх.
Типичные боли L2/L3
К нам прилетают пустые запросы типа «не работает» — что не работает, что делали, что пробовали для исправления — ничего этого нет.
В тикете нет логина, ID операции, скриншотов, даже времени ошибки.
Диагностика на L1 не проводится, нас используют как справочную службу.
Первая линия нас постоянно дёргает, хотя сама же не оформила тикет нормально — в нём нет практически никаких исходных данных.
Что чувствует клиент
Меня футболят от одного специалиста к другому.
Каждому новому сотруднику приходится рассказывать одно и то же миллион раз.
Никто не может сказать, что происходит и сколько ещё мне ждать.
На уровне метрик это проявляется как: рост времени решения по эскалированным тикетам, высокий процент «неправильных эскалаций» — возвратов на L1, — повторные обращения по тем же вопросам и увеличение количества негативных отзывов, и, как следствие, снижение NPS.
Стратегия: что должна решать эскалация
Важно зафиксировать несколько принципов, чтобы эскалация не воспринималась как «сброс ответственности».
1. Эскалация — часть решения, а не отказ от него. L1 не «отстреливается» фразой «передаю на второй уровень», а остаётся владельцем кейса в глазах клиента: он обновляет статус, даёт промежуточные ответы, объясняет, на каком этапе сейчас работа.
2. Принцип «одного касания» на L2/L3. Переданный запрос должен содержать максимум информации, но, главное, там должен быть необходимый минимум, достаточный для старта работы без возврата на L1. Каждый возврат — это лишний круг ожидания для клиента и потеря времени двух линий.
3. Чёткое разделение задач по линиям:
L1 — типовые вопросы из базы знаний, базовая диагностика по скриптам, фиксация ответов на каждом шаге. Главная задача — качественно подготовить тикет для эскалации, если решить нельзя.
L2 — нестандартные кейсы, работа в нетиповых конфигурациях и кастомных проектах, глубокая техническая диагностика в рамках продукта.
L3 — баги, архитектурные проблемы, необходимость доработки продукта, сложнейшие кейсы.
4. Эскалация работает не всегда «вверх». Есть функциональная эскалация «в сторону» — например, из общей поддержки в команду безопасности или платёжную команду. Важно заранее определить, какие типы кейсов куда уходят. Но эта опция для второй и третьей линии, точно не для первой.
Когда эскалировать: понятные критерии для L1
Чтобы снять лишнее напряжение между линиями, нужны не только ощущения — я такого не знаю, это сложно, передам наверх, — а набор чётких критериев, описанных в регламенте и базе знаний.
Кейс эскалируется, если выполняется хотя бы одно условие:
По сложности: для решения нужны доступы к логам, БД, конфигурационным файлам, админ‑панелям, к которым L1 не имеет доступа.
По полномочиям: требуется действие вне компетенций L1 — возврат денег, пересчёт тарифа, изменение статуса, блокировка пользователя.
По SLA: запрос находится в зоне риска нарушения срока решения — например, 75% от целевого времени истекло, а прогресса нет.
По клиенту: VIP‑клиент, публичный кейс, значительный чек, высокая температура по NPS/CSAT.
По шаблону: запрос попадает в один из типовых сценариев для L2/L3 — ошибка 500, проблемы интеграций, системный баг, массовый инцидент.
Такие критерии удобно оформить в виде статьи в базе знаний, чтобы агент мог быстро свериться: «если A, B, C — эскалируем, если нет — продолжаем решать на уровне первой линии».
Как эскалировать: «упаковка» кейса для L2/L3
Алгоритм для L1 должен быть максимально конкретным и встроенным в инструменты — шаблоны в тикет‑системе, нюансы их заполнения — в базе знаний. Ок, пусть тикет-система — это только название, про реализацию речь пока не идёт. Общий чат поддержки — это тоже тикет-система, если больше ничего нет.
Вот алгоритм эскалации.
1. Исчерпать чек‑лист L1
Перед тем как нажать «эскалировать», агент обязан пройти базовый сценарий диагностики:
Проверить статус сервисов (нет ли массового инцидента).
Перепроверить данные клиента.
Свериться с базой знаний: нет ли готового решения.
Выполнить простые действия (перезапуск, смена браузера, проверка соединения и т.п.).
Чек‑лист должен быть явным, а не жить в головах операторов. Например, он может быть вшит в тикет-систему.
2. Сформировать краткое описание
Subject тикета — не «не работает», а короткое, но информативное описание:
Клиент X не может оплатить заказ Y: ошибка «Оплата отклонена» в 15:30 по МСК.
Это помогает L2 сразу понять контекст, а не открывать тикет «на удачу».
3. Описать шаги воспроизведения
Пошагово:
Клиент заходит в приложение, авторизуется.
Переходит в раздел «Мои заказы», выбирает заказ Y.
Нажимает «Оплатить», выбирает карту ****1234.
После подтверждения СМС видит ошибку «Оплата отклонена».
Если клиент не помнит точную последовательность, агент фиксирует максимум того, что удалось выяснить, и честно пишет, чего не хватает.
4. Добавить собранную информацию
Минимальный набор:
Логин/ID клиента.
ID заказа/операции.
Версия приложения, ОС, браузера.
Время возникновения ошибки.
Скриншоты, сообщения об ошибках.
Ссылки на связанные тикеты, если проблема повторяется.
Чем сложнее система, тем важнее стандартизировать этот блок: сделать обязательные поля в форме эскалации. Не заполнил — не смог эскалировать.
5. Указать предпринятые действия / чек-лист перед эскалацией
L2 должен видеть, что уже пробовал L1:
Проверить статус сервиса — ошибок нет.
Клиент пробовал оплатить с другой карты — результат тот же.
Кэш/куки очищены, режим инкогнито пробовали.
Это избавляет и клиента и специалистов от повторения одних и тех же шагов, снижает градус раздражения клиента.
6. Опционально: добавить гипотезу
Не обязательно, но полезно:
Похоже на тикет #12345: тогда проблема была в лимитах платёжного шлюза.
Гипотеза помогает L2 быстрее искать решение, особенно если первая линия видит повторяющиеся паттерны. Но может и увести от правильного ответа. Но на то и экспертность второй линии, чтобы отделить мух от котлет.
7. Проставить приоритет и дедлайн
На основе SLA, типа клиента и, возможно, градуса его раздражения:
Приоритет (низкий/средний/высокий/критический).
Целевое время решения или хотя бы ожидания по обновлению статуса.
Даже при работе в b2b или b2g сегменте общение с человеком может как вырастить репутацию компании, так и уронить её настолько, что клиент уйдёт — а это плохо не только чисто финансово, но и политически.
8. Выбрать правильного получателя
Эскалировать «куда‑то в техподдержку» — путь к хаосу. Лучше настроить очереди по доменам: «Платежи», «Мобильное приложение», «Интеграции», «База данных». Тогда тикет сразу попадёт к нужной команде — разумеется, если эти команды есть физически.
Инструменты и правила игры
Даже идеальный алгоритм не взлетит, если эскалации продолжают жить в личных чатах и «серой зоне» неофициальных каналов коммуникации.
Единый канал эскалаций. Решите, где вы живёте: сервис‑деск, таск‑менеджер, внутренняя платформа. Важно, чтобы все эскалации шли только здесь, а чаты использовались лишь как вспомогательный канал для уточнений.
Шаблоны и скрипты. Создайте шаблон тикета L1→L2, где все важные блоки уже есть: описание, шаги, данные, предпринятые действия, приоритет. То же — для внутренних сценариев общения с клиентом: как корректно объяснить, что запрос передан на следующий уровень, не создавая ожидания «сейчас всё решат за 5 минут».
Внутренние SLA (OLA). Помимо SLA для клиентов, стоит договориться о внутренних SLA между L1, L2 и L3: время реакции на эскалацию, условия, когда L2 обязан взять тикет в работу, правила приоритизации. Иначе любая претензия L1 типа «нам долго отвечали» будет опираться только на субъективные ощущения.
Как учить L1 и контролировать качество
Эскалация — навык, который можно тренировать.
Обучение L1
Регулярные воркшопы по диагностике: разбор типичных кейсов, «игра в детектива».
Разбор полётов: хорошие эскалации как примеры, плохие — как материал для улучшения.
Чек‑лист для самопроверки: «Все ли обязательные поля заполнены? Есть ли скриншот? Понятен ли шаг воспроизведения?».
Контроль качества (QA)
Добавить в критерии оценки работы L1 пункт «качество эскалаций».
Попросить L2 и L3 давать регулярную обратную связь по входящим тикетам: раз в неделю разбирать несколько кейсов.
Периодически просматривать выборку эскалированных запросов руководителям L1 и L2.
На что смотреть в метриках
Хороший процесс эскалации виден в числах.
Полезные показатели:
Количество возвратов с L2 на L1 из‑за нехватки информации — ключевой индикатор качества работы L1.
Процент эскалаций: сколько запросов уходит на L2/L3 от общего числа. Определяется эмпирически. Если показатель слишком мал — первая линия задыхается от сложных кейсов; слишком велик — первая линия не использует базу знаний и скрипты.
Время до первого ответа второй линии (FRT): как быстро запрос берётся в работу.
Время решения эскалированных запросов: меняется ли оно после внедрения регламента.
Оценка L2/L3 качества входящих эскалаций — можно делать опросом внутри команды. Например, собрать статистику в TEAMLY, где одно из представлений в умных таблицах — форма.
Как внедрить процесс и не сломать команду
План внедрения лучше делать по шагам:
Подготовить проект регламента на основе текущих проблем и описанного выше каркаса.
Обсудить его с тимлидами L1, L2 и L3 — собрать замечания, учесть реальность.
Создать инструменты: шаблоны тикетов, чек‑листы, статьи в базе знаний.
Запустить пилот на одной связке «команда L1 → команда L2» в одном домене (например, только платежи).
Обучить этих сотрудников, дать им понятные цели и метрики.
Запустить пилот, 2–4 недели следить за метриками и собирать обратную связь.
Доработать регламент и масштабировать на остальные направления.
Итог: чек‑лист здоровой эскалации
В конце у вас должен появиться простой чек‑лист:
Регламент эскалации описан и доступен в базе знаний.
Критерии «когда эскалировать» и «на кого эскалировать» понятны всем операторам первой линии.
Есть шаблоны тикетов/форм для передачи на L2/L3.
Внутренние SLA между уровнями согласованы.
Проведено обучение для L1, L2, L3.
Настроены отчёты по ключевым метрикам.
Назначены ответственные за мониторинг и развитие процесса.
Если всё это есть, эскалация перестаёт быть «перекидыванием мячика» и превращается в управляемый бизнес‑процесс. Клиент не чувствует разницы между уровнями поддержки, первая линия не выгорает от бессмысленных конфликтов, а технические специалисты тратят время на решение проблем, а не на поиск базовой информации по тикету.
