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

Если применение идентификации по АОНу по каким-либо причинам невозможно, а персонализированное обслуживание на основе сегментации клиентов необходимо, то можно воспользоваться другим способом идентификации клиента, а именно на основе какого-либо цифрового набора, введенного самим вызывающим абонентом. Чаще всего в качестве такого цифрового набора выступает пара логин-пароль. Логином может служить как случайно выбранная системой комбинация цифр, так и какая-то более осмысленная информация, например номер кредитной карточки или страхового полиса клиента.

Не следует путать эту функцию с меню вызова, хотя и в том и в другом случае необходим тональный набор. Но если в первом случае осуществляется, как мы уже говорили, сегментация вызовов, то во втором действительно идет сегментация клиентов. Кроме того, при таком способе идентификации необходимы система интерактивного речевого взаимодействия Ineractive Voice Responce (IVR) и средства компьютерно-телефонной интеграции (CTI), о которых мы подробно поговорим в главе 7.

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

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

^{Рис. 4.7. Способы идентификации вызывающего абонента}

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

• Принцип распределения вызовов на основе квалификации операторов Skill Based Routing в настоящее время фактически стал индустриальным стандартом.

• При формировании групп по методу Skill Based Routing следует помнить, что чем больше группы, тем эффективнее обслуживание вызовов.

• Алгоритм выбора наиболее свободного оператора (Most Idle Agen) является универсальным. Алгоритм выбора наименее занятого оператора (Least Occupied Agent), хотя и позволяет сбалансировать нагрузку на операторов, владеющих разным числом профессиональных навыков, имеет довольно ограниченное применение.

• Главные правила эффективного использования принципа «первой линии обороны»: не менее 70 % вызовов должны обслуживаться операторами первого уровня; не должно быть эффекта «узкого горлышка широкой бутылки» на первом уровне; не должно быть длинной очереди к операторам второго уровня.

• Без грамотной политики сегментации клиентов невозможно эффективное обслуживание вызовов.

• Существуют три основных способа идентификации вызывающего абонента: по набранному номеру; по цифрам, введенным абонентом; на основании информации об абоненте, хранящейся в клиентской базе данных.

Прогностические методы маршрутизации

Вспомним наши рассуждения, приведенные в главе 3, о важности борьбы с перегрузками, о необходимости проактивных, а не реактивных действий. Единственная возможность проактивных действий заключается в использовании различных прогностических методов. Один из примеров таких методов – это расчет предполагаемого времени ожидания в очереди на основании одновременного анализа оперативных и хронологических данных (Expected Wait Time, EWT).

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

Предположим, что компания «Ваша пицца», занимающаяся доставкой пиццы на дом, имеет трех клиентов: конечно же, Иванова, Петрова и Сидорова. Сидоров, добродушный толстяк, обожающий пиццу, каждый день съедает 2–3 порции. Петров тоже любит вкусную лепешку, но заботится о фигуре и позволяет себе делать заказ не чаще чем раз в неделю. А Иванов – просто очень экономный и предпочитает тратить деньги на такое баловство, как поедание пиццы, всего лишь раз в месяц (и правильно делает!).

А теперь пойдем дальше и клонируем (благо наука это уже позволяет) нашу троицу. Таким образом, получаем три группы клиентов: Ивановых, Петровых и Сидоровых. В соответствии с тремя этими типами клиентов выделены три группы операторов: группа № 1 – самая большая, обслуживающая Сидоровых, и группы № 2 и № 3 – поменьше, обслуживающие, соответственно, Петровых и Ивановых.

Теперь представим обычный рабочий день в операторском центре компании «Ваша пицца». До 10:00 утра все идет нормально. Отчеты реального времени показывают, что очередей нет, а операторы отвечают на вызовы в среднем через 30 секунд.

Неожиданно в 10:00 возникает перегрузка в первой группе операторов (не иначе гурманы Сидоровы проснулись). Вызовы поступают быстрее, чем операторы могут на них ответить, абоненты отказываются ждать в очереди 2–3 минуты и вешают трубки. Менеджеры операторского центра вовремя отследили эту ситуацию, поэтому решили предпринять адекватные действия и перебросить операторов из группы № 2 в группу № 1. Мотивация их решения следующая: в группе № 2 в данный момент 15 операторов заняты обслуживанием вызовов, двое ушли на перерыв, трое находятся в режиме поствызывной обработки и четверо свободны. Вот трех из этих четырех операторов менеджеры и решили перебросить в группу № 1.

Такие действия немедленно дали положительный эффект: очередь в первую группу стала меньше. Однако не исчезла совсем. Прошло еще полчаса. Теперь возникли трудности с обслуживанием вызовов в группе № 2. Неплохо бы вернуть трех операторов, переброшенных в первую группу. Но как это сделать? Ведь они необходимы ей как воздух. А что, если во вторую группу перебросить операторов из третьей группы? Там, конечно, не наблюдается явного избытка операторов, но все же двух можно перевести. Но как долго они могут там оставаться? А если в это время проснутся все Ивановы и в группе № 3 тоже возникнет перегрузка?

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

