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

К сожалению, а вернее, к счастью, теперь это невозможно. Избыточный штат операторов – непозволительная роскошь (подробнее о затратах на содержание штата операторов мы поговорим в главе 11). Что же делать? Ответ прост: создавать очередь. Да-да, очередь. Естественно, разумной длины и хорошо управляемую, но тем не менее очередь. Иными словами, постараться обрабатывать как можно большее число вызовов как можно меньшим числом операторов, но никак не за счет ухудшения качества обслуживания и не в ущерб здоровью операторов, работающих на износ. Скажем прямо, задача нелегкая. Но выполнимая.

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

• число вызовов, ожидающих в очереди;

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

• средняя скорость ответа;

• время ожидания в очереди самого раннего вызова;

• число работающих операторов;

• число свободных операторов;

• время суток;

• день недели.

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

В целом на оптимизацию длины очереди позитивно влияют следующие факторы:

• эффективное планирование человеческих ресурсов (вреден как избыток, так и недостаток операторов);

• поддержка железной дисциплины в ЦОВ (соблюдение графиков перерывов, своевременный приход на работу и т. п.);

• эффективные алгоритмы обслуживания вызовов. Такие решения стоят недешево, но оправдывают себя, позволяя экономить большие средства за счет увеличения объема обслуженных вызовов и одновременного сокращения штата операторов. В этой книге я постараюсь рассказать вам о некоторых таких решениях – от простейших до достаточно сложных.

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

Почему я говорю именно так? Да потому, что полностью исключить потерянные вызовы – задача нереальная. Конечно, чем эффективнее обслуживание вызовов, тем меньшее число их будет потеряно. Тем не менее доказано, что, к сожалению, не существует абсолютно прямой связи между значением уровня обслуживания и количеством абонентов, которые повесили трубку, не дождавшись ответа оператора. И в первую очередь это связано с тем, что во многом на параметр Abandoned Calls влияет такой труднопредсказуемый и трудноуправляемый показатель, как поведение вызывающих абонентов.

По мнению американского института ICMI (International Customer Management Institute), существуют семь причин, обусловливающих поведение вызывающих абонентов:

1) степень заинтересованности (например, клиент, звонящий в банк, чтобы заблокировать потерявшуюся кредитную карточку, способен ждать дольше, нежели клиент, желающий узнать изменение процентных ставок);

2) наличие альтернативных каналов доступа к информации (другой телефонный номер, сайт компании и т. п.);

3) наличие хорошего Центра обслуживания вызовов у конкурентов (понятно, что этот фактор имеет особое значение в тех областях, где есть сильная конкуренция; к сожалению, там, где существует монополия на какие-либо услуги, этот фактор не играет никакой роли);

4) уровень ожиданий (важна сложившаяся репутация компании);

5) наличие свободного времени (здесь вне конкуренции пенсионеры);

6) способ оплаты (в нашей стране с введением повременной платы за внутригородские соединения этот фактор становится важным);

7) настроение (о, здесь большой простор для воображения… Так и представляется дождливый английский день и сидящий у камина с трубкой в зубах и телефонной трубкой в руках абонент…).

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

Тем не менее за этим показателем надо пристально следить. Рост, особенно внезапный, числа потерянных вызовов может сигнализировать о возникновении каких-либо серьезных проблем (помните, я приводила пример из практики PSO Lucent Technologies?). В этом случае управляющий персонал должен проанализировать ситуацию и принять соответствующие меры.

На мой взгляд, при нормальной работе операторского центра допустимое число потерянных вызовов может составлять 3–5 %.

Думаю, не открою вам секрета, если скажу, что в жизни бывают моменты, когда все плохо. Ну просто все. Форс-мажор, иными словами. Для Call Center это означает возникновение сильной перегрузки, управлять которой уже не получается.

Но что под ней понимать? Это зависит от конкретного операторского центра. Пороговые значения могут быть разными. В одном случае явной перегрузкой считается превышение средней скорости ответа одноминутного значения, а в других же допустимо и пятиминутное ожидание. Но тем не менее в том или ином виде, чаще или реже, форс-мажорные перегрузки, к сожалению, встречаются почти в любом Центре обслуживания вызовов.

Что делать в этом случае? Тут возможны три варианта:

• пить валокордин, рвать на себе волосы и сообщать абонентам заоблачное время ожидания;

• принудительно отбивать вызовы; абоненты при этом будут слышать сигнал «занято»;

• предоставить абонентам возможность оставить сообщение и потом им перезвонить.

Лично я предпочитаю второй вариант. Сейчас объясню почему.

Действительно, стоит ли в случае явной перегрузки пользоваться сигналом «занято»? На мой взгляд – стоит.

Не испугают ли короткие гудки клиентов, не отобьют ли у них навсегда охоту обращаться в эту компанию? Судя по моему опыту – не отобьют.

Использование сигнала «занято» в случае явной перегрузки полезно по следующим причинам:

