• система записи вызовов.
Только грамотное использование возможностей обеих этих систем позволит вам эффективно управлять Центром обслуживания вызовов – как с точки зрения эффективности, так и с точки зрения качества.
Мониторинг производительности с помощью системы отчетности и управления
Половину успеха ЦОВ обеспечивает развитая система отчетности. И чем больше у нее возможностей, тем лучше, поскольку управляющий персонал операторского центра сможет с ее помощью влиять на кратковременные и долговременные показатели эффективности.
Увеличение потока вызовов вследствие объявленной рекламной кампании, изменение состава вызовов из-за меняющихся клиентских предпочтений или сезонных колебаний, изменение числа и квалификации операторов (треть ушла в декрет, треть болеет гриппом) и т. д. и т. п. – все это оказывает самое непосредственное влияние на производительность Центра обслуживания вызовов.
Для того чтобы адекватно реагировать на такого рода изменения, управляющий персонал ЦОВ должен иметь эффективную обратную связь. В этом случае становится возможным не только отслеживать происходящие перемены, но и принимать адекватные решения по перенастройке операторского центра: начиная с изменения состава операторских групп в «горячем» режиме и заканчивая разработкой новых алгоритмов обслуживания.
В книге Анджея Уэйта «Практическое руководство по технологии Центра обслуживания вызовов» (Andrew J. Waite, A Practical Guide to Call Center Technology) приводятся слова Норриса Таппа – одного из сотрудников операторского центра, сказанные еще в 1979 году: «Если ты не можешь это измерить, ты не можешь этим управлять». Лучше, по-моему, о значимости системы мониторинга и не скажешь.
Каким качествам должна отвечать современная система мониторинга? На мой взгляд, в ней должны быть предусмотрены следующие возможности:
• формирования отчетов реального времени для оперативного управления;
• формирования хронологических (или исторических, или накопленных) отчетов для аналитической работы;
• администрирования операторского центра как в «холодном», так и в «горячем» режимах;
• создания пользовательских отчетов (как реального времени, так и хронологических). В эти отчеты вы можете включить только те данные и в том порядке, которые кажутся вам необходимыми именно для вашего операторского центра. При этом возможность создания пользовательских отчетов не снижает потребность в достаточно широком наборе стандартных отчетов;
• кроме того, должен быть предусмотрен дружелюбный графический интерфейс пользователя.
Хотелось бы немного подробнее остановиться на последних двух пунктах и поговорить об удобном интерфейсе, о степени гибкости системы мониторинга и о соотношении числа стандартных и пользовательских (настраиваемых) отчетов.
Возможно, вас удивит мое мнение, но я считаю, что излишняя гибкость и настраиваемость системе отчетности только вредят. Центр обслуживания вызовов – это все-таки не Центр управления полетами: параметров для мониторинга производительности и принятия управленческих решений не так много. Главное – выбрать основные показатели производительности, на которые вы будете ориентироваться (мы подробно говорили об этом в главе 5), остановиться на нескольких стандартных и нескольких пользовательских, настроенных лично под вас, отчетах – и большего не надо. Интерфейс должен быть простым и удобным. Когда же в системе предусмотрена чрезмерная гибкость, появляется необходимость чуть ли не в программисте, чтобы ее настроить.
Для обеспечения наиболее полного представления о производительности операторского центра необходимо оперировать отчетами (хронологическими и реального времени) на следующих уровнях:
• операторских групп и очередей;
• операторов;
• точек входа в систему;
• соединительных линий.
Разные производители используют разные наборы отчетов, но перечисленные уровни являются общими для большинства из них. Иногда бывает полезным посмотреть отчеты на уровне вызова, но это скорее декоративный, нежели необходимый элемент.
Хотелось бы пояснить, в чем разница между отчетами на уровне операторских групп и очередей и отчетами на уровне точек входа в систему. В зависимости от того, на какую точку входа поступит вызов, выбирается алгоритм его обслуживания. Точка входа в операторский центр чаще всего представляет собой виртуальный внутренний номер коммутатора, физически не закрепленный ни за каким оборудованием. Так как она является обычным внутренним номером коммутатора, то и доступ к ней может осуществляться практически любым способом, предусмотренным для внутренних номеров.
Как только вызов достигает точки входа, начинается его обработка: вызывающий абонент слышит приветствие, а система определяет, по какому маршруту этот вызов направить. После того как решение будет принято, звонок поступает к соответствующей группе операторов. Если в группе находится свободный сотрудник, вызов сразу направляется к нему, в противном случае – встает в очередь. Иными словами, принципиальным моментом является то, что очередей на уровне точки входа в операторский центр нет, – они образуются на уровне операторских групп. Тем не менее отчеты на уровне точек входа очень важны, так как позволяют оценить все время, потраченное на обслуживание вызова, включая и то, когда абонент слышит входное приветствие, а также определить, сколько вызовов теряется еще во время воспроизведения приветствия (вспомните пример из главы 3).
Отчеты реального времени
С помощью отчетов реального времени менеджеры разного уровня могут принимать оперативные, тактические решения по управлению операторским центром. Например, при обнаружении перегрузки в одной группе операторов супервизор может мгновенно перебросить в нее операторов из другой группы. Благодаря отчетности подобного типа вы можете держать руку на пульсе операторского центра: он весь будет у вас как на ладони.
Отчеты реального времени должны обновляться не реже чем раз в 3–5 с (в противном случае они будут уже «не очень реального времени»). Кроме того, как это ни странно на первый взгляд, в этих отчетах должны содержаться некоторые хронологические данные, накопленные, например, за последние полчаса. Это очень удобно, поскольку дает возможность одновременно видеть настоящее и прошлое операторского центра и понимать, как влияют принятые оперативные решения на более долговременные задачи.
Пользу от отчетов реального времени на уровне операторских групп и очередей трудно переоценить. Вот лишь некоторые параметры, которые благодаря им можно увидеть:
• статус каждого оператора, входящего в состав конкретной группы;
• число обслуженных и потерянных вызовов;
• время ожидания в очереди самого раннего вызова;
• общее число вызовов в очереди;
• расчетное время ожидания;
• распределение вызовов по временным интервалам (профиль вызова); например, можно определить, сколько вызовов было обслужено и потеряно в течение 10–15 секунд после постановки в очередь, сколько – в течение следующих 10–15 секунд и т. д.;
• процент вызовов, обслуженных с заданным уровнем производительности, и т. д.
Давайте подробнее рассмотрим два наиболее удобных и полезных отчета реального времени на примере системы отчетности Avaya™ Call Management System (CMS).
Отчет на уровне операторской группы
Это очень удобный для мониторинга и важный для принятия оперативных управленческих решений отчет, пример которого представлен на рисунке 6.1.
Рис. 6.1. Пример отчета реального времени на уровне операторской группы
С левой стороны рисунка мы видим список всех операторов, входящих в данную группу. Слева и справа от имени оператора обозначен статус, в котором он пребывает в настоящий момент:
«свободен» (Available) – оператор готов к приему вызова;
«обслуживает вызов» (ACD) – оператор обслуживает вызов;
«поствызывная работа» (After Call Work) – оператор находится на рабочем месте, но не может принимать вызовы, поскольку выполняет другой вид работы;
«перерыв» (Auxilary) – оператор не может принимать вызовы, поскольку ушел на перерыв.
Слева – пиктограмма статуса: например, снятая трубка телефона означает, что оператор занят разговором с абонентом, чашка кофе – оператор ушел на перерыв. Справа – буквенное обозначение статуса. Следующая колонка показывает время, в течение которого оператор пребывает в данном состоянии.
В верхней части правой стороны рисунка находится, в принципе, та же информация, только в сжатом графическом виде (это может быть круг или гистограмма). Каждый сектор гистограммы соответствует определенному статусу оператора, а цифры отражают число операторов, пребывающих в данном статусе. Например, розовый сектор соответствует состоянию перерыва. Если супервизор кликнет по нему мышкой, то он увидит список всех операторов, находящихся на перерыве, причем с указанием его причины (обед, обучение, «ушла на базу» и т. п.).
Кстати, такой возможностью супервизоры могут воспользоваться, если в операторском центре в целом или в одной из его групп возникла перегрузка (или только ее угроза). Увидев, например, что трое из десяти отсутствующих на рабочем месте операторов ушли на кратковременный перерыв, супервизор может немного успокоиться: через две-три минуты сотрудники вернутся, и ситуация разрядится. А вот если все 10 человек одновременно ушли на обед, дела обстоят хуже: надо подключиться самому, а потом подкорректировать расписание перерывов, чтобы впредь не допускать возникновения подобной ситуации.
В нижней части правой стороны рисунка показана смесь оперативных данных и хронологических, накопленных от начала очередного получаса. К данным реального времени относятся: число вызовов в очереди (3) и время, которое ожидает в очереди самый ранний вызов (15 секунд).
Теперь посмотрим на хронологические данные. Мы видим, что с заданной скоростью ответа было обслужено всего 11 % вызовов («% Within Service Level»), средняя скорость ответа составляет 50 секунд. Всего от начала текущего получаса было обслужено 8 вызовов и ни одного не потеряно. Среднее время разговора составило 3 минуты 18 секунд. Судя по данным, супервизору этой группы надо немедленно вмешаться и отрегулировать процесс обслуживания вызовов.
Как видите, этот отчет, с одной стороны, не содержит ничего лишнего, а с другой – дает значимый набор важнейших данных, чтобы осуществлять оперативное управление.
Хочу обратить ваше внимание на то, что показатели, которые превышают заранее заданные пороговые значения, отмечены желтым и красным цветом. Желтый означает, что данные показатели превышают нормальный уровень и супервизору следует обратить на них внимание, а красный – что эти показатели превысили критическое значение, и супервизору надо немедленно вмешаться, чтобы исправить ситуацию. Например, на рисунке 6.1 желтым цветом отмечено время ожидания в очереди самого раннего вызова – 15 секунд. А вот чрезвычайно низкий уровень обслуживания – всего 11 % – отмечен уже тревожным красным цветом: совершенно очевидно, что необходимо срочное вмешательство супервизора.
Интегрированный отчет на уровне нескольких операторских групп
Помимо отчета на уровне одной операторской группы очень важно использовать отчеты на уровне всех или хотя бы нескольких операторских групп. Это даст вам возможность видеть состояние дел в Центре обслуживания вызовов в целом. Отчеты на уровне отдельных групп используют в основном супервизоры, а интегрированные отчеты – менеджеры более высокого звена. Пример отчета на уровне всего ЦОВ в целом показан на рисунке 6.2.
Рис. 6.2. Пример интегрированного отчета на уровне всего ЦОВ
Этот отчет интересен тем, что помимо оперативных данных содержит постоянно обновляемые хронологические данные за текущие сутки.
Например, три первые (после названия операторских групп) столбца показывают оперативные данные о количестве операторов в данной группе, числе вызовов в очереди и времени ожидания самого раннего вызова. А вот следующие шесть столбцов уже показывают данные, накопленные за сутки к данному моменту и регулярно (раз в несколько секунд) обновляющиеся. Для каждой группы показываются:
• число обслуженных вызовов (ACD Calls);
• среднее время разговора (Average ACD Time);
• число потерянных вызовов (Abandoned Calls);
• среднее время, после которого абонент вешает трубку, не дождавшись ответа (Average Abandoned Time);
• средняя скорость ответа (Average Speed of Answer);
• уровень обслуживания (Service Level).
Это самый любимый мой отчет, и у меня на компьютере он открыт всегда.
Хронологические отчеты
В отличие от отчетов реального времени, позволяющих решать сиюминутные тактические задачи, хронологические отчеты дают возможность решать долгосрочные стратегические задачи по повышению эффективности работы операторского центра. Например, с помощью анализа подобных отчетов можно определить наилучший способ организации приема и обслуживания вызовов, оптимальное количество сотрудников в каждом подразделении с учетом степени их квалификации, оптимальное число соединительных линий и многое другое.
Желательно, чтобы хронологические отчеты обновлялись с получасовым интервалом (т. е. каждые полчаса данные из отчетов реального времени преобразовывались в хронологическую форму). 15-минутный интервал дает слишком мелкое дробление данных и перегружает отчетность, а часовой малоинформативен для последующей аналитики и принятия управленческих решений.
Желательно также, чтобы данные могли суммироваться по интервалам, дням, неделям и месяцам. Это очень удобно для дальнейшей аналитической работы. Хочется также заметить, что, несмотря на обилие стандартных и пользовательских отчетов, не стоит пренебрегать возможностью экспорта данных в Excel. Перенеся отчетные данные в таблицы, сделанные в этой программе, вы получите неограниченные возможности для их комплексной обработки и всестороннего анализа.
Хронологические отчеты на уровне операторских групп и очередей
Хронологические отчеты на уровне групп и очередей дают обильную пищу для анализа производительности операторского центра. Так, они содержат как минимум следующие данные:
• число обслуженных и потерянных вызовов;
• процент вызовов, обслуженных с заданным уровнем производительности;
• средняя скорость ответа, среднее время разговора, среднее время поствызывной обработки;
• максимальная задержка при ответе на вызов;
• данные о производительности каждого оператора, входящего в данную операторскую группу;
• распределение вызовов по временным интервалам (профиль вызова); например, можно определить, сколько вызовов было обслужено и потеряно в течение 10–15 секунд после постановки в очередь, сколько – в течение следующих 10–15 секунд и т. д.
Давайте остановимся немного подробнее на некоторых из возможных хронологических отчетов на уровне операторской группы. Мы не будем здесь рассматривать достаточно очевидные показатели типа числа обслуженных и пропущенных вызовов и т. п. Попытаемся лучше провести некоторый, пусть минимальный, анализ на основании таких, например, данных, как показатели скорости ответа на вызовы.
В таблице 6.1 приведены данные о производительности процесса обслуживания вызовов, накопленные за одну неделю.
Таблица 6.1. Пример хронологического отчета на уровне группы
Если взять только один столбец, а именно – среднюю скорость ответа, то ее значения выглядят вполне удовлетворительно: 9–15 секунд – отличный показатель ASA. Если же взглянуть на следующий столбец – уровень обслуживания, то радужная картинка несколько померкнет. Если в понедельник, 2 февраля 2009 года, уровень обслуживания составил 88 %, то к пятнице, 6 февраля 2009 года, он упал до 69 %. Понятно, что стоит обратить внимание на причины, вызвавшие столь негативные изменения.
Пойдем дальше. Четвертый столбец показывает процент вызовов, ожидавших ответа оператора более полутора минут. Как видим, по сравнению с понедельником число таких вызовов возросло почти в 5 раз. И наконец, последний столбец, показывающий максимальную задержку при ответе на вызов, дает еще одно подтверждение выявленной тенденции ухудшения качества обслуживания: если в понедельник максимальная задержка с ответом составляла менее двух минут, то в пятницу она вплотную приблизилась к семи минутам, что очень много.
Итак, обнаружилась негативная тенденция. Следующие наши действия могут быть примерно такими:
1) необходимо проанализировать данные за другие несколько недель. Если в течение этого периода наблюдалась такая же картина ухудшения качества обслуживания по мере продвижения от понедельника к пятнице, значит, тенденция носит не частный, а общий характер и требует более пристального внимания;
2) необходимо проанализировать, чем объясняется подобное ухудшение качества обслуживания. Это может быть вызвано всего двумя причинами (или их комбинацией): объективной, а именно – ростом нагрузки, т. е. увеличением числа и длительности звонков, и субъективной, а именно – усталостью операторов в конце недели, и отсюда – снижением скорости ответа, невнимательностью, замедлением реакции, увеличением длительности разговора и поствызывной обработки;
3) в случае объективной причины ухудшения качества обслуживания необходимо проанализировать, чем вызвано такое увеличение нагрузки.
Если это разовый всплеск, случайный или, например, обусловленный проведением рекламной кампании, то надо постараться улучшить оперативное наблюдение за операторским центром в целом или за данной конкретной группой. Ведь именно при пиковых нагрузках так важны качественный мониторинг и управление в режиме реального времени. Если же выявится устойчивая тенденция роста нагрузки к концу недели, следует обратить внимание на график работы операторов и увеличить число сотрудников в четверг и особенно в пятницу;