Comments 17
На практике руководитель контакт-центра при сохранении ASA «в номинале» при любой длине очереди не заметит роста расходов на 800-ый трафий. Оно же как в жизни? Пока показатели в норме — все окей, а расходы подведем в конце месяца.
И! Речь не про сравнение. А о том, что при разных вариантах развития событий, один из которых ведет к неоправданным расходам, целевые показатели КЦ будут оставаться в норме.
Ну не измеряет никто почти расходы реал-тайм.
Я что пытаюсь объяснить: обычно мониторят только скорость ответа, она при разных расходах может оказаться одинаковой.
Да, за длиной очереди следят, но в 99.99% случаев руководитель не знает, какая длина очереди является критической. А раз не знает, то не понимает, к каким расходам приведет ее рост и что делать.
Если выполняются нормативы по ASA, то считается, что все нормально, никто не смотрит в деньги. А деньги могут расходоваться разные при одинаковых ASA.
Но во втором случае у него растет очередь, очередь генерит расходы, рост расходов напрямую он в 99% случаев НЕ видит. У него показатель доступности (доступность-это насколько быстро абоненты получают ответ на свой запрос) в норме, зачем метаться.
А денежки начинают улетать в трубу, как топливо у истребителя на форсаже, потому что расходы на 8-800 с ростом длины очереди растут нелинейно.
И в этом случае он начнет принимать меры только тогда, когда %потерянных вызовов (оно же LCR, оно же Abandonment Rate) — еще один условно обязательный индикатор — превысит пороговое значение.
Но! Могут возникать ситуации, когда скорость ответа в норме, доля потерянных вызовов в норме (обычно принимают <=5%), абоненты ждут ответа. Для небольшого контакт-центра из 15-20 операторов, если последний вызов в очереди ждал три минуты, расходы на 8-800 превысят расходы на ФОТ КЦ. И этого упорно не замечают, что меры нужно принимать ДО того, как посыплется доля потерянных звонков.
Это не то, что не видно, туда не смотрят и не имеют индикации о том, что расходы запредельные.
Разговор о том, что пока общепринятые в отрасли показатели доступности в номинале, расходы никого не парят. Больше того, в реальной жизни бюджеты часто разделены — ФОТ операторов — это к КЦ, а 8-800 — бюджет маркетинга или ИТ.
И только в конце месяца, после того, как провайдер связи выставит счет, брюки превращаются… превращаются брюки в вопрос гендиректора или финконтроля: «А почему мы в этом месяце столько потратили на трафик?» При том, что цели по показателям доступности — ASA и LCR соблюдены и с точки зрения руководителя КЦ ничего страшного не произошло.
Вы немного не с того конца заходите, по-моему. Когда речь заходит о мониторинге чего-либо, в первую очередь надо определиться:
- Что вообще мы мониторим и зачем
- Какие показатели — "хорошо", а какие — "плохо"
После чего подбирать агрегирующие функции (специально не говорю — усреднения, ибо как раз усреднения чаще всего не подходят, у них иная роль), которые будут демонстрировать именно эти показатели. А не брать некие абстрактные средние и потом рассуждать, что они плохо описывают картину (зачем вообще рассматривать то, что заведомо не подходит к задаче)?
Если нас интересует продолжительность отдельных звонков, и "хорошим" мы считаем короткие звонки, а "плохим" — длинные (оставим в стороне осмысленность этого подхода), то просто из самого смысла усредняющих функций становится очевидно, что они тут не помогут.
Дальше вы пишете:
Еще момент. Математически правильно вместо среднего арифметического использовать медиану, если результат процесса не подчиняется нормальному (гауссову) распределению, иначе получится ситуация с олигархом, трактористом и огурцами.
Это не "математически правильно", и гауссово распределение вообще ни при чём. Тут суть в самом смысле показателей, которые вы описываете и функций, которые вы применяете. Среднее арифметическое является усредняющей функцией, а медиана — нет. Медиана по смыслу — это тот же самый "хвост" с отсечкой на 50%. Но что даёт именно её применение в данном случае? Ну знаете вы, что 50% звонков короче целевого времени, а толку? Вас не волнуют остальные 50%? Ой, сомневаюсь.
Поэтому, повторюсь, упор было бы правильнее сделать на то, ЧТО мы пытаемся мониторить, каков реальный смысл этих показателей, и что мы считаем хорошим/плохим. И тут вы совершенно правильно пишете про SL tails. В SLA прописано, что 90% звонков должно укладываться в отведенное время? Вот на это и надо смотреть. Собственно, всё.
Задача — контроль индикаторов в реальном времени, я же не зря пример для статьи выбрал.
Представьте, у вас 500 операторов, 20 проектов (допустим, горячих линий) одновременно, по каждому надо обеспечить контроль минимум 4 KPI (а на самом деле 12+), будем делать ручками в Экселе? Никак не выйдет.
Нет, конечно, можно подключить Эксель к базе программного комплекса КЦ, грузить оттуда данные и макросом их, макросом, но это ненужное извращение. Кроме того, в реалтайме нужно помнить, что сотруднику Эксель может понадобиться, например, для подготовки отчета или составления графика работы. Пусть параллельно автоматом процентиль.искл() вычисляется и руками человека составляется график?
И на реальных объемах данных Эксель ляжет, к гадалке не ходи. 500 операторов генерируют грубо 240.000 записей в базе за 8 часов.
С точки зрения практической реализации тут, конечно, нормальная система мониторинга нужна, а не эксель. Если в организации есть достаточный доступ к системе телефонии (или откуда там еще брать информацию), вменяемый админ и человек, который сможет грамотно поставить задачу, это не должно быть большой проблемой.
Единственная проблема в том, что одной медианы недостаточно...
И тут я уже ждал что дальше вы расскажете как? А увидел конец статьи (( Как-то всё обрывками урывками
Сравниваем первую табличку с последней и да видим что медиана лучше чем просто среднее, а вот сравнение с хвостами не видим
Но хвост решает задачу, потому что как только вы видите, что х% звонков ждут больше, чем разрешено, вы понимаете, что у вас едет экономика.
Главное — хвост: о порочности усредненных значений