Оптимизация загрузки операторов мультиканального колл-центра +6



Как вы считаете, сколько обращений может одновременно обработать оператор современного колл центра: одно, два или может быть десять?

Если ваш ответ: «больше одного», то эта статья для вас. Из нее вы узнаете, как можно на практике решить задачу одновременной обработки нескольких обращений с помощью специального алгоритма обработки, известного как Agent Capacity Model (Загрузка оператора).



Одного обращения уже недостаточно

Обычный человек в типовой ситуации сконцентрирован на одной задаче. Разговор по телефону является хорошим подтверждением этого наблюдения. По такому же принципу построены стандартные процедуры обработки в КЦ: «одно обращение – один оператор».

Но новые типы обращений (e-mail, чат, мобильные приложения) не требуют полной концентрации, давая возможность выделить время для решения других задач. Рассмотрим чат сессию. Когда оператор участвует в чате с клиентом, он простаивает определенное время, ожидая ответа. Это время можно использовать более продуктивно. Например, дав ему возможность принять запрос в чате от другого клиента. Установлено, что квалифицированный оператор может участвовать одновременно в 2-3 чат-сессиях без ухудшения показателей качества обслуживания.

В теории проблем с загрузкой оператора нет. Но они возникают с реализацией ее на практике. Традиционная схема распределения вызовов, применяемая в большинстве платформ для колл центров (как зарубежных, так и отечественных), при распределении обращения на оператора переводит его в состояние «Занято/ Busy».



Рассмотрим типовую ситуацию: оператор отвечает на e-mail от клиента. Допустим, что в определенный момент времени в колл центр приходит телефонный запрос. Все операторы, отвечающие на телефонные запросы, заняты. Логично было бы в этой ситуации, чтобы не потерять вызов, направить его на оператора, обрабатывающего e-mail. Почему?

Дело в том, что обработка e-mail не требует ответа в реальном времени, в отличие от телефонного обращения. Традиционные схемы распределения не работают в этой ситуации, т.к. оператор находится в состоянии «Занят» и не может принять другое обращение.

В решении этих проблем может помочь концепция Rich Contact Experience (RCE), позволяющая создать единую среду общения между клиентами и КЦ. Отметим, что с помощью Rich Contact Experience можно обработать любое количество контактов по любым каналам. За счет чего?

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

Оптимизация загрузки оператора

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

Именно эти слова были выделены в начале статьи. Параметр «Agent Capacity» является ключевым для решения поставленной задачи.

«Agent Capacity» определяется, как максимальное количество обращений, которые оператор может обработать в единицу времени. Например, если один оператор может участвовать одновременно в 3 чат-сессиях, то показатель «Agent Capacity» равен 3. Допустим, что в данный момент времени оператор обслуживает один чат-запрос. В этом случае, оператор еще загружен не полностью и может принять еще 2 чат-обращения (поскольку в нашем примере «Agent Capacity» = 3).

Для обращений по телефону параметр «Agent Capacity» целесообразно принять равным 1, т.е. оператор может обрабатывать только одно обращение по телефону в единицу времени (что соответствует правилам, принятым в большинстве колл центров).



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

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



Для настройки правил вводятся два дополнительных параметра: Interruption matrix (матрица прерываний) и Max capacity vector (вектор максимальной загрузки).

Interruption matrix представляет из себя матрицу размером NxN, где N – количество типов обращений, которые обрабатывает колл центр (голос, e-mail, чат и т.п.). Каждый элемент матрицы image может быть равен значениям y (yes), n(no) или a (any). Это значит, что если обращение типа i может быть прервано обращением j, то используется значение y, если нет – то значение n. Значение a означает, что новое обращение может быть добавлено к текущему и обрабатываться параллельно.

В качестве примера рассмотрим матрицу INT и вектор MAX.

image


Матрица INT описывает взаимоотношения между тремя типами обращений: голос, e-mail, чат. Первая строка относится к голосу. Она означает, что голос не может быть прерван ни одним из типов обращений (включая другое голосовое обращение). Вторая строка описывает обработку e-mail. Ее параметры показывают, что e-mail может быть прерван голосом и чатом. Также, новый e-mail может быть добавлен к уже обрабатываемому. Третья строка показывает, что чат не может быть прерван голосом и e-mail. Также, как и e-mail, новый чат может быть добавлен к уже существующему.

image


Max capacity vector MAX задает максимальное количество обращений одного типа, которые оператор может одновременно обработать. В нашем примере установлены следующие значения: голос – 1, e-mail — 5, чат – 3.

Текущий статус оператора описывается матрицей AS размером NxM, где M – число контактов (клиентов), с которыми работает оператор в настоящее время, N – типы обращений. Рассмотрим пример:

image


Размер матрицы показывает, что оператор работает с двумя контактами. Первый контакт включает в себя только телефонное обращение. Второй контакт заключается в обработке e-mail и чат-сессию.

Модель Agent Capacity работает в виде процедуры, которая определяет, может ли оператор принять новый контакт или нет. Предположим, новый контакт включает в себя e-mail и чат, что определяется вектором С:

image


Чтобы решить, может ли оператор обработать новый контакт, выполняется следующая процедура:

1. Для каждого не равного нулю элемента вектора С, проверяется, может ли этот тип обращения прервать текущую работу оператора или быть добавлен к ней. Проверка делается с использованием interruption matrix и max capacity vector. Если выяснится, что работа оператора не может быть прервана, то оператор считается «недоступным».

2. Если все новые обращения могут прервать или быть добавлены к существующим: проверяется, чтобы новое число обращений не превысило максимальное количество, указанное в векторе MAX. Если это условие выполняется, оператор считается «готовым» для приема данного обращения. В противном случае – оператор считается «неготовым».

В нашем примере можно легко определить, может ли оператор принять обращение от нового контакта С. Оператор отвечает на телефонное обращение, поэтому он не будет прерван e-mail и чатом.

Приведем схему, поясняющую, как работает маршрутизация вызовов в случае использования параметра «Agent Capacity». Предположим, что все операторы имеют одинаковые interruption matrix и max capacity vector со значениями, как в примерах выше.



Клиент Вадим обращается в колл центр с чат-запросом. Все операторы уже обслуживают обращения от других клиентов. Оператор Ирина работает с голосовым обращением и e-mail от одного клиента. Согласно заданным в нашем примере правилам, голос не может быть прерван. Оператор Галина обслуживает 3-х клиентов в трех чат сессиях одновременно. Она не сможет обработать новый запрос от Вадима, т.к. в этом случае общее количество запросов (4) превысит максимальное значение, установленное для чат-обращений (3). Оператор Елена работает с клиентом, обрабатывая e-mail и чат обращение. С учетом сделанных настроек, именно она сможет принять запрос от нового клиента.

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

За распределение загрузки оператора отвечает ряд настроек, которые показаны на рис. ниже.



1-я колонка (Capacity share taken by each interaction) определяет, насколько загружен оператор при обработке каждого типа запросов. В данном примере голосовое обращение занимает 100% времени оператора (т.е. он может обработать только 1 голосовое обращение); чат: 30% (сможет одновременно участвовать в 3-х чат-сессиях); e-mail: 20% (может одновременно работать с 5 e-mail).

2-я колонка (Required spare capacity to receive interaction) определяет, насколько должен быть свободен оператор, чтобы принять данный вид обращения.

Например, для участия в новом чате оператор должен быть свободен минимум на 30% (иначе говоря, загружен на 70%). Это значит, что если он обрабатывает три чата (загрузка 90%=30+30+30) или e-mail + голос (загрузка 120%=20+100), то при новом чат-запросе, оператор не сможет его обработать: для чатов оператор свободен на 10% (100-90), для e-mail+голос полностью занят. А если оператор участвует в одной чат сессии и обрабатывает e-mail (загрузка 50%: 30+20), то он сможет ответить на чат-запрос, поскольку свободен на 50% (100-50).

Поэтому в нашем примере новый чат-запрос распределился на оператора Елену (чат+e-mail), а не на операторов Галину (участвует в чате) и Ирину (e-mail + голос).

3-я колонка (Precedence) определяет приоритет обработки обращений при распределении на оператора мультиканального колл центра. Если загрузка оператора позволяет ему обработать обращения нескольких типов, первым будет обработан запрос с более высоким приоритетом. Например, если поступят запросы на чат-сессию и e-mail, то на оператора Елена будет распределен чат, а e-mail встанет в очередь, т.к. чат имеет более высокий приоритет.

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

Выводы:

Реализация концепции Rich Contact Experience помогает решить две задачи:

1) сократить время обработки обращений и уменьшить число потерянных вызовов

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

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




К сожалению, не доступен сервер mySQL