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

Самолюбова Александра

_{Таблица 3.1. Пример профиля вызовов}

Почему же возникают такие «провалы» в обслуживании? Конечно, из-за перегрузок в операторском центре. Поэтому так важно их не допускать. Именно не допускать, предупреждать само появление перегрузок, а не бороться с ними по мере их возникновения.

Предвижу ваш резонный вопрос: почему в профессионально

работающем, хорошо отлаженном операторском центре (а ведь к этому все и стремятся, не так ли?) могут вообще возникать перегрузки? По двум причинам. Я бы условно назвала их объективной (внешней) и субъективной (внутренней).

Объективная (внешняя) причина заключается в том, что, как мы уже говорили, в операторский центр вызовы никогда не поступают равномерно, поэтому в течение дня, недели или сезона обязательно будут возникать пиковые нагрузки. Иногда их можно предсказать (объявление маркетинговой кампании, сезон гриппа) – и тогда они в какой-то мере перестают быть пиковыми, а иногда нельзя (сбой в системе, экстренная ситуация, даже непредсказуемое поведение и предпочтения абонентов) – и тогда они носят классический пиковый характер.

Субъективная (внутренняя) причина возникновения перегрузок обусловлена человеческим фактором в самом Центре обслуживания вызовов (как говаривали в позабытые нынче времена Никиты Сергеевича Хрущева – «волюнтаризмом»). Вдруг возникает момент, когда по какой-либо причине начинает ощущаться острая нехватка операторов: кто-то ушел на обед (хотя в большинстве ЦОВ это время регламентировано), у кого-то заболел зуб, у кого-то прихватило желудок, кому-то именно в это время позвонили по личному вопросу и т. д.

Особенно часто такую картину можно наблюдать в небольших операторских центрах.

Со всеми перегрузками, вызванными как объективными, так и, тем более, субъективными причинами, можно и нужно бороться. Конечно, мы не можем влиять на все семь факторов, определяющих поведение вызывающих абонентов, но тем не менее многое в наших руках. Оставив в стороне вопросы планирования ресурсов и поддержания дисциплины (об этом мы подробно поговорим в главе 11), рассмотрим способы управления ЦОВ на основе метода, предсказывающего расчетное время ожидания в очереди.

Расчетное время ожидания в очереди

Имея в своем распоряжении такой важный параметр, как расчетное время ожидания в очереди, можно в значительной мере повысить эффективность обслуживания вызовов за счет:

• объявления клиенту о том, сколько он может прождать в очереди (подробнее об этом мы говорили выше). Гораздо предпочтительнее, чтобы в случае резко возросшего расчетного времени ожидания в момент пиковой нагрузки (например, 3 минуты и более) клиенты вешали трубку и перезванивали позже, а не бесконечно «висели» на линии;

• прямого вмешательства супервизора,

• автоматической перенастройки системы.

Вручную супервизор может предупредить пиковые нагрузки следующим простым способом: увидев, что в одной из операторских групп расчетное время ожидания приближается к опасной черте, а в другой равно нулю или чрезвычайно мало, он может просто перебросить операторов из второй группы в первую и таким образом сократить время ожидания в проблемной группе. В небольшом Сall Center супервизор может также проверить, по какой причине его подчиненные ушли на перерыв, и, если это возможно, попросить их вернуться на рабочее место.

Конечно, приведенная картина весьма схематична, в жизни все гораздо сложнее (например, см. главу 5), но все же подход описан верно.

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

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

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

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

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

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

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

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

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

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

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

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