Помочь применить это руководство?Спросить команду DripTell
Клиент объясняет проблему одному специалисту, получает разумный первый ответ, а затем общается еще с тремя людьми, прежде чем дело сдвигается с места. Внутри службы поддержки каждая передача могла казаться оправданной. Для клиента результатом не владел никто.
Поэтому простого числа переводов недостаточно. Измеряйте переназначения по истории событий обращения, считайте смену только после того, как ответственный владелец принял работу, и отделяйте полезные передачи от бессмысленного хождения по кругу. Затем сопоставляйте показатель с дополнительным ожиданием, повторными контактами и итогом для клиента.
Считайте смену владельца, а не попытки назначения
Переназначение происходит, когда ответственность за нерешенное обращение переходит от одного принявшего владельца к другому человеку или команде. Первое назначение не считается переназначением. Предложение работы, которое сотрудник отклонил или не принял, тоже не считается. Консультация не меняет владельца, если первоначальный специалист по-прежнему отвечает за следующий шаг и сообщение клиенту.
Различие важно, потому что системы маршрутизации создают много технических событий. Например, Microsoft отдельно описывает ручное и автоматическое назначение, отправку в очередь, консультацию, перевод и переназначение руководителем в справочнике по диагностике разговоров. Если считать каждое событие сменой владельца, показатель будет завышен еще до анализа.
| Событие в истории обращения | Считать переназначением | Причина |
|---|---|---|
| Первый принявший владелец | Нет | С этого начинается ответственное владение |
| Отклоненное или просроченное предложение | Нет | Никто не принял владение |
| Консультация со специалистом | Нет | Текущий владелец отвечает за следующий шаг |
| Принятый перевод новому владельцу | Да | Ответственность перешла |
| Возврат в очередь | Да | Именной владелец отказался от ответственности |
| Системная коррекция до принятия | Нет | Это попытка маршрутизации, а не владение |
Публикуйте эти правила вместе с метрикой. Иначе два аналитика получат разные результаты из одного журнала.
Постройте цепочку владения для каждого обращения
Выберите фиксированную когорту, например все корректные обращения, созданные за неделю. Дайте каждому одинаковое окно наблюдения. Не берите только закрытые обращения, иначе из анализа исчезнет незавершенная работа, которая чаще всего ходит между владельцами.
- 1Зафиксируйте когортуВключите все подходящие обращения одного периода и дайте им одинаковое окно наблюдения.
- 2Восстановите цепочкуРасположите по времени принятие, освобождение, перевод, очередь и следующее принятие.
- 3Классифицируйте сменыОтделите необходимую экспертизу и плановую передачу от неверной маршрутизации, емкости, доступа и неизвестного.
- 4Проверьте влияниеСопоставьте смены с ожиданием, повторным объяснением, поздним контактом, открытием и возрастом работы.
- 5Исправьте раннюю причинуИзмените одну частую управляемую причину и сравните следующую сопоставимую когорту.
Расположите события по времени. Запишите начало владения, принявшего человека или команду, причину смены, время принятия следующим владельцем и необходимость для клиента повторять уже известные факты. Различайте владение очереди и конкретного человека.
Названия событий зависят от продукта, но доказательство должно оставаться понятным. В документации Microsoft по работе с очередями освобождение элемента удаляет имя из поля ответственного и возвращает его владельцу очереди. Ручное принятие при этом может обойти проверки графика, навыков, присутствия и емкости. У этих событий разные причины.
Общий ящик делает переписку видимой, однако видимость не доказывает владение. Для аудита нужны принявший владелец, время события, причина и понятное следующее обязательство.
Отделите полезную передачу от лишнего движения
Одно переназначение может защищать клиента. Специалист по оплате может иметь полномочия, которых нет у первого сотрудника. Смена может закончиться во время открытого инцидента. Руководитель может передать рискованное обращение квалифицированному человеку. Если называть каждое движение провалом, сотрудники начнут удерживать работу, которую не могут безопасно закончить.
Используйте небольшой набор причин:
- необходимая экспертиза или полномочия;
- запланированная передача между сменами;
- исправление неверной первой маршрутизации;
- несоответствие емкости или доступности;
- отсутствие доступа, информации или дисциплины владения;
- неизвестная причина без записи.
Для первых двух причин требуйте подтвержденное принятие и короткую запись о передаче. Остальные проверяйте как возможные сбои процесса. Оставляйте неизвестное видимым, не превращая пробел в данных в вымышленный вывод.
Автоматизация процессов может сохранять причину перевода и возвращать непринятое обращение в безопасную очередь. Контроль доступа может не допустить назначения тому, кто не видит запись. Но оба механизма не заменяют проверку фактической истории.
Используйте несколько связанных показателей
Главная метрика равна доле подходящих обращений хотя бы с одной сменой владельца после принятия. Добавьте среднее число переназначений на обращение и распределение с нулем, одной, двумя, тремя и более сменами. Длинный хвост важнее аккуратного среднего.
Добавьте две клиентские меры. Посчитайте время от освобождения обращения одним владельцем до принятия следующим. Затем проверьте выборку и выясните, пришлось ли клиенту повторять сведения, уже находившиеся в записи. Долгое время обработки само по себе этого не доказывает.
Разбивайте данные по типу запроса, исходному каналу, первой очереди, смене и причине. Не составляйте рейтинг сотрудников. Человек, принимающий сложные спасенные обращения, может получать много переназначений, не создавая ни одного.
Используйте отчеты по ящику, чтобы увидеть распределение, а карточку клиента, чтобы проверить более поздний контакт или повторное открытие. Цель состоит в понимании пути, а не в награде за низкое число.
Ищите причину в первом управляемом решении
Если обращение ходит по кругу, начните с самого раннего решения, которое можно изменить. Неверно определен тип запроса? В первой очереди не было нужного навыка? Данные о емкости устарели? Разрешения сделали запись недоступной? Передача состоялась без подтверждения нового владельца?
Проверьте небольшую выборку по каждой крупной причине и из длинного хвоста. Сравните ее с похожими обращениями, которые сохранили одного владельца. Тогда операционная команда поддержки получит конкретную точку ремонта, например правило маршрутизации, состав очереди, пробел в знаниях, правило доступа или порядок передачи.
Сохраните необходимые переводы и устраните повторяемые причины лишних. Снижение показателя полезно только тогда, когда ожидание, повторные контакты, повторные открытия и возраст нерешенных обращений не растут.
Превратите показатель в безопасное решение
Задача не в том, чтобы довести переназначения до нуля. Важно понять, приблизила ли каждая смена владельца обращение к проверенному результату, не потеряв контекст.
Опубликуйте определение события, когорту, окно, причины, долю неизвестного и проверки результата. Затем выберите одну частую устранимую причину, измените правило или процесс и сравните следующую когорту. Такая метрика помогает учиться и не вынуждает скрывать необходимую помощь.
Часто задаваемые вопросы
Какой уровень переназначений считается хорошим
Универсального уровня нет. Сравнивайте одинаковые типы запросов во времени и отделяйте необходимые передачи от лишнего движения до постановки цели.
Считается ли консультация переназначением
Нет, если первоначальный владелец отвечает за следующий шаг и сообщение клиенту. Считайте ее только при официальном переходе ответственности к консультанту или его команде.
Считать ли возврат обращения в очередь
Да, если человек уже принял владение. Возврат создает новое состояние и может добавить ожидание без владельца, даже когда другой сотрудник принимает работу быстро.
Можно ли ранжировать сотрудников по этой метрике
Не следует. Переназначения часто отражают правила маршрутизации, доступ, штат, состав обращений или необходимую экспертизу. Сначала изучите причины и клиентские результаты.
DripTell Editorial
Практические материалы, проверенные командой продукта и клиентских процессов DripTell.
Узнайте, как DripTell проверяет сведения о продукте, использует первичные источники и исправляет ошибки.
Редакционная политика и источники