- Головна
- /
- Стаття
Розумію маршрутизацію та чергування в Webex Contact Center
Ця стаття дає огляд того, як Webex Contact Center обробляє та спрямовує вхідніn взаємодії до агентів. Вона охоплює різні типи черг, такі як навики таn не орієнтовані на навики, а також методи маршрутизації, такі як Longest Available, Circular і Best Available.rn Також пояснюється діяльність потоку, які допомагають адміністраторам керувати взаємодіями, призначати агентів, контролювати/n контролювати потік дзвінків і отримувати оновлення черги в реальному часі для покращення операцій і досвіду клієнтів/клієнтівn .
Черга
Огляд
У Webex Contact Center черга слугує зоною утримання для вхідних взаємодій, таких як телефонія, чат, електронна пошта чи соціальні мережі. Контакти залишаються в чергах, доки їх автоматично не розповсюджують агентам або агенти вручну забирають їх для обробки. Крім того, вони підтримують такі функції, як маршрутизація на основі навичок, управління пріоритетами та справедливий розподіл навантаження.
Керівники можуть використовувати черги, щоб спостерігати за різними напрямками роботи та покращувати виконання завдань у контакт-центрі.
Деякі з ключових переваг ефективного використання черг такі:
- Кращий досвід клієнтів: Керуйте часом очікування та повідомляйте клієнтам, що вони в черзі на допомогу.
- Підвищення ефективності: Переконайтеся, що дзвінки обробляються впорядковано, зменшуючи хаос і неправильне управління.
- Справедливий розподіл контактів: Рівномірно розподіляйте дзвінки між агентами, щоб уникнути перевантаження окремого агента.
- Пріоритетне оброблення: Дозвольте пріоритетно розраховувати на певні дзвінки, такі як VIP-клієнти або термінові питання.
Типи черг
Webex Contact Center підтримує кілька типів черг, які дозволяють широкий спектр кейсів використання для контакт-центрів будь-якого розміру та складності на всіх типах медіа з уніфікованими можливостями.
Є черги, які враховують навички агента у маршрутизації контактів, і черги, які цього не роблять. Ці черги також відрізняються тим, як агенти асоціюються з ними для роботи з контактами.
Існує дві основні категорії черг:
- Черги, що не залежать від навичок
- Черги на основі навичок
Черги, що не залежать від навичок
Черги, що не пов'язані з навичками, не враховують навички, пов'язані з агентами. Ви можете налаштувати черги, не пов'язані з навичками, за такими опціями:
- Призначення команд
- Призначення агентів
Черги без навичок з командним призначенням
У чергах, не пов'язаних із навичками, з призначенням команд можна організувати агентів у команди та об'єднати їх для створення груп розподілу дзвінків (CDG). Ви можете встановити часову затримку між кожною групою для керування потоком дзвінків.
Групи розподілу дзвінків допомагають визначити кілька рівнів агентів, які стають придатними для роботи з контактами в цій черзі протягом визначених проміжків часу. Контакти призначаються агентам залежно від рівня їхньої команди. Якщо агентів немає, контакти залишаються на заздалегідь визначений час, перш ніж розширити їх до наступної групи команд. Цей процес триває, доки не з'явиться агент або всі групи не будуть перевірені.
Ви можете створити такі типи команд:
- Окремі команди: Агенти можуть бути організовані у команди, які можуть представляти конкретну організаційну функцію, а потім вони можуть стати частиною черг, щоб контакти можна було перенаправляти до агентів у цих командах. Ви можете позначати агента на кілька команд для обробки контактів із різних черг для ефективної маршрутизації.
- Команди на основі ємності: Команда на основі ємності (CBT) — це функція, яка направляє голосові дзвінки на прямий номер (DN), що залежить від пропускної здатності, де пропускна здатність визначає, скільки дзвінків можна обробляти одночасно. Він дозволяє маршрутизувати дзвінки на номери телефонів без необхідності входу агентів у систему, що робить його придатним для випадків, коли дзвінки приймаються голосовою поштою, автовідповідачами або групами полювання, а не традиційними агентами кол-центру. У цій схемі немає конкретних агентів, призначених до команди, і вони не використовують Webex Contact Center Agent Desktop.
У цьому прикладі є три групи розподілу дзвінків, які дозволяють розширювати цілі, тобто розширювати більше агентів у командах протягом визначених часових інтервалів.
Перша група розподілу дзвінків містить TEAM 1, яка має 3 налаштовані агенти – A1, A2 та A5.
Друга група розподілу дзвінків містить TEAM 2, яка має 3 налаштованих агентів – A2, A3 та A4.
Третя (і остання) група розподілу дзвінків містить TEAM 3, яка має 2 налаштованих агентів – A6 та A7.
Коли контакт ставиться в чергу, система спочатку шукає відповідного агента в першій групі розподілу дзвінків. Якщо агентів не знайдено, контакт залишається на визначений час перед розширенням цільової групи до наступної групи. Це додає нові команди до існуючих. Цей процес повторюється, доки не знайде відповідність або всі групи не розширюються.
Можливість «Check Agent Availability» миттєво розширює контакт до наступної групи розподілу дзвінків, якщо в поточній групі немає відповідних агентів. Це можна увімкнути в активності Контакт у черзі <LINK TO розділ 3.1.1> у потоці.
Така схема призводить до наступних сценаріїв:
- A2 належить КОМАНДІ 1 і КОМАНДІ 2. Якщо A2 обирає TEAM 1 для входу в Agent Desktop, система вважає A2 частиною TEAM 1, а отже, лише першою групою розподілу дзвінків.
- A5 належить до TEAM 1, однак міг бути частиною іншої команди організації, до якої вони зараз увійшли. Тому A5 не вважається частиною TEAM 1 і не пов'язана з цією чергою.
Черги з призначенням команд надають потужну можливість агентам переміщатися між чергами, просто обираючи команду під час входу.
Доступний шаблон маршрутизації:
Черги без навичок із призначенням агентів
Черги, що не пов'язані з навичками, — це тип черги, де пул агентів безпосередньо призначається черзі. На відміну від інших типів черг, які опосередковано визначають пул призначених їм агентів, ці черги дозволяють адміністраторам обирати агентів безпосередньо та вручну. Наприклад, командні черги призначення призначають агентів на основі їхніх увійдених команд, а черги призначення на основі навичок співставляють агентів відповідно до необхідних навичок. Натомість адміністратори можуть безпосередньо додавати агентів до цих черг, щоб вони стали частиною черги. Це забезпечує простий спосіб управління розподілом агентів без покладання на системні призначення.
Черги з призначенням агентів забезпечують прості, але ефективні алгоритми маршрутизації, які допомагають розподіляти контакти серед пулу агентів. Вони не враховують навички агентів у маршрутизації контактів. Однак агентів можна впорядковувати в межах кожної черги, і це враховується при маршрутизації контактів до них. У цьому контексті команди насамперед слугують організаційною структурою для керівників, а не фактором у прийнятті рішень про асоціацію між агентами і чергою та маршрутизації контактів, що спрощує управління чергою.
Цей тип черги найкраще підходить там, де статичне призначення агентів і управління асоціацією агент-черга є можливим і бажаним для операційного контролю, а вибір алгоритмів маршрутизації підходить для розподілу роботи між агентами. Ці черги також особливо корисні у ситуаціях, коли різні типи запитів клієнтів потребують спеціалізованої експертизи, яку може обслуговувати заздалегідь сформований сегмент експертних агентів.
Однак складним організаціям контакт-центрів може бути складно ручно керувати призначенням агентів у цих чергах. Вони могли б більше виграти від інших типів черг, які пропонують динамічну маршрутизацію та асоціації агент-черга.
У цьому прикладі черга має набір агентів, відображених у певному порядку, таких як A4, A9, A7 тощо. Цей порядок відіграє роль у спеціалізованих алгоритмах маршрутизації, які співвідносять вхідні контакти з агентами. Система співвідносить контакти з цими агентами на основі їх доступності та обраного алгоритму маршрутизації.
На відміну від черг із призначенням команд, тут немає концепції розширення цілі за часові інтервали. Якщо жоден із налаштованих агентів не доступний для маршрутизації цього контакту, він залишається в черзі, доки один із цих агентів не стане доступним для обробки контактів до тайм-ауту паркування. Цільове розширення не застосовується до цих черг.
Доступні шаблони маршрутизації:
Черги на основі навичок
Черги, засновані на навичках, дають можливість направляти контакти до агентів із відповідними навичками, що відповідають їхнім потребам.
Ви можете налаштувати такі типи навичок на основі навичок:
Критерії навичок, призначені для черги
Адміністратори можуть призначати критерії навичок чергам. Черги на основі навичок з критеріями навичок дозволяють адміністраторам налаштовувати необхідні навички безпосередньо в черзі. Усі агенти організації, які мають усі необхідні навички черги через прямий профіль навичок, неявно стають частиною цієї черги.
Ця система допомагає адміністраторам мати живий перегляд агентів, які відображаються в черзі завдяки навичкам. У випадках, таких як великий обсяг або малий обсяг, адміністратори можуть розглянути можливість коригування необхідних навичок черги та профілів навичок агентів, щоб розширити або скоротити пул агентів залежно від потреби.
Цей тип черги відрізняється від черг на основі призначення команд тим, що немає налаштування групи розподілу дзвінків, тобто команда не відіграє ролі в асоціації між агентом і чергою. Крім того, потрібні навички статично налаштовані в цій черзі, на відміну від командних черг навичок, де потік вводить (статичні або змінні) необхідні навички. Отже, технічно навички є частиною черги, а не самого контакту.
Будь-який агент в організації, який повністю відповідає критеріям навичок черги (маючи навички з прямого профілю навичок), неявно асоціюється з цією чергою. Команда не відіграє жодної ролі в асоціації агентів із цими чергами. Ці агенти можуть бути частиною будь-якої команди для управління та операційних цілей.
Кожен контакт, що потрапив у чергу в цій черзі, автоматично прийматиме критерії навичок, визначені в самій черзі. Індивідуальні контакти не можуть визначати або скасовувати власні вимоги/критерії до навичок, на відміну від черг на основі навичок із призначенням команд.
У цьому прикладі,
- Лише агенти A1, A3 і A7 повністю відповідають критеріям навичок, налаштованим у черзі, тому лише ці агенти будуть пов'язані з цією чергою.
- Агенти A2, A4 і A6, які частково відповідають критеріям, або A5, які не мають відповідних навичок, не можуть бути пов'язані з цією чергою.
Оновлення профілю навичок агента (яке називається перенавичкою) так, щоб він відповідав критеріям черги, автоматично та динамічно робить цього агента частиною цієї черги. Альтернативно, оновлення самого критерію навичок черги так, щоб більше (або менше) агентів відповідали оновленим критеріям, автоматично та динамічно додавало (або видаляло) агентів із цієї черги.
На відміну від черг із призначенням команд, тут немає концепції розширення цілі за часові інтервали. Якщо контакт не вдається зрівняти з жодним із пов'язаних агентів, він залишається в черзі, доки один із цих агентів не стане доступним для обробки контактів до тайм-ауту.
Черги, засновані на навичках, найкраще підходять там, де статичне призначення навичок і управління чергою до асоціації агентів є здійсненними та бажаними для операційного контролю. Вони також підходять, коли вибір алгоритмів маршрутизації відповідає розподілу роботи між агентами. Ці черги також особливо корисні у ситуаціях, коли різні типи запитів клієнтів вимагають специфічних навичок, які можуть бути обслуговувані заздалегідь сформованим сегментом експертних агентів.
Складні організації контакт-центрів можуть знайти легше керувати чергою до призначення агентів у чергах, заснованих на навичках, порівняно з чергами з призначенням агента, де кожного агента потрібно додавати вручну до списку, що особливо незручно для великої організації.
Вимоги до навичок, призначені у flow
Черги на основі навичок з вимогами до навичок, призначеними у flow, — це тип черги на основі призначення команд у Webex Contact Center, де набір команд налаштований на кількох рівнях, які називаються групами розподілу дзвінків. Агенти, які увійшли в ці налаштовані команди, отримують контакти з цієї черги відповідно до рівня групи розподілу дзвінків, на якому їхня команда налаштована в черзі, якщо вони також повністю відповідають вимогам до навичок контакту.
У такій черзі команди агентів об'єднуються у групи розподілу дзвінків з налаштовуваними затримками за часом між ними. Якщо агент для контакту недоступний, запит залишається, а після затримки маршрутизація розширюється до наступної групи розподілу дзвінків. Цей процес триває, доки не буде призначено агента або всі групи не вичерпаються. Тим часом, якщо агент із раніше перевіреної групи стає доступним під час цього процесу, цей агент обирається.
Агенти набувають навички через профіль, який безпосередньо присвоюється агенту. Навички агента визначаються на основі вибору команди під час входу.
Кожен контакт може за бажанням вказати вимоги до навичок у потоці, які порівнюються з навичками доступних агентів для вибору найбільш відповідного агента.
Крім того, контакти можуть визначати розслаблення навичок у визначені часові інтервали. Це модифікований набір вимог до навичок, які переписують початкові вимоги контакту на визначених часових інтервалах. Це дозволяє контакту змінювати (зазвичай використовується для «розслаблення») свої вимоги до навичок, стоячи в черзі, щоб більше агентів могли відповідати цим розслабленим вимогам до навичок.
Цільове розширення через групи розподілу дзвінків може відбуватися одночасно з циклами розслаблення навичок — обидва спрямовані на швидше узгодження припаркованого контакту з відповідними агентами, що зменшує загальний час очікування та покращує рівень обслуговування черги.
Як і черги для некваліфікованих осіб із призначенням команд, вона має три групи розподілу дзвінків, які дозволяють «цільове розширення», тобто розширення на більше агентів у командах протягом визначених часових інтервалів.
- Перша група розподілу дзвінків включає TEAM 1, яка має 3 налаштованих агентів – A1, A2 та A5.
- Друга група розподілу дзвінків містить TEAM 2, яка має 3 налаштованих агентів – A2, A3 та A4.
- Третя (і остання) група розподілу дзвінків містить TEAM 3, яка має 2 налаштованих агентів – A6 та A7.
Однак є дві основні речі, на які варто звернути увагу:
- Кожен контакт, який потрапляє в чергу, визначає вимоги до навичок і розслаблення навичок через потік.
- Агенти могли мати налаштовані навички (через профіль навичок — безпосередньо або успадкований від команди, що увійшла в систему).
Хоча A2 налаштована бути частиною і КОМАНДИ 1, і КОМАНДИ 2, залежно від вибору команди, яку цей агент зробив під час входу, у поточній сесії він вважається частиною цієї команди і, відповідно, також успадковує профіль навичок (а отже, і значення навичок) від цієї команди (якщо це не замінено прямою конфігурацією профілю навичок для цього агента).
Це потужна можливість, яку забезпечують черги з призначенням команд, де агенти можуть переміщатися між чергами, просто обираючи команду під час входу.
У поєднанні з можливістю успадкувати налаштування профілю навичок від обраної команди, агент може працювати з різними наборами навичок.
У цьому прикладі,
- Контакти ставляться в чергу з початковою вимогою до навичок (sk_1 >=6) під час ескалації з потоку, з розслабленням навичок (sk_1 >= 3) після визначеного часового інтервалу.
- Серед усіх агентів у всіх групах розподілу дзвінків лише A1, A3, A6 та A7 мають навички, які задовольняють початкову вимогу до навичок у черзі контактів.
- Решта агентів або мають навичку (sk_1), але не відповідають вимогам (наприклад, A2 у TEAM 1 і A4 у TEAM 2), або взагалі не мають цієї навички (наприклад, A5, A2 у TEAM 2).
- З часом, після розслаблення навичок, також A2 і A4 також задовольняють «розслаблені» вимоги контакту.
Для кожного контакту, який потрапляє в чергу в цю чергу, система намагається знайти відповідного агента в першій групі розподілу дзвінків, який повністю відповідає поточним вимогам до навичок контакту. Якщо не знайдено відповідного агента, контакт залишається на встановлений час до того, як цільове розширення відбудеться до другої групи розподілу дзвінків. Усі команди, налаштовані у другу групу розподілу дзвінків, також додаються до існуючих команд першої групи. Тепер система намагається знайти відповідного агента всередині розширеної групи. Зверніть увагу, що поки це відбувається, релаксація навичок також оновлюватиме вимоги до навичок контакту у визначені часові інтервали, а система використовуватиме оновлені вимоги до навичок для відповідності доступним агентам у поточній групі розподілу дзвінків.
Це триває, доки всі налаштовані групи розподілу дзвінків не будуть розширені і не застосовано всі послаблення навичок, якщо не знайдено відповідного агента раніше.
Доступні шаблони маршрутизації:
Конфігурація черги
Налаштуйте черги на основі навичок
Призначте критерії навичок черзі
- Створюйте навички.
- Створюйте профілі навичок.
- Призначте профіль навичок безпосередньо агентам.
- Створіть чергу з типом каналу: телефонія, чат, електронна пошта чи соціальні мережі.
- Призначайте вимоги до навичок чергам у Control Hub.
- Перегляньте список агентів, які можуть обробляти контакти в черзі.
- Виберіть алгоритм маршрутизації — або LAA, або BAA.
- Додайте активність «Контакт з чергою» у Flow і виберіть цю чергу.
Призначте вимоги до навичок у черзі
- Створюйте навички.
- Створюйте профілі навичок.
- Призначте профіль навичок безпосередньо агентам або команді.
- Створіть команду .
- Додайте агентів до команди.
- Створіть чергу за типом каналу: телефонія, чат, електронна пошта чи соціальні мережі.
- Додайте команди в чергу в одному CDG або кількох CDG.
- Виберіть шаблон маршрутизації — або LAA, або BAA.
- Додайте активність Черги Контакт у Flow і виберіть чергу, для якої налаштовано маршрутизацію на основі навичок. Детальніше дивіться у розділі «Контакт у черзі».
- Призначте навички та розслаблення навичок у режимі Контакт у черзі.
- Використовуйте Escalate Call Distribution Activity у черзі потоку POST щоб швидко перейти до наступної групи розподілу дзвінків або останнього.
Налаштуйте черги без навичок
Призначити команду в чергу
- Створіть команду .
- Додайте агентів до команди.
- Створіть чергу за типом каналу: телефонія, чат, електронна пошта чи соціальні мережі.
- Додайте команди в чергу в одному CDG або кількох CDG.
- Виберіть маршрутний шаблон або LAA.
- Додайте активність «Контакт з чергою» у Flow і виберіть цю чергу.
- Використовуйте Escalate Call Distribution Activity у черзі потоку POST, щоб швидко перейти до наступної групи розподілу дзвінків або останнього.
Призначити агента потоку черги
- Створіть чергу за типом каналу: телефонія, чат, електронна пошта чи соціальні мережі.
- Додавайте агентів безпосередньо до черг (примітка: у цьому типі черги не використовуються ні навички, ні команда).
- Виберіть шаблони маршрутизації, такі як Циркулярний, Лінійний або Найдовший доступний агент.
маршрутизація
Концепції маршрутизації
Сценарій надлишку агентів
Сценарій надлишку агента виникає, коли доступних агентів більше, ніж у черзі контактів. У такому випадку, коли контакт із клієнтом ставиться в чергу, система намагається негайно знайти відповідного агента для цього конкретного контакту, і якщо знайдено відповідного агента, контакт не потрібно залишати в черзі і чекати, поки агент буде доступний пізніше.
Кожного разу, коли контакт проходить розширення через Групу розподілу дзвінків або через розслаблення навичок, система знову намагається негайно знайти агента, що відповідає, саме для цього контакту.
Пошук відповідного агента для конкретного контакту використовує налаштований шаблон маршрутизації в черзі.
Webex Contact Center пропонує кілька маршрутизаторів у різних типах черг, що дозволяє організаціям оптимізувати обслуговування клієнтів, мінімізуючи час очікування, балансуючи навантаження агентів і забезпечуючи зв'язок клієнтів із агентами, які мають необхідні навички для задоволення їхніх конкретних потреб. Дивіться розділ «Маршрутизуючий шаблон» для детальної інформації про маршрутизації.
Сценарій контактного надлишку
Маршрутизація надлишкових контактів виникає, коли кількість вхідних взаємодій (або контактів) з клієнтами перевищує доступні агенти. Ця ситуація часто трапляється у пікові періоди або несподівані стрибки контактного об'єму. Основна мета маршрутизації надлишку контактів — ефективно керувати цим надлишком, забезпечуючи збереження стандартів обслуговування клієнтів попри надмірний попит. Для агента, який щойно став доступним на певному каналі, маршрутизація надлишку контактів працює для пошуку та призначення відповідного контакту серед усіх припаркованих контактів у всіх чергах, з якими цей агент пов'язаний.
Ключові стратегії ефективного проведення маршрутизації контактів з обмеженою доступністю агентів:
-
Рейтинг черги
Ранжування черги дозволяє адміністраторам визначати відносну важливість черг. Адміністратори можуть визначати рейтинги черги, щоб встановити порядок маршрутизації викликів з черг до агентів, увійдених у команди, на основі кожної команди.
Наприклад, розглянемо, що агенти, які увійшли в Команду А, пов'язані з двома чергами — «Білінг» і «Продажі». Адміністратори можуть використовувати ранжування черги для присвоєння вищого рейтингу черзі «Білінг», щоб коли контакти потрапляють у черги, контакти з «Білінгу» перенаправлялися до агентів команди А перед контактами з черг «Продажів». Це відбуватиметься, навіть якщо в черзі «Продажі» можуть чекати старші та більш пріоритетні контакти — просто тому, що черга «Білінг» має вищий рейтинг, ніж «Продаж». Лише коли в черзі «Білінг» більше немає очікуваних контактів, агенти з Команди А отримуватимуть маршрутизацію контактів з «Продажів» (та будь-якої іншої черги), з якою вони пов'язані.
Нижче наведено деякі важливі характеристики ранжування черги:
-
- Якщо ранг призначається лише деяким чергам, виклики в цих чергах матимуть пріоритет над викликами в чергах, для яких ранг не вказаний.
- Рейтинг черги можна встановити на максимум 50 черг у всіх типах медіа з значенням від 1 до 50, при цьому 1 є найвищим рейтингом.
- Ви можете призначити один і той самий ранг кільком чергам.
- Якщо ви увімкнете рейтинг черги, черги, яким не присвоєно явного рангу, вважаються нижчими за всі ранжовані черги.
-
Рейтинг черги працює в межах того ж типу медіа.
Наприклад, якщо Queue Sale — це голосова медіа-черга з рангом 2, а підтримка білінгу в черзі — чат з рангом 1 для команди A, то агенти, доступні на голосовому каналі в команді A, отримують голосовий дзвінок першими, навіть якщо ранг 2.
Однак розглянемо дві черги чатів для Команди B — кредитна картка черги з рангом 2 та дебетова картка черги з рангом 1. Тоді доступним агентам у команді B спочатку будуть запропоновані контакти з Queue Debit Card.
-
Рейтинг у черзі не застосовується до команд, що базуються на місткості.
-
-
Пріоритет контакту
Коли контакт ставиться в чергу, його пріоритет можна визначити, присвоївши ієрархічну важливість від 1 (найвища) до 10 (найнижча за замовчуванням). Таке пріоритезування гарантує, що певні контакти будуть вирішуватися швидше залежно від їхньої важливості, терміновості або стратегічної цінності для організації. Коли агент доступний для обробки наступного контакту серед усіх припаркованих контактів у всіх чергах, з якими він пов'язаний, найвищий пріоритетний контакт у всіх чергах перенаправляється до агента (за умови виконання інших критеріїв, таких як відповідність навичок та інші).
Для контактів, які стоять у черзі без явного пріоритету, вважається пріоритет за замовчуванням 10 (найнижчий). Серед кількох контактів з однаковим пріоритетом контакт, який чекає в черзі найдовше, першим перенаправляється до доступного та відповідного агента.
-
Найтриваліший контакт у очікуванні
Це базова стратегія, яка гарантує, що найдовше очікуваний контакт у всіх чергах, з якими пов'язаний агент, маршрутизується до агента.
Це остаточний критерій, який визначає маршрутизацію контакту, коли кілька контактів у чергах з однаковим рейтингом черги та однаковим пріоритетом чекають обробки.
По суті, маршрутизація зайвих контактів для агента, який щойно став доступним, означає вибір одного контакту, який:
- має той самий тип носії, що й той, на якому агент доступний
- стоїть у будь-якій черзі, з якою пов'язаний цей агент
- вимоги до навичок якого (якщо такі є) задовольняються цим агентом
- розташований у черзі, ранг якої вищий за інші черги, як налаштовано в команді агента
- має найвищий пріоритет серед усіх таких контактів
- є найстарішим очікуваним контактом серед контактів з однаковим пріоритетом
У наведеному вище прикладі, який ілюструє сценарій надлишку контактів, агент A1 увійшов у TEAM 1 і став доступним для роботи з контактами на різних типах медіа.
A1 пов'язана з трьома чергами — Q1, Q2 та Q3. TEAM 1 також визначила рейтинг черги, де Q1 займає найвищий рейтинг, а потім Q2 і Q3 відповідно.
У всіх цих чергах вже є контакти, з вимогами до навичок і пріоритетом для кожного контакту.
Тепер сценарій надлишку контактів працює так:
-
Серед усіх припаркованих контактів у цих чергах лише 4 можуть бути спрямовані на A1 – C2 , C7 (з ЧЕРГИ 2) та C3 , C8 (з ЧЕРГИ 3).
Лише вимоги до навичок цих 4 контактів повністю задовольняються навичками A1.
-
Серед цих чотирьох контактів пріоритет надається контактам з QUEUE 2 (тобто C2, C7), оскільки QUEUE 2 має вищий рейтинг черги.
Зверніть увагу, що хоча QUEUE 1 є найвищою за рейтингом, жоден із її припаркованих контактів не може бути переадресований до A1, оскільки їхні вимоги до навичок не задовольняються A1.
-
Між C2 і C7 найвищим пріоритетним контактом є C7. Отже, останній вибір — C7, і система маршрутизує його на A1.
Це відбувається навіть тоді, коли C2 був поставлений у чергу раніше, оскільки пріоритет контактів має пріоритет над часом у черзі.
Змішані мультимедійні профілі
Через конфігурацію мультимедійного профілю Webex Contact Center дозволяє агентам обслуговувати контакти різних типів медіа (голос, чат, електронна пошта та соціальні мережі). На основі цієї конфігурації агенти отримують канали, налаштовані за типом медіа.
Кожен контакт, спрямований до агента, споживає один канал цього медіатипу, доки агент працює над цим контактом. Хоча агенти можуть мати лише один голосовий канал, вони можуть мати до п'яти каналів інших типів медіа.
Налаштування змішаної маршрутизації в Multimedia Profiles дозволяє адміністраторам контролювати, як різні канали можуть використовуватися одночасно для кожного агента. Це дозволяє організаціям приділяти належну увагу клієнтам, просуваючи кращий Quality of Service, покращений клієнтський досвід і кращі коефіцієнти конверсії. Крім того, організації можуть балансувати навантаження між медіаканалами при нерівномірному навантаженні в деяких каналах, що дозволяє ефективно використовувати агентів.
Є три варіанти:
-
Ексклюзивний
-
Змішаний
-
Змішаний реальний час
Для отримання додаткової інформації про налаштування мультимедійних профілів дивіться розділ Керування мультимедійними профілями.
Маршрутні схеми
Скіл Базується
Маршрутизації на основі навичок у Webex Contact Center прямі взаємодії з вхідними клієнтами до агентів на основі конкретних навичок, необхідних для розв'язання запиту, таких як володіння мовою або технічна експертиза. Ці моделі забезпечують зв'язок кожного клієнта з найбільш кваліфікованим агентом, підвищуючи ефективність обслуговування та задоволеність клієнтів. Переваги включають скорочення часу обробки, покращення рівня вирішення та оптимізоване використання ресурсів агентів завдяки узгодженню їхньої експертизи з потребами клієнтів.
Коли використовуються шаблони маршрутизації на основі навичок, спочатку використовуються вимога до навичок контакту (призначена у потоці) або критерії навичок, призначені черзі, для фільтрації доступних агентів, чиї навички повністю відповідають цим вимогам/критеріям. Потім серед агентів, які фільтруються, обирається один для контакту на основі налаштованого шаблону маршрутизації.
Найдовший доступний
Патерн маршрутизації на основі навичок «Найдовший доступний» маршрутизує контакт до того агента, чия навичка повністю відповідає вимогам навичок контакту / критеріям навичок черги, і який був доступний найдовше з моменту обробки останнього контакту серед усіх відповідних агентів у цій черзі.
Такий маршрутизуючий патерн допомагає рівномірно розподіляти роботу між агентами, призначаючи взаємодії тим, хто був доступний найдовше, запобігаючи дисбалансу навантаження. Це допомагає підтримувати справедливість у розподілі роботи, гарантуючи, що жоден агент не буде перевантажений, а інші залишаються вільними.
У наведеному вище прикладі є 4 агенти з навичками володіння та некомпетентністю з різними значеннями навичок володіння.
Розглянемо контакт, який ставиться в чергу на основі навичок і має шаблон маршрутизації «Найдовший доступний»:
- з наведеними вище вимогами до навичок, призначеними через Flow, або
- з наведеними вище критеріями навичок у черзі на основі навичок
У цьому сценарії:
-
Для маршрутизації розглядаються лише агенти, які повністю відповідають вимогам до контактних навичок / критеріям навичок у черзі. Лише агенти A1, A2 і A4 повністю відповідають вимогам щодо контактних навичок / критеріїв навичок черги.
Агент A3 не має права на участь. У випадку критеріїв навичок, призначених у чергу, A3 навіть не пов'язаний із чергою.
-
Серед A1, A2 та A4 контакт буде переадресований до найдовшого доступного агента — A1, який доступний вже 10 хвилин, довше за A2 або A4.
Завдяки тому, що A1 отримав цей контакт, A1 більше не буде найдовшим доступним агентом на всіх медіаканалах.
- Наступний контакт із такими ж вимогами до навичок буде спрямований до наступного за тривалістю доступного агента — A2, і так далі.
Цей шаблон маршрутизації підтримується у таких типах черг на основі навичок:
Найкраще доступне
Найкращий доступний маршрутизуючий шаблон на основі навичок гарантує, що взаємодія з клієнтами буде спрямована до найбільш кваліфікованого агента. Ця модель оцінює не лише наявність необхідних навичок серед агентів, а й рівень їх володіння, розраховуючи бал навичок для визначення найбільш кваліфікованого («найкращого») агента для кожного контакту.
Цей шаблон повністю фільтрує доступних агентів, чиї навички повністю відповідають вимогам контакту / черги навички. Потім оцінка для кожного відповідного агента розраховується за значеннями володіння всіма навичками, зазначеними у вимогах до контакту / критеріях навичок у черзі. Агент із найвищим показником майстерності вважається «найкращим» агентом для кожного контакту.
Фактично, сума значень навичок агента, які відповідають вимогам до контакту / критеріям навичок черги, визначає бал.
Декілька ключових моментів, які варто зрозуміти:
- Зазвичай фактичне значення навички використовується при розрахунку балів, оскільки вищий бал вказує на сильніший матч. За винятком того, що вимога до навичок використовує умову менше ніж дорівнює (<=), це конкретне значення навичок агента інвертується при розрахунку балів, тобто effective_skill_value = (10) мінус (actual_skill_value). Це робиться для того, щоб нижчий бал свідчив про сильніший матч.
- Коли кілька відповідних агентів мають однаковий бал, обирають найдовше доступного агента серед них
- Для розрахунку балів враховуються лише навички володіння. Будь-які булеві, текстові чи енумні навички у вимогах до контактних навичок / критеріях черги не розглядаються для розрахунку балів.
У наведеному вище прикладі є чотири агенти з навичками володіння та некомпетентністю з різними значеннями навичок володіння.
Розглянемо контакт, який ставиться в чергу на основі навичок і має шаблон маршрутизації «Best Available»:
- з наведеними вище вимогами до навичок, призначеними через Flow, або
- з наведеними вище критеріями навичок, налаштованих у черзі на основі навичок.
У цьому сценарії:
-
Для маршрутизації розглядаються лише агенти, які повністю відповідають вимогам до контактних навичок / критеріям навичок у черзі. Лише агенти A1, A2 і A4 повністю відповідають вимогам щодо контактних навичок / критеріїв навичок черги.
Агент A3 не має права на участь. У випадку критеріїв навичок, призначених у чергу, A3 навіть не пов'язаний із чергою.
-
Серед A1, A2 та A4 розрахунок балів здійснюється системою на основі вимог до контактних навичок / критеріїв навичок у черзі, де враховуються лише навички володіння.
Для розрахунку балів враховуються лише навички, зазначені у вимогах до контактних навичок / у черзі, навіть якщо агенти можуть мати додаткові або інші навички володіння.
Також зверніть увагу на інверсію значення навичок при розрахунку балів, коли використовується умова менша за рівність (<=).
-
Контакт перенаправляється до A2 , оскільки це найкращий доступний агент за рейтингом. Якщо A2 недоступний або зайнятий, контакт буде переадресований до наступного найкращого доступного агента з другим найвищим балом, і так далі.
Однак у нас є 2 агенти – A1 і A4 з наступним найвищим балом. Контакт перенаправляється до найдовшого доступного агента між A1 і A4.
Цей шаблон маршрутизації підтримується у таких типах черг на основі навичок:
Маршрутизація без навичок
Webex Contact Center також підтримує різноманітні маршрутизації, не пов'язані з навичками, які зосереджені на розподілі взаємодії з клієнтами без урахування конкретних навичок чи експертизи агентів. На відміну від маршрутизації на основі навичок, вони не враховують навички агента і не вимагають контакту чи черги для визначення вимог чи критеріїв для маршрутизації. Натомість вони надають пріоритет таким факторам, як доступність, розподіл навантаження та заздалегідь визначені послідовності, що дозволяє ефективно обробляти контакти на основі операційної логіки, а не компетенцій окремих агентів. Ці патерни особливо корисні в середовищах, де взаємодії відносно однорідні або не потребують спеціалізованого підходу.
Найдовший доступний
Патерн маршрутизації «Найдовший доступний» маршрутизує контакт до того агента в черзі, який був доступний найдовше з моменту обробки останнього контакту, серед усіх агентів, які є доступними та пов'язані з цією чергою.
Цей маршрутизуючий патерн забезпечує справедливий і збалансований розподіл навантаження, призначаючи взаємодії агентам, які найдовше перебували без активності. Запобігаючи дисбалансу навантаження, він гарантує, що жоден агент не буде перевантажений, а інші залишаються вільними. Цей підхід особливо ефективний у періоди стабільного контакту, підтримуючи стабільну взаємодію по всьому пулу агентів.
Агенти втрачають свої «найдовший доступний» посади у всіх каналах, коли їм пропонують контакт будь-якого медіа-типу. Це означає, що після того, як агент обробляє контакт, наступний контакт будь-якого медіа-типу в черзі буде призначений наступному за тривалістю доступному агенту в цій черзі.
У наведеному вище прикладі агент A1 є найдовшим доступним агентом (позиція 1) — або він увійшов першим, або не отримав контакт довше, ніж будь-який інший агент.
Агенти A2 (позиція 2) та A3 (позиція 3) також доступні, але вони або увійшли в систему, або обробляли контакти після A1. Усі агенти пов'язані з обома чергами, які мають цей шаблон маршрутизації.
Розглянемо наступний сценарій:
-
У момент T0 голосовий контакт C1 ставиться в чергу і направляється до найдовшого доступного агента, тобто A1.
Через те, що A1 отримав C1, A1 більше не є найдовшим доступним агентом у всіх медіа-каналах.
- У момент T1 чат-контакт C2 ставиться в чергу і направляється до найдовшого доступного агента, яким тепер є A2.
-
Нарешті, у момент T2, ще один голосовий контакт C3 ставиться в чергу і направляється до A3.
A1 і A2 нещодавно отримали контакти – на цей момент саме A3 чекає найдовше.
Цей шаблон маршрутизації підтримується у таких типах черг без навичок:
Циркуляр
Кругова маршрутизація розподіляє вхідні контакти між групою доступних агентів у круговому порядку. Коли контакт ставиться в чергу, система призначає його наступному доступному агенту в черзі на основі заздалегідь визначеної послідовності.
Процес починається з агентів у визначеному порядку. Перший вхідний контакт призначається першому доступному агенту в цій послідовності. Для наступних контактів система обирає наступного доступного агента, продовжуючи з того місця, де зупинилася у визначеному порядку черги. Цей патерн повторюється, перемикаючись між агентами, але завжди починаючи після позиції останнього обраного агента.
Цей підхід ефективний для справедливого та рівномірного розподілу контактів між агентами. Це допомагає гарантувати, що жоден агент не буде перевантажений контактами, а всі агенти мають рівні можливості для послідовної взаємодії. Однак циклічна маршрутизація не враховує поточне навантаження чи інші фактори, які можуть впливати на здатність агента обробляти конкретний контакт.
У наведеному вище прикладі агенти налаштовані у кругову чергу в наступному порядку: A3 → A4 → A5 → A6 → A1 → A2.
Для початку початкова позиція — це перший агент у налаштованому порядку (A3). Коли контакти маршрутизуються до агентів у цій черзі, позиція переміщується по колу, позиціонуючись до агента, який знаходиться наступним у налаштованому порядку від агента, до якого був направлений останній контакт.
Розглянемо наступний сценарій:
-
Перший контакт (C1) ставиться в чергу і маршрутизується до агента A3.
Вказівник оновлюється до наступного агента у налаштованому порядку, тобто A4.
-
Коли другий контакт (C2) ставиться в чергу, система починає знаходити доступних агентів, починаючи з A4 , тобто A4 → A5 → A6 → A1 → A2 → A3.
Однак A4 і A5 недоступні (або вони навіть не зареєстровані, або не активні, або повністю зайняті іншими контактами цього типу медіа), тому C2 маршрутизується до наступного доступного агента – A6. Вказівник оновлюється до наступного агента у налаштованому порядку, тобто A1.
-
Аналогічно, третій контакт (C3) маршрутизується до A1, четвертий контакт (C4) — до A2. Вказівник знову на рівні A3 .
Ця логіка зберігається, і контакти розподіляються між доступними агентами у схемі «круговий» / «круговий турнір».
Якщо в черзі стоїть припарковані контакти, сценарій надлишку агента співпаде наступного агента, який стане доступним на цьому типі медіа, з найвищим пріоритетним і найстарішим контактом серед них.
Це не враховує і не впливає на існуюче значення позиції в цій черзі, яке оновлюється лише тоді, коли маршрутизація надлишку контактів успішно співпадає з агентом.
Цей шаблон маршрутизації підтримується у таких типах черг без навичок:
Зверху вниз
Патерн маршрутизації зверху вниз розподіляє вхідні контакти між групою доступних і впорядкованих агентів у послідовному порядку. Коли контакт ставиться в чергу, система завжди проходить впорядкований список агентів з самого початку і співставляє контакт з першим доступним агентом (який має вільний канал типу медіа контакту) у цій послідовності.
Це відбувається для кожного контакту, який потрапив у чергу. Контакт намагається підібрати, завжди починаючи зверху (перший налаштований агент) і просуваючись вниз по списку, доки не буде знайдено відповідного агента.
На відміну від кругового маршрутизації, немає «вказівника», який динамічно змінює початкову точку залежно від позиції останнього обраного агента.
Цей підхід ефективний для розподілу контактів між агентами, які впорядковані на основі певної упередженості чи вподобань, визначених адміністратором. Це допомагає гарантувати, що агенти на вершині завжди отримують перевагу для роботи з контактами над агентами нижче. Однак маршрутизація зверху вниз не враховує поточне навантаження чи інші фактори, які можуть впливати на здатність агента обробляти конкретний контакт.
У наведеному вище прикладі агенти налаштовуються у черзі зверху вниз у наступному порядку: A3 → A4 → A5 → A6 → A1 → A2.
Це означає, що адміністратор хоче, щоб кожен контакт маршрутизувався до першого агента (A3), якщо він доступний, інакше — до наступного агента (A4), якщо доступний, і так далі, у налаштованому порядку.
Розглянемо наступний сценарій:
- Перший контакт (C1) ставиться в чергу і маршрутизується до агента A3, оскільки A3 знаходиться на початку замовлення.
-
Коли другий контакт (C2) ставиться в чергу, маршрутизація знову здійснюється зверху замовлення (завжди починаючи з A3).
Якщо A3 має більшу пропускну здатність для цього медіа-типу, C2 також маршрутизується до A3. Однак, якщо A3 повністю зайнята цим типом медіа, маршрутизація продовжується вниз по списку до A4.
- Однак A4 і A5 недоступні (вони або навіть не зареєстровані, або не активні, або повністю зайняті іншими контактами цього медіа-типу), тому C2 маршрутизується до наступного доступного агента у порядку зверху вниз – A6.
-
Аналогічно, третій контакт (C3) намагається прокласти від A3 вниз до низу. Першим співпадаючим агентом буде A1.
Ця логіка триває, доки контакт не знайде жодного доступного агента до кінця замовлення, тоді він залишається в черзі.
Цей шаблон маршрутизації підтримується у таких типах черг без навичок:
Маршрутизація на основі агентів
Маршрутизація на основі агента — це можливість, яка маршрутизує або ставить у чергу контакт безпосередньо до визначеного ("пріоритетного") агента. Пошук агента за адресою електронної пошти агента або ID перенаправляє контакт до бажаного агента. Активність Queue To Agent у потоці допомагає досягти маршрутизації на основі агента. Детальніше дивіться у розділі «Черга до агента ».
Контакт може мати відображення з одним або кількома пріоритетними агентами, які зазвичай можуть керуватися у зовнішньому додатку поза Webex Contact Center. Пошук бажаного агента для контакту здійснюється через активність HTTP-запиту , яка отримує відображення з зовнішнього додатку. Щоб маршрутизувати або припаркувати контакт із бажаним агентом, налаштуйте активність Queue To Agent, використовуючи Webex Contact Center ID або електронну адресу агента. Контакт також може бути припаркований поруч із пріоритетним агентом, якщо цей агент недоступний негайно.
Маршрутизація на основі агентів корисна у наступних сценаріях:
- Пріоритетне маршрутизування агента: Клієнт може призначати контакти спеціалізованим агентам або керівникам з відносин. У таких випадках маршрутизація на основі агента маршрутизує контакти безпосередньо до цього бажаного агента.
- Остання маршрутизація агента: Коли контакт кілька разів дзвонить до контакт-центру для взаємодії з агентом, маршрутизація на основі агента може направити контакт до останнього агента, який обробляв цей контакт.
В обох випадках використання дані контакту та відображення агента зберігаються поза Webex Contact Center.
можливості черги та маршрутизації у Flow
Можливості черги та маршрутизації у Flow
У Webex Contact Center широкий спектр можливостей маршрутизації, чергування та контролю дзвінків можна оркеструвати через потоки.
Різноманітні активності потоку та обробники подій, надані в Flow Designer, можуть бути розміщені в потік для ефективного управління життєвим циклом вхідних і вихідних контактів.
Для отримання додаткової інформації про налаштування та використання потоків дивіться розділ «Побудова та керування потоками за допомогою Flow Designer».
Чергові заходи
Контакт черги
Активність Queue Contact дає змогу поставити контакт у активну вхідну чергу від організації, щоб його можна було підібрати та направити до потрібного агента в цій черзі.
Наступні аспекти черги можна керувати через цю діяльність:
- Пріоритет — Призначення ієрархічної важливості від 1 (найвища) до 10 (найнижча, за замовчуванням) контакту, що ставиться в чергу.
- Вимоги до навичок — Встановіть критерії навичок, які агенти повинні виконати у черзі на основі навичок, щоб вважатися придатними для маршрутизації контакту.
- Розслаблення навичок — налаштування, модифікація або видалення раніше встановлених вимог до навичок після певного часу, щоб підвищити шанси знайти агента.
- Перевірити доступність агента — дозволити системі миттєво розширюватися через усі групи розподілу дзвінків, де немає доступних агентів, щоб уникнути часу очікування.
Дивіться розділ «Маршрутизація» для детальнішої інформації про те, як пріоритет, конфігурація навичок і доступність агента відіграють роль у маршрутизації контактів.
Після успішної діяльності В черзі контакту в черзі контакт,
-
Якщо агент, що відповідає, вже доступний, система намагається направити контакт до агента.
Це перериває виконання основного потоку , і подальші події можуть запускати відповідні потоки подій за умови конфігурації.
-
Якщо не знайдено співпадаючого агента, контакт залишається в черзі і чекає, поки з'явиться агент для відповідності.
Виконання потоку продовжується з активністю, прикріпленою після Queue Contact, що дає змогу:
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі — прикріпивши активність PlayMusic .
- Зареєструйте зворотний дзвінок на основі запиту клієнта — прикріпивши активність Callback .
- Повторна черга, тобто видаляйте контакт із поточної черги та додавайте його в нову чергу — приєднуючи до активності агента ще один контакт або черга черги.
Коли збігається агент, система намагається перенаправити контакт до агента.
У разі успіху це перериває виконання Main Flow , і подальші події можуть запускати відповідні Event Flows, якщо їх налаштувати.
Використання активності Queue Contact не підтримується, якщо:
- Агент уже призначений для контакту.
- У потоці надається неправильна черга, навичка або інша конфігурація.
- Максимально дозволені переходи між точками входу та черги (25) для контакту вичерпані.
- Максимальна кількість дозволених спроб успішного маршрутизації контакту (20) вичерпана.
У таких випадках діяльність призводить до відмови, і виконання потоку переходить на шлях обробки помилок.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі Build and manage flows > Queue Contact.
Черга до агента
Активність «Черга до агента» дає змогу поставити контакт у чергу безпосередньо до бажаного агента, знайшовши його унікальний агент ID або електронну адресу в Webex Contact Center.
Наступні аспекти черги можна керувати через цю діяльність:
- Пріоритет — присвоїти контактам, що стоїть у черзі з одним і тим самим агентом, вищу/меншу важливість.
- Черга звітування — визначте чергу для налаштування, наприклад, запису та стандартної музики в черзі, а також повідомляйте про цілі контакту.
- Черга відновлення — визначте чергу, яку можна використовувати як запасний варіант, якщо контакт не вдається направити до вказаного бажаного агента.
Як тільки активність Queue To Agent успішно ставить контакт у чергу,
-
Якщо агент уже доступний, контакт перенаправляється до агента.
Це перериває виконання основного потоку , і подальші події можуть запускати відповідні потоки подій за умови конфігурації.
-
Якщо агент доступний, але вирішує відмовитися, не відповісти або не отримує контакт, його переміщують у запропоновану чергу відновлення.
У черзі відновлення контакт буде переадресований до найдовшого доступного агента без жодної підтримки навичок.
-
Якщо агент недоступний і вибрана опція « Контакт з паркуванням, якщо агент недоступний», контакт паркується і чекає, поки агент стане доступним.
Виконання потоку продовжується з активністю, прикріпленою після Queue To Agent, що дає можливість:
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі — прикріпивши активність PlayMusic .
- Активність повторного дзвінка.
- Повторна черга, тобто видаляє контакт із поточної черги і додає його в нову чергу — приєднуючи ще одну чергу до активності агента або контакту черги.
Коли агент стає доступним, система намагається перенаправити контакт до агента.
Це перериває виконання основного потоку , і подальші події можуть запускати відповідні потоки подій за умови конфігурації.
- Якщо агент недоступний і опція « Зв'язатися з паркуванням, якщо агент недоступний » не вказана, черга провалюється.
- Агент уже призначений для контакту.
- Надається недійсний пріоритетний агент ID або електронна адреса.
- Надається недійсна черга звітування або відновлення.
- Пріоритетний агент існує, але не увійшов у систему, недоступний або зайнятий обробкою іншого контакту.
У таких випадках діяльність призводить до відмови, і виконання потоку переходить на шлях обробки помилок.
Для детальнішої інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі Build and manage flows > Queue To Agent.
Ескалаційна група розподілу дзвінків
Активність Escalate Call Distribution Group підтримується лише для черг із призначенням команд і дає можливість негайно оновити групу розподілу дзвінків для контакту, замість очікування автоматичного оновлення для наступної групи після налаштованого періоду очікування. Це дозволяє швидко направляти контакт до всіх відповідних агентів у черзі.
Використовуючи активність Escalate Call Distribution Group, контакт можна передати до:
- Наступна група — розширення набору команд, щоб включити тих, що додаються до групи розповсюдження наступного дзвінка.
- Остання група — розширення набору команд, щоб включити всі команди, відображені у всіх групах розподілу дзвінків, налаштованих для черги.
- Контакт ще не в черзі.
- Контакт стоїть у черзі, яка не підтримує концепцію груп розподілу дзвінків.
У таких випадках діяльність призводить до відмови, і виконання потоку переходить на шлях обробки помилок.
Розглянемо приклад, коли контакт потрапляє в чергу з трьома групами розподілу дзвінків, кожна з яких оновлюється через 30 секунд.
Агенти недоступні у командній частині CDG 1 та CDG 2, а агент доступний у TEAM 3 , яка належить до групи останнього розподілу дзвінків.
Коли активність групи розподілу дзвінків не використовується у потоку, це призводить до тривалого очікування, як показано нижче:
Час очікування можна скоротити, використовуючи діяльність Escalate Call Distribution Group, яка використовується наступним чином:
На основі обраних опцій Next Group або Last Group, час очікування контакту значно скорочується, як показано нижче:
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідних даних дивіться розділ «Build and manage flows > Escalate Call Distribution Group».
Інформаційні заходи в черзі
Отримати інформацію про чергу
Активність Get Line Info надає можливість отримувати інформацію черги в реальному часі для конкретного контакту, наприклад:
- Поточна позиція контакта в черзі (PIQ) або потенційна позиція, якщо ще не поставлена в чергу.
- Орієнтовний час очікування (EWT) або тривалість, протягом якої завдання очікується в черзі перед отриманням відповіді.
- Кількість агентів, які увійшли в систему або доступні в поточній групі розподілу дзвінків контакту.
- Кількість агентів, увійшоних у систему або доступних у всіх групах розподілу дзвінків для вибраної черги.
- Тривалість, протягом якої найстарший контакт у черзі чекає.
Ці деталі надаються під час виконання потоку як вихідні змінні активності.
Для отримання додаткової інформації про використання діяльності, детальне визначення та метод розрахунку для кожної деталі черги дивіться у розділі Build and manage flows > Get Queue Info.
Деякі способи використання інформації черги можуть бути:
- Оголосити позицію контакта в черзі та приблизний час очікування клієнту, поки він чекає на маршрутизацію.
- Щоб вирішити, чи можна зареєструвати зворотний дзвінок для клієнта, якщо орієнтовний час очікування занадто довгий.
- Для ескалації контакту до групи розподілу наступного дзвінка (CDG), якщо агентів немає в командах, відтворених на поточний CDG.
Використання інформації Get Queue Info активність не підтримується, коли через вибір змінної надається недійсна черга.
У цьому випадку діяльність призводить до відмови, і виконання потоку переходить на шлях обробки помилок.
- контакт (поки що) не ставиться в чергу під час виконання активності Отримати інформацію в черзі.
- Контакт розташований у черзі, яка не підтримує концепцію груп розподілу дзвінків.
У таких випадках значення -1 у цих вихідних полях вказує, що ця інформація не застосовується.
Розглянемо приклад, коли клієнт має бути повідомлений про довгий EWT у черзі після кожних 15 секунд у черзі.
Цього можна досягти за допомогою активності Get Queue Info у потоці наступним чином:
Розширена інформація про чергу
Активність Розширеної інформації про чергу надає можливість отримувати інформацію про чергу в реальному часі для конкретного контакту, додатково враховуючи критерії навичок контакту, такі як:
- Поточна позиція контакта в черзі (PIQ) або потенційна позиція, якщо ще не поставлена в чергу.
- Кількість агентів, які увійшли або були доступні в поточній групі розподілу дзвінків контакту, що відповідає заданим критеріям навичок.
- Кількість агентів, які увійшли в систему або були доступні у всіх групах розподілу дзвінків для обраної черги, що відповідає заданим критеріям навичок.
- Поточна група розподілу дзвінків, де контакт стоїть у наданій черзі.
- Загальна кількість груп розподілу дзвінків у наданій черзі.
Ці деталі надаються під час виконання потоку як вихідні змінні активності.
Для отримання додаткової інформації про використання діяльності, детальне визначення та метод розрахунку для кожної деталі черги див. розділи «Побудова та керування потоками» > Розширена інформація про чергу.
Деякі способи використання розширеної інформації черги можуть бути такими:
- Щоб оголосити позицію контакта в черзі клієнту, поки він чекає на маршрутизацію.
- Щоб передати контакт до групи розподілу наступного дзвінка, якщо у командах, відібраних із поточною групою розподілу дзвінків, немає агентів, які відповідають критеріям навичок.
- Щоб вирішити, чи можна зареєструвати зворотний дзвінок для клієнта, якщо жоден агент, що відповідає критеріям навичок, не зареєстрований у всіх групах розподілу дзвінків.
Використання розширеної інформації про чергу активність не підтримується, якщо:
- Інформація запитується для черг із критеріями навичок, призначеними для черги.
- Контакт уже стоїть у черзі, але в іншій черзі, ніж та, де запитується інформація.
- Контакт ставиться безпосередньо до пріоритетного агента.
У таких випадках діяльність призводить до відмови, і виконання потоку переходить на шлях обробки помилок.
Розглянемо приклад ситуації, коли клієнт має бути поінформований про повторний дзвінок, оскільки агенти, які відповідають критеріям навичок, немає.
Цього можна досягти, використовуючи активність Advanced Queue Info у потоці наступним чином:
Діяльність з контролю дзвінків
Встановити ідентифікатор абонента
Активність Set Caller ID використовується для визначення абонента ID, який має відображатися під час дзвінка. Активність Set Caller ID має використовуватися лише на попередніх подіях подій як термінальна активність, що позначає кінець подійного потоку.
Активність Set Caller ID дозволяє налаштувати необхідну автоматичну ідентифікацію номера (ANI) на основі служби ідентифікації набраного номера (DNIS), типу операції або типу учасника.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі Build and manage flows > Set Caller ID.
Контроль запису
Активність контролю запису призначена для використання разом із активністю в меню для отримання згоди на запис від абонента. Це забезпечує відповідність нормативам або політикам, які вимагають явної згоди перед початком запису, безшовно інтегруючи цей етап у робочий процес.
Активність Меню IVR має зафіксувати згоду користувача у булеву змінну, яка буде призначена як вхід для діяльності Контролю запису. Якщо клієнту потрібно повідомити про згоду користувача у звіті згоди, значення згоди має зберігатися у глобальній змінній, що може бути звітованою. Альтернативно, якщо звітність не потрібна, можна використовувати локальну змінну. Такий підхід надає орендарям і клієнтам більшу гнучкість у ефективному управлінні та використанні змінних.
Коли ця діяльність додається до потоку, згода користувача має пріоритет над налаштуваннями конфігурації на рівні орендаря, черги чи графіка запису.
Порядок пріоритету такий:
- Якщо згода користувача — «Так» у потоці, то дзвінок записується, незалежно від налаштування запису, встановленої на рівні орендаря, черги чи графіка запису.
- Якщо користувач не дає згоди у відповідь на активність, дзвінок не записується, незалежно від налаштування запису на рівні орендаря, черги чи графіка запису.
- Якщо активність контролю запису не налаштована в потоку, але конфігурація встановлена на Так на будь-якому з інших рівнів, таких як орендар, черга чи графік запису, тоді дзвінок записується.
- Якщо активність контролю запису не налаштована у потоці, і конфігурація встановлена на «Ні» на всіх рівнях, таких як орендар, черга та графік запису, дзвінок не записується.
Цей контроль запису можна проілюструвати нижче:
Крім того, конфігурації запису, такі як Continue On Transfer, Pause Resume Enabled, Pause Duration та інші, залишаються актуальними відповідно до існуючої ієрархії, включаючи рівні розкладу орендаря, черги або запису.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідних даних дивіться розділ Build and manage flows > Recording Control.
Передавання наосліп
Сліпий трансфер — це процес, при якому контакт ефективно маршрутизується на зовнішній номер набору (DN) через систему IVR, усуваючи потребу у залученні агента.
Активність сліпої передачі використовується, коли дзвінок має бути переадресований на зовнішній або сторонній DN. Це термінальна діяльність, тому потік закінчується після виконання передачі.
Активність сліпого перенесення не підтримується під час виконання потоку для консультацій.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідних даних дивіться розділ Build and manage flows > Blind Transfer.
Містковий трансфер
Діяльність Bridged Transfer дозволяє тимчасово передати контакт зовнішньому пункту призначення, поки потік зберігає контроль над дзвінком. Зовнішнім пунктом призначення може бути зовнішній міст або сервіс Interactive Voice Response (IVR).
Коли зовнішній цільовий пристрій завершує дзвінок, потік виклику продовжується за потреби, наприклад, виставляючи його в чергу агенту.
Діяльність Bridge Transfer виводить контакт з чергу, передаючи його сторонній IVR або автоматичній системі розповсюдження дзвінків (ACD). Якщо контакт не обробляється сторонньою системою, його можна знову поставити в оригінальну чергу, забезпечуючи збереження контакту в робочому процесі для належного обробки.
Наприклад, припустимо, що контакт-центр має ресурси Webex Contact Center агента та ресурси агента на зовнішньому кол-центрі або приватній філії (PBX). Клієнт хоче поставити дзвінок у чергу з агентами Webex Contact Center на короткий час (скажімо, 60 секунд). Якщо агент не доступний протягом цього періоду, дзвінок можна перенести (з неявним дечергуванням) до зовнішнього кол-центру для обробки контакту.
- Активність мостового переказу не підтримується у вихідних потоках викликів та подіях події.
- Контакти, які вже призначені агенту, не підтримуються для Bridge Transfer через потік.
Для детальнішої інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі Build and manage flows > Bridged Transfer.
Відключити контакт
Активність Disconnect Contact дає можливість безпосередньо від'єднати або завершити активний контакт із потоком.
Це термінальна активність, пов'язана з потоком, і може бути корисною для завершення контактів без втручання агента, що підходить для потоків шляху помилок або після реєстрації зворотного дзвінка для клієнта.
Залежно від конфігурації, опитування або зворотний зв'язок POST запускається, коли контакт завершено через цю активність.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідні параметри дивіться Build and manage flows > Disconnect contact.
Set Contact Priority (Задання пріоритету контакту)
Активність Set Contact Priority сприяє ефективному управлінню пріоритетом контактів у потоці, дозволяючи призначати конкретні рівні пріоритетів контактам. Це дозволяє надавати певним контактам більшу або меншу важливість, забезпечуючи їх правильну маршрутизацію порівняно з іншими контактами, які очікують, коли агенти стають доступними. Ця гнучкість дозволяє точно контролювати пріоритетність контактів протягом усього потоку.
Пріоритет встановлюється шляхом присвоєння ієрархічного рівня важливості від 1 (найвищий) до 9 (найнижчий). Контакти з найвищим пріоритетом направляються раніше за ті, що мають нижчі пріоритети. Коли кілька контактів мають однаковий рівень пріоритету, контакт, який чекав найдовше, першим перенаправляється до наступного доступного та відповідного агента. Ця система гарантує, що контакти з вищим пріоритетом отримують оперативну увагу, зберігаючи справедливість між контактами однакового пріоритету залежно від часу очікування.
- Активність Set Contact Priority може бути розміщена в будь-якій точці основного або подійного потоку.
- Якщо активність Set Contact Priority налаштована перед активністю в черзі (наприклад, Queue Contact або Queue To Agent), її налаштування пріоритету може бути перекрите будь-яким пріоритетом, явно налаштованим у наступних діях. Однак, якщо наступна активність у черзі не вказує пріоритет, буде застосований пріоритет контактів, встановлений попередньою активністю Set Contact Priority.
- Навпаки, якщо активність Set Contact Priority налаштована після операції в черзі (наприклад, В черзі контакт або Черга до агента), вона скасовує налаштування пріоритету, налаштоване попередньою діяльністю черги.
- Активність Set Contact Priority наразі не підтримується для вихідних та кампанійних контактів.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі Build and manage flows > Set Contact Priority.
Зворотні заходи
Зворотний виклик
Активність зворотного дзвінка дозволяє абонентам замовляти повторний дзвінок, а не чекати на лінії, що суттєво підвищує задоволеність клієнтів шляхом скорочення часу очікування та мінімізації кількості покинутих телефонів. При активації активність зворотного дзвінка створює завдання в черзі, забезпечуючи доступний агент можливість повернути дзвінок клієнта.
Дизайнер потоку може налаштувати активність так, щоб контакт залишався в початковій черзі, де почався виклик, або призначити його іншій черзі відповідно до вподобань. Якщо зворотний дзвінок залишається в початковій черзі, контакт зберігає свою позицію, навички, пріоритет і контекстні дані, що дозволяє безшовно призначити наступному доступному агенту. Однак, якщо вибрана інша черга, контакт переміщується в кінець вибраної черги без навичок і з пріоритетом за замовчуванням.
Ця активність також дозволяє клієнтам замовляти повторні дзвінки у своїх обраних агентів, додаючи особистості досвіду та підвищуючи задоволення клієнтів. Цього можна досягти, коли активність зворотного виклику слідує за активністю QueueToAgent у потоці. Крім того, активність зворотного дзвінка пропонує опціональну конфігурацію для налаштування автоматичної ідентифікації номера (ANI), що використовується під час процесу зворотного дзвінка. Ця кастомізація допомагає підтримувати послідовність бренду та знижує ймовірність відхилення дзвінка, забезпечуючи впізнаваного абонента ID.
Дизайнер потоку має опцію включити подію CallbackFailed у потік події. Ця подія запускається, коли спроба зворотного виклику невдала, що дозволяє проєктувальнику потоку реалізувати повторні спроби у певні інтервали. Затримку або інтервал між повторними спробами можна налаштувати за допомогою активності Wait, з мінімальним інтервалом повторної спроби 10 секунд і максимумом 72 години. Система підтримує до 10 повторних спроб протягом максимум 14 днів із використанням активності Wait.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі Build and manage flows > Callback.
Заплануйте повторний дзвінок
Активність із запланованим зворотним дзвінком надає потокам можливість надати клієнтам зручність запитувати зворотний дзвінок у визначену майбутню дату та час — усуваючи потребу в негайному зв'язку з агентом. Ця функція покращує досвід клієнта, дозволяючи їм обрати зручне вікно зворотного дзвінка, мінімізуючи сприйнятий час очікування та зменшуючи рівень припинення дзвінків.
Потік повинен захоплювати вхідні дані абонента, такі як бажана дата і час, через підказки DTMF і передавати їх активності після виконання необхідної перевірки введення.
Перед початком, будь ласка, переконайтеся, що Callback Default Entry Point налаштовано в налаштуваннях каналу в Control Hub. Детальніше дивіться у розділі «Налаштувати точку входу для зворотного виклику».
Зворотний дзвінок можна запланувати за допомогою будь-якої телефонної черги — як вхідної, так і вихідної. Для найкращих результатів рекомендується додати активність Відключення одразу після запланованого зворотного дзвінка, щоб переконатися, що поточний дзвінок завершиться коректно після запланованого зворотного дзвінка. Для отримання додаткової інформації про розклад IVR зворотних дзвінків дивіться у розділі Розклад IVR Зворотні дзвінки.
Коли зворотний дзвінок запускається у запитані майбутні дати та час, створюється новий дзвінок або взаємодія. Ця нова взаємодія буде слідувати стандартному потоку, пов'язаному з Call Back Default Entry Point. Якщо спроба зворотного виклику не вдається, потік може автоматично повторити виклик за допомогою обробника подій CallbackFailed , якщо він налаштований у цьому потоку.
Перед передачею вхідних даних у активність слід розглянути наступні валідації вхідних даних:
- Вибір дати — Ви можете обрати будь-яку дату від сьогоднішнього дня до 31 дня в майбутньому. Дата має бути у такому форматі: YYYY-MM-DD (наприклад, 2025-07-18).
- Час початку та завершення часового вікна — обраний вами час має починатися щонайменше через 30 хвилин і тривати Anywhere від 30 хвилин до 8 годин. Будь ласка, використовуйте формат 24-годинного часу (наприклад
, 14:30:00). - Часовий пояс — Ви повинні ввести дійсний часовий пояс у форматі IANA (наприклад
, America/New_York), щоб ми могли зателефонувати вам у потрібний час.
Референсна реалізація надається у вигляді шаблону підпотоку для демонстрації DTMF підказок і базових валідацій, які використовуються разом із діяльністю. Для отримання додаткової інформації дивіться шаблон Запланованого зворотного підпотоку.
Аналіз прогресу дзвінків
Активність аналізу прогресу дзвінків (CPA) дозволяє виявляти автоматизовані системи відповіді та живі людські голоси під час зворотних дзвінків.
Коли спроба зворотного дзвінка стикається з детектором автовідповідача (AMD) або голосовою поштою, система ідентифікує дзвінок як невдалий. Результат виявлення автовідповідачем (AMD) фіксується у вихідній змінній причини обробника подій CallbackFailed. На основі цієї вихідної змінної проєктувач потоку може налаштувати повторення зворотного виклику.
- Для повторного дзвінка CallProgressAnalysis можна розмістити в точці після активності зворотного дзвінка у основному потоку. Для запланованого зворотного дзвінка або особистого запланованого зворотного дзвінка його можна розмістити після NewPhoneContact у основному потоку.
- У потоці подій він підтримується лише в обробнику подій CallbackFailed.
- Якщо в потоці налаштовано опитування клієнтів POST call (активність зворотного зв'язку), воно не буде ініційовано, якщо дзвінок приймається AMD або голосовою поштою. Це запобігає виникненню непотрібних опитувань.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі «Створення та керування потоками» > Аналіз прогресу дзвінків.