Анализ эскалаций: почему растёт число эскалированных обращений
Когда эскалации растут, решение «нужно больше людей во второй линии» часто лечит следствие. В статье — анализ эскалаций: четыре типичные причины, разбивка роста по четырём измерениям, отслеживание доли вместо числа и почему эскалация не всегда плохо.
Короткий ответ
Чтобы понять, почему растут эскалации, рост нужно разложить по четырём измерениям: тема (какая проблема эскалируется), канал (бот, чат, звонок), время (какая неделя, какой час) и маршрут (кто кому передал разговор). Рост обычно вызван одной из четырёх причин: появилась новая проблема, первой линии не хватает знаний или полномочий, изменилось правило маршрутизации или выросли ожидания клиентов.
Решение для каждой причины своё. Посмотреть на общее число эскалаций и решить «нужно больше сотрудников второй линии» — часто значит лечить следствие, а не проблему.
Что такое эскалация и как её распознать
Эскалация — передача обращения более полномочному сотруднику или команде, потому что первая линия (бот или оператор первой линии) не смогла его решить. В разговоре её можно распознать тремя способами: запись о передаче в системе (от бота к оператору, от оператора к руководителю), явное требование клиента («хочу поговорить с руководителем») и фраза оператора («передаю специалисту»). Первый самый надёжный, но есть не во всех системах.
Причина 1: новая проблема
Новый продукт, изменение цены, технический сбой или новое правило приводят клиентов с вопросами, на которые у первой линии нет ответа. Признак: рост сосредоточен в одной-двух темах и начинается с конкретной даты. Решение: дать первой линии ответ или полномочия и устранить саму проблему.
Причина 2: пробел в знаниях или полномочиях первой линии
Тема не новая, но первая линия не может её решить: ответа нет в базе знаний или он устарел, либо у оператора нет полномочий (например, на небольшой возврат). Признак: одна и та же тема всегда эскалируется, а вторая линия закрывает её стандартным ответом. Решение: добавить ответ в базу знаний или расширить полномочия.
Причина 3: изменение маршрутизации
Изменилось правило передачи у бота, подключили новый канал или поменяли график смен. Признак: рост равномерный по всем темам и привязан к одной дате, каналу или часу. Тогда проблема в правиле, а не в клиенте. Как строятся правила передачи у бота, объясняет статья правила эскалации чат-бота.
Причина 4: рост ожиданий клиентов
Клиенты больше не принимают ответ, который раньше принимали: конкурент обслуживает быстрее, кампания пообещала больше или общественное событие повысило чувствительность. Признак: растёт доля явных требований вроде «хочу поговорить с руководителем», а темы те же. Решение: пересмотреть стандарт ответа или уровень сервиса.
Анализ по четырём измерениям
- ТемаРаспределение эскалированных разговоров по темам и его изменение к прошлому периоду. Рост в одной теме — причина 1 или 2.
- КаналПередачи от бота к оператору и от оператора к руководителю отдельно. Рост в одном канале — причина 3.
- ВремяПо дням и часам. Рост в определённые часы — смены или маршрутизация.
- Кто комуКакая смена или группа передаёт. Это нужно, чтобы видеть процесс, а не для индивидуальной оценки.
Доля эскалаций, а не число
Когда растёт общее число обращений, растут и эскалации. Настоящий показатель — доля эскалаций: эскалированные разговоры к общему числу разговоров, отдельно по темам. Для некоторых тем высокая доля нормальна (например, юридические запросы всегда уходят специалисту). Важно изменение.
Иллюстративный пример
Это иллюстративный пример. В интернет-магазине за две недели заметно растут передачи от бота к оператору. Распределение по темам показывает: рост в основном в теме «статус возврата» и начинается с даты перехода на нового платёжного провайдера. Бот называет сроки старого провайдера, а клиенты пишут, что деньги не пришли.
Здесь сочетаются причины 1 (новая проблема) и 2 (устаревшие знания бота). Ответ бота обновляют, платёжной команде передают список задержанных возвратов. В следующие недели отслеживают долю эскалаций по этой теме.
Еженедельный разбор эскалаций
Разбирайте эскалации каждую неделю на короткой 30-минутной встрече с руководителем поддержки и владельцем базы знаний. Повестка постоянная: две самые быстрорастущие темы, типичный ответ второй линии по ним, можно ли передать этот ответ первой линии или боту, и результаты решений прошлой недели. Каждая встреча должна давать хотя бы одно изменение: новый ответ в базе знаний, расширенные полномочия или исправленное правило передачи. Эффект проверяется по доле эскалаций на следующей неделе.
Эскалация — это не плохо
Целью не должно быть полное сокращение эскалаций. Иногда правильная и своевременная передача — лучший исход: сложная жалоба, юридический вопрос, раздражённый клиент. Проблема — передавать то, что могли решить бот или первая линия, или не передавать то, что нужно. Поэтому отслеживайте два показателя вместе: долю эскалаций и долю разговоров, оставшихся нерешёнными без эскалации.
Типичные ошибки
- Смотреть на общее число и добавлять сотрудников во вторую линию.
- Объяснять рост слабостью операторов, не глядя на процесс.
- Ужесточать правило эскалации бота только ради меньшего числа передач — клиент попадает в ловушку.
- Не читать разговоры, которые решает вторая линия.
Границы
- Если передача не записана в системе, AI лишь оценивает её по фразам в разговоре.
- Эскалация, когда клиент переходит на телефон или приходит лично, может не попасть в разговор.
- На малых числах изменения доли могут быть случайными.
Анализ эскалаций в Vexvon
В Vexvon фиксируется, кто вёл разговор — бот или сотрудник, — и панель показывает распределение между ботом и сотрудниками. Поля вроде «причина эскалации» и «тема» компания создаёт сама; AI-помощник панели показывает их в пересечении с каналом и временем и в сравнении периодов. Ответы бота строятся по базе знаний, поэтому пробел в знаниях первой линии исправляется прямо там. Подробнее: аналитика и база знаний.
Следующий шаг
Разделите эскалированные разговоры за последние две недели по темам и прочитайте 15 из самой быстрорастущей: какая из четырёх причин видна? Метод поиска первопричин — в статье анализ первопричин жалоб; анализ можно построить вместе на демо.
Продолжение темы: болевые точки пути клиента, анализ пробелов базы знаний.