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

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

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

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

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

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

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

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

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

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

Рис. 4.9.Прогнозируемое время ожидания, 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. Иначе говоря, система сначала определяет прогнозируемое время ожидания, а затем сравнивает его с заданным для этого вида вызовов желаемым временем ответа. В результате выбирается вызов с наибольшим отклонением прогнозируемого времени ожидания от желаемого времени ответа.

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

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

Предположим, в очереди стоят три вызова от трех разных категорий клиентов: № 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).