Дело в том, что единственная на сегодня доступная стратегия оптимизации работы операторского центра – это борьба с проблемами после их возникновения, а не до. Конечно, можно попробовать бороться с пиковыми нагрузками и до того, как они появятся, но для этого придется специально держать некоторый избыток операторов, и тогда уровень обслуживания клиентов всегда будет на должном уровне, даже в часы пик. Но держать лишний штат операторов в расчете на пиковые нагрузки – очень дорогое и неэффективное решение. На Западе одной из самых значительных составляющих затрат на содержание операторского центра является труд операторов. Казалось бы, в России рабочая сила стоит значительно дешевле. Однако времена меняются, и труд квалифицированных сотрудников ценится все дороже: растет их зарплата, увеличиваются налоги, стоимость аренды помещения и обучения…

Наступает момент, когда выгоднее вложить средства в высококлассную технику и добиться улучшения сервиса не за счет увеличения числа операторов, а благодаря уникальным алгоритмам обслуживания. В качестве примера подобного инструмента рассмотрим решение Avaya™ Business Advocate («Адвокат»), основанное на следующих алгоритмах:

• автоматического перераспределения ресурсов (Service Level Supervisor);

• маршрутизации вызовов на основе прогнозируемого времени ожидания (Predicted Wait Time);

• маршрутизации вызовов на основе прогнозируемого времени ожидания с учетом уровня обслуживания (Service Objective).

Основное отличие методов «Адвокат» от стандартной маршрутизации на основе Skill Based Routing заключается в следующем:

• при использовании Skill Based Routing решение о маршрутизации вызова принимается в момент его поступления;

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

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

Алгоритм Service Level Supervisor позволяет автоматически перераспределять операторов в моменты пиковой нагрузки. Как только для какой-либо группы будет превышена заранее заданная пороговая величина расчетного времени ожидания, система автоматически введет в работу дополнительных, «резервных» операторов, а по мере исчезновения в этом надобности выведет их из этой группы. Таким образом, система автоматически адаптируется к изменениям оперативной обстановки, особенно к неожиданному нарастанию трафика и возникновению пиковых нагрузок.

Чтобы увеличить гибкость системы, можно для каждого типа вызовов установить два пороговых значения времени ожидания (либо расчетного Expected Wait Time, либо реального – по желанию пользователя). Соответственно, назначаются две группы резервных операторов: резерв № 1 и резерв № 2. При достижении первого порога активизируется резерв № 1, при достижении второго – резерв № 2.

Более того, предусмотрена возможность динамического изменения пороговых значений EWT в автоматическом режиме в зависимости от значений уровня обслуживания. Представьте себе, что он равен 90:30, т. е. 90 % вызовов должны получить ответ в течение 30 с. При этом пороговое значение EWT установлено на уровне 20 с. Если реальные показатели обслуживания становятся лучше, например 94:30, то пороговое значение EWT увеличивается до 24 с. И наоборот, если уровень обслуживания падает, например, до 84:30, то и пороговое значение EWT уменьшается до, скажем, 14 с (рис. 4.8).

^{Рис. 4.8. Динамическое изменение пороговых значений EWT в зависимости от уровня обслуживания}

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

Теперь почувствуйте разницу между стандартным методом Skill Based Routing и методом резервных операторов, предлагаемым «Адвокатом». При использовании обычного Skill Based Routing операторы будут вовлекаться в процесс обслуживания вызовов в соответствии с уровнями владения квалификационными навыками. А именно: если оператор Петя знает английский хуже, чем Вася, но поступил английский вызов, а Вася занят, то Петя, хочешь не хочешь, должен подключиться к его обслуживанию.

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

Кстати, таким образом, используя «Адвокат», можно разгружать высококвалифицированных операторов, которые в этом случае будут способны:

1) выполнять функции супервизора небольшой группы;

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

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

В основу данного метода маршрутизации положен мощный прогностический алгоритм, оперирующий понятием «прогнозируемое время ожидания» (Predicted Wait Time, PWT). «Что за чертовщина? – наверняка сейчас воскликнули вы. – Расчетное время ожидания, прогнозируемое время ожидания – какая разница-то?» Не торопитесь, сейчас попытаюсь объяснить.

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

Таким образом, PWT – это общее время ожидания, складывающееся из:

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

• возможного времени ожидания после освобождения оператора, если он не ответит на этот вызов (рис. 4.9).

^{Рис. 4.9. Прогнозируемое время ожидания, PWT}

Или, иными словами:

PWT = Текущее время ожидания + Возможное время ожидания в случае неответа оператора.

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

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

1) EWT прогнозирует время ожидания до освобождения оператора, а PWT – общее время ожидания, включая и возможное время после освобождения оператора, если он не ответит на этот вызов;

2) EWT не меняет принцип формирования очереди «первым пришел – первым обслужен» (First In – First Out, сокращенно FIFO), в то время как PWT может обслужить вызов в обход этого принципа.

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

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

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

