Как создать матрицу эскалации поддержки

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

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

Начните с двух видов ответственности

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

Запишите в матрице обе роли:

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

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

Опишите распознаваемые условия

Избегайте условий вроде «важный клиент» или «серьезная проблема». Два сотрудника поймут их по-разному. Используйте признаки, которые можно проверить по разговору и данным аккаунта.

Хорошие условия обычно относятся к четырем группам:

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

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

Если оба поля меняют маршрут, определите оба. В противном случае используйте более простое и точно укажите, что оно измеряет.

Стройте строку вокруг одного решения

Каждая строка должна описывать повторяемое решение, а не просто отдел компании. Практическая строка содержит:

1. Наблюдаемое условие.
2. Уровень воздействия или серьезности.
3. Владельца решения или функциональный маршрут.
4. Время до включения следующего маршрута.
5. Резервного владельца, если первый недоступен.
6. Доказательства, которые передаются вместе с обращением.
7. Время следующего сообщения клиенту.
8. Условие закрытия и последующего разбора.

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

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

Передавайте пакет фактов вместо стенограммы

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

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

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

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

Сохраняйте владельца клиентского разговора

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

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

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

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

Проверьте матрицу на прошлых обращениях

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

Затем проведите короткий пилот и оцените три показателя:

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

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

Пересматривайте матрицу после изменений политики, продукта, состава команды или риска. Удаляйте строки, которые больше не ведут к реальному владельцу. Добавляйте строку только для повторяющегося решения, которое нельзя обработать существующим условием.

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

Что должна содержать матрица эскалации поддержки

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

Когда обращение следует эскалировать

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

Кто сообщает новости клиенту после эскалации

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