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

Як ви вважаєте, скільки звернень може одночасно обробити оператор сучасного кол центру: одне, два або може бути десять?

Якщо ваша відповідь: «більше одного», то ця стаття для вас. З неї ви дізнаєтеся, як можна на практиці вирішити завдання одночасної обробки декількох звернень за допомогою спеціального алгоритму обробки, відомого як 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, чат тощо). Кожен елемент матриці може дорівнювати значенням y (yes), n (no) або a (any). Це означає, що якщо звернення типу i може бути перервано зверненням j, то використовується значення y, якщо немає - то значення n. Значення a означає, що нове звернення може бути додано до поточного і оброблятися паралельно.

Як приклад розглянемо матрицю INT і вектор MAX.

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

Max capacity vector MAX визначає максимальну кількість звернень одного типу, які оператор може одночасно обробити. У нашому прикладі встановлено такі значення: голос - 1, e-mail - 5, чат - 3.

Поточний статус оператора описується матрицею AS розміром NxM, де M - число контактів (клієнтів), з якими працює оператор в даний час, N - типи звернень. Розгляньмо приклад:

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

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

Щоб вирішити, чи може оператор обробити новий контакт, виконується наступна процедура:

1. Для кожного не рівного нуля елемента вектора C, перевіряється, чи може цей тип звернення перервати поточну роботу оператора або бути доданий до неї. Перевірка робиться з використанням 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).

Тому в нашому прикладі новий чат-запит розподілився на оператора Олену (чат + е-mail), а не на операторів Галину (бере участь у чаті) та Ірину (e-mail + голос).

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

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

Висновки:

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

1) скоротити час обробки звернень та зменшити кількість втрачених викликів

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

У результаті зростає ефект від застосування багатоканальності, як при роботі з сучасними каналами спілкування (голос, e-mail, чат, соц мережі, відео), так і при підключенні нових каналів у майбутньому.