А как же прогнозируемое время ожидания? Оно ведь никак не учитывает политику компании в области сегментации клиентов, и если значение PWT будет больше для вызова, поступившего от Иванова, то именно этот вызов и будет обслужен в первую очередь, несмотря на всю ценность толстого Сидорова. Что делать? Ответ напрашивается сам собой: усложнить алгоритм прогнозирования и постараться учитывать ценность вызова. Для этого назначим для каждого его типа желаемое время ответа (Delay Level). Затем введем коэффициент Service Objective, показывающий отклонение прогнозируемого времени ожидания (PWT) от желаемого времени ответа (Delay Level).

Коэффициент Service Objective определяется по формуле:

Service Objective = PWT ÷ Delay Level

Когда оператор, входящий в несколько групп, освобождается, к нему поступает вызов с наибольшим значением коэффициента Service Objective. Иначе говоря, система сначала определяет прогнозируемое время ожидания, а затем сравнивает его с заданным для этого вида вызовов желаемым временем ответа. В результате выбирается вызов с наибольшим отклонением прогнозируемого времени ожидания от желаемого времени ответа.

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

А при грамотной политике сегментации клиентов (о важности которой мы уже не раз говорили) с учетом прогнозируемого времени ожидания и ценности вызова никто не будет в обиде: ни худые Ивановы с Петровыми, ни гурманы Сидоровы, ни операторы, ни, само собой, компания.

Предположим, в очереди стоят три вызова от трех разных категорий клиентов: № 1, № 2 и № 3. Первый вызов ждет в очереди 20 секунд, второй – 25 секунд и третий – 10 секунд. Освобождается оператор. Какой вызов ему поступит?

Без использования логики «Адвоката», конечно же, в первую очередь будет обслужен вызов № 2. Причина: вызов № 2 дольше всех провел в очереди в ожидании обслуживания (табл. 4.10).

_{Таблица 4.10. Выбор вызова без «Адвоката»}

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

_{Таблица 4.11. Выбор вызова с «Адвокатом» по алгоритму «Прогнозируемое время ожидания»}

Предположим, что если освободившийся оператор не ответит на данный вызов, то клиент № 1 прождет еще 40 секунд, № 2–5 секунд и № 3 – 35 секунд. Таким образом, для первого вызова PWT составит 20 + 40 = 60 секунд, для второго 25 + 5 = 30 секунд и для третьего 10 + 35 = 45 секунд.

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

А теперь давайте назначим для каждого вызова желаемое время ответа и в каждом случае определим коэффициент отклонения прогнозируемого времени ожидания от желаемого времени ответа. Для вызова № 1 Service Objective составит 60: 35 = 1,71, для вызова № 2 – 30: 20 = 1,5 и для вызова № 3 – 45: 25 = 1,8 (табл. 4.12).

В результате выбирается вызов (№ 3) с наибольшим отклонением прогнозируемого времени ожидания от желаемого времени ответа. Иначе говоря, несмотря на то что текущее время ожидания у выбранного вызова № 3 самое маленькое (10 секунд), этот вызов будет обслужен в первую очередь. Никогда бы не пришло в голову, правда?

_{Таблица 4.12. Выбор вызова с «Адвокатом» по алгоритму «Уровень обслуживания»}

Видите, как разные подходы к маршрутизации меняют саму логику обслуживания вызовов?

Основное отличие прогностических методов маршрутизации от обычных заключается в следующем.

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

^{Рис. 4.10. Сравнение стандартных и прогностических методов маршрутизации}

Именно из этого основополагающего отличия и вытекают все преимущества прогностических методов маршрутизации:

• возможность эффективной сегментации клиентов. Простой пример: обычно компания может предоставить своим, скажем, «золотым» абонентам привилегированное обслуживание по сравнению с «серебряными» путем простой приоритизации вызовов. Однако часто приходится сталкиваться с дилеммой: если «серебряный» вызов уже ожидает в очереди несколько минут, должен ли вновь поступивший «золотой» сразу направляться в начало очереди? Благодаря «Адвокату» эта дилемма легко разрешается: наиболее важные для компании вызовы будут получать ответ в первую очередь, однако и другим группам клиентов окажут должное внимание в соответствии с установленным для них уровнем обслуживания;

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

• наиболее эффективное обслуживание каждого конкретного вызова;

• наиболее эффективное использование операторских ресурсов; повышение эффективности обслуживания разных типов вызовов: сокращение максимальной задержки при ответе на вызовы;

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

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

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

Правда, все эти преимущества прогностических методов проявляются только в очень больших Центрах обслуживания вызовов с ярко выраженной сегментацией клиентов. Если число операторов не превышает 100 человек, то этим алгоритмам просто не хватает «статистической пищи» для эффективной работы. Чем крупнее колл-центр и чем четче политика сегментации клиентов, тем эффективнее работают прогностические алгоритмы и тем оправданнее их применение. На мой взгляд, думать об алгоритмах типа «Адвокат» следует, когда число операторов превышает 300–400 человек.