Расширенный набор KPI для потерянных вызовов
3 минуты на чтение
Директор или руководитель контакт-центра просматривает отчет по доступности входящей линии за месяц. Предельно допустимая доля потерянных вызовов (%AR, Abandonment Rate) 5.00%, фактическая – 4.97%. На первый взгляд все в порядке. Так ли это?
Продвинутые коллцентростроители скажут, что для ответа нужно проверить историю звонков, потому что все зависит от того, сколько вызовов в какие дни терялось. Это верно. Вот два случая. Видно, что знания только %AR недостаточно для правильной оценки ситуации.
Нужен еще один индикатор, который поможет отличить один случай от другого. Во-первых, потому что у руководителей высокого уровня не всегда есть время просматривать детализированную статистику, особенно если направлений работы или проектов на площадке много. Во-вторых, если вы захотите настроить в системе контрольные события, запускающие, например, сигнализацию (“Алярм!”), то не сможете обойтись без измеримого индикатора.
На первый взгляд, подходит вот такая штука, я ее назвал операционным соответствием (Operational accuracy, OA).
На приведенном выше правом графике %AR был за рамками допустимого в 13 из 30 дней сентября. OAAR=(30-13)/30~0.57. У нас помимо %AR появилась дополнительная информация о том, что только 57% времени “все работает как надо”. Но это все равно не круто, потому что ситуации могут быть такие:
В обоих случаях во втором примере предельно допустимое значение %AR превышено в 8 днях из 30 и OAAR=(30-8)/30~0.73 - одинаковые. Тем не менее, случай на графике справа снова хуже левого: в отдельные дни доля потерянных вызовов приближается к 10%. Нужна дополнительная индикация, которая укажет на худший случай.
Что предлагается? Предлагается посмотреть, в какие дни было потеряно больше всего вызовов. В примере это 13, 20 и 26 сентября (80,52% всех потерь сверх допустимой нормы).
Я назвал новый индикатор долей интервалов с времени с более чем 80% проблем (%80PRI). Записывается он также как Service Level, через слэш (это НЕ знак деления):
Например, в нашем случае:
80,52% вызовов (сверх допустимого объема 5%) было потеряно всего за 3 дня (они выделены цветом в таблице).
Порядок расчета PR:
- Для каждого интервала времени найти разность между числом пропущенных вызовов и числом вызовов, которые можно было пропустить. Если полученная разность меньше нуля, результат приравнять к нулю (в примере результат в столбце “Допустимый объем потерь превышен на, звонков)”.
- Отсортировать интервалы времени по убыванию значений, полученных на предыдущем шаге.
- Найти суммарный превышенный объем вызовов (в примере в строке “Итого” – 231)
- Для каждого интервала времени найти долю превышения в общем объеме вызовов (например, для 13.09.15 превышенный объем потерь в 91 звонок составляет 33.39% от 231 – суммарного объема превышений).
- Рассчитать % превышений нарастающим итогом.
- Двигаться по результатам расчета, полученным в п.5., вниз до тех пор, пока рассчитанный % превышений нарастающим итогом не станет больше либо равен 80%. (В примере остановиться нужно на значении 80,52% в крайнем правом столбце). Значение PR получено.
Порядок расчета I:
При выполнении п.6. расчета PR вести подсчет количества интервалов до нахождения PR. В примере значение PR=80,52%, I=3 (третий сверху по порядку интервал).
Итого в примере:
Физический смысл: За отчетный период было потеряно 4.97% вызовов при допустимом значении 5.00% и результат можно формально признать успешным. Однако, норма по потерянным звонкам выполнялась не постоянно, а только в 73.33% дней работы проекта, то есть 26.67% времени проект требования по %AR не выполнял. При этом 80.52% всех потерь сверх допустимой нормы относятся только к 3 дням из 30 (80,52% потерь сверх допустимой нормы приходятся на 10% времени работы проекта). Тот случай, когда KPI начинают отражать реальную суть вещей.
По-моему, так информативнее, программировать отчет – 15 минут. Польза очевидна. Что скажете вы?
Автор: Дмитрий Галкин, независимый эксперт по вопросам организации контактных центров http://dgalkin.com
