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