Что такое эскалация обращения и когда её запускать

Кратко

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

Два вида эскалации, которые путают

Вертикальная (иерархическая). Обращение уходит на следующую линию поддержки или к руководителю. Причина — не хватает квалификации, прав доступа или полномочий на решение. Именно этот вид имеют в виду, когда говорят «эскалировали на вторую линию».

Горизонтальная (функциональная). Обращение уходит не выше, а в сторону: в разработку, к бухгалтерии, к поставщику услуги. Причина — вопрос вообще не в компетенции поддержки. Здесь нет «повышения уровня», есть смена ответственного подразделения.

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

Когда эскалация запускается

Есть два принципиально разных повода, и хорошая служба использует оба.

По событию. Оператор понял, что не решит: нет прав, нет знаний, вопрос вне его зоны. Это ручная эскалация, и она должна быть дешёвой — одна кнопка, без объяснительной. Дорогая эскалация не запускается: оператор предпочтёт помучиться сам, и обращение просрочится молча.

По времени. Прошла заданная доля срока, движения нет — система сама поднимает обращение. Это автоматическая эскалация, и она ловит именно то, что ручная пропускает: случаи, когда никто не понял, что застряли.

Разумная лестница по времени для обращения обычного приоритета со сроком решения 8 рабочих часов:

Ключевая строка здесь — третья: эскалация происходит до нарушения, пока ещё можно успеть. Процесс, в котором эскалация наступает после просрочки, называется не эскалацией, а разбором полётов.

Что обязано переехать вместе с обращением

Эскалация без контекста — это переложенная работа, а не переданная. Принимающий начинает с нуля, клиент пересказывает всё второй раз, и суммарное время растёт вместо того чтобы падать.

Минимум, который передаётся вместе с обращением:

• Что уже проверено и не помогло — списком, а не прозой. Это экономит принимающему первый час.
• Почему передаём — одна строка: нет прав / нет знаний / не наша зона / истекает срок.
• Сколько времени осталось — остаток до срока, а не срок целиком. У принимающего не восемь часов, у него два.
• Что обещано клиенту — дословно. Второе обещание, противоречащее первому, злит сильнее самой проблемы.

Техническая сторона в системе — во внутренних заметках, которые видит команда и не видит клиент: Внутренние заметки.

Признаки сломанной эскалации

Эскалация как наказание. Если передача наверх воспринимается как признание некомпетентности, её будут избегать. Симптом: доля эскалированных обращений близка к нулю при растущей доле просрочек. Разумная доля эскалаций — единицы процентов; ноль означает не силу первой линии, а страх.

Эскалация как свалка. Обратная крайность: первая линия пересылает всё, что требует больше двух минут. Симптом: вторая линия занята вопросами, ответ на которые есть в базе знаний. Лечится не запретом, а базой знаний и правилом «эскалация только после проверки по списку».

Эскалация без обратного хода. Обращение ушло на вторую линию и пропало: первая линия не знает, что с ним, клиент пишет первой линии, та не может ответить. Лечится тем, что ответственность за срок остаётся на исходном владельце, даже когда работу делает другой.

Эскалация вникуда. Передали «в разработку» — то есть никому конкретно. Обращение лежит в общем пуле, у него нет имени и нет срока. Правило: эскалация всегда на роль или человека с именем, никогда — на отдел целиком.

Частая ошибка: эскалация вместо приоритета

Самый частый сбой выглядит так. Клиент недоволен и пишет руководителю. Руководитель приходит к оператору с фразой «займись срочно». Обращение получает внимание, но не меняет приоритет в системе, и все счётчики продолжают считать его обычным.

Последствие: по отчётам служба выглядит ровно, а по факту порядок работы диктуют те, кто громче пишет. Через квартал этому учатся все клиенты, и очередь начинает управляться жалобами.

Лечение простое и неприятное: любое вмешательство руководителя обязано менять приоритет в системе, а не только в чате. Если обращение достойно внеочередного внимания — значит, признак приоритета был определён неверно, и стоит поправить сам признак, а не обходить его. Как устроены признаки — в статье Приоритет заявки: как его определяют через влияние и срочность.

Как проверить за вечер

• Посчитайте долю эскалированных обращений за месяц. Ноль — эскалации боятся. Больше 20 % — первая линия не работает, а сортирует.
• Найдите эскалации, случившиеся после истечения срока. Каждая такая — доказательство, что автоматической лестницы нет.
• Возьмите пять эскалированных обращений и посмотрите, что было передано вместе с ними. Если принимающий задавал клиенту вопросы, на которые тот уже отвечал, — контекст не переезжает.
• Проверьте, на кого эскалируют: на имя или на отдел. Эскалации на отдел найдите и измерьте их время решения отдельно — оно почти всегда худшее в службе.

Связанные статьи

• Первая и вторая линия поддержки: чем они отличаются
• Что считается нарушением SLA и что делать с просрочкой
• Настройка SLA, приоритетов и крайнего срока