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