• абоненту приятнее услышать короткие гудки, чем объявление типа «Ваш вызов будет обслужен через 15 минут»;

• абоненты, которые услышали сигнал «занято», перезвонят в операторский центр с гораздо большей вероятностью, чем те, что повесили трубку, так и не дождавшись ответа оператора;

• благодаря сигналу «занято» уменьшается нагрузка на соединительные линии;

• операторский центр не теряет управляемость и не выходит из-под контроля.

Конечно, увлекаться короткими гудками не стоит. Это крайняя мера, но на нее иногда приходится идти, чтобы избежать еще больших неприятностей.

А вот чего делать, на мой взгляд, решительно не следует – это предоставлять абонентам возможность оставить сообщение. Хотя многие менеджеры и предпочитают именно этот путь, полагая, что так поступать гораздо вежливее по отношению к вызывающим абонентам: «Мы заботимся о наших клиентах, у нас ни один вызов не остается безответным. Даже если мы не можем сразу же вам ответить, мы перезвоним вам позже».

Я считаю, что это мнимая забота о клиентах. И логика тут такая: «Я – клиент, и я звоню вам сейчас и хочу получить ваш ответ тоже сейчас – когда это удобно мне, а не вам. Меня не интересует, что вы мне скажете через полчаса или час, когда соизволите перезвонить. Может быть, я вообще в это время буду занят – отправлюсь в магазин или буду участвовать в совещании. Если уж вы организовали Центр обслуживания вызовов, то обслуживайте мой вызов – здесь и сейчас».

Мне кажется, что, предоставляя абонентам возможность оставить сообщение, управляющий персонал ЦОВ на самом деле просто облегчает себе жизнь, дает себе некоторые поблажки, лазейки, так как заранее допускает возможность НЕОТВЕТА НА ВЫЗОВ! А это никуда не годится.

Гораздо честнее по отношению к клиентам в случае явной перегрузки просто выдавать сигнал «занято», а уж дело менеджмента – постараться ее не допускать. О том, каким образом это можно сделать, мы поговорим ниже, в разделе «Анализ очереди».

Управляющий персонал большинства операторских центров следует логике персонажей Оруэлла: «Все вызовы для нас равны, но некоторые равнее». Это связано и с политикой сегментации клиентов, и с различными внутренними причинами, способными повлиять на очередность обслуживания вызовов[7].

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

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

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

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

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

• уровень обслуживания;

• максимальные задержки при ответе на вызовы;

• средняя скорость ответа;

• профиль вызовов.

К сожалению, многие менеджеры ЦОВ довольствуются только одним из этих индикаторов, а именно средним временем ожидания в очереди, или, как его чаще называют, средней скоростью ответа (Average Speed of Answer, ASA). Однако среднее время ожидания, как и любая усредненная величина, – крайне обманчивая, я бы даже сказала коварная, вещь. (Думаю, вам сейчас, как и мне, вспомнился известный анекдот про среднюю температуру по больнице.) Уровень обслуживания (Service Level) – гораздо более объективный показатель. Понимание того, что 80 % вызовов получают ответ в течение 20 с, для вас гораздо более ценно, чем знание того, что средняя скорость ответа составляет 20 с. Если вы будете жестко придерживаться обязательств по уровню обслуживания, то о средней скорости ответа можете не беспокоиться – она всегда будет в норме. Подробнее об этом мы поговорим в главе 5.

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

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

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

Давайте посмотрим на следующем примере, как можно использовать профиль вызовов. Предположим, в течение дня он выглядит таким образом (табл. 3.1).

Средняя скорость ответа – меньше 30 секунд. Казалось бы, неплохо. Однако мы видим, что, хотя большинство вызовов (330 из 532) получили ответ в течение 15 секунд, 202 вызова, т. е. почти 38 %, ждали обслуживания гораздо дольше. Причем 15 % провели в очереди более 1,5 минуты! А самые стойкие 4 % прождали более 5 минут.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Методы, основанные на анализе хронологических данных за какой-то интервал времени, например за последние полчаса, оперируют такими показателями, как средняя скорость ответа, заданный уровень обслуживания и т. п. Давайте рассмотрим подробнее распространенный метод 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.

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

Из приведенного графика видно, что хотя метод, основанный на анализе оперативной ситуации, работает немного лучше, чем построенный на анализе хронологических данных (например, для 30-го вызова соотношение между предполагаемым и реальным временем ожидания составит 6,5 против 13 минут вместо 3 против 13 минут по методу ASA), все равно его точности не хватает для эффективного управления операторским центром.

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

• число работающих операторов;

• время обработки вызовов;

• частоту поступления вызовов с учетом их приоритетности;

• параметры потерянных вызовов (их количество и время, после которого абоненты вешают трубку, не дождавшись ответа);

• возможность постановки вызовов в очередь в несколько групп одновременно;

• возможность работы операторов в нескольких группах одновременно и др.

Давайте посмотрим теперь, что получится. Назовем такой комбинированный метод просто Expected Wait Time (EWT). На рисунке 3.6 показаны графики реального и предполагаемого времени ожидания, рассчитанного по методам ASA, OCW и EWT. Эти графики свидетельствуют о том, что метод, основанный на комбинированном анализе хронологических и оперативных данных, работает точнее всего.

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

И это вполне объяснимо. Пользуясь хронологическими методами расчета (типа ASA), вы можете понять, что у вас только что были проблемы. Пользуясь методами расчета на основе оперативных данных (типа OCW), вы можете понять, что у вас сейчас есть проблемы. Пользуясь комбинированным методом, вы можете понять, что у вас могут возникнуть проблемы. Ну а кто предупрежден, тот вооружен!

К сожалению, несмотря на высокую точность определения расчетного времени ожидания, а также на важность его использования для маршрутизации вызовов и оповещения абонентов, метод EWT имеет некоторые ограничения.

Так, его нецелесообразно использовать при малом числе вызовов (так как при этом время ожидания чаще всего просто равно нулю, ибо нет никакой очереди) и при малом числе операторов. EWT следует применять, когда одновременно работают не меньше 15, а еще лучше – 20 операторов. В противном случае пострадает точность расчета EWT. Во-первых, будет не хватать чисто статистической «пищи». Во-вторых, очень большое значение приобретут различные субъективные характеристики поведения как вызывающих абонентов, так и операторов.

Вообще, как и в любом статистическом методе, чем больше число работающих операторов, тем точнее рассчитывается предполагаемое время ожидания в очереди.

Кроме того, поскольку EWT определяется на основе как оперативной, так и хронологической информации, могут возникнуть трудности при первоначальном вводе системы в эксплуатацию или при добавлении новой операторской группы. Дело в том, что в этих случаях будет некоторое время «хромать» хронологическая составляющая, поскольку ей просто еще неоткуда взяться. Точно так же негативное влияние на точность показателя EWT будут оказывать крупные реорганизации операторских групп. Кстати, на эти обстоятельства следует обратить особое внимание, если для расчета предполагаемого времени ожидания вы пользуетесь хронологическими методами типа рассмотренного выше способа расчета на основе средней скорости ответа ASA.

Расчетное время ожидания может быть определено:

• на уровне каждого отдельного вызова;

• на уровне отдельной операторской группы.

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

Поясним нашу мысль. Предположим, есть две операторские группы: № 1 и № 2. Расчетное время ожидания для первой группы (EWT1) составляет 2 минуты, для второй (EWT2) – 1,5 минуты. Это означает, что если бы сейчас в группу № 1 поступил новый вызов, то он прождал бы ответа ее оператора 2 минуты. Соответственно, если бы вызов поступил в группу № 2, то он прождал бы 1,5 минуты.

Теперь предположим, что вызов, о котором мы столько говорили, наконец поступил. Какое у него будет расчетное время ожидания? Здесь возможны три варианта:

• если этот вызов может быть обслужен только операторами из группы № 1, то его расчетное время будет равно расчетному времени ожидания именно для этой группы, т. е. 2 минутам;

• если этот вызов может быть обслужен только операторами из группы № 2, то его расчетное время будет равно расчетному времени ожидания именно для этой группы, т. е. 1,5 минутам;

• если же этот вызов может быть обслужен операторами из обеих групп, то его расчетное время будет равно минимальному EWT для каждой группы. Таким образом, поскольку EWT2 < EWT1, то в качестве EWT вызова будет выбрано значение EWT2, т. е. 1,5 минуты.

Влиять на EWT вызова супервизор, естественно, не может, в то время как на EWT группы – вполне.

Начнем, как водится, с хорошего – с уменьшения EWT. На уменьшение расчетного времени ожидания могут влиять следующие факторы (некоторые из них вполне очевидны, а некоторые не очень):

• уменьшение числа вызовов в очереди;

• увеличение числа операторов;

• сокращение времени разговора;

• увеличение числа потерянных вызовов (на первый взгляд выглядит странно, но если немного подумать, то понятно);

• уменьшение доли вызовов с самым высоким уровнем приоритета;

• уменьшение числа вызовов, пропущенных операторами.

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

• увеличение числа вызовов в очереди;

• уменьшение числа операторов (по любой причине: кто-то вышел из системы, кто-то ушел на перерыв и т. п.);

• увеличение времени разговора;

• сокращение числа потерянных вызовов;

• увеличение доли вызовов с самым высоким уровнем приоритета;

• увеличение числа вызовов, пропущенных операторами.

Коротко о главном

• Основной принцип организации очереди – обрабатывать как можно большее число вызовов как можно меньшим числом операторов без ухудшения качества обслуживания и перегрузки сотрудников ЦОВ.

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

• В случае возникновения перегрузки лучше воспользоваться сигналом «занято», чем речевой почтой.

• При оценке эффективности обслуживания не следует полагаться на усредненные показатели типа средней скорости ответа ASA. Важно исследовать уровень обслуживания, максимальные задержки с ответом и профиль вызовов.