Главное - хвост: о порочности усредненных значений

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

Главное - хвост: о порочности усредненных значений

Покажем на примере. Пусть контакт-центр обслуживает входящие звонки, которые поступают на номер 8-800. Руководитель отслеживает среднюю скорость ответа (Average Speed of Answer, ASA).

В первом и втором случае звонки поступают в очередь ожидания, но характер наполнения очереди разный: неравномерный и равномерный:

Главное - хвост: о порочности усредненных значений

Если смотреть только на среднее, то можно не заметить рост длины очереди, понести необоснованные расходы на 8-800 и/или потерять часть клиентов, не готовых ждать долго. При этом значения ASA вполне могут оказаться в пределах целевого коридора, как в примере.

Кстати, в e-commerce, где время перезвона по клиентской заявке часто критично для конверсии, руководители контакт-центров не уделяют этому внимания и не смотрят одновременно на ASA и суммарное время ожидания. А клиенты переключаются на конкурентные предложения и количество чеков за период становится меньше.

Есть разные способы “отловить” ситуацию. Вариант №1 рассмотрели:

Главное - хвост: о порочности усредненных значений

Вариант №2, с помощью часто используемого индикатора Service Level. Я не очень люблю им пользоваться, но это вопрос личных предпочтений.

Главное - хвост: о порочности усредненных значений

Мне больше нравится вариант №3, учитывающий “хвост” Service Level, т.н. SL Tail. Хотя показатель редкий и в стандартах его нет.

Главное - хвост: о порочности усредненных значений
Главное - хвост: о порочности усредненных значений

Удобство в том, что можно измерять одновременно несколько “хвостов” для разных предельно допустимых времен ожидания. Тогда можно на гистограмму распределения вызовов по Waiting Time не смотреть: несколько чисел сразу показывают, какие доли от общего объема контактов ждут больше 1,2,3….минут. Соответственно, место на мониторе освобождается от громоздкого графика. Выглядит он, кстати, примерно так:

Главное - хвост: о порочности усредненных значений

Аналогично с FCR – долей вопросов, решенных с первого раза и его “двоюродной сестрой” FLR (долей вопросов, решенных на первой линии). У FCR тоже есть “хвост” – вопросы, потребовавшие больше чем N обращений. В целом, у значимых для бизнес-процессов индикаторов очень желательно измерять “хвосты”, это переводит управляемость контакт-центра как системы на новый уровень, а для руководителя делает ситуацию более прозрачной.

Еще момент. Математически правильно вместо среднего арифметического использовать медиану, если результат процесса не подчиняется нормальному (гауссову) распределению, иначе получится ситуация с олигархом, трактористом и огурцами. Медиана простыми словами – это число, которое занимает среднее положение в отсортированном списке (на картинке ниже медиана в первом случае равна 76, а во втором 90):

Главное - хвост: о порочности усредненных значений

Здесь при одинаковых средних медианы разные, доступность контакт-центра различается. Во втором случае половина вызовов ждала больше 90 секунд и это бы легко понять, не залезая в детализацию звонков. Единственная проблема в том, что одной медианы недостаточно, чтобы аналитик мог увидеть разброс данных, а это характеристика качества менеджмента. Да требовать от среднестатистического супервайзера разбираться в медианах и дисперсиях кажется не очень хорошей идеей. “Хвосты” легко воспринимаются и понимаются даже слабо подготовленным руководителем.

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

Дмитрий Галкин, независимый консультант по вопросам создания и управления контакт-центрами специально для “Omniline”

Больше полезной информации о технологиях, клиентском сервисе, автоматизации вы найдете на нашем сайте, в Telegram-канале и на нашей странице в Facebook

22
2 комментария

А почему не использовать статистику в программах? Допустим в манго офисе это все подсчитывается автоматически

Ответить

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

Ответить