Как честно измерять долю эскалаций в клиентском сервисе

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

Измеряйте долю эскалаций в клиентском сервисе как процент уникальных подходящих случаев, которым потребовался определенный более высокий уровень полномочий, экспертизы или ответственности за риск. Считайте каждый случай один раз, отделяйте переводы и консультации от эскалаций и сопоставляйте показатель с качеством решения. Меньшее значение не всегда лучше. Необходимая эскалация защищает клиента, а предотвратимая показывает устранимый пробел.

В актуальной сводной панели Customer Service Microsoft определяет этот показатель как процент эскалированных случаев. Формулировка проста. Сложность начинается с единого определения эскалации внутри вашей операции.

Определите что считать эскалацией

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

Не называйте эскалацией каждую передачу. Языковая маршрутизация, смена дежурства, консультация или правильное первичное направление могут перемещать работу без повышения уровня решения. В документации Microsoft о метриках сегментов каждый вход в очередь, перевод или выход создает отдельный сегмент. Поэтому переводы между очередями считаются отдельно от доли эскалаций на уровне случая.

Если один случай прошел через три очереди, отчет по сегментам покажет три записи, но в числителе эскалаций это должен остаться один клиентский вопрос. Сохраняйте исходный идентификатор проблемы между каналами и переназначениями.

Зафиксируйте группу и считайте случай один раз

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

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

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

Представим 400 подходящих случаев, из которых 52 дошли до определенного более высокого уровня. Доля равна 13 процентам. Повторные эскалации покажите отдельно. Они выявляют блуждание между командами или отсутствие владельца решения.

Разделите необходимые и предотвратимые эскалации

Общий показатель становится полезным после классификации причин. Просмотрите реальные диалоги и события. Определите, чего не хватало первому сотруднику и был ли этот предел оправдан.

Не превращайте необходимую эскалацию в ошибку сотрудника. Если у первой линии нет права одобрить возврат, давление ради низкого показателя ведет к задержке или неправомерному решению. Нулевая цель также может скрывать слишком раннее закрытие.

Читайте показатель вместе с исходами

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

Разделяйте данные по типу вопроса, каналу, очереди, продукту и причине до сравнения команд. Техническую очередь со сложными дефектами нельзя оценивать как очередь общих вопросов. Смотрите медиану и старый хвост, а не только среднее.

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

Превратите результат в одно исправление

Начните с крупнейшей предотвратимой причины, а не с сотрудника с самым высоким процентом. Проверьте репрезентативные случаи и найдите отказавший контроль. Исправлением может стать правило маршрутизации, ясные полномочия, лучшая статья знаний, график специалистов или безопасная матрица эскалации.

Назначьте владельца и срок изменения, затем сравните одинаково определенные когорты до и после. Используйте выводы контроля качества, чтобы отличить системный дефект от потребности в обучении. Если разные типы вопросов указывают на один сбой, проведите анализ первопричины.

Не гонитесь за общим отраслевым ориентиром. Подходящий диапазон зависит от сложности, полномочий первой линии, риска и вашего определения события. Стабильная собственная база, причины и клиентские исходы надежнее.

Сохраните клиентский контекст

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

Рабочее пространство поддержки и командный inbox DripTell построены вокруг общей истории, назначений, заметок и статуса обращения. Какую бы систему вы ни использовали, храните одну запись вопроса на всем пути. Так измерение будет чище, а опыт клиента спокойнее.

Полезная цель состоит не в минимальном проценте, а в том, чтобы правильный случай один раз попал к нужным полномочиям вместе с достаточным контекстом.

Часто задаваемые вопросы

Как рассчитывается доля эскалаций

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

Считается ли каждый перевод эскалацией

Нет. Считайте перевод только тогда, когда существенная задача или решение переходят на более высокий уровень полномочий, экспертизы или владения риском. Обычную маршрутизацию, консультации и смену дежурства отслеживайте отдельно.

Какая доля эскалаций считается хорошей

Универсального значения нет. Сравнивайте стабильные периоды и похожие группы случаев, затем изучайте причины и исходы. Снижение вместе с ростом повторных открытий или небезопасных решений не является улучшением.

Нужно ли наказывать сотрудников за эскалации

Не по сырому показателю. Проверьте, была ли эскалация необходимой, своевременной и хорошо документированной. Сначала исправьте пробелы маршрутизации, знаний, полномочий, продукта и ресурсов.