Как честно оценивать переводы в службе поддержки

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

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

Начните с потребности клиента

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

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

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

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

Сохраняйте событие передачи

По последнему владельцу нельзя оценить качество. Нужно сохранить саму передачу.

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

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

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

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

Классифицируйте перемещение честно

Достаточно четырех рабочих классов.

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

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

Используйте несколько показателей

Начните с простой доли потребностей, переданных хотя бы один раз.

переданные потребности клиентов ÷ все подходящие потребности клиентов

Затем посчитайте глубину передачи.

общее число смен владельца ÷ потребности с хотя бы одной передачей

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

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

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

Изучайте закономерности вместо рейтинга людей

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

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

Анализ причин эскалации Microsoft различает ожидаемые эскалации, заложенные в процесс, и неожиданные, вызванные ошибками. То же разделение полезно в работе людей. Передача по политике ожидаема. Передача из-за сломанного права доступа нет.

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

Исправьте причину и проверьте снова

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

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

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

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

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

Какая доля переводов считается хорошей?

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

Нужно ли считать правильную передачу специалисту?

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

Как найти передачи, которые не состоялись?

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