Call Center на 100%: Практическое руководство по организации Центра обслуживания вызовов

Гораздо эффективнее, если система сама сможет перенастраиваться, т. е. выбирать оптимальный алгоритм обслуживания в зависимости от расчетного времени ожидания. Например, она может сравнить несколько операторских групп по этому параметру и направить вызов в ту, у которой такое время минимально.

Причем заметьте: и супервизор, и система анализируют не реальное, текущее, а расчетное, предполагаемое время ожидания. Таким образом, возникает очень ценная возможность проактивных, а не реактивных действий. Иными словами, можно не ждать возникновения проблем, а попытаться их предотвратить.

Но именно в том, что приходится оперировать не реальным, а только предполагаемым временем ожидания, и заключается вся сложность. Ведь длительность ожидания в очереди в каждый момент зависит от множества труднопредсказуемых составляющих: поведения вызывающих абонентов, длительности разговоров, даже, наконец, поведения и производительности операторов (хотя как раз в последнем случае прогноз сделать легче).

Как наиболее точно рассчитать предполагаемое время ожидания? Ведь чем точнее оно будет рассчитано, тем эффективнее будет управление операторским центром и, следовательно, тем эффективнее будут выбраны алгоритмы обслуживания.

Существуют три основных подхода к определению расчетного времени ожидания:

• на основе анализа хронологических данных;

• на основе анализа текущей производительности;

• на основе комбинирования оперативных и хронологических данных.

Расчет времени ожидания на основе хронологических данных

Методы, основанные на анализе хронологических данных за какой-то интервал времени, например за последние полчаса, оперируют такими показателями, как средняя скорость ответа, заданный уровень обслуживания и т. п. Давайте рассмотрим подробнее распространенный метод Average Speed of Answer (ASA), основанный на определении средней скорости ответа за какой-либо отрезок времени, чаще всего – за последние полчаса. Схематично это выглядит так.

Предположим, в операторский центр поступил вызов определенного типа. Система определяет, что среднее время ожидания для вызовов данного типа за последние полчаса составило 2 минуты, поэтому она экстраполирует этот показатель и на вновь поступивший вызов и прогнозирует, что он тоже прождет 2 минуты. Через каждые полчаса показатель ASA снова пересчитывается.

Такая схема вполне работоспособна, но лишь в случае постоянной равномерной нагрузки. Однако, как мы уже не раз говорили, для операторского центра такое положение вещей – идеальное и потому недостижимое. А как только происходит скачкообразное нарастание потока вызовов, любой метод, основанный на анализе не текущей, а уже прошедшей ситуации, начинает буксовать. Ведь оперативная ситуация резко изменилась и оказалась достаточно далека от той, что была 10, а тем более 20 минут назад. И чем дальше, тем больше расчетное время ожидания расходится с реальным.

Схематично данный процесс показан на рисунке 3.4.

^{Рис. 3.4. Графики реального и расчетного времени ожидания, определенные по методу ASA}

Из приведенного графика видно, сколь неточно работает данная методика. Например, уже для 30-го звонка предполагаемое время ожидания, рассчитанное по методу ASA, может составить 3 минуты, в то время как в действительности оно будет равно 13 минутам. Разве можно принимать адекватные решения, базируясь на такой недостоверной информации?

Расчет времени ожидания на основе оперативной ситуации

При использовании методов, основанных на анализе производительности в данный момент времени, оперируют такими показателями, как число вызовов в очереди, время, которое провел в очереди самый ранний вызов, и т. п. Метод, построенный на анализе времени ожидания самого раннего вызова (Oldest Call Waiting, OCW), является наиболее популярным. Давайте рассмотрим его подробнее.

Предположим, в операторский центр поступил вызов определенного типа. Система определяет, что к данному моменту самый ранний вызов этого типа уже ожидает в очереди 2 минуты, поэтому она экстраполирует данный показатель и на вновь прибывший вызов, прогнозируя, что он тоже прождет 2 минуты.

На первый взгляд неплохая схема, но тоже лишь в случае равномерной нагрузки. Если она становится пиковой, использование этого метода дает неточные результаты.

Дело в том, что он основан на следующем предположении: вызов, стоящий в очереди самым последним, будет ждать обслуживания столько же, сколько и самый первый. Но за то время, пока этот последний вызов доберется до начала очереди, может произойти множество изменений, например в числе работающих операторов, количестве вызовов в очереди, времени обслуживания вызова и т. д. Поэтому чем длиннее очередь, тем хуже работает метод OCW.

Схематично данный процесс показан на рисунке 3.5.