- Головна
- /
- Стаття
Дякуємо за відгук.
У цій статті
Надіслати відгук?У цій статті наведено огляд того, як контактний центр Webex обробляє та спрямовує Вхідні взаємодії з агентами. Він охоплює різні типи черг, наприклад, на основі навичок та методи, що не засновані на навичках, та методи маршрутизації, такі як найдовший доступний, круговий та найкращий доступний. Він також пояснює дії потоку, які допомагають адміністраторам керувати взаємодіями, призначати агентів, контролювати потік дзвінків та отримання оновлень черги в режимі реального часу для покращення операцій та клієнтів досвід.
Огляд
У контакт-центрі Webex черга слугує місцем зберігання вхідних взаємодій, таких як телефонія, чат, електронна пошта або соціальні канали. Контакти залишаються в чергах, доки їх автоматично не розподілять між агентами або агенти вручну не заберуть їх для обробки. Крім того, вони підтримують такі функції, як маршрутизація на основі навичок, управління пріоритетами та справедливий розподіл робочого навантаження.
Керівники можуть використовувати черги для спостереження за різними напрямками роботи та покращення обробки завдань у контакт-центрі.
Деякі з ключових переваг ефективного використання черг:
- Кращий клієнтський досвід: Керуйте часом очікування та повідомляйте клієнтів, що вони стоять у черзі на обслуговування.
- Підвищена ефективність: Забезпечте впорядковану обробку дзвінків, зменшуючи хаос та неефективне управління.
- Справедливий розподіл контактів: Рівномірно розподіляйте дзвінки між агентами, щоб запобігти перевантаженню жодного окремого агента.
- Пріоритетна обробка: Дозволити пріоритетність певних дзвінків, таких як VIP-клієнти або термінові питання.
Типи черг
Webex Contact Center підтримує кілька типів черг, що дозволяє використовувати широкий спектр варіантів використання для контакт-центрів будь-якого розміру та складності, для всіх типів носіїв з однаковими можливостями.
Є черги, які враховують навички агентів під час маршрутизації контактів, і черги, які цього не роблять. Ці черги також відрізняються тим, як агенти пов'язані з ними для роботи з контактами.
Існує дві широкі категорії черг:
- Черги, що не базуються на навичках
- Черги на основі навичок
Черги, що не базуються на навичках
Черги, що не базуються на навичках, не враховують навички, пов'язані з агентами. Ви можете налаштувати черги, що не базуються на навичках, за допомогою таких параметрів:
- Завдання команди
- Призначення агентів
Черги, що не базуються на навичках, з призначенням команд
У чергах, що не базуються на навичках, з призначенням команд, ви можете організовувати агентів у команди та об'єднувати ці команди для формування груп розподілу викликів (CDG). Ви можете встановити часову затримку між кожною групою для керування потоком викликів.
Групи розподілу викликів допомагають визначити кілька рівнів агентів, які отримують право на роботу з контактами в цій черзі протягом налаштованих інтервалів часу. Контакти призначаються агентам залежно від рівня їхньої команди. Якщо агенти недоступні, контакти паркуються на попередньо налаштований період, перш ніж розширюватися, щоб включити наступну групу команд. Цей процес триває, доки агент не стане доступним або всі групи не будуть перевірені.
Ви можете створити такі типи команд:
- Окремі команди: Агентів можна організувати в команди, які можуть представляти певну функцію організації, а потім вони можуть стати частиною черг, щоб контакти можна було перенаправляти до агентів у цих командах. Ви можете позначити агента в кількох командах для обробки контактів з різних черг для ефективної маршрутизації.
- Команди, що базуються на можливостях: Команда на основі ємності (CBT) – це функція, яка спрямовує голосові виклики на прямий номер (DN) на основі ємності, де ємність визначає, скільки викликів можна обробляти одночасно. Це дозволяє перенаправляти дзвінки на телефонні номери без необхідності входу агентів у систему, що робить його придатним для сценаріїв, коли на дзвінки відповідає голосова пошта, автовідповідачі або групи пошуку, а не традиційні агенти кол-центру. У цій конфігурації команді не призначено конкретних агентів, і вони не використовують Webex Contact Center Agent Desktop.
У цьому прикладі є три групи розподілу викликів, які дозволяють розширення цільової групи, що означає розширення для більшої кількості агентів у командах протягом налаштованих інтервалів часу.
Перша група розподілу викликів містить КОМАНДУ 1, у якій налаштовано 3 агентів – A1, A2 та A5.
Друга група розподілу викликів містить TEAM 2, у якій налаштовано 3 агентів – A2, A3 та A4.
Третя (і остання) група розподілу викликів містить команду 3, у якій налаштовано 2 агенти – A6 та A7.
Коли контакт поміщається в чергу, система спочатку шукає відповідного агента в першій групі розподілу викликів. Якщо агентів не знайдено, контакт паркується на налаштований період, перш ніж його буде перенесено до наступної групи. Це додає нові команди до існуючих. Цей процес повторюється, доки не буде знайдено збіг або доки не будуть розширені всі групи.
Функція «Перевірити доступність агента» дозволяє контакту миттєво розширити зв’язок до наступної групи розподілу викликів, якщо в поточній групі не знайдено відповідних агентів. Це можна ввімкнути в дії контакту черги <LINK TO section 3.1.1> у потоці.
Таке налаштування призводить до таких сценаріїв:
- A2 належить КОМАНДІ 1 та КОМАНДІ 2. Якщо A2 вибере КОМАНДУ 1 для входу в Agent Desktop, система вважатиме A2 частиною КОМАНДИ 1, а отже, лише першою групою розподілу викликів.
- A5 належить до КОМАНДИ 1, проте також міг бути частиною якоїсь іншої команди в організації, до якої він зараз увійшов. Таким чином, A5 не вважається частиною команди 1 і не пов'язаний з цією чергою.
Черги з призначенням команд надають агентам потужну можливість переміщатися між чергами, просто вибираючи команду під час входу в систему.
Доступні схеми маршрутизації:
Черги без навичок з призначенням агентів
Черги, що не базуються на навичках, – це тип черги, де пул агентів безпосередньо призначається черзі. На відміну від інших типів черг, які опосередковано визначають пул агентів, призначених їм, ці черги дозволяють адміністраторам вибирати агентів безпосередньо та вручну. Наприклад, черги призначень на основі команд призначають агентів на основі їхніх команд, що зареєстровані в системі, а черги призначень на основі навичок підбирають агентів на основі необхідних навичок. Натомість адміністратори можуть безпосередньо додавати агентів до цих черг, щоб стати їх частиною. Це забезпечує простий спосіб керування розподілом агентів без залежності від системних призначень.
Черги з призначенням агентів забезпечують прості, але ефективні алгоритми маршрутизації, які допомагають розподіляти контакти між пулом агентів. Вони не враховують навички агентів у маршрутизації контактів. Однак, агентів можна впорядкувати в кожній черзі, і це враховується під час маршрутизації контактів до них. У цьому контексті команди переважно слугують організаційною конструкцією для керівників, а не фактором у зв'язку між агентом і чергою та рішеннями щодо маршрутизації контактів, що спрощує управління чергою.
Цей тип черги найкраще підходить там, де статичне призначення агентів та управління зв'язком агент-черга є можливим та бажаним для операційного контролю, а вибір алгоритмів маршрутизації підходить для розподілу роботи між агентами. Ці черги також особливо корисні для сценаріїв, коли кілька типів запитів клієнтів потребують спеціалізованої експертизи, яку може обслужити попередньо створений сегмент експертів-агентів.
Однак, складним організаціям контакт-центрів може бути важко вручну керувати призначенням агентів у цих чергах. Вони могли б отримати більше користі від інших типів черг, які пропонують динамічну маршрутизацію та зв'язки між агентом і чергою.
У цьому прикладі черга має набір агентів, зіставлених з нею в певному порядку, наприклад, A4, A9, A7 тощо. Цей порядок відіграє певну роль у певних алгоритмах маршрутизації, які зіставляють вхідні контакти з агентами. Система зіставляє контакти з цими агентами на основі їхньої доступності та обраного алгоритму маршрутизації.
На відміну від черг із призначенням команд, тут відсутнє поняття розширення цілі з часом. Якщо жоден із налаштованих агентів недоступний для маршрутизації цього контакту, він паркується в черзі, доки один із цих агентів не стане доступним для обробки контактів до закінчення часу паркування. Розширення цілі не застосовується до цих черг.
Доступні схеми маршрутизації:
Черги на основі навичок
Черги на основі навичок надають можливість перенаправляти контакти до агентів з потрібними навичками для задоволення їхніх потреб.
Ви можете налаштувати такі типи опцій на основі навичок:
Критерії кваліфікації, призначені черзі
Адміністратори можуть призначати чергам критерії кваліфікації. Черги на основі навичок з критеріями навичок дозволяють адміністраторам налаштовувати необхідні навички безпосередньо в черзі. Усі агенти в організації, які мають усі необхідні навички черги через прямий профіль навичок, неявно стають частиною цієї черги.
Ця конфігурація допомагає адміністраторам бачити в режимі реального часу агентів, що відображаються в черзі, на основі навичок. У таких ситуаціях, як великий або малий обсяг, адміністратори можуть розглянути можливість коригування необхідних навичок черги та профілів навичок агентів, щоб розширити або зменшити пул агентів залежно від потреби.
Цей тип черги відрізняється від черг на основі призначення команд тим, що немає налаштування групи розподілу викликів, а це означає, що команда не відіграє жодної ролі у зв'язку агента з чергою. Більше того, необхідні навички в цій черзі налаштовуються статично, на відміну від черг навичок, що базуються на команді, де потік вводить (статичні або змінні) необхідні навички. Отже, технічно навички є частиною черги, а не самим контактом.
Будь-який агент в організації, який повністю відповідає критеріям навичок черги (маючи навички з прямого профілю навичок), неявно пов'язується з цією чергою. Команда не відіграє жодної ролі у зв'язку агентів з цими чергами. Ці агенти можуть бути частиною будь-якої команди для управлінських та операційних цілей.
Кожен контакт, поставлений у цю чергу, автоматично прийме критерії навичок, визначені в самій черзі. Окремі контакти не можуть визначати або перевизначати власні навички requirements/criteria на відміну від черг на основі навичок із призначенням команди.
У цьому прикладі,
- Тільки агенти A1, A3 та A7 повністю відповідають критеріям кваліфікації, налаштованим у черзі, отже, лише ці агенти будуть пов'язані з цією чергою.
- Агенти A2, A4 та A6, які частково відповідають критеріям, або A5, якому бракує відповідних навичок, не можуть бути пов'язані з цією чергою.
Оновлення профілю навичок агента (так зване перекваліфікацією) таким чином, щоб він відповідав критеріям навичок черги, автоматично та динамічно зробить цього агента частиною цієї черги. Або ж оновлення критеріїв кваліфікації черги таким чином, щоб більше (або менше) агентів задовольняли оновлені критерії кваліфікації, також автоматично та динамічно додаватиме (або видалятиме) агентів з цієї черги.
На відміну від черг із призначенням команд, тут відсутнє поняття розширення цілі з часом. Якщо контакт не може бути зіставлений з жодним із пов’язаних агентів, він паркується в черзі, доки один із цих агентів не стане доступним для обробки контактів до закінчення часу паркування.
Черги на основі навичок найкраще підходять там, де статичне призначення навичок та управління чергою для асоціації агентів є можливим та бажаним для операційного контролю. Вони також підходять, коли вибір алгоритмів маршрутизації відповідає розподілу роботи між агентами. Ці черги також особливо корисні для сценаріїв, де різні типи запитів клієнтів вимагають певних навичок, які може обслужити попередньо сформований сегмент експертних агентів.
Організації зі складними контакт-центрами можуть вважати керування чергою для призначення агентів у чергах на основі навичок простішим порівняно з чергами з призначенням агентів, де кожного агента потрібно додавати до списку вручну, що є громіздким, особливо для більшої організації.
Вимоги до навичок, призначені в потоці
Черги на основі навичок із вимогами до навичок, призначеними в потоці, – це тип черги на основі призначення команд у Webex Contact Center, де набір команд налаштовано на кількох рівнях, які називаються групами розподілу викликів. Агентам, які увійшли до цих налаштованих команд, призначаються контакти з цієї черги на основі рівня групи розподілу викликів, на якому налаштовано їхню команду в черзі, якщо вони також повністю відповідають вимогам до навичок контакту.
У такій черзі команди агентів об'єднуються в групи розподілу викликів з налаштовуваними часовими затримками між ними. Якщо для контакту немає доступного агента, запит паркується, і після затримки маршрутизація розширюється до наступної групи розподілу викликів. Цей процес триває, доки не буде призначено агента або не будуть вичерпані всі групи. Тим часом, якщо під час цього процесу стає доступним агент із попередньо перевіреної групи, цього агента вибирають.
Агенти набувають навичок через профіль навичок, безпосередньо призначений агенту. Навички агента визначаються на основі вибору команди під час входу.
Кожен контакт може за бажанням вказати вимоги до навичок у процесі, які зіставляються з навичками доступних агентів для вибору найбільш підходящого агента.
Крім того, контакти також можуть вказувати послаблення навичок через налаштовані інтервали часу. Це модифікований набір вимог до навичок, який замінює початкові вимоги до навичок контакту через налаштовані інтервали часу. Це дозволяє контакту змінювати (зазвичай використовується для «послаблення») вимог до своїх навичок, перебуваючи в черзі, щоб більше агентів могли відповідати цим послабленим вимогам.
Розширення цільової аудиторії за допомогою груп розподілу викликів може відбуватися одночасно з циклами релаксації навичок – обидва спрямовані на швидше зіставлення запаркованого контакту з відповідними агентами, тим самим зменшуючи загальний час очікування та покращуючи рівень обслуговування в черзі.
Як і черги для некваліфікованих операторів із призначенням команд, вона має три групи розподілу викликів, які дозволяють «розширення цільової аудиторії», тобто розширення для більшої кількості агентів у командах протягом налаштованих інтервалів часу.
- Перша група розподілу викликів містить КОМАНДУ 1, у якій налаштовано 3 агентів – A1, A2 та A5.
- Друга група розподілу викликів містить TEAM 2, у якій налаштовано 3 агентів – A2, A3 та A4.
- Третя (і остання) група розподілу викликів містить команду 3, у якій налаштовано 2 агентів – A6 та A7.
Однак, слід зазначити дві головні речі:
- Кожен контакт, який потрапляє до цієї черги, визначатиме свої вимоги до навичок та можливості їх зниження в процесі роботи.
- Агенти можуть мати налаштовані навички (через профіль навичок – безпосередньо або успадковані від команди, що увійшла в систему).
Хоча A2 налаштовано бути частиною як КОМАНДИ 1, так і КОМАНДИ 2, залежно від вибору команди, який цей агент зробив під час входу, у своєму поточному сеансі він вважається частиною цієї команди, і тому також успадкує профіль навичок (і, отже, значення навичок) від цієї команди (якщо це не буде перевизначено безпосередньою конфігурацією профілю навичок для цього агента).
Це потужна можливість, що надається чергами з призначенням команд, де агенти можуть переміщатися між чергами, просто вибираючи команду під час входу в систему.
У поєднанні з можливістю успадкування налаштувань профілю навичок від вибраної команди, агент також може працювати з різними наборами навичок.
У цьому прикладі,
- Контакти ставляться в чергу з початковою вимогою до навичок (sk_1 >= 6) під час ескалації з потоку, з розслабленням навичок (sk_1 >= 3) після налаштованого інтервалу часу.
- Серед усіх агентів у всіх групах розподілу викликів лише A1, A3, A6 та A7 мають навички, що відповідають початковим вимогам до навичок контактів у черзі.
- Решта агентів або мають навичку (sk_1), але не відповідають вимогам до навичок (наприклад, A2 у КОМАНДІ 1 та A4 у КОМАНДІ 2), або взагалі не мають цієї навички (наприклад, A5, A2 у КОМАНДІ 2).
- З часом, після розслаблення навичок, додаткові A2 та A4 також тепер задовольняють вимоги до "розслаблених" навичок контакту.
Для кожного контакту, який потрапляє до цієї черги, система намагається знайти відповідного агента в першій групі розподілу викликів, який повністю відповідає поточним вимогам до кваліфікації контакту. Якщо відповідного агента не знайдено, контакт паркується на налаштований період, перш ніж відбудеться розширення цільової групи до другої групи розподілу викликів. Усі команди, налаштовані у другій групі розподілу викликів, також додаються до існуючих команд з першої групи. Тепер система намагається знайти відповідного агента в розширеній групі. Зверніть увагу, що під час цього послаблення навичок також оновлюватиме вимоги до навичок контакту через налаштовані інтервали часу, а система використовуватиме оновлені вимоги до навичок для зіставлення з доступними агентами в поточній групі розподілу викликів.
Це продовжується, доки всі налаштовані групи розподілу викликів не будуть розгорнуті та не застосовані всі послаблення навичок, якщо до цього не буде знайдено відповідного агента.
Доступні схеми маршрутизації:
Конфігурація черги
Налаштування черг на основі навичок
Призначення критеріїв кваліфікації черзі
- Створіть навички та, за потреби, динамічні навички.
- Створити профілі навичок.
- Призначте профіль навичок безпосередньо агентам.
- Призначайте динамічні навички безпосередньо агентам. Динамічні навички не призначаються через профілі навичок.
- Створити чергу з типом каналу Телефонія, Чат, Електронна пошта або Соціальні мережі.
- Призначте навички та вимоги до динамічних навичок чергам у Центрі керування.
- Перегляньте список агентів, які можуть обробляти контакти в черзі.
- Виберіть алгоритм маршрутизації: LAA або BAA. Для BAA налаштуйте ваги для навичок володіння майстерністю та динамічних навичок володіння майстерністю, коли це необхідно.
- Додайте дію контакту черги в потік і виберіть цю чергу.
Призначення вимог до навичок черзі
- Створіть навички та, за потреби, динамічні навички.
- Створити профілі навичок.
- Призначте профіль навичок безпосередньо агентам або команді.
- Призначайте динамічні навички безпосередньо агентам. Динамічні навички не призначаються через профілі навичок.
- Створіть команду.
- Додайте агентів до команди.
- Створити чергу з типом каналу: Телефонія, Чат, Електронна пошта або Соціальні мережі.
- Додайте команди до черги в одному або кількох CDG.
- Виберіть шаблон маршрутизації: LAA або BAA.
- Додайте до потоку дію «Контакт черги» та виберіть чергу, для якої налаштовано маршрутизацію на основі навичок. Для отримання додаткової інформації див. Контакт черги.
- Призначення навичок, динамічних навичок та розслаблення навичок у активності «Контакти з чергою». Для BAA налаштуйте ваги для навичок володіння майстерністю та динамічних навичок володіння майстерністю, коли це необхідно.
- Використовуйте функцію «Ескалація активності розподілу викликів» у потоці після черги, щоб швидко перейти до наступної або останньої групи розподілу викликів.
Налаштування черг, що не базуються на навичках
Призначити команду до черги
- Створіть команду.
- Додайте агентів до команди.
- Створити чергу з типом каналу: Телефонія, Чат, Електронна пошта або Соціальні мережі.
- Додайте команди до черги в одному або кількох CDG.
- Виберіть шаблон маршрутизації або LAA.
- Додайте дію контакту черги в потік і виберіть цю чергу.
- Використовуйте функцію «Ескалація активності розподілу викликів» у потоці після черги, щоб швидко перейти до наступної або останньої групи розподілу викликів.
Призначити агента черзі
- Створити чергу з типом каналу: Телефонія, Чат, Електронна пошта або Соціальні мережі.
- Додайте агентів безпосередньо до черг (Примітка: У цьому типі черги не використовуються ні навички, ні команда).
- Виберіть шаблони маршрутизації, такі як «Кругова», «Лінійна» або «Найдовший доступний агент».
Концепції маршрутизації
Сценарій надлишку агента
Сценарій надлишку агента виникає, коли доступних агентів більше, ніж контактів у черзі. У цьому випадку, коли взаємодія з клієнтом (контакт) поставлена в чергу, система негайно намагається знайти відповідного агента для цього конкретного контакту, і якщо відповідний агент знайдено, контакт не потрібно ставити в чергу та чекати, поки відповідний агент стане доступним пізніше.
Щоразу, коли контакт розширюється через групу розподілу викликів або через послаблення навичок, система знову намагається негайно знайти відповідного агента для цього конкретного контакту.
Пошук відповідного агента для певного контакту використовує налаштований шаблон маршрутизації в черзі.
Webex Contact Center пропонує кілька шаблонів маршрутизації для різних типів черг, що дозволяє організаціям оптимізувати обслуговування клієнтів, мінімізуючи час очікування, балансуючи навантаження на агентів і забезпечуючи зв'язок клієнтів з агентами, які мають необхідні навички для задоволення їхніх конкретних потреб. Зверніться до розділу «Шаблони маршрутизації» для отримання детальної інформації про шаблони маршрутизації.
Сценарій надлишку контактів
Маршрутизація надлишку контактів відбувається, коли кількість вхідних взаємодій з клієнтами (або контактами) перевищує кількість доступних агентів. Така ситуація часто виникає в години пік або під час неочікуваних стрибків кількості контактів. Основна мета маршрутизації надлишку контактів полягає в ефективному управлінні цим переповненням, забезпечуючи підтримку стандартів обслуговування клієнтів, незважаючи на надмірний попит. Для агента, який щойно став доступним на певному каналі, маршрутизація надлишкових контактів працює для пошуку та призначення відповідного контакту серед усіх запаркованих контактів у всіх чергах, з якими пов'язаний цей агент.
Ключові стратегії для ефективного маршрутизації контактів за обмеженої доступності агентів:
- Рейтинг черги
Ранжування черг дозволяє адміністраторам визначати відносну важливість черг. Адміністратори можуть визначати ранжування черг, щоб встановити порядок, у якому виклики спрямовуються з черг до агентів, які ввійшли в команди, для кожної команди окремо.
Наприклад, розглянемо, що агенти, які увійшли до команди A, пов’язані з двома чергами – «Виставлення рахунків» та «Продажі». Адміністратори можуть використовувати ранжування черги, щоб призначити вищий рейтинг черзі «Виставлення рахунків», тому, коли контакти потрапляють до черги, контакти з «Виставлення рахунків» будуть перенаправлені агентам, що належать до команди A, а не контактам з черги «Продажі». Це станеться, навіть якщо в черзі «Продажі» можуть бути старіші контакти з вищим пріоритетом, які можуть чекати, – просто тому, що черга «Виставлення рахунків» має вищий рейтинг, ніж черга «Продажі». Тільки коли в черзі «Виставлення рахунків» більше не буде контактів, що очікують, агентам з команди A будуть перенаправлені контакти з черги «Продажі» (та будь-якої іншої), з якою вони пов’язані.
Нижче наведено деякі важливі характеристики ранжування черги:
-
- Якщо ранг призначено лише деяким чергам, виклики в цих чергах матимуть пріоритет над викликами в чергах, для яких ранг не вказано.
- Ранг черги можна встановити максимум для 50 черг для всіх типів медіафайлів зі значенням від 1 до 50, де 1 є найвищим рангом.
- Кільком чергам можна призначити той самий ранг.
- Якщо ввімкнути ранжування черги, черги, яким не призначено жодного явного рангу, вважатимуться нижчими, ніж усі ранжовані черги.
-
Ранжування черги працює в межах одного типу медіа.
Наприклад, якщо «Черга продажу» – це черга голосового медіа-типу з рангом 2, а «Черга підтримки виставлення рахунків» – це черга чату з рангом 1 для команди A, то агенти, доступні в голосовому каналі в команді A, отримують голосовий виклик першими, навіть якщо ранг дорівнює 2.
Однак, розглянемо дві черги чатів для команди B - чергу кредитної картки з рангом у черзі 2 та чергу дебетової картки з рангом у черзі 1. Потім доступним агентам у Команді B спочатку будуть запропоновані контакти з дебетової картки черги.
-
Рейтинг черги не застосовується до команд на основі місткості.
-
- Пріоритет контакту
Коли контакт поміщається в чергу, його пріоритет можна визначити, призначивши ієрархічну важливість у діапазоні від 1 (найвищий) до 10 (найнижчий, за замовчуванням). Така пріоритезація гарантує, що певні контакти обробляються швидше залежно від їхньої важливості, терміновості або стратегічної цінності для організації. Коли агент доступний для обробки наступного контакту серед усіх запаркованих контактів у всіх чергах, з якими пов’язаний агент, контакт з найвищим пріоритетом у всіх чергах перенаправляється до агента (за умови, що задовольняються інші критерії, такі як відповідність навичок та інші).
Для контактів, що стоять у черзі без явного пріоритету, враховується пріоритет за замовчуванням 10 (найнижчий). Серед кількох контактів з однаковим пріоритетом контакт, який перебуває в черзі найдовше, спочатку перенаправляється до доступного та відповідного агента.
- Найдовший контакт у очікуванні
Це базова стратегія, яка гарантує, що найдовший контакт у всіх чергах, з якими пов'язаний агент, буде перенаправлено до цього агента.
Це головний критерій, який визначає контакт, який буде маршрутизовано, коли на обробку очікують кілька контактів у чергах з однаковим рангом у черзі та однаковим пріоритетом контакту.
По суті, маршрутизація надлишкових контактів для агента, який щойно став доступним, означає вибір одного контакту, який:
- має той самий тип носія, що й той, на якому доступний агент
- припаркований у будь-якій з черг, з якими пов'язаний цей агент
- вимоги до кваліфікації яких (якщо такі є) задовольняються цим агентом
- припаркований у черзі, ранг якої вищий за інші черги, як налаштовано в команді агента
- має найвищий пріоритет серед усіх таких контактів
- є найстарішим контактом, що очікує, серед контактів з таким самим пріоритетом
У наведеному вище прикладі, що ілюструє сценарій надлишку контактів, агент A1 увійшов до команди TEAM 1 та став доступним для обробки контактів на кількох типах носіїв.
A1 пов'язаний з 3 чергами – Q1, Q2 та Q3. КОМАНДА 1 також визначила ранжування черги, де Q1 має найвищий рейтинг, потім Q2 та Q3 відповідно.
У всіх цих чергах вже є контакти, для кожного з яких визначено вимоги до навичок та пріоритет.
Тепер сценарій надлишку контактів працює наступним чином:
-
Серед усіх запаркованих контактів у цих чергах лише 4 контакти можна перенаправити до A1 – C2, C7 (з ЧЕРГИ 2) та C3, C8 (з ЧЕРГИ 3).
Тільки вимоги до навичок цих 4 контактів повністю задовольняються навичками A1.
-
Серед цих 4 контактів пріоритет надається контактам з ЧЕРГИ 2 (тобто C2, C7), оскільки ЧЕРГА 2 має вищий рейтинг у черзі.
Зверніть увагу, що хоча ЧЕРГА 1 є чергою з найвищим рангом, жоден з її запаркованих контактів не може бути перенаправлений до A1, оскільки A1 не задовольняє вимоги до їхніх навичок.
-
Між C2 та C7контактом з найвищим пріоритетом є C7. Отже, остаточний вибір — C7, і система спрямовує його до A1.
Це трапляється, навіть якщо C2 було поставлено в чергу раніше, оскільки пріоритет контакту має перевагу над часом перебування в черзі.
Змішані мультимедійні профілі
Завдяки налаштуванню мультимедійного профілю, Webex Contact Center дозволяє агентам обслуговувати контакти через різні типи медіа (голосовий зв’язок, чат, електронна пошта та соціальні мережі). На основі цієї конфігурації агенти отримують канали, що надаються для кожного типу медіа.
Кожен контакт, спрямований до агента, використовує один канал цього типу медіа, поки агент працює над цим контактом. Хоча агенти можуть мати лише один голосовий канал, вони можуть мати до п'яти каналів інших типів медіа.
Налаштування змішаної маршрутизації в мультимедійних профілях дозволяє адміністраторам контролювати, як різні канали можуть використовуватися одночасно для кожного агента. Це дозволяє організаціям приділяти особливу увагу клієнтам, сприяючи підвищенню якості обслуговування, покращенню клієнтського досвіду та підвищенню коефіцієнтів конверсії. Крім того, організації можуть балансувати навантаження між медіаканалами, коли навантаження на деякі канали нерівномірне, що дозволяє ефективно використовувати агентів.
Є три варіанти:
-
Ексклюзивно
-
Змішано
-
Змішаний режим реального часу
Щоб отримати додаткові відомості про налаштування мультимедійних профілів, див. Керування мультимедійними профілями.
Шаблони маршрутизації
На основі кваліфікації
Шаблони маршрутизації на основі навичок у Webex Contact Center спрямовують вхідні звернення клієнтів до агентів на основі конкретних навичок, необхідних для вирішення запиту, таких як володіння мовою або технічні знання. Ці моделі гарантують, що кожен клієнт зв'яжеться з найкваліфікованішим агентом, підвищуючи ефективність обслуговування та задоволеність клієнтів. Переваги включають скорочення часу обробки, покращення показників вирішення проблем та оптимізоване використання ресурсів агентів шляхом узгодження їхньої експертизи з потребами клієнтів.
Маршрутизація на основі навичок може використовувати навички, які агенти отримують з профілів навичок, та динамічні навички, призначені безпосередньо агентам. Динамічні навички представляють атрибути агента, які можуть змінюватися незалежно від профілю навичок агента.
Коли використовуються шаблони маршрутизації на основі навичок, спочатку вимога до навичок контакту (призначеного в потоці) або критерії навичок, призначені черзі, використовуються для фільтрації доступних агентів, чиї навички та динамічні навички відповідають цим вимогам. / критерії повністю. Потім серед відфільтрованих агентів для контакту вибирається один на основі налаштованого шаблону маршрутизації.
Для найкращої доступної маршрутизації, навички володіння та динамічні навички володіння також можуть використовувати ваги, щоб впливати на оцінку, що використовується для вибору агента. Вагові коефіцієнти не впливають на маршрутизацію за принципом «Найдовша доступна»; цей шаблон використовує лише навички та динамічні навички для визначення відповідності агента вимогам.
Найдовше доступно
Найдовший доступний шаблон маршрутизації на основі навичок спрямовує контакт до того агента, чиї навички відповідають вимогам до навичок контакту. / критерії кваліфікації черги повністю, а також хто був доступний найдовше з моменту обробки останнього контакту серед усіх відповідних агентів у цій черзі.
Така схема маршрутизації допомагає рівномірно розподілити роботу між агентами, призначаючи взаємодії тим, хто був доступний найдовше, запобігаючи дисбалансу робочого навантаження. Це допомагає підтримувати справедливість у розподілі роботи, гарантуючи, що жоден агент не буде перевантажений, а інші залишатимуться вільними.
У наведеному вище прикладі є 4 агенти з різними значеннями навичок рівня кваліфікації та без нього.
Розглянемо контакт, який поставлений у чергу на основі навичок зі шаблоном маршрутизації «Найдовший доступний»:
- з вищезазначеними вимогами до навичок, призначеними через потік, або
- з налаштуванням вищезазначених критеріїв навичок у черзі на основі навичок
У цьому сценарії:
-
Тільки агенти, які повністю відповідають вимогам щодо навичок контакту / Для маршрутизації враховуються критерії кваліфікації черги. Тільки агенти A1, A2 та A4 відповідають вимогам щодо навичок контакту / критерії навичок у черзі повністю.
Агент A3 не відповідає вимогам. У випадку критеріїв навичок, призначених черзі, A3 навіть не пов'язаний з чергою.
-
Серед A1, A2 та A4 контакт буде спрямовано до агента, який доступний найдовше – A1, який був доступний протягом 10 хвилин, довше, ніж A2 або A4.
Оскільки контактною особою було призначено A1, A1 більше не буде агентом з найдовшим терміном дії на всіх медіаканалах.
- Наступний контакт з точно такими ж вимогами до навичок буде перенаправлено до наступного доступного агента з найдовшим терміном дії – A2тощо.
Цей шаблон маршрутизації підтримується в таких типах черг на основі навичок:
Найкраще з доступних
Схема маршрутизації на основі найкращих доступних навичок гарантує, що взаємодії з клієнтами спрямовуються до найкваліфікованішого доступного агента. Цей шаблон оцінює не лише наявність необхідних навичок серед агентів, але й рівень володіння цими навичками, обчислюючи бал навичок для визначення найбільш кваліфікованого («найкращого») агента для кожного контакту.
Цей шаблон фільтрує доступних агентів, чиї навички відповідають вимогам до контактних навичок / критерії навичок у черзі повністю. Потім для кожного відповідного агента розраховується бал, використовуючи значення рівня володіння всіма навичками, зазначеними у вимогах до контактних навичок. / критерії кваліфікації черги. Агент з найвищим балом навичок вважається «найкращим» агентом для кожного контакту.
Фактично, сума значень навичок агента, які відповідають вимогам до контактних навичок / критерії майстерності черги визначають бал.
Деякі ключові моменти, які слід зрозуміти:
- Зазвичай, фактичне значення навички використовується для розрахунку балу, оскільки вищий бал навички вказує на сильнішу відповідність. За винятком випадків, коли вимога до навичок використовує оператор «менше ніж дорівнює» ( < =) умова, що значення конкретної навички агента інвертується при розрахунку балу, тобто effective_skill_value = (10) мінус (actual_skill_value). Це робиться для того, щоб нижчий бал означав сильнішу відповідність.
- Коли кілька відповідних агентів мають однаковий бал, вибирається агент з найдовшим доступним терміном служби серед них.
- Для розрахунку балів враховуються лише навички володіння мовою. Будь-які логічні, текстові або перераховані навички у вимогах до навичок контакту / Критерії навичок черги не враховуються для розрахунку балів.
У наведеному вище прикладі є чотири агенти, які мають навички рівня кваліфікації та навички, що не відповідають кваліфікації, з різними значеннями цих навичок.
Розглянемо контакт, який поставлений у чергу на основі навичок зі шаблоном маршрутизації «Найкращий доступний»:
- з вищезазначеними вимогами до навичок, призначеними через потік, або
- з налаштуванням вищезазначених критеріїв навичок у черзі на основі навичок.
У цьому сценарії:
-
Тільки агенти, які повністю відповідають вимогам щодо навичок контакту / Для маршрутизації враховуються критерії кваліфікації черги. Тільки агенти A1, A2 та A4 відповідають вимогам щодо навичок контакту / критерії навичок у черзі повністю.
Агент A3 не відповідає вимогам. У випадку критеріїв навичок, призначених черзі, A3 навіть не пов'язаний з чергою.
-
Серед A1, A2 та A4 розрахунок балів виконується системою на основі вимог до контактних навичок / критерії навичок черги, де враховуються лише навички володіння майстерністю.
Тільки навички, зазначені у вимогах до контактних навичок / критерії навичок роботи в черзі враховуються для розрахунку балів, навіть якщо агенти можуть мати додаткові / інші навички володіння майстерністю.
Також зверніть увагу на інверсію значення навички в розрахунку балів, коли вона менше ніж дорівнює ( < =) використовується умова.
-
Контакт перенаправляється до A2, оскільки це найкращий доступний агент на основі оцінки. Якщо A2 недоступний / зайнятий, контакт буде перенаправлено до наступного найкращого доступного агента з другим найвищим балом тощо.
Однак, у нас є 2 агенти – A1 та A4 з наступним найвищим балом. Контакт перенаправляється до агента з найдовшим доступним терміном між A1 та A4.
Цей шаблон маршрутизації підтримується в таких типах черг на основі навичок:
Маршрутизація без урахування навичок
Контакт-центр Webex також підтримує різноманітні шаблони маршрутизації, що не базуються на навичках, які зосереджені на розподілі вхідних взаємодій з клієнтами без урахування конкретних навичок чи досвіду агентів. На відміну від шаблонів маршрутизації на основі навичок, ці не враховують навички агента та не вимагають від контактної особи чи черги визначення вимог до навичок. / критерії для маршрутизації. Швидше, вони надають пріоритет таким факторам, як доступність, розподіл робочого навантаження та попередньо визначені послідовності, що дозволяє ефективно обробляти контакти на основі операційної логіки, а не компетенцій окремих агентів. Ці шаблони особливо корисні в середовищах, де взаємодії є відносно однорідними або не потребують спеціалізованої обробки.
Найдовше доступно
Шаблон маршрутизації «Найдовший доступний» спрямовує контакт до того агента в черзі, який був доступний найдовше з моменту обробки його останнього контакту серед усіх агентів, доступних і пов’язаних із цією чергою.
Така схема маршрутизації забезпечує справедливий та збалансований розподіл робочого навантаження, призначаючи взаємодії агентам, які найдовше простоювали. Запобігаючи дисбалансу робочого навантаження, це гарантує, що жоден агент не буде перевантажений, а інші залишатимуться вільними. Такий підхід особливо ефективний у періоди стабільного потоку контактів, підтримуючи постійну взаємодію з усім пулом агентів.
Агенти втрачають свої «найдовші доступні» позиції на всіх каналах, коли їм пропонують контакт будь-якого типу медіа. Це означає, що після того, як агент обробить контакт, наступний контакт будь-якого типу носія з черги буде призначено наступному за тривалістю доступному агенту в цій черзі.
У наведеному вище прикладі агент 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.
Ця логіка продовжується, доки контакт не знайде жодного доступного агента до кінця замовлення, і в такому разі його поміщають у чергу.
Цей шаблон маршрутизації підтримується в таких типах черг, що не базуються на навичках:
Маршрутизація на основі агентів
Маршрутизація на основі агентів — це можливість, яка направляє або ставить контакт у чергу безпосередньо до вказаного («бажаного») агента. Пошук агента за адресою електронної пошти агента або його ідентифікатором спрямовує контакт до бажаного агента. Діяльність «Черга до агента» в потоці допомагає досягти маршрутизації на основі агентів. Для отримання додаткової інформації див. активність Черга до агента.
Контакт може бути пов’язаний з одним або кількома бажаними агентами, якими зазвичай можна керувати в зовнішній програмі поза межами Webex Contact Center. Пошук бажаного агента для контакту здійснюється через дію HTTP Request, яка отримує зіставлення із зовнішньої програми. Щоб спрямувати або припаркувати контакт для потрібного агента, налаштуйте дію «Додати до агента в чергу», використовуючи ідентифікатор агента в контакт-центрі Webex або адресу електронної пошти. Контакт також можна припаркувати для бажаного агента, якщо цей бажаний агент зараз недоступний.
Маршрутизація на основі агентів корисна в таких сценаріях:
- Бажана маршрутизація агента: Клієнт може призначити контакти спеціалізованим агентам або менеджерам з взаємодії з клієнтами. У таких сценаріях маршрутизація на основі агентів спрямовує контакти безпосередньо до цього бажаного агента.
- Маршрутизація останнього агента: Коли контакт кілька разів передзвонює до контакт-центру для взаємодії з агентом, маршрутизація на основі агента може спрямувати контакт до останнього агента, який обробляв цей контакт.
В обох випадках використання дані контакту та зіставлення агента зберігаються поза межами контакт-центру Webex.
Можливості черг та маршрутизації у Flow
У Webex Contact Center широкий спектр можливостей маршрутизації, організації черги та керування викликами можна координувати за допомогою потоків.
Різноманітні дії потоку та обробники подій, що надаються в конструкторі потоків, можна розмістити в потоці для ефективного керування життєвим циклом вхідних та вихідних контактів.
Щоб отримати додаткові відомості про налаштування та використання потоків, див. Створення та керування потоками за допомогою Flow Designer.
Діяльність у черзі
Контакт у черзі
Дія «Додати контакт до черги» надає можливість додавати контакт до активної черги вхідних повідомлень з організації, щоб його можна було зіставити та спрямувати до потрібного агента в цій черзі.
За допомогою цієї дії можна керувати такими аспектами черг:
- Пріоритет – Призначення ієрархічної важливості від 1 (найвищий) до 10 (найнижчий, за замовчуванням) контакту, що ставиться в чергу.
- Вимоги до кваліфікації – Встановіть критерії кваліфікації, яким повинні відповідати агенти в черзі на основі кваліфікації, щоб вважатися придатними для маршрутизації контакту.
- Послаблення вимог до навичок – Налаштування, зміна або видалення раніше встановлених вимог до навичок через певний проміжок часу для покращення шансів знайти агента.
- Перевірити доступність агента – Дозволити системі миттєво розширюватися по всіх групах розподілу викликів, де не знайдено доступних агентів, щоб уникнути часу очікування.
Див. Маршрутизаціядля отримання додаткової інформації про те, яку роль відіграють пріоритет, конфігурація навичок та доступність агента в маршрутизації контактів.
Після того, як дія «Контакт у черзі» успішно поставить контакт у чергу,
Якщо відповідний агент вже доступний, система намагається спрямувати контакт до агента.
Це перериває виконання основного потоку, і подальші події можуть запускати відповідні потоки подій, якщо вони налаштовані.
Якщо відповідного агента не знайдено, контакт ставиться в чергу та очікує, поки з'явиться відповідний агент.
Виконання потоку потім продовжується з діями, доданими після дії контакту з чергою, що надає можливість:
- Відтворити попередньо налаштовану музику для клієнта, який чекає в черзі, додавши дію
PlayMusic. - Зареєструйте зворотний виклик на основі запиту клієнта, додавши активність
Callback. - Переставити в чергу, тобто видалити контакт із поточної черги та додати його до нової черги, додавши ще одну дію
Queue ContactабоQueue to Agent.
- Відтворити попередньо налаштовану музику для клієнта, який чекає в черзі, додавши дію
Коли з'являється відповідний агент, система намагається спрямувати контакт до агента.
У разі успіху це перериває виконання основного потоку, і подальші події можуть запускати відповідні потоки подій, якщо вони налаштовані.
Діяльність контакту черги працює, коли:
- Контакт не призначено та готовий до перенаправлення агенту.
- Черга, навичка та інші конфігурації потоку налаштовані правильно.
- Контакт залишається в межах дозволеної кількості в 25 точок входу та переходів між чергами.
- Контакт залишається в межах дозволеного ліміту в 20 успішних спроб маршрутизації.
Налаштуйте шлях обробки помилок для коректного керування контактами, які потребують альтернативного маршрутизації або додаткової обробки.
У таких випадках дія призводить до збою, і виконання потоку переходить до шляху Обробка помилок.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Контакт черги.
Черга до агента
Дія «Черга до агента» надає можливість додавати контакт безпосередньо до потрібного агента, шукаючи його унікальний ідентифікатор агента або адресу електронної пошти в центрі контактів Webex.
За допомогою цієї дії можна керувати такими аспектами черг:
- Пріоритет - Призначення higher/lower важливість для контактів, що стоять у черзі з тим самим агентом.
- Черга звітів – Визначте чергу, яка використовуватиметься для налаштування, такого як запис і музика в черзі за замовчуванням, а також цілі звітування про контакт.
- Черга відновлення – Визначає чергу, яка використовуватиметься як резервний варіант, коли контакт не вдається перенаправити до вказаного бажаного агента.
Після того, як дія «Перевести агента в чергу» успішно поставить контакт у чергу,
Якщо агент вже доступний, контакт перенаправляється до агента.
Це перериває виконання основного потоку, і подальші події можуть запускати відповідні потоки подій, якщо вони налаштовані.
Якщо агент доступний, але вирішує відмовити, не відповідати або не може отримати контакт, він переміщується до наданої черги відновлення.
У черзі відновлення контакт буде перенаправлено до агента, доступного найдовше, без будь-якої підтримки навичок.
Якщо агент недоступний і вибрано опцію "
Park Contact If Agent Unavailable" зі значенням , контакт паркується та чекає, поки агент стане доступним.Виконання потоку потім продовжується з діями, доданими після дії «Додати до агента в чергу», що дає можливість:
- Відтворити попередньо налаштовану музику для клієнта, який чекає в черзі, додавши дію
PlayMusic. Callbackдіяльність.- Переставити в чергу, тобто видалити контакт із поточної черги та додати його до нової черги, додавши ще одну дію
Queue to AgentабоQueue Contact.
Щойно агент стає доступним, система намагається спрямувати контакт до агента.
Це перериває виконання основного потоку, і подальші події можуть запускати відповідні потоки подій, якщо вони налаштовані.
- Відтворити попередньо налаштовану музику для клієнта, який чекає в черзі, додавши дію
- Якщо агент недоступний, а опція "
Park Contact If Agent Unavailable" не вибрана , черга завершується невдачею.
Дія «Черга до агента» працює, коли:
- Контакт не призначено та готовий до перенаправлення агенту.
- Ідентифікатор бажаного агента або адреса електронної пошти дійсні.
- Чергу звітів та чергу відновлення налаштовано правильно.
- Бажаний агент увійшов у систему, доступний та готовий обробити контакт.
Налаштуйте чергу відновлення, щоб забезпечити безперебійне маршрутизування контакту, коли бажаний агент недоступний.
У таких випадках дія призводить до збою, і виконання потоку переходить до шляху Обробка помилок.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Черга до агента.
Група розподілу викликів для ескалації
Дія «Ескалація групи розподілу викликів» підтримується лише для черг з призначенням командита надає можливість негайно оновлювати групу розподілу викликів для контакту, замість очікування автоматичного розширення оновлення для наступної групи після налаштованого періоду очікування. Це дозволяє швидко перенаправити контакт до всіх відповідних агентів у черзі.
За допомогою дії «Ескалація групи розподілу викликів» контакт можна ескалювати до:
- Наступна група— Розширення набору команд, щоб включити ті, що додані до групи розподілу наступних викликів.
- Остання група— Розширення набору команд, щоб включити всі команди, зіставлені з усіма групами розподілу викликів, налаштованими для черги.
Дія «Ескалація групи розподілу викликів» працює, коли:
- Контакт вже поставлений у чергу та готовий до ескалації.
- Контакт поміщено в чергу, яка використовує групи розподілу викликів.
Для черг, що використовують стандартну маршрутизацію, продовжуйте розподіляти контакти за допомогою налаштованої поведінки маршрутизації черги.
У таких випадках дія призводить до збою, і виконання потоку переходить до шляху Обробка помилок.
Розглянемо приклад сценарію, коли контакт потрапляє до черги з трьома групами розподілу викликів, кожна з яких оновлюється через 30 секунд.
У частинах команд CDG 1 та CDG 2немає доступних агентів, а в TEAM 3 доступний агент, який належить до групи розподілу останніх викликів.
Коли дія «Ескалація групи розподілу викликів» не використовується в потоці, це призводить до тривалого часу очікування, як показано нижче:
Час очікування можна зменшити, використовуючи дію «Ескалація групи розподілу викликів», яка використовується наступним чином:
Залежно від вибраного параметра Наступна група або Остання група, час очікування контакту значно скорочується, як показано нижче:
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Група розподілу викликів «Ескалація».
Інформація про чергу Діяльність
Отримати інформацію про чергу
Дія «Отримати інформацію про чергу» надає можливість отримувати інформацію про чергу в режимі реального часу для певного контакту, таку як:
- Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо ще не поставлено в чергу.
- Орієнтовний час очікування (EWT) або тривалість, протягом якої завдання, за оцінками, перебуватиме в черзі, перш ніж на нього буде дано відповідь.
- Кількість агентів, які увійшли в систему або доступні в поточній групі розподілу викликів контакту.
- Кількість агентів, які увійшли в систему або доступні у всіх групах розподілу викликів для вибраної черги.
- Тривалість очікування найстарішого контакту в черзі.
Ці деталі доступні під час виконання потоку як змінні виводу діяльності.
Для отримання додаткової інформації про використання активності, детальне визначення та метод розрахунку для кожної деталі черги див. Створення та керування потоками > Отримати інформацію про чергу.
Деякі способи використання інформації про чергу можуть бути:
- Оголошувати клієнту позицію контакту в черзі та орієнтовний час очікування, поки він чекає на маршрутизацію.
- Щоб вирішити, чи можна зареєструвати зворотний виклик для клієнта, якщо очікуваний час очікування занадто довгий.
- Щоб перенаправити контакт до наступної групи розподілу викликів (CDG), якщо в командах, зіставлених з поточною CDG, немає доступних агентів.
Дія «Отримати інформацію про чергу» працює, коли вибрана змінна перетворюється на дійсну чергу.
Налаштуйте шлях обробки помилок для коректного керування випадками, коли вибрана змінна потребує перевірки або не потрапляє до доступної черги.
- Контакт (ще) не поставлений у чергу, коли виконується операція «Отримати інформацію про чергу».
- Контакт поставлено в чергу, яка не підтримує концепцію груп розподілу викликів.
У цих випадках значення -1 у цих вихідних полях вказує на те, що ця інформація не застосовується.
Розглянемо приклад сценарію, коли клієнта слід повідомляти про довге EWT у черзі кожні 15 секунд, проведених у черзі.
Цього можна досягти за допомогою дії «Отримати інформацію про чергу» в потоці наступним чином:
Розширена інформація про чергу
Дія «Розширена інформація про чергу» надає можливість отримувати інформацію про чергу в режимі реального часу для певного контакту, додатково враховуючи критерії кваліфікації контакту, такі як:
- Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо ще не поставлено в чергу.
- Кількість агентів, які увійшли в систему або доступні в поточній групі розподілу викликів контакту, що відповідають заданим критеріям кваліфікації.
- Кількість агентів, які увійшли в систему або доступні у всіх групах розподілу викликів для вибраної черги, що відповідають заданим критеріям кваліфікації.
- Поточна група розподілу викликів, де контакт запарковано у вказаній черзі.
- Загальна кількість груп розподілу викликів у наданій черзі.
Ці деталі доступні під час виконання потоку як змінні виводу діяльності.
Для отримання додаткової інформації про використання активності, детальне визначення та метод розрахунку для кожної деталі черги див. Створення та керування потоками > Розширена інформація про чергу.
Деякі способи використання розширеної інформації про чергу можуть бути:
- Оголосити клієнту позицію контакту в черзі, поки він очікує на маршрутизацію.
- Щоб перенести контакт до наступної групи розподілу викликів, якщо в командах, зіставлених з поточною групою розподілу викликів, немає доступних агентів, які відповідають критеріям навичок.
- Щоб вирішити, чи можна зареєструвати зворотний виклик для клієнта, якщо в жодній групі розподілу викликів не зареєстровано жодного оператора, який відповідає критеріям навичок.
Дія «Розширена інформація про чергу» працює, коли:
- Інформація про чергу запитується для черг, де вимоги до навичок налаштовані в процесі, а не як критерії навичок на рівні черги.
- Якщо контакт вже в черзі, інформація запитується для тієї ж черги, де зараз знаходиться контакт.
- Контакт ставиться до черги, а не безпосередньо до бажаного агента.
Налаштуйте шлях обробки помилок для керування запитами, які не відповідають цим вимогам.
У таких випадках дія призводить до збою, і виконання потоку переходить до шляху Обробка помилок.
Розглянемо приклад сценарію, коли клієнта слід повідомити про отримання зворотного виклику, враховуючи, що немає доступних агентів, які відповідають критеріям кваліфікації.
Цього можна досягти, використовуючи дію «Розширена інформація про чергу» в потоці наступним чином:
Дії з керування дзвінками
Встановити ідентифікатор абонента
Дія «Встановити ідентифікатор абонента» використовується для визначення ідентифікатора абонента, який має відображатися під час виклику. Дія «Встановити ідентифікатор абонента» має використовуватися лише в потоках подій PreDial як термінальна дія, що позначає кінець потоку подій.
Дія «Встановити ідентифікатор абонента» дозволяє налаштувати необхідну автоматичну ідентифікацію номера (ANI) на основі служби ідентифікації набраного номера (DNIS), типу операції або типу учасника.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Встановити ідентифікатор абонента.
Керування записом
Діяльність «Керування записом» призначена для використання разом із дією «Меню» для отримання згоди на запис від абонента. Це забезпечує дотримання правил або політик, що вимагають явної згоди перед початком запису, бездоганно інтегруючи цей крок у робочий процес.
Активність Menu IVR повинна фіксувати згоду користувача в булеву змінну, яка буде призначена як вхідні дані для активності Recording Control. Якщо клієнту потрібно повідомити про згоду користувача у звіті про згоду, значення згоди слід зберігати у звітній глобальній змінній. Або ж можна використовувати локальну змінну, якщо звітування не потрібне. Такий підхід забезпечує орендарям та клієнтам підвищену гнучкість в управлінні та ефективному використанні змінних.
Коли цю дію додано до потоку, згода користувача має пріоритет над налаштуваннями конфігурації на рівні клієнта, черги або розкладу запису.
Порядок пріоритету такий:
- Якщо згода користувача в процесі роботи має значення «Так», то виклик записується незалежно від конфігурації запису, встановленої на рівні клієнта, черги або розкладу запису.
- Якщо користувач не дає згоди у відповідь на дію, то виклик не записується, незалежно від конфігурації запису, встановленої на рівні клієнта, черги або розкладу запису.
- Якщо дія керування записом не налаштована в потоці, але конфігурація встановлена на Так на будь-якому іншому рівні, такому як клієнт, черга або розклад запису, тоді виклик записується.
- Якщо дія керування записом не налаштована в потоці, а конфігурація має значення «Ні» на всіх рівнях, таких як клієнт, черга та розклад запису, виклик не записується.
Цей контроль запису можна проілюструвати наступним чином:
Крім того, такі конфігурації запису, як «Продовжити під час переадресації», «Пауза: увімкнено відновлення», «Тривалість паузи» та інші, залишаються застосовними відповідно до існуючої ієрархії, включаючи рівні орендаря, черги або розкладу запису.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Керування записом.
Сліпий трансфер
Сліпа переадресація – це процес, під час якого контакт ефективно перенаправляється на зовнішній номер (DN) через систему IVR, що усуває необхідність участі агента.
Дія «Сліпа переадресація» використовується, коли виклик потрібно переадресувати на зовнішній або сторонній DN. Це термінальна операція, тому потік завершується після виконання передачі.
Дія «Сліпа передача» не підтримується, коли потік виконується для консультації.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Сліпий переказ.
Перехід через мост
Дія «Мостова передача» дозволяє тимчасово перевести контакт на зовнішній отримувач, водночас потік зберігає контроль над викликом. Зовнішнім пунктом призначення може бути зовнішній міст або служба інтерактивного голосового відповіді (IVR).
Коли зовнішній абонент завершує виклик, потік викликів продовжується далі за потреби, наприклад, ставлячи його в чергу до агента.
Дія «Переадресація мосту» видаляє контакт із черги під час його переадресації до сторонньої системи IVR або автоматичного розподілу викликів (ACD). Якщо контакт не обробляється сторонньою системою, його можна повторно поставити в початкову чергу, забезпечуючи належну обробку контакту в робочому процесі.
Наприклад, припустимо, що контакт-центр має ресурси агента Webex Contact Center та ресурси агента на зовнішньому кол-центрі або в АТС (PBX). Клієнт хоче поставити виклик у чергу агентів контакт-центру Webex на короткий період (скажімо, 60 секунд). Якщо протягом цього періоду жоден агент недоступний, виклик може бути перенаправлений через міст (з неявним видаленням з черги) до зовнішнього кол-центру для обробки контакту.
- Дія мостового переадресування не підтримується у вихідних потоках викликів та потоках подій.
- Контакти, які вже призначені агенту, не підтримуються для переадресації через Bridge Transfer через цей процес.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Мостова передача.
Відключити контакт
Дія «Відключити контакт» надає можливість відключити або завершити активний контакт безпосередньо з потоку.
Це термінальна активність, приєднана до потоку, і може бути корисною для завершення контактів без втручання агента, що підходить для потоків помилок або після реєстрації зворотного виклику для клієнта.
Залежно від конфігурації, опитування або зворотний зв'язок після дзвінка запускається, коли контакт завершується через цю дію.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Роз’єднати контакт.
Встановити пріоритет контакту
Дія «Встановити пріоритет контакту» сприяє ефективному керуванню пріоритетом контактів у потоці, дозволяючи призначати контактам певні рівні пріоритету. Це дозволяє надавати певним контактам вищу або нижчу важливість, забезпечуючи їхню відповідну маршрутизацію порівняно з іншими контактами, що очікують, коли агенти стають доступними. Така гнучкість дозволяє точно контролювати пріоритетність контактів протягом усього процесу.
Пріоритет встановлюється шляхом призначення ієрархічного рівня важливості від 1 (найвищий) до 9 (найнижчий). Контакти з найвищим пріоритетом перенаправляються раніше за ті, що мають нижчий пріоритет. Коли кілька контактів мають однаковий рівень пріоритету, контакт, який чекав найдовше, спочатку перенаправляється до наступного доступного та відповідного агента. Ця система гарантує, що контакти з вищим пріоритетом отримуватимуть оперативну увагу, зберігаючи при цьому справедливий розподіл між контактами з однаковим пріоритетом на основі часу очікування.
- Дію «Встановити пріоритет контакту» можна розмістити в будь-якій точці основного потоку або потоку події.
- Якщо дію «Встановити пріоритет контакту» налаштовано перед дією постановки в чергу (наприклад, «Додати контакт до черги» або «Додати до агента до черги»), її налаштування пріоритету може бути перевизначено будь-яким пріоритетом, явно налаштованим у наступних діях постановки в чергу. Однак, якщо наступна дія черги не вказує пріоритет, буде застосовано пріоритет контакту, встановлений попередньою дією «Встановити пріоритет контакту».
- І навпаки, якщо дію «Встановити пріоритет контакту» налаштовано після дії постановки в чергу (наприклад, «Додати контакт до черги» або «Додати до черги до агента»), вона замінить налаштування пріоритету, налаштоване попередньою дією постановки в чергу.
- Дія «Встановити пріоритет контакту» наразі не підтримується для контактів зовнішніх викликів та кампанії.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Встановити пріоритет контакту.
Діяльність зворотного дзвінка
Зворотній виклик
Дія зворотного виклику дозволяє абонентам запитувати зворотний виклик, а не чекати на утримуванні, що значно підвищує задоволеність клієнтів, скорочуючи час очікування та мінімізуючи рівень перерв. Після активації функція зворотного виклику (Callback) створює завдання в черзі, гарантуючи, що доступний агент зможе відповісти на дзвінок клієнта.
Розробник потоку може налаштувати дію так, щоб контакт залишався в початковій черзі, звідки виник виклик, або призначався до іншої черги на основі налаштувань. Якщо зворотний виклик залишається в початковій черзі, контакт зберігає свою посаду, навички, пріоритет та контекстні дані, що дозволяє безперешкодно призначити його наступному доступному агенту. Однак, якщо вибрано іншу чергу, контакт буде переміщено в кінець вибраної черги без навичок та з пріоритетом за замовчуванням.
Ця функція також дозволяє клієнтам запитувати зворотні дзвінки від своїх обраних агентів, додаючи персоналізованого підходу та підвищуючи задоволеність клієнтів. Цього можна досягти, коли дія зворотного виклику слідує за діяльністю QueueToAgent у потоці. Крім того, дія зворотного виклику пропонує додаткову конфігурацію для налаштування автоматичної ідентифікації номера (ANI), яка використовується під час процесу зворотного виклику. Таке налаштування допомагає забезпечити узгодженість бренду та зменшує ймовірність відхилення виклику, забезпечуючи розпізнаваний ідентифікатор абонента.
Дизайнер потоку має можливість включити подію CallbackFailed до потоку подій. Ця подія спрацьовує, коли спроба зворотного виклику не вдається, що дозволяє розробнику потоку реалізувати повторні спроби через певні інтервали. Затримку або інтервал між повторними спробами можна налаштувати за допомогою дії «Очікування», з мінімальним інтервалом повторних спроб 10 секунд і максимальним 72 годинами. Система підтримує до 10 повторних спроб протягом максимального періоду 14 днів за допомогою дії «Очікування».
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Зворотний виклик.
Запланувати зворотний дзвінок
Дія «Запланований зворотний виклик» дозволяє потоку пропонувати клієнтам зручність запиту зворотного виклику у певну майбутню дату та час, усуваючи необхідність негайного з’єднання з агентом. Ця функція покращує враження клієнтів, дозволяючи їм вибрати зручне вікно зворотного дзвінка, тим самим мінімізуючи сприйнятий час очікування та зменшуючи рівень перерв дзвінків.
Потік повинен фіксувати вхідні дані абонента, такі як бажана дата та час, за допомогою підказок DTMF та передавати їх до дії після виконання необхідних перевірок вхідних даних.
Перш ніж розпочати, переконайтеся, що Точка входу зворотного виклику за замовчуванням налаштована в розділі Налаштування каналу в Центрі керування. Для отримання додаткової інформації див. Налаштування точки входу зворотного виклику.
Зворотний виклик можна запланувати, використовуючи будь-яку телефонну чергу — вхідну чи вихідну. Для досягнення найкращих результатів рекомендується додати дію Disconnect одразу після дії Scheduled Callback, щоб забезпечити коректне завершення поточного виклику після запланованого зворотного виклику. Щоб отримати додаткові відомості про планування зворотних викликів IVR, див. Планування зворотних викликів IVR.
Коли зворотний виклик спрацьовує у запитувану майбутню дату та час, створюється новий виклик або взаємодія. Ця нова взаємодія відбуватиметься за стандартним потоком, пов’язаним із точкою входу зворотного виклику за замовчуванням. Якщо спроба зворотного виклику не вдається, потік може автоматично повторити спробу виклику за допомогою обробника події CallbackFailed, якщо це налаштовано в цьому потоці.
Перед передачею вхідних даних до дії слід врахувати такі перевірки вхідних даних:
- Вибір дати — ви можете вибрати будь-яку дату від сьогоднішньої до 31 дня в майбутньому. Дата має бути в такому форматі: РРРР-ММ-ДД (наприклад, 2025-07-18).
- Час початку та завершення часового вікна — вибраний вами час має починатися щонайменше через 30 хвилин від теперішнього моменту та може тривати від 30 хвилин до 8 годин. Будь ласка, використовуйте 24-годинний формат часу (наприклад,
14:30:00). - Часовий пояс — ви повинні ввести дійсний часовий пояс у форматі IANA (наприклад,
America/New_York), щоб ми могли зателефонувати вам у потрібний час.
Довідкова реалізація надається у вигляді шаблону підпотоку для демонстрації підказок DTMF та основних перевірок, що використовуються разом з діяльністю. Для отримання додаткової інформації див. Шаблон підпотоку запланованого зворотного виклику.
Аналіз прогресу дзвінків
Аналіз виконання викликів (CPA) дозволяє виявляти автоматизовані системи відповіді та живі людські голоси під час зворотних викликів.
Коли під час спроби зворотного дзвінка виникає сигнал виявлення автовідповідача (AMD) або голосової пошти, система ідентифікує дзвінок як невдалий. Результат виявлення автовідповідача (AMD) фіксується у вихідній змінній reason обробника події CallbackFailed. На основі цієї вихідної змінної дизайнер потоку може налаштувати повторні спроби зворотного виклику.
- Для ввічливого зворотного виклику, CallProgressAnalysis можна розмістити в точці після дії Callback в основному потоці. Для запланованого зворотного виклику або персонального запланованого зворотного виклику його можна розмістити після NewPhoneContact в основному потоці.
- У потоці подій це підтримується лише в обробнику подій CallbackFailed.
- Якщо в процесі налаштовано опитування клієнтів після дзвінка (дія зворотного зв'язку), воно не буде ініційовано, якщо на дзвінок відповість AMD або голосова пошта. Це запобігає проведенню непотрібних опитувань.
Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. Створення та керування потоками > Аналіз прогресу виклику.
Огляд
У контактному центрі Webex черга служить зоною утримання для вхідних взаємодій, таких як телефонія, чат, електронна пошта або соціальні канали. Контакти паркуються в чергах, поки вони не будуть автоматично розподілені агентам або агентам, які вручну заберуть їх для обробки. Крім того, вони підтримують такі функції, як маршрутизація на основі навичок, управління пріоритетами та справедливий розподіл навантаження.
Керівники можуть використовувати черги, щоб спостерігати за різними напрямками роботи та покращувати спосіб вирішення завдань у контакт-центрі.
Деякі з ключових переваг ефективного використання черг:
- Кращий досвід роботи з клієнтами: керуйте часом очікування та повідомляйте клієнтам, що вони стоять у черзі, щоб отримати допомогу.
- Підвищення ефективності: Переконайтеся, що дзвінки обробляються впорядковано, зменшуючи хаос та неправильне управління.
- Справедливий розподіл контактів: рівномірно розподіляйте дзвінки між агентами, щоб запобігти перевантаженню будь-якого окремого агента.
- Пріоритетна обробка: Дозволити пріоритетність певних дзвінків, таких як VIP-клієнти або термінові проблеми.
Види черг
Контактний центр Webex підтримує декілька типів черг, які забезпечують широкий спектр випадків використання для контактних центрів будь-якого розміру та складності, для всіх типів носіїв з єдиними можливостями.
Є черги, які враховують навички агента в маршрутизації контактів, і черги, які не роблять цього. Ці черги також відрізняються з точки зору того, як агенти пов'язані з ними для роботи над контактами.
Існує дві широкі категорії черг:
- Черги, не засновані на навичках
- Черги на основі навичок
Черги, не засновані на навичках
Черги, не засновані на навичках, не враховують навички, пов'язані з агентами. Ви можете налаштувати черги, не засновані на навичках, за допомогою таких параметрів:
- Командні завдання
- Призначення агента
Черги, не засновані на навичках, з командними завданнями
У чергах, що не засновані на навичках із призначенням команди, ви можете організувати агентів у команди та об'єднати ці команди, щоб сформувати групи розподілу викликів (CDG). Ви можете встановити затримку часу між кожною групою, щоб керувати потоком дзвінків.
Групи розподілу викликів допомагають визначити кілька рівнів агентів, які можуть працювати з контактами в цій черзі протягом налаштованих інтервалів часу. Контакти признача ються агентам залежно від рівня їх команди. Якщо агентів немає, контакти припарковуються на попередньо налаштовану тривалість, перш ніж розширити, щоб включити наступну групу команд. Цей процес триває до тих пір, поки агент не буде доступний або не буде перевірено всі групи.
Ви можете налаштувати такі типи команд:
- Окремі команди: Агенти можуть бути організовані в команди, які можуть представляти певну організаційну функцію, яка потім може стати частиною черг, щоб контакти могли бути спрямовані до агентів у цих командах. Ви можете позначити агента до кількох команд, щоб обробляти контакти з різних черг для ефективної маршрутизації.
- Команди на основі ємності: Команда на основі ємності (CBT) - це функція, яка спрямовує голосові дзвінки на прямий номер на основі ємності (DN), де ємність визначає, скільки дзвінків можна обробляти одночасно. Він дозволяє маршрутизувати дзвінки на телефонні номери, не вимагаючи від агентів входу в систему, що робить його придатним для сценаріїв, коли на дзвінки відповідають голосова пошта, автовідповідачі або групи пошуку, а не традиційні агенти call-центру . У цьому налаштуванні немає конкретних агентів, призначених для команди, і вони не використовують контактний центр Agent Desktop Webex.
У цьому прикладі є три групи розподілу викликів, які дозволяють цільове розширення, що означає розширення до більшої кількості агентів у різних командах протягом налаштованих часових інтервалів.
Перша група розподілу викликів містить TEAM 1, у якій налаштовано 3 агенти — A1, A2 та A5.
Друга група розсилки викликів містить TEAM 2, у якій налаштовано 3 агенти — A2, A3 та A4.
Третя (і остаточна) група розсилки викликів містить TEAM 3, у якій налаштовано 2 агента — A6 та A7.
Коли контакт знаходиться в черзі, система спочатку шукає відповідного агента в першій групі розподілу викликів. Якщо агентів не знайдено, контакт буде припарковано протягом налаштованої тривалості, перш ніж здійснити розширення цілі до наступної групи. Це додає нові команди до існуючих. Цей процес повторюється до тих пір, поки він не знайде відповідність, або всі групи не будуть розширені.
Функція «Перевірити доступність агента» призводить до того, що контакт миттєво розширюється до наступної групи розподілу викликів, якщо у поточній групі не знайдено відповідних агентів. Це можна увімкнути під час дії Контакти черги <LINK TO section 3.1.1>у потоці.
Ця настройка призводить до наступних сценаріїв:
- А2 належить командам 1 та КОМАНДІ 2. Якщо A2 вибирає команду 1 для входуAgent Desktop, система розглядає A2 частиною TEAM 1, а отже, лише першу групу розподілу викликів.
- A5 належить TEAM 1, однак, також міг бути частиною якоїсь іншої команди в організації, в яку вони зараз увійшли. Тому A5 не розглядається як частина TEAM 1 і не пов'язаний з цією чергою.
Черги з призначенням команди забезпечують цю потужну можливість агентам переходити між чергами, просто вибираючи команду під час входу в систему.
Доступний шаблон маршрутизації:
Черги, що не засновані на навичках, із призначенням агентів
Черги, що не засновані на навичках, — це тип черги, де пул агентів безпосередньо призначається до черги. На відміну від інших типів черг, які опосередковано визначають пул призначених їм агентів, ці черги дозволяють адміністраторам вибирати агентів безпосередньо та вручну. Наприклад, черги призначення на основі команд призначають агентів на основі їхніх зареєстрованих команд, а черги призначення на основі навичок відповідають агентам на основі необхідних навичок. На відміну від цього, адміністратори можуть безпосередньо додавати агентів до цих черг, щоб стати частиною черги. Це забезпечує простий спосіб управління розподілом агентів, не покладаючись на системні призначення.
Черги з призначенням агента забезпечують прості, але ефективні алгоритми маршрутизації, які допомагають розподілити контакти між пулом агентів. Вони не враховують навички агентів у маршрутизації контактів. Однак агенти можуть бути замовлені в межах кожної черги, і це враховується при маршрутизації контактів до них. У цьому контексті команди в першу чергу служать організаційною конструкцією для керівників, а не фактором асоціації черги агента та рішень щодо маршрутизації контактів, що спрощує управління чергою.
Цей тип черги найкраще підходить там, де статичне призначення агентів та управління асоці ацією агент-черги є можливим і бажаним для оперативного контролю, а вибір алгоритмів маршрути зації підходить для розподілу роботи між агентами. Ці черги також особливо корисні для сценаріїв, коли кілька типів запитів клієнтів вимагають спеціалізованої експертизи, яку може обслуговувати попередньо створений сегмент експертних агентів.
Однак складним організаціям контакт-центру може бути важко вручну керувати призначеннями агентів у цих чергах. Вони могли б отримати більше користі від інших типів черг, які пропонують динамічну маршрутизацію та асоціації черги агента.
У цьому прикладі черга має набір агентів, зіставлених до неї в певному порядку, наприклад A4, A9, A7 тощо. Цей порядок відіграє роль у конкретних алгоритмах маршрутизації, які відповідають вхід ним контактам агентам. Система зіставляє контакти з цими агентами на основі їх доступності та обраного алгоритму маршрутизації.
На відміну від черг із призначенням команди, немає концепції розширення цілі протягом часових інтервалів. Якщо жоден із налаштованих агентів не доступний для маршрутизації цього контакту, він буде припаркований у черзі, доки один із цих агентів не стане доступним для обробки контактів до тайм-ауту паркування. Цільове розширення не застосовується до цих черг.
Доступні шаблони маршрутизації:
Черги на основі навичок
Черги на основі навичок забезпечують можливість перенаправлення контактів до агентів з правильними навичками для задоволення їхніх потреб.
Ви можете налаштувати наступні типи опцій на основі навичок:
Критерії навичок, присвоєні черзі
Адміністратори можуть призначати чергам критерії навичок. Черги на основі навичок з критеріями навичок дозволяють адміністраторам налаштовувати необхідні навички безпосередньо в черзі. Усі агенти в організації, які мають всі необхідні навички черги через прямий профіль навичок, неявно стають частиною цієї черги.
Ця настройка допомагає адміністраторам мати реальний перегляд агентів, що відображаються в черзі завдяки навичкам. У таких ситуаціях, як великий обсяг або низький обсяг, адміністратори можуть розглянути можливість коригування необхідних навичок черги та профілів навичок агента, щоб розширити або зменшити пул агентів за потреби.
Цей тип черги відрізняється від черг на основі призначення команди тим, що немає налаштувань групи розподілу викликів, що означає, що команда не відіграє жодної ролі в асоціації агента до черги. Більше того, необхідні навички статично налаштовані в цій черзі, на відміну від командних черг нави чок, де потік вводить (статичні або змінні) необхідні навички. Отже, технічно навички є частиною черги, а не самого контакту.
Будь-який агент в організації, який повністю задовольняє критеріям кваліфікації черги (маючи навички з прямого профілю навичок) неявно стає пов'язаним з цією чергою. Команда не відіграє жодної ролі в асоціації агентів з цими чергами. Ці агенти можуть бути частиною будь-якої команди для управлінських та операційних цілей.
Кожен контакт, який знаходиться в черзі в цій черзі, автоматично прийматиме критерії навичок, визначені в самій черзі. Окремі контакти не можуть визначити або перевизначити власні вимоги /критерії навичок, на відміну від черг на основі навичок із призначенням команди.
У цьому прикладі
- Тільки агенти A1, A3 і A7 повністю відповідають критеріям навичок, налаштованим у черзі, о тже, лише ці агенти будуть пов'язані з цією чергою.
- Агенти A2, A4 та A6, які частково відповідають критеріям, або А5, які не мають відповідних навичок, не можуть бути пов'язані з цією чергою.
Оновлення профілю навичок агента (так зване перекваліфікацією) таким чином, щоб він відповідав критеріям кваліфікації черги, автоматично та динамічно зробить цього агента частиною цієї черги. Крім того, оновлення самих критеріїв навичок черги таким чином, щоб більше (або менше) агентів відповідали оновленим критеріям навичок, також автоматично та динамічно додавати (або видаляти) агентів із цієї черги.
На відміну від черг із призначенням команди, немає концепції розширення цілі протягом часових інтервалів. Якщо контакт не вдається співвіднести до жодного з асоційованих агентів, він припарковується в черзі, доки один з цих агентів не стане доступним для обробки контактів до тайм-ауту паркування.
Черги, засновані на навичках, найкраще підходять там, де статичне призначення навичок та управління чергою асоціації агентів є можливим і бажаним для оперативного контролю. Вони також підходять, коли вибір алгоритмів маршрутизації підходить для розподілу роботи між агентами. Ці черги також особливо корисні для сценаріїв, коли різні типи запитів клієнтів вимагають певних навичок, які може обслуговувати попередньо виведений сегмент експертних агентів.
Складним організаціям контактного центру може бути легше керувати чергою до призначення агентів у чергах на основі навичок, порівняно з чергами з призначенням агента, де кожного агента потрібно вручну додати до списку, що є громіздким, особливо для більшої організації.
Вимоги до навичок, поставлені в потоці
Черги на основі навичок з вимогами до навичок, призначеними в потоці, є типом черги на основі командних завдань у контактному центрі Webex, де набір команд налаштовується на кількох рівнях, які називаються групами розподілу викликів. Агентам, які увійшли до цих налаштованих команд, призначаються контакти з цієї черги на основі рівня групи розподілу викликів, на якому їх команда налаштована в черзі, якщо вони також повністю задовольняють вимоги до навичок контакту.
У такій черзі команди агентів групуються в групи розподілу дзвінків з налаштованими затри мками часу між ними. Якщо для контакту немає агента, запит припарковано, і після затримки маршрутизація розширюється до наступної групи розподілу викликів. Цей процес триває до тих пір, поки агент не буде призначений або не вичерпані всі групи. Тим часом, якщо агент у попередньо перевіреній групі стає доступним під час цього процесу, цей агент вибирається.
Агенти набувають навичок через профіль навичок, безпосередньо призначений агенту. Навички аген та визначаються на основі вибору команди під час входу.
Кожен контакт може за бажанням вказати вимоги до навичок у потоці, які відповідають нави чкам доступних агентів для вибору найбільш підходящого агента.
Крім того, контакти також можуть вказати розслаблення навичок через налаштовані проміжки часу. Це модифікований набір вимог до навичок, які перезаписують початкові вимоги до навичок контак ту за налаштованими часовими інтервалами. Це дозволяє контакту змінювати (зазвичай використовується для «розслаблення») своїх вимог до навичок під час стоянки в черзі, щоб більше агентів могли відповідати цим розслабленим вимогам до навичок.
Розширення цілі через групи розподілу дзвінків може відбуватися одночасно з циклами розслаблення навичок - обидва спрямовані на швидке узгодження припаркованого контакту з відповідними агентами, таким чином скорочуючи загальний час очікування та покращуючи рівень обслуговування черги.
Як і некваліфіковані черги з призначенням команди, він має три групи розподілу викликів, які дозволяють «цільове розширення», тобто розширення до більшої кількості агентів у різних командах протягом налаштованих часових інтервалів.
- Перша група розсилки викликів містить 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 у КОМАНДІ 1 та A4 у КОМАНДІ 2), або взагалі не володієте цією навичкою (напр. А5, А2 в КОМАНДІ 2).
- З часом, після розслаблення навичок, додатково A2 та A4 тепер також задовольняють «розслаблені» вимоги до навичок контакту.
Для кожного контакту, який потрапляє в чергу в цю чергу, система намагається знайти відповідного агента в першій групі розподілу викликів, який повністю задовольняє поточні вимоги до навичок контакту. Якщо не знайдено відповідного агента, контакт буде припарковано протягом налаштованої тривалості, перш ніж цільове розширення відбудеться для другої групи розподілу викликів. Усі команди, налаштовані у другій групі розподілу викликів, також додаються до існу ючих команд з першої групи. Тепер система намагається знайти відповідного агента в розширеній групі. Зауважте, що поки це відбувається, розслаблення навичок також оновлюватиме вимоги до навичок контакту через налаштовані проміжки часу, і система використовуватиме оновлені вимоги до навичок для відповідності з доступними агентами в поточній групі розподілу викликів.
Це продовжується до тих пір, поки всі налаштовані групи розподілу викликів не будуть розширені та не будуть застосовані всі розслаблення навичок, якщо раніше не знайдено відповідного агента.
Доступні шаблони маршрутизації:
Налаштування черги
Налаштування черг на основі навичок
Призначте критерії навичок черзі
- Створюйте навички та, якщо потрібно, динамічні навички.
- Створіть профілі навичок.
- Призначте профіль навичок безпосередньо агентам.
- Призначте динамічні навички безпосередньо агентам. Динамічні навички не призначаються через профілі навичок.
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Призначте навички та вимоги до динамічних навичок чергам у Центрі управління.
- Перегляд списку агентів, які можуть обробляти контакти в черзі.
- Виберіть алгоритм маршрутизації LAA або BAA. Для BAA налаштуйте ваги для навичок кваліфікації та динамічних навичок, коли це необхідно.
- Додайте до потоку активність «Контакт у черзі» та виберіть цю чергу.
Призначте вимоги до навичок черзі
- Створюйте навички та, якщо потрібно, динамічні навички.
- Створіть профілі навичок.
- Призначте профіль навичок безпосередньо агентам або команді.
- Призначте динамічні навички безпосередньо агентам. Динамічні навички не призначаються через профілі навичок.
- Створіть команду.
- Додайте агентів до команди.
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Додайте команди до черги в одному CDG або декількох CDG.
- Виберіть шаблон маршрутизації LAA або BAA.
- Додайте до потоку активність «Контакт черги» та виберіть чергу, для якої налаштов ано маршрутизацію на основі навичок. Докладніші відомості див. у статті Кон такти в черзі.
- Призначте навички, динамічні навички та розслаблення навичок у діяльності «Контакт у черзі». Для BAA налаштуйте ваги для навичок кваліфікації та динамічних навичок, коли це необхідно.
- Використовуйте Ескалацію активності розподілу викликів у потоці після черги, щоб швидко перейти до наступної групи розси лки викликів або останньої.
Налаштування черг, не заснованих на навичках
Призначення команди до черги
- Створіть команду.
- Додайте агентів до команди.
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Додайте команди до черги в одному CDG або декількох CDG.
- Виберіть шаблон маршрутизації або LAA.
- Додайте до потоку активність «Контакт у черзі» та виберіть цю чергу.
- Використовуйте Ескалацію активності розподілу викликів у потоці після черги, щоб швидко перейти до наступної групи розси лки викликів або останньої.
Призначення агента до потоку черги
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Додайте агентів безпосередньо до черг (Примітка: ні навички, ні команда не використовуються в цьому типі черги).
- Виберіть шаблони маршрутизації, такі як Круговий або Лінійний або Найдовший доступний агент.
Концепції маршрутизації
Сценарій надлишку агента
Сценарій надлишку агента виникає, коли доступних агентів більше, ніж контактів у черзі. У цьому випадку, коли взаємодія з клієнтом (контакт) знаходиться в черзі, система намагається негайно знайти відповідного агента для цього конкретного контакту, і якщо знайдено відповідного агента, контакт не потрібно припарковувати в черзі та чекати, поки відповідний агент стане доступним пізніше.
Кожного разу, коли контакт зазнає розширення через групу розподілу дзвінків або через розслаблення навичок, система знову намагається негайно знайти відповідного агента для цього конкретного контакту.
Пошук відповідного агента для конкретного контакту використовує налаштований шаблон маршрутизації в черзі.
Контактний центр Webex пропонує кілька шаблонів маршрутизації в різних типах черг, що дозволяє організаціям оптимізувати обслуговування клієнтів, мінімізуючи час очікування, балансуючи навантаження агента та забезпечуючи зв'язок клієнтів з агентами, які мають необхідні навички для задоволення їхніх конкретних потреб. Докладну інформацію про шаблони маршрутизації див. у розділі Шаблон маршрутизації.
Сценарій надлишку контактів
Маршрутизація надлишку контактів виникає, коли кількість вхідних взаємодій з клієнтами (або контактів) перевищує доступні агенти. Така ситуація часто виникає під час пікових періодів або несподіваних стрибків об'єму контакту. Основною метою маршрутизації надлишків контактів є ефективне управління цим переповненням, забезпечуючи підтримку стандартів обслуговування клієнтів, незважаючи на надлишковий попит. Для агента, який щойно став доступним на певному каналі, маршрутизація надлишків контактів працює для пошуку та призначення відповідного контакту серед усіх припаркованих контак тів у всіх чергах, з якими пов'язаний цей агент.
Ключовими стратегіями ефективного виконання маршрутизації контактів з обмеженою доступністю аген тів є:
-
Рейтинг черги
Ранжування черг дозволяє адміністраторам вказати відно сну важливість черг. Адміністратори можуть визначати рейтинг черг, щоб встановити порядок маршрути зації викликів від черг до агентів, які увійшли до команд, на основі кожної команди.
Наприклад, припустимо, що агенти, які увійшли в команду A, пов'язані з двома чергами — «Виставлення рахунків» та «Продажі». Адміністратори можуть використовувати ранжування черги, щоб призначити вищий рейтинг черзі «Виставлення рахунків», тому, коли контакти потрапляють у черги, контакти з «Виставлення рахунків» будуть спрямовані до агентів, що належать до команди A, перш ніж контакти з черг «Продажі». Це станеться, навіть якщо у черзі «Продажі» можуть бути старші контакти з вищим пріоритетом, які можуть чекати - лише тому, що черга «Виставлення рахунків» має вищий рейтинг черги, ніж черга «Продажі». Тільки тоді, коли в черзі «Виставлення рахунків» більше немає контактів, агенти команди А будуть перенаправлені контакти з черги «Продажі» (та будь-якої іншої), з якою вони пов'язані.
Нижче наведено деякі важливі характеристики ранжування черг:
-
- Якщо ранг присвоюється лише деяким чергам, виклики в цих чергах матимуть перевагу над викликами в чергах, для яких ранг не вказано.
- Рейтинг черг можна встановити максимум на 50 черг у всіх типах носіїв із значенням від 1 до 50, з 1 як найвищим рангом.
- Ви можете призначити один і той же ранг декільком чергам.
- Якщо ввімкнути ранжування черг, черги, яким не присвоєно жодного явного рангу, будуть розглядатися нижче, ніж усі ранговані черги.
-
Рейтинг черги працює в межах одного типу медіа.
Наприклад, якщо продаж у черзі — це черга типу голосових медіа з рангом 2, а підтримка виставлення рахунків у черзі — черга чату з рангом 1 для команди A, тоді агенти, які доступні на голосовому каналі в команді А, отримують голосовий дзвінок першими, навіть якщо рейтинг до рівнює 2.
Однак розглянемо дві черги чатів для команди B - черга кредитної картки з чергою 2 і чер га дебетової картки з рангом черги 1. Тоді доступним агентам у команді B спочатку будуть запропоновані контакти з дебетової картки черги.
-
Рейтинг в черзі не поширюється на команди, що базуються на потужності.
-
-
Пріоритет контакту
Коли контакт знаходиться в черзі, його пріоритет можна визначити, призначивши ієрархічну важливість від 1 (найвища) до 10 (найнижча, за замовчуванням). Ця пріоритетність гарантує , що певні контакти вирішуються швидше на основі їх важливості, терміновості або стратегічної цінності для організації. Коли агент доступний для обробки наступного контакту серед усіх припаркованих контактів у всіх чергах, з якими пов'язаний агент, контакт з найвищим пріоритетом у всіх чергах перенаправляється до агента (за умови дотримання інших критеріїв, таких як відповідність навичок та інші).
Для контактів, які перебувають у черзі без явного пріоритету, вважається пріоритет за замовчуванням 10 (найнижчий). Серед кількох контактів, які мають однаковий пріоритет, контакт, який че кає в черзі найдовше, перенаправляється спочатку до доступного та відповідного агента.
-
Найдовший очікуваний контакт
Це базова стратегія, яка гарантує, що найдовший очікуваний контакт у всіх чергах, з якими пов'язаний агент, буде спрямований до агента.
Це кінцевий критерій, який визначає контакт, який буде маршрутизований, коли кілька контактів у чергах з однаковим ранжуванням черги та однаковим пріоритетом контактів чекають на обробку.
По суті, маршрутизація надлишку контактів для агента, який щойно став доступним, означає вибір одного контакту, який:
- має той самий медіа-тип, що і той, на якому доступний агент
- припарковано в будь-якій з черг, з якими пов'язаний цей агент
- чиї вимоги до кваліфікації (якщо такі є) задовольняються цим агентом
- припарковано в черзі, чия ранг вищий, ніж інші черги, налаштовані в команді агента
- має найвищий пріоритет серед усіх таких контактів
- найстаріший контакт, що очікує серед контактів з однаковим пріоритетом
У наведеному вище прикладі, який ілюструє сценарій надлишку контактів, агент A1 увійшов до TEAM 1 і став доступним для обробки контактів на декількох типах медіа.
А1 асоціюється з трьома чергами — Q1, Q 2 і Q 3. TEAM 1 також ви значила рейтинг черг, де Q1 займає найвищий рейтинг, потім Q2 та Q 3 відповідно.
У всіх цих чергах вже припарковані контакти, з вимогами до навичок та пріоритетом, визначеними для кожного контакту.
Тепер сценарій надлишку контактів працює наступним чином:
-
Серед усіх припаркованих контактів у цих чергах лише 4 контакти можуть бути спрямовані на A1 — C2, C7 (з ЧЕРГИ 2) та C 3, C8 (з ЧЕРГИ 3).
Тільки вимоги до кваліфікації цих 4 контактів повністю задовольняються навичками А1.
-
Серед цих 4 контактів пріоритет надається контактам з ЧЕРГИ 2 (тобто C2, C7), оскільки ЧЕРГА 2 має вищий рейтинг черги.
Зверніть увагу, що хоча ЧЕРГА 1 є чер гою з найвищим рейтингом, жоден з його припарков аних контактів не може бути спрямований на A1, оскільки їх вимоги до кваліфікації не задовольняються A1.
-
Між C2 і C7 контакт найвищого пріоритету - C 7. Отже, остаточний вибір - С7, і система направляє його на А1.
Це відбувається, навіть якщо C2 був у черзі раніше, оскільки пріоритет контактів має перевагу над часом у черзі.
Змішані мультимедійні профілі
Завдяки налаштуванню мультимедійного профілю, Контактний центр Webex дозволяє агентам обслуговувати контакти з різними типами медіа (голосовий, чат, електронна пошта та соціальна мережа). На основі цієї конфігурації агенти отримують канали, передбачені для кожного типу носія.
Кожен контакт, спрямований на агента, споживає один канал цього типу медіа, доки агент працює над цим контактом. Хоча агенти можуть мати лише один голосовий канал, вони можуть мати до п'яти каналів інших типів медіа.
Налаштування змішаної маршрутизації в мультимедійних профі лів дозволяє адміністраторам керувати тим, як різні канали можуть використовуватися одночасно для кожного агента. Це дозволяє організаціям надавати віддану увагу клієнтам, сприяючи кращій якості обслуговування, покращенню досвіду клієнтів та кращим коефіцієнтам конверсії. Крім того, організації можуть збалансувати навантаження між ме діа-каналами при нерівномірному навантаженні в деяких каналах, що дозволяє ефективно використовувати агенти.
Є три варіанти:
-
Ексклюзив
-
Змішані
-
Змішаний в реальному часі
Докладніші відомості про налаштування мультимедійних профілів див. у розділі Кер ування мультимедійними профілями.
Шаблони маршрутизації
На основі навичок
Шаблони маршрутизації на основі навичок у контактному центрі Webex спрямовують вхідні взаємодії з клієн тами з агентами на основі конкретних навичок, необхідних для вирішення запиту, таких як володіння мовою або технічна експертиза. Ці моделі гарантують, що кожен клієнт підключається до найбільш кваліфікованого агента, підвищуючи ефективність обслуговування та задоволеність клієнтів. Переваги включають скорочення часу обробки, покращення швидкості вирішення та оптимізоване використання ресурсів агента шляхом узгод ження їхнього досвіду з потребами клієнтів.
Маршрутизація на основі навичок може використовувати навички, які агенти отримують із профілів навичок та динамічних навичок , які присвоюються безпосередньо агентам. Динамічні навички представляють атрибути агента, які можуть змінюватися незалежно від профілю навичок агента.
Коли використовуються шаблони маршрутизації на основі навичок, спочатку вимоги до навичок контакту (призначені в потоці) або критерії навичок, призначені для черги, використовуються для фільтрації доступних агентів, чиї навички та динамічні навички повністю задовольняють цим вимогам/критеріям. Потім серед агентів, які фільтруються, вибирається один для контакту на основі налаштованого шаблону маршрутизації.
Для найкращої доступної маршрутизації, навичок кваліфікації та кваліфікації Динамічні навички також можуть використовувати ваги, щоб вплинути на оцінку, яка використовується для вибору агента. Ваги не впливають на найдовшу доступну маршрутизацію; цей шаблон використовує навички та динамічні навички лише для визначення відповідності аген та.
Найдовший доступний
Шаблон маршрутизації на основі найдовших доступних навичок спрямовує контакт до того агента, навички якого повністю задовольняють вимоги до навичок контакту/критерії навичок черги, і який був доступний найдовше з моменту обробки останнього контакту серед усіх відповідних агентів у цій черзі.
Цей шаблон маршрутизації допомагає рівномірно розподілити роботу між агентами, призначаючи взаємодії тим, хто був доступний найдовше, запобігаючи дисбалансу навантаження. Це допомагає підтримувати справедливість у розподілі роботи, гарантуючи, що жоден агент не перевантажений, а інші залишаються вільними.
У наведеному вище прикладі є 4 агенти, які мають навички кваліфікації та некваліфікації з різними значеннями навичок кваліфікації.
Розглянемо контакт, який знаходиться в черзі до черги, заснованої на навичках, з шаблоном маршрутизації «Найдовша доступність»:
- з вищезазначеними вимогами до навичок, призначеними за допомогою потоку, або
- при цьому вищевказані критерії навичок налаштовуються в черзі на основі навичок
У цьому сценарії:
-
Для маршрутизації враховуються лише агенти, які повністю задовольняють вимоги до навичок контакту/критерії навичок черги. Тільки агенти A1, A2 та A4 повністю задовольняють вимоги до навичок контакту/критерії навичок черги.
Агент А3 не має права. У випадку критеріїв навичок, призначених для черги, A3 навіть не пов'яз аний з чергою.
-
Серед A1, A2 та A4 контакт буде спрямований до найдовшого доступного агента - A1, який доступний протягом 10 хвилин, довше, ніж A2 або A4.
Через те, що A1 буде призначений контакт, A1 більше не буде найдовшим доступним агентом у всіх медіа-каналах.
- Наступний контакт з точно такими ж вимогами до навичок буде спрямований до наступного най довшого доступного агента - A2 тощо.
Цей шаблон маршрутизації підтримується в наступних типах черг на основі навичок:
Найкраще доступне
Шаблон маршрутизації на основі найкращих доступних навичок гарантує, що взаємодія з клієнтами спрямована до найбільш кваліфікованого доступного агента. Ця модель оцінює не тільки наявність необхідних навичок серед агентів, але й рівень кваліфікації цих навичок, обчислюючи оцінку кваліфікації для визначення найбільш кваліфікованого («найкращого») агента для кожного контакту.
Цей шаблон фільтрує доступних агентів, навички яких повністю задовольняють вимоги до навичок контакту/критерії навичок черги. Потім оцінка розраховується для кожного відповідного агента, використовуючи значення квалі фікації всіх навичок, зазначених у вимогах до контактних навичків/ критеріях навичок черги. Агент з найвищим балом кваліфікації вважається «найкращим» агентом для кожного контакту.
Ефективно сума значень навичок агента, які відповідають вимогам до навичок контакту /критеріям навичок черги, визначає оцінку.
Деякі ключові моменти для розуміння:
- Зазвичай фактичне значення навичок використовується для розрахунку балів, оскільки вищий бал навичок вказує на сильніший матч. За винятком випадків, коли вимога до навичок використовує умов у менше, ніж дорівнює (< =), це конкретне значення навичок агента інвертується при розрахунку балів, тобто effective_skill_value= (10) мінус (). actual_skill_value Це робиться для того, щоб менший бал вказував на більш сильний матч.
- Якщо кілька агентів, які відповідають вимогам, мають однаковий бал, вибирається найдовший доступний агент серед них
- Для розрахунку балів враховуються лише навички володіння. Будь-які булеві, текстові або енумні навички у вимогах до навичок контакту/критеріях навичок черги не враховуються для розрахунку балів.
У наведеному вище прикладі є чотири агенти, які мають навички кваліфікації та некваліфікації з різними значен нями навичок кваліфікації.
Розглянемо контакт, який знаходиться в черзі до черги на основі навичок з шаблоном маршрутизації «Найкраще доступне»:
- з вищезазначеними вимогами до навичок, призначеними за допомогою потоку, або
- при цьому вищевказані критерії навичок налаштовуються в черзі на основі навичок.
У цьому сценарії:
-
Для маршрутизації враховуються лише агенти, які повністю задовольняють вимоги до навичок контакту/критерії навичок черги. Тільки агенти A1, A2 та A4 повністю задовольняють вимоги до навичок контакту/критерії навичок черги.
Агент А3 не має права. У випадку критеріїв навичок, призначених для черги, A3 навіть не пов'яз аний з чергою.
-
Серед А1, А2 та А4 розрахунок балів здійснюється системою на основі вимог до навичок контакту/критеріїв навичок черги, де враховуються лише навички кваліфікації.
Для розрахунку балів враховуються лише навички, зазначені у вимогах до контактних навичків /критеріях навичок черги, навіть якщо агенти можуть мати додаткові/інші навички кваліфікації.
Також зверніть увагу на інверсію значення навичок при розрахунку балів, коли використовується умова менша, ніж рівна (< =).
-
Контакт перенаправ ляється на A2, оскільки це найкращий доступний агент на основі оцінки. Якщо A2 не доступний/ зайнятий, контакт буде перенаправлений до наступного найкращого доступного агента з другим найвищим балом тощо.
Однак у нас є 2 агенти — А1 та А4 з наступним найвищим балом. Кон такт направляється до найдовшого доступного агента між А1 та А4.
Цей шаблон маршрутизації підтримується в наступних типах черг на основі навичок:
Маршрутизація без навичок
Контактний центр Webex також підтримує різноманітні моделі маршрутизації, що не засновані на навичках, які зосереджені на розподілі вхідних взаємодій з клієнтами без урахування конкретних навичок або досвіду агентів. На відміну від моделей маршрутизації на основі навичок, вони не враховують навички агента або вимагають контакту чи черги для визначення вимог до навички/критеріїв маршрутизації. Швидше, вони надають пріоритет таким факторам, як доступність, розподіл навантаження та заздалегідь визначені послідовності, що дозволяє ефективно обробляти контакти на основі операційної логіки, а не компетенції окремих агентів. Ці шаблони особливо корисні в середовищах, де взаємо дія відносно рівномірна або не вимагає спеціалізованого поводження.
Найдовший доступний
Шаблон маршрутизації «Найдовший доступний» маршрутизує контакт до того агента у черзі, який був доступний найдовше з моменту обробки останнього контакту серед усіх агентів, які доступні та пов'язані з цією чергою.
Цей шаблон маршрутизації забезпечує справедливий і збалансований розподіл навантаження, при значаючи взаємодії агентам, які не працювали найдовше. Запобігаючи дисбалансу навантаження, це гарантує, що жоден агент не перевантажується, а інші залишаються вільними. Цей підхід особливо ефективний у періоди постійного контактного потоку, підтримуючи послідовну взаємодію у пу лі агентів.
Агенти втрачають свої «найдовші доступні» позиції на всіх каналах, коли їм пропонують контакт будь-якого типу медіа. Це означає, що після того, як агент обробляє контакт, наступний контакт будь-якого типу медіа в черзі буде призначений наступному найдовшому доступному агенту в цій черзі.
У наведеному вище прикладі агент A1 є найдовшим доступним агентом (позиція 1) — або цей агент увійшов першим, або йому не присвоєно контакт довше, ніж будь-якому іншому агенту.
Агенти A2 (позиція 2) та A3 (позиція 3) також доступні, але вони або ввій шли в систему, або обробляли контакти після A1. Усі агенти пов'язані з обома чергами, які мають цей шаблон маршрутизації.
Розглянемо наступний сценарій:
-
У момент T0 голосовий контакт C1 перебуває в черзі та направляється до найдовшого доступного агента, тобто A1.
Через те, що A1 присвоєно C1, A1 більше не є найдовшим доступним аген том у всіх медіа-каналах.
- У момент T1 контакт чату C2 перебуває в черзі та направляється до найдовшого доступного агента, який зараз є A2.
-
Нарешті, в момент T2 інший голосовий контакт С 3 стави ться в чергу і направляється на A3.
А1 та А2 нещодавно отримали контакти — на даний момент саме A3 чекав найдовше.
Цей шаблон маршрутизації підтримується в наступних типах черг, не заснованих на навичках:
Циркулярний
Шаблон кругової маршрутизації розподіляє вхідні контакти між групою доступних агентів у порядку кругової обробки. Коли контакт знаходиться в черзі, система призначає його наступному доступному агенту в черзі на основі заздалегідь визначеної послідовності.
Процес починається з агентів у налаштованому порядку. Перший вхідний контакт присвоюється першому доступному агенту в цій послідовності. Для наступних контактів система вибирає наступного доступного аген та, продовжуючи з того місця, де зупинилася у визначеному порядку черги. Цей шаблон повторюється, проходячи через агентів, але завжди починається після останньої позиції обраного агента.
Такий підхід ефективний для справедливого та рівномірного розподілу контактів між агентами. Це допомагає гарантувати, що жоден агент не перевантажений контактами, і що всі агенти мають рівні можливості послідовно обробляти взаємодії. Однак схема кругової маршрути зації не враховує поточне навантаження або інші фактори, які можуть вплинути на здатність агента обробляти певний контакт.
У наведеному вище прикладі агенти налаштовуються в круговій черзі в наступному порядку: A3 → A4 → A5 → A6 → A1 → A2.
Почнемо з того, що початкова позиція - це перший агент в налаштованому порядку (А3). Коли контакти перенаправляються до агентів у цій черзі, позиція переміщується навколо кола, розташована до агента, який знаходиться поруч у налаштованому порядку до агента, якому був спрямований останній контакт .
Розглянемо наступний сценарій:
-
Перший контакт (C1) знаходиться в черзі, і він перенаправляється до агента A3.
Покажчик оновлюється до наступного агента у налаштованому порядку, тобто A4.
-
Коли другий контакт (С2) знаходиться в черзі, система починає знаходити доступні агенти починаючи з А4, тобто A4 → A5 → A6 → A1 → A2 → A3.
Однак A4 і A5 недоступні (або вони навіть не зареєстровані, або в режимі очікування, або повністю зайняті іншими контактами цього типу носія), тому C2 направляється на наступний доступний агент — A6. Покажчик оновлюється до наступного агента у налаштованому порядку, тобто A1.
-
Аналогічно, третій контакт (С3) спрямований на A1, четвертий контакт (C4) спрямов аний на A2. Вказівник знову знаходиться на А3.
Ця логіка продовжується, і контакти розподіляються між доступними агентами за шаблоном «круговий»/«круговий».
Якщо в черзі припарковані контакти, сценарій надлишку агента буде відповідати наступному агенту, який стане доступним для цього типу медіа, з найбільш пріоритетним і найстарішим контактом серед них.
Це не враховує і не впливає на існуюче значення позиції в цій черзі, яке оновлюється лише тоді, коли маршрутизація надлишків контактів успішно збігається з агентом.
Цей шаблон маршрутизації підтримується в наступних типах черг, не заснованих на навичках:
Зверху вниз
Шаблон маршрутизації зверху вниз розподіляє вхідні контакти між групою доступних та в порядкованих агентів у послідовному порядку. Коли контакт знаходиться в черзі, система завжди проходить через упорядкований список агентів з самого початку і зіставляє контакт з першим доступним агентом (який має вільний доступний канал типу медіа контакту) у цій послідовності.
Це відбувається для кожного контакту, який стоїть в черзі. Контакт намагається зіставити завжди, починаючи зверху (перший налаштований агент) і продовжуючи вниз по списку, доки не буде знайдений відповідний агент.
На відміну від кругового шаблону маршрутизації, немає «вказівника», який динамічно змі нює початкову точку на основі позиції останнього вибраного агента.
Цей підхід ефективний для розподілу контактів між агентами, які впорядковані на основі певного упередження/уподобання, визначеного адміністратором. Це допомагає гарантувати, що агенти у верхній частині завжди вважають за краще обробляти контакти над агентами під ними. Однак шаблон маршрутизації зверху вниз не враховує поточне навантаження або інші фактори, які можуть вплинути на здатність агента обробляти певний контакт.
У наведеному вище прикладі агенти налаштовуються в черзі зверху вниз у наступному порядку: A3 → A4 → A5 → A6 → A1 → A2.
Це означає, що адміністратор хоче, щоб кожен контакт був спрямований до першого агента (A3), якщо він доступний, інакше наступного агента (A4), якщо він доступний тощо, у налаштованому порядку.
Розглянемо наступний сценарій:
- Перший контакт (C1) знаходиться в черзі, і він перенаправляється до агента A3, оскільки A3 знаходиться у верхній частині замовлення.
-
Коли другий контакт (C2) знаходиться в черзі, маршрутизація знову проводиться з верх ньої частини замовлення (завжди починаючи з A3).
Якщо A3 має більшу ємність каналу для цього типу медіа, C2 також спрямовується на A3. Однак, якщо A3 повністю зайнятий на цьому типі носія, маршрути зація йде вниз по списку до формату A4.
- Однак A4 і A5 недоступні (вони або навіть не зареєстровані, або в режимі очікування, або повністю зайняті іншими контактами цього типу носія), тому C2 направляється до наступного доступного агента в порядку зверху вниз — A6.
-
Аналогічно, третій контак т (С3) намагається маршрутизувати, починаючи від A3 вниз до нижньої частини. Першим відповідним агентом буде А1.
Ця логіка продовжується до тих пір, поки контакт не знайде доступних агентів до кінця замовлення, і в цьому випадку він припаркований у черзі.
Цей шаблон маршрутизації підтримується в наступних типах черг, не заснованих на навичках:
Маршрутизація на основі агента
Маршрутизація на основі агентів — це можливість, яка прямує контакт до вказаного («бажаного») агента безпосередньо в чергу. Пошук агента за допомогою адреси електронної пошти агента або ідентифікатора агента спрямовує контакт до бажаного агента. Діяльність «Черга до агента» у потоці допомагає досягти маршрутизації на основі агента. Докладніші відомості див. у статті Діяльність агента у чер зі.
Контакт може мати зіставлення до одного або декількох бажаних агентів, якими зазвичай можна керувати у зовнішньому додатку поза контактним центром Webex. Бажаний пошук агента для контакту здійснюється за допомогою активності запиту HTTP, яка отримує відображення із зовнішньої програми. Щоб маршрутизувати або припаркувати контакт з бажаним агентом, налаштуйте активність «Черга до агента» за допомогою ідентифікатора контактного центру Webex або адреси електронної пошти агента. Контакт також може бути припаркований проти бажаного агента, якщо цей бажаний агент не доступний негайно.
Маршрутизація на основі агентів корисна в наступних сценаріях:
- Бажана маршрутизація аген та: Клієнт може призначити контакти спеціальним агентам або керівникам відносин. У таких сценаріях маршрутизація на основі агента спрямовує контакти безпосередньо до цього бажаного агента.
- Маршрутизація останнього аген та: Коли контакт кілька разів передзвонює контакт-центру для взаємодії з агентом, маршрутизація на основі агента може спрямувати контакт до останнього агента, який обробляв цей контакт.
В обох випадках дані контакту та відображення агента зберігаються поза контактним цен тром Webex.
Персоналізована маршрутизація AI
Персоналізована маршрутизація штучного інтелекту в контактному центрі Webex допомагає спрямувати взаємодію до відповідного агента, який, за прогнозами, забезпечить найкращий результат для вибраного бізнес-результату. Результатом може бути операційний показник, такий як час обробки, або показник клієнта чи бізнесу, такий як задоволеність клієнтів або результат користувацької взаємодії.
Персоналізована маршрутизація штучного інтелекту не замінює черги, команду, навички, пріоритет, потужність або конфігурацію потоку. Контактний центр Webex спочатку визначає, які агенти мають право на взаємодію на основі існуючої конфігурації маршрутизації. Потім маршрутизація штучного інтелекту ранжує відповідних агентів для вибраного результату бізнесу та повертає рекомендований список. Контактний центр Webex пропонує взаємодію з агентом, який найдовше очікує у цьому списку рекомендованих.
Коли використовувати маршрутизацію AI
Використовуйте маршрутизацію AI для черг, які мають достатньо історичних даних взаємодії, варіації результатів агента та чітку бізнес-мету. Перш ніж активувати маршрутизацію AI, скористайтеся перевіркою оптимізації, щоб переглянути очікуваний потенціал покращення для черги. Результат з низьким потенціалом є рекомендаційним і не заважає вам використовувати маршрутизацію AI.
Маршрутизація AI та маршрутизація на основі правил
Маршрутизація AI працює з маршрутизацією на основі правил. Маршрутизація на основі правил визначає, які агенти мають право на взаємодію. Маршрутизація штучного інтелекту ранжує тих агентів, які відповідають вимогам для вибраного результату, і рекомендує агентів, які, за прогнозами, забезпечать найсильніший результат.
| Площа | Маршрутизація на основі правил | Маршрутизація AI |
|---|---|---|
| Рішення про маршрутизацію | Маршрутизація за налаштованими правилами, такими як найдовша доступність, найкраща доступність, кругова, зверху вниз, пріоритет або призначення агента. | Рейтингує відповідних агентів за прогнозованим результатом для вибраного бізнес-результату. |
| Право на право агента | Використовує членство в черзі, команди, навички, ємність каналу, доступність та правила потоку. | Спочатку використовує ту саму відповідність, а потім рекомендує найсильніших агентів, які відповідають вимогам для взаємодії. |
| Дані, що використовуються | Використовує налаштовані параметри черги та маршрутизації. | Використовує параметри маршрутизації, а також дані про історичну взаємодію, агента, клієнта та результати. |
| Мета оптимізації | Зосереджується на поведінці операційної маршрутизації. | Фокусується на бізнес-результатах на рівні взаємодії, таких як час обробки, задоволеність клієнтів, вирішення першого контакту або спеціальний KPI. |
| Перевірка | Адміністратори коригують правила вручну та контролюють результуючу поведінку. | Адміністратори використовують режим перевірки та оцінки оптимізації перед активацією маршрутизації AI для реального трафіку. |
Максимізуйте результати бізнесу
Коли ви налаштовуєте маршрутизацію AI, виберіть бізнес-результат, який модель повинна оптимізувати. Результат повинен бути доступний на рівні взаємодії, щоб модель могла вчитися на завершених взаємодіях і послідовно повідомляти про результати.
Ви можете використовувати стандартні результати, такі як час обробки або задоволеність клієнтів, коли вони відповідають цілі маршрутизації для черги. Ви також можете використовувати нестандартні результати взаємодії, такі як успіх оновлення, вартість додаткового продажу або вирішення першого контакту, коли організація отримує цю цінність для завершених взаємодій.
Для користувацьких результатів надішліть значення результату до контактного центру Webex як значення рівня взаємодії. Зберігайте послідовність назви змінної, типу даних та значення бізнесу у всіх взаємодіях. Числові або булеві значення найкраще підходять для власних результатів, які потрібно оцінювати та повідомляти.
Ви можете оновлювати глобальні змінні, що підлягають звітуванню, з потоку, веб-хука або робочого процесу після взаємодії після завершення взаємодії. Для отримання додаткової інформації зверніться до порталу розробників.
Для отримання додаткової інформації відвідайте розділ Н алаштування персоналізованої маршрутизації AI.
Можливості черги та маршрутизації в Flow
У Контактному центрі Webex широкий спектр можливостей маршрутизації, черги та керування викликами можна організувати через потоки.
Різноманітні дії потоку та обробники подій, що надаються в Flow Designer, можуть бути розміщені в потоці для ефективного управління життєвим циклом вхідних та вихідних контактів.
Докладніші відомості про налаштування та використання потоків див. у статті С творення потоків та керування ними за допомогою Flow Designer.
Діяльність по черзі
Контакт в черзі
Діяльність «Контакти черги» надає можливість ставити контакт у черзі до активної в хідної черги з організації, щоб його можна було зіставити та направити до потрібного агента у цій черзі.
За допомогою цієї діяльності можна керувати наступними аспектами черги:
- Пріори тет - присвоєння ієрархічної важливості від 1 (найвища) до 10 (найнижча, за замовчуванням) контакту, що знаходиться в черзі.
- Вимо@@ ги до нави чок - Встановіть критерії навичок, яким повинні відповідати агенти в черзі на основі навичок, щоб вважатися придатними для маршрутизації контакту.
- Розслаблення нави чок - Налаштування, зміна або видалення раніше встановлених вимог до навичок через деякий час, щоб підвищити шанси знайти агента.
- Перевірити доступність аген та - Дозвольте системі миттєво розширюватися через усі групи розподілу дзвінків, де немає доступних агентів, щоб уникнути часу очікування.
Див. Мар шрутизація, щоб отримати додаткову інформацію про те, як пріоритет, конфігурація навичок та доступність агента відіграють роль у маршрутизації контактів.
Після того, як активність «Контакт черги» успішно переведе контакт у чергу,
Якщо відповідний агент вже доступний, система спробує спрямувати контакт до агента.
Це перериває виконання основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
Якщо не знайдено відповідного агента, контакт припаркується в черзі та чекає, поки відповідний агент стане доступним.
Потім виконання потоку продовжується з діями, приєднаними після активності Queue Contact, що забезпечує можливість:
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
PlayMusicдіяльність. - Реєструйте зворотний дзвінок на підставі запиту замовника - приєднавши
Callbackдіяльність. - Повторна черга, тобто видаліть контакт з поточної черги та додайте до нової черги - приєд
навши інший
Queue ContactабоQueue to Agentдіяльність.
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
Коли відповідний агент стає доступним, система намагається спрямувати контакт до агента.
У разі успіху це перериває виконання Основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
У наступних випадках активність «Контакт черги» призводить до збою, і виконання потоку переміщується на шлях обробки помилок:
- До контакту вже призначений агент.
- У потоці передбачена недійсна черга, навик або інша конфігурація.
- Максимально дозволені переходи точки входу та черги (25) для контакту вичерпані.
Після того, як активність «Контакт черги» успішно ставить контакт у черзі, наступні спроби маршрутизації відбуваються поза викон анням діяльності. Якщо контакт неодноразово пропонується агентам і на нього немає відповіді, наприклад, через Ring No Answer (RONA), контактний центр Webex повторно спробує маршрутизацію до максимального ліміту 20 спроб. Коли цей лі міт вичерпується, контакт закінчується ROUTING_LIMIT_EXCEEDED помилкою. Він не переміщується до шляху обробки помилок контактів черги, і подальша логіка потоку не виконується.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Контакт у черзі.
Черга до агента
Діяльність «Черга до агента» надає можливість подавати контакт у чергу безпосередньо до бажаного агента, шукаючи його унікальний ідентифікатор агента або адресу електронної пошти в контактному центрі Webex.
За допомогою цієї діяльності можна керувати наступними аспектами черги:
- Пріори тет - Призначте вище/меншу важливість контактам, що знаходяться в черзі проти того самого агента.
- Черга звітності - Визначте чергу, яка буде використовуватися для конфігурації, такої як запис і типова музика в черзі, а також цілі звіту про контакт.
- Черга відновлення - Визначте чергу, яка буде використана як резервна черга, коли контакт не може бути перенаправлений до вказаного бажаного агента.
Після того, як активність «Черга до агента» успішно переведе контакт у чергу,
Якщо агент вже доступний, контакт перенаправляється до агента.
Це перериває виконання основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
Якщо агент доступний, але вирішив відмовитися, а не відповісти або не отримав контакт, він переміщується до наданої черги відновлення.
У черзі відновлення контакт буде спрямований до найдовшого доступного агента без підтримки навичок.
Якщо агент недоступний і вибр ано параме
Park Contact If Agent Unavailableтр «", контакт буде припарковано і чекає, поки агент стане доступним.Потім виконання потоку продовжується з діями, приєднаними після активності «Черга до агента», що дає можливість:
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
PlayMusicдіяльність. Callbackактивність.- Повторна черга, тобто видаліть контакт з поточної черги та додайте до нової черги - приєд
навши інший
Queue to AgentабоQueue Contactдіяльність.
Після того, як агент стає доступним, система намагається спрямувати контакт до агента.
Це перериває виконання основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
- Якщо агент недоступний, а параметр
Park Contact If Agent Unavailable"«не вибрано, черга не виконується.
Діяльність «Черга до агента» працює, коли:
- Контакт не призначений і готовий до перенаправлення до агента.
- Бажаний ідентифікатор агента або адреса електронної пошти є дійсними.
- Черга звітності та черга відновлення налаштовані правильно.
- Бажаний агент увійшов у систему, доступний і готовий обробляти контакт.
Налаштуйте чергу відновлення, щоб забезпечити безперебійну маршрутизацію контакту, коли бажаний агент недоступний.
У таких випадках діяльність призводить до збою, і виконання потоку переміщується на шлях обробки помилок.
Докладніші відомості про параметри активності, використання та змінні виводу див. у статті С творення потоків та керування ними > Черга до аген та.
Ескалація групи розподілу дзвінків
Активність «Ескалація групи розподілу викликів» підтримується лише для черг із призначенням команди , і надає можливість негайно оновити групу розподілу викли ків для контакту, замість того, щоб чекати автоматичного оновлення розширення для наступної групи після налаштованої тривалості очікування. Це дозволяє швидко перенаправляти контакт до всіх відповідних агентів у черзі.
За допомогою активності «Ескалація групи розподілу викликів» контакт може бути переведений до:
- Наступна група - Розширення набору команд, щоб включити ті, які додані до групи розподілу найближчих викликів.
- Остання група — Розширення набору команд, щоб включити всі команди, зіставлені між усіма групами розподілу викликів, налаштованими для черги.
Активність «Ескалація групи розподілу дзвінків» працює, коли:
- Контакт вже стоїть в черзі і готовий до ескалації.
- Контакт знаходиться в черзі в черзі, яка використовує групи розсилки викликів.
Для черг, які використовують стандартну маршрутизацію, продовжуйте розподіляти контакти через налаштовану поведінку маршрутизації черги.
У таких випадках діяльність призводить до збою, і виконання потоку переміщується на шлях обробки помилок.
Розглянемо приклад сценарію, коли контакт потрапляє в чергу в чергу з трьома гру пами розподілу викликів, кожна з яких оновлюється через 30 секунд.
У командній частині і немає агентів CDG 2, CDG 1а також
доступний агент, TEAM 3який належить до останньої групи розподілу дзвінків.
Якщо активність Ескалація групи розподілу дзвінків не використовується в потоці, це призводить до тривалого часу очікування, як показано нижче:
Час очікування можна скоротити, використовуючи Ескалацію групи розподілу дзвінків, що використовується наступним чином:
Виходячи з вибраного параметра Наступ на група або Остання група, час очікування контакту значно зменшується, як показано нижче:
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Ескалація групи розподілу викликів.
Діяльність з інформацією про чергу
Отримати інформацію про чергу
Діяльність Отримати інформацію про чергу надає можливість отримати інформацію про чергу в режимі реального часу для певного контак ту, наприклад:
- Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо ще не стоїть у черзі.
- Розрахунковий час очікування (EWT) або тривалість, протягом якої передбачається очікування завдання в черзі, перш ніж отримати відповідь.
- Кількість агентів, які увійшли в систему або доступні в поточній групі розподілу дзвінків контакту.
- Кількість агентів, які увійшли в систему або доступні в усіх групах розподілу викликів для вибраної черги.
- Тривалість, протягом якої чекав найстаріший контакт у черзі.
Ці деталі доступні у виконанні потоку як змінні виводу активності.
Докладніші відомості про використання активності, детальне визначення та метод розрахунку для кожної деталі черги див. у розділі Створення потоків та керування ними > Отримати інформацію про чергу.
Деякі способи використання інформації про чергу можуть бути:
- Оголосити позицію контакту в черзі та передбачуваний час очікування клієн ту, поки він чекає маршрутизації.
- Вирішити, чи можна зареєструвати зворотний дзвінок для клієнта, якщо передбачуваний час очікування занадто довгий.
- Щоб перевести контакт до наступної групи розподілу викликів (CDG), якщо агенти не доступні в командах, пов'язаних з поточною CDG.
Діяльність Отримати інформацію про чергу працює, коли вибрана змінна переходить до дійсної черги.
Налаштуйте шлях обробки помилок, щоб витончено керувати випадками, коли вибрана змінна потребує перевірки або не переходить до доступної черги.
- контакт (ще) не перебуває в черзі, коли виконується дія Отримати інформацію про чергу.
- контакт знаходиться в черзі в черзі, яка не підтримує концепцію груп розсилки викликів.
У цих випадках значення -1 у цих вихідних полях вказує на те, що ця інформація не застосовується.
Розглянемо приклад сценарію, коли клієнт повинен бути повідомлений про довгу EWT в черзі, після кожних 15 секунд, проведених у черзі.
Цього можна досягти за допомогою активності Отримати інформацію про чергу у потоці наступним чином:
Розширена інформація про чергу
Активність Advanced Queue Info надає можливість отримати інформацію про чергу в режимі реального часу для даного контакту, додатково враховуючи критерії навичок контакту, такі як:
- Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо ще не стоїть у черзі.
- Кількість агентів, які увійшли в систему або доступні в поточній групі розподілу дзвінків контакту, що відповідають заданим критеріям кваліфікації.
- Кількість агентів, які увійшли в систему або доступні для всіх груп розподілу викликів для вибраної черги, що відповідають заданим критеріям навичок.
- Поточна група розподілу викликів, де контакт припаркований у передбаченій черзі.
- Загальна кількість груп розсилки дзвінків у передбаченій черзі.
Ці деталі доступні у виконанні потоку як змінні виводу активності.
Докладніші відомості про використання активності, детальне визначення та метод розрахунку для кожної деталі черги див. у розділі Створення та керування потоками > Додаткові відомості про чергу.
Деякі способи використання розширеної інформації про чергу можуть бути:
- Оголосити позицію контакту в черзі замовнику, поки він чекає маршру тизації.
- Щоб перевести контакт до наступної групи розподілу викликів, якщо агенти, які відповідають критеріям навичок, не доступні в командах, пов'язаних з поточною групою розподілу викликів.
- Щоб вирішити, чи можна зареєструвати зворотний дзвінок для клієнта, якщо жоден агент, що відповідає критеріям кваліфікації, не ввійшов у систему у всіх групах розподілу дзвінків.
Активність Додаткова інформація про чергу працює, коли:
- Інформація про чергу запитується для черг, де вимоги до навичок налаштовуються в потоці, а не як критерії навичок рівня черги.
- Якщо контакт вже знаходиться в черзі, інформація запитується для тієї самої черги, де контакт зараз знаходиться в черзі.
- Контакт знаходиться в черзі до черги, а не безпосередньо до бажаного агента.
Налаштуйте шлях обробки помилок для керування запитами, які не відповідають цим вимогам.
У таких випадках діяльність призводить до збою, і виконання потоку переміщується на шлях обробки помилок.
Розглянемо приклад сценарію, коли замовника слід повідомити про отримання зворотного дзвінка, враховуючи, що агенти, що відповідають критеріям кваліфікації, не доступні.
Цього можна досягти, використовуючи активність Додаткові відомості про чергу в потоці наступним чином:
Діяльність контролю дзвінків
Встановити ідентифікатор абонента
Активність «Встановити ідентифікатор абонента» використовується для визначення ідентифікатора абонента, який повинен відображатися під час дзвінка. Активність «Встановити ідентифікатор абонента» повинна використовуватися лише для потоків подій PreDial як термінальну активність , яка позначає кінець потоку подій.
Активність «Встановити ідентифікатор абонента» дозволяє налаштувати необхідну автомати чну ідентифікацію номера (ANI) на основі служби ідентифікації набраного номера (DNIS), типу операції або типу учасника.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Встановлення ідентифікатора абонен та.
Контроль запису
Активність керування записом призначена для використання разом із активністю меню для отримання згоди на запис від абонента. Це забезпечує дотримання правил або політик, що вимагають явної згоди перед початком запису, плавно інтегруючи цей крок у робочий процес.
Активність меню IVR повинна відображати згоду користувача в булеву змінну, яка буде призначена як вхід для активності керування записом. Якщо клієнту потрібно повідомити про згоду користувача у звіті про згоду, значення згоди має зберігатися в глобальній змінній, що підлягає звітності. Крім того, можна використовувати локальну змінну, якщо звітність не потрібна. Такий підхід забезпечує орендарям та клієнтам підвищену гнучкість у ефективному управлінні та використанні змінних.
Коли ця діяльність додається до потоку, згода користувача має перевагу над рівнем орендаря або рівнем черги або налаштуваннями рівня розкладу запису.
Порядок пріоритету такий:
- Якщо згода користувача є у потоці «Так», то дзвінок записується незалежно від конфігурації запису, встановленої на рівні орендаря, черги чи розкладу запису.
- Якщо користувач не дає згоди як відповідь на діяльність, то дзвінок не записується, незалежно від конфігурації запису, встановленої на рівні орендаря, черги чи розкладу запису.
- Якщо в потоці не налаштовано дію «Керування записом», але для конфігурації встановлено значення Так на будь-якому з інших рівнів, наприклад орендаря, черги або графіка запису , виклик записується.
- Якщо в потоці не налаштовано дію керування записом, а для конфігурації встановлено значення Ні на всіх рівнях, таких як орендар, черга та графік запису, виклик не записується.
Цей контроль запису можна проілюструвати, як показано нижче:
Крім того, конфігурації запису, як-от «Продовжити при перенесенні», «Призупинити відновлення», «Призупинити тривалість» та інші, залишаються застосовними відповідно до існуючої ієрархії, включаючи рівні орендаря, черги чи розкладу запису.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Керування записами.
Сліпий трансфер
Blind Transfer — це процес, при якому контакт ефективно перенаправляється на зовнішній номер набору (DN) через систему IVR, що виключає необхідність залучення агента.
Активність Blind Transfer використовується, коли виклик повинен бути перенесений до зовнішнього або стороннього DN. Це кінцева діяльність, тому потік закінчується після виконання передачі.
Активність Blind Transfer не підтримується, коли потік виконується для консультації.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Blind Transfer.
Мостова передача
Активність «Мостова передача» дозволяє тимчасово перенести контакт до зовнішнього пункту призначення, поки потік зберігає контроль над викликом. Зовнішнім пунктом призначення може бути зовнішній міст або послуга інтерактивної голосової відповіді (IVR).
Коли зовнішній пункт призначення закінчує дзвінок, потік дзвінків продовжується далі за потреби, наприклад, подаючи його в чергу до агента.
Активність Bridge Transfer видаляє контакт у черзі під час передачі його до сторонньої системи IVR або автоматичного розподілу дзвінків (ACD). Якщо контакт не обробляється сторонньою системою, його можна переставити в чергу до початкової черги, гарантуючи, що контакт залишається в робочому процесі для належної обробки.
Наприклад, припустимо, що контактний центр має ресурси агента контактного центру Webex та ресурси агента у зовнішньому колл-центрі або Біржі приватних відділень (АТС). Клієнт хоче поставити дзвінок у чергу до черги агентів контактного центру Webex протягом короткого періоду (скажімо, 60 секунд). Якщо агент не доступний протягом цього періоду, виклик може бути переданий мостовиком (з неявним виведенням черги) зовнішньому кол-центру для обробки контакту.
- Активність мостового переказу не підтримується у потоках вихідних викликів та потоках подій.
- Контакти, які вже призначені агенту, не підтримуються для Bridge Transfer через потік.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Мостова передача.
Відключити контакт
Активність «Відключити контакт» забезпечує можливість відключення або припинення активного контак ту безпосередньо від потоку.
Це термінальна діяльність, приєднана до потоку, і може бути корисною для припи нення контактів без втручання агента, підходить для потоків шляху помилок або після реєстрації зворотного дзвінка для клієнта.
Виходячи з конфігурації, опитування після дзвінка або зворотний зв'язок спрацьовує, коли контакт закінчується через цю діяльність.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Відключення контакту.
Встановити пріоритет контактів
Діяльність «Встановити пріоритет контактів» сприяє ефективному управлінню пріоритетом контактів у потоці, дозволяючи призначати контактам конкретні рівні пріоритету. Це дозволяє надавати певним контактам більшу або меншу важливість, гарантуючи, що вони належним чином спрямовуються порівняно з іншими контактами, які очікують, коли агенти стануть доступними. Ця гнучкість дозволяє точно контролювати пріоритетність контактів протягом усього потоку.
Пріоритет встановлюється шляхом присвоєння ієрархічного рівня важливості від 1 (найвищий) до 9 (найнижчий). Контакти з найвищим пріоритетом спрямовуються раніше тих, хто має нижчі пріоритети. Якщо кілька контактів мають однаковий рівень пріоритету, контакт, який чекав найдовше, перенаправляється першим до наступного доступного та відповідного агента. Ця система гарантує, що контакти з вищим пріоритетом отримують оперативну увагу, зберігаючи справедливість між контактами однакового пріоритету залежно від часу їх очікування.
- Активність «Встановити пріоритет контактів» може бути розміщена в будь-якій точці основного потоку або потоку подій.
- Якщо дію «Встановити пріоритет контактів» налаштовано перед дією черги (наприклад, Контакт у черзі або Агент черги), її параметр пріоритету може бути замінений будь-яким пріоритетом, явно налаштованим у наступних діях черги. Однак, якщо наступна дія черги не вказує пріоритет, буде застосовано пріоритет контактів, встановлений попередньою активністю «Встановити пріоритет контактів».
- І навпаки, якщо активність «Встановити пріоритет контактів» налаштовується після дії черги (наприклад, Контакт у черзі або Черга до агента), вона замінить параметр пріоритету, налаштований попередньою діяльністю черги.
- Активність «Встановити пріоритет контактів» наразі не підтримується для контактів зовнішнього дзвінка та кампанії.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Встановити пріоритет контактів.
Діяльність зворотного дзвінка
Зворотний дзвінок
Активність зворотного дзвінка дозволяє абонентам запитувати зворотний дзвінок, а не чекати в очікуванні, значно покращуючи задоволеність клієнтів за рахунок скорочення часу очікування та мінімі зації частоти відмови. Після активації активність зворотного дзвінка створює завдання в черзі, гарантуючи, що доступний агент може повернути дзвінок клієнта.
Конструктор потоку може налаштувати активність так, щоб контакт залишався в первісній черзі, де виклик почався, або призначати його до іншої черги на основі налаштувань. Якщо зворо тний виклик залишається в початковій черзі, контакт зберігає свою позицію, навички, пріоритет та контекстні дані, що дозволяє безперебійно призначити наступному доступному агенту. Однак, якщо вибрано іншу чергу, контакт пересувається до кінця вибраної черги без навичок і з пріоритетом за замовчуванням.
Ця діяльність також дозволяє клієнтам запитувати зворотні дзвінки від своїх бажаних агентів, додаючи особистий штрих до досвіду та підвищуючи задоволеність клієнтів. Цього можна досягти, коли активність зворотного виклику слідує за діяльністю QueueToAgent у потоці. Крім того, активність зворотного дзвінка пропонує додаткову конфігурацію для налаштування автоматичної ідентифікації номера (ANI), що використовується під час процесу зворотного дзвінка. Ця настройка допомагає узгодити бренд та зменшує ймовірність відхилення дзвінка, забезпечуючи впізнаваний іденти фікатор абонента.
Конструктор потоку має можливість включити подію callbackFailed у потік подій. Ця подія спрацьовує, коли спроба зворотного виклику не вдається, що дозволяє дизайнеру потоку реалізовувати повторні спроби через певні проміжки часу. Затримку або інтервал між повторними спробами можна налаш тувати за допомогою активності очікування, з мінімальним інтервалом повторної спроби 10 секунд і максимум 72 години. Система підтримує до 10 спроб повторної спроби протягом максимум 14 днів, використовуючи активність «Очікування».
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Зворотний виклик.
Заплануйте зворотний дзвінок
Діяльність «Запланований зворотний дзвінок» дає можливість клієнтам запропонувати клієнтам зручність запиту зворотного дзвінка в певну майбутню дату та час, усуваючи необхідність негайного підключення до агента. Ця функція покращує досвід клієнтів, дозволяючи їм вибрати зручне вікно зворотного дзвінка, тим самим мінімізуючи уявний час очікування та зменшуючи частоту відмови від дзвінків.
Потік повинен фіксувати вхідні дані абонента, такі як бажана дата та час, через підказки DTMF та передавати їх діяльності після виконання необхідних перевірок введення.
Перш ніж розпочати роботу, переконайтеся, що точка входу зворотного дзвінка за замовчуванням налаштована в розділі Параметри каналу в Центрі управління. Докладніші відомості див. у статті Налаштування точки входу зворотного виклику.
Зворотний виклик можна запланувати за допомогою будь-якої черги телефонії, будь то вхідний або вихідний. Для досягнення найкращих результатів рекомендується додати активність «Відключити» одразу після дії Запланований зворотний дзвінок, щоб переконатися, що поточний дзвінок закінчується належним чином після запланованого зворотного дзвінка. Для отримання додаткової інформації про планування зворотних викликів IVR див. Розклад зворотних викликів IV R.
Коли зворотний дзвінок спрацьовує у запитану майбутню дату та час, створюється новий дзвінок або взаємодія. Ця нова взаємодія буде слідувати стандартному потоку, пов'язаному з точкою входу за замовчуванням зворотного дзвінка. Якщо спроба зворотного виклику не вдається, потік може автоматично повторити виклик за допомогою обробника подій callbackFailed, якщо його налаштов ано у цьому потоці.
Перед передачею вхідних даних до діяльності слід враховувати наступні перевірки вхідних даних:
- Вибір дати — Ви можете вибрати будь-яку дату від сьогодні до 31 дня в майбутньому. Дата повинна бути в такому форматі: РРРРР-ММ-ДД (наприклад, 2025-07-18).
- Час початку та закінчення часового вікна — час, який ви вибрали, повинен починатися щонайменше за 30 хвилин і може тривати від 30 хвилин до 8 годин. Будь ласка, використовуйте 24-годинний формат часу (наприклад
14:30:00). - Часовий пояс — Ви повинні ввести дійсний часовий пояс у форматі IANA (наприклад
America/New_York), щоб ми могли зателефонувати вам у потрібний час.
Довідкова реалізація надається у формі шаблону підпотоку для демонстрації підказок DTMF та основних перевірок, які використовуються разом із діяльністю. Докладніші відомості див. у розділі Шаблон підпотоку запланованого зворотного виклику.
Аналіз прогресу дзвінків
Активність аналізу прогресу дзвінків (CPA) дозволяє виявляти автоматизовані автовідповідачі та живі люд ські голоси під час дзвінків зворотного дзвінка.
Коли при спробі зворотного дзвінка виникає виявлення автовідповідача (AMD) або голосова пошта, система визначає дзвінок як невдалий. Результат виявлення автовідповідача (AMD) фік сується у вихідній змінній reason обробника подій callbackFailed. На основі цієї вихідної змінної конструктор потоку може налаштувати повторні спроби виклику.
- Для ввічливого зворотного дзвінка, CallProgressAnalysis можна розмістити в точці після дії зворотного виклику в основному потоці. Для запланованого зворотного дзвінка або особистого заплан ованого зворотного дзвінка його можна розмістити після NewPhoneContact в основному потоці.
- У потоці подій вона підтримується лише в обробнику подій callbackFailed.
- Якщо в потоці налаштовано опитування клієнтів після дзвінка (активність зворотного зв'язку), воно не буде ініціюватися, якщо на дзвінок відповість AMD або голосова пошта. Це запобігає запуску непотрібних обстежень.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Аналіз прогресу викликів.
Огляд
У контактному центрі Webex черга служить зоною утримання для вхідних взаємодій, таких як телефонія, чат, електронна пошта або соціальні канали. Контакти паркуються в чергах, поки вони не будуть автоматично розподілені агентам або агентам, які вручну заберуть їх для обробки. Крім того, вони підтримують такі функції, як маршрутизація на основі навичок, управління пріоритетами та справедливий розподіл навантаження.
Керівники можуть використовувати черги, щоб спостерігати за різними напрямками роботи та покращувати спосіб вирішення завдань у контакт-центрі.
Деякі з ключових переваг ефективного використання черг:
- Кращий досвід роботи з клієнтами: керуйте часом очікування та повідомляйте клієнтам, що вони стоять у черзі, щоб отримати допомогу.
- Підвищення ефективності: Переконайтеся, що дзвінки обробляються впорядковано, зменшуючи хаос та неправильне управління.
- Справедливий розподіл контактів: рівномірно розподіляйте дзвінки між агентами, щоб запобігти перевантаженню будь-якого окремого агента.
- Пріоритетна обробка: Дозволити пріоритетність певних дзвінків, таких як VIP-клієнти або термінові проблеми.
Види черг
Контактний центр Webex підтримує декілька типів черг, які забезпечують широкий спектр випадків використання для контактних центрів будь-якого розміру та складності, для всіх типів носіїв з єдиними можливостями.
Є черги, які враховують навички агента в маршрутизації контактів, і черги, які не роблять цього. Ці черги також відрізняються з точки зору того, як агенти пов'язані з ними для роботи над контактами.
Існує дві широкі категорії черг:
- Черги, не засновані на навичках
- Черги на основі навичок
Черги, не засновані на навичках
Черги, не засновані на навичках, не враховують навички, пов'язані з агентами. Ви можете налаштувати черги, не засновані на навичках, за допомогою таких параметрів:
- Командні завдання
- Призначення агента
Черги, не засновані на навичках, з командними завданнями
У чергах, що не засновані на навичках із призначенням команди, ви можете організувати агентів у команди та об'єднати ці команди, щоб сформувати групи розподілу викликів (CDG). Ви можете встановити затримку часу між кожною групою, щоб керувати потоком дзвінків.
Групи розподілу викликів допомагають визначити кілька рівнів агентів, які можуть працювати з контактами в цій черзі протягом налаштованих інтервалів часу. Контакти признача ються агентам залежно від рівня їх команди. Якщо агентів немає, контакти припарковуються на попередньо налаштовану тривалість, перш ніж розширити, щоб включити наступну групу команд. Цей процес триває до тих пір, поки агент не буде доступний або не буде перевірено всі групи.
Ви можете налаштувати такі типи команд:
- Окремі команди: Агенти можуть бути організовані в команди, які можуть представляти певну організаційну функцію, яка потім може стати частиною черг, щоб контакти могли бути спрямовані до агентів у цих командах. Ви можете позначити агента до кількох команд, щоб обробляти контакти з різних черг для ефективної маршрутизації.
- Команди на основі ємності: Команда на основі ємності (CBT) - це функція, яка спрямовує голосові дзвінки на прямий номер на основі ємності (DN), де ємність визначає, скільки дзвінків можна обробляти одночасно. Він дозволяє маршрутизувати дзвінки на телефонні номери, не вимагаючи від агентів входу в систему, що робить його придатним для сценаріїв, коли на дзвінки відповідають голосова пошта, автовідповідачі або групи пошуку, а не традиційні агенти call-центру . У цьому налаштуванні немає конкретних агентів, призначених для команди, і вони не використовують контактний центр Agent Desktop Webex.
У цьому прикладі є три групи розподілу викликів, які дозволяють цільове розширення, що означає розширення до більшої кількості агентів у різних командах протягом налаштованих часових інтервалів.
Перша група розподілу викликів містить TEAM 1, у якій налаштовано 3 агенти — A1, A2 та A5.
Друга група розсилки викликів містить TEAM 2, у якій налаштовано 3 агенти — A2, A3 та A4.
Третя (і остаточна) група розсилки викликів містить TEAM 3, у якій налаштовано 2 агента — A6 та A7.
Коли контакт знаходиться в черзі, система спочатку шукає відповідного агента в першій групі розподілу викликів. Якщо агентів не знайдено, контакт буде припарковано протягом налаштованої тривалості, перш ніж здійснити розширення цілі до наступної групи. Це додає нові команди до існуючих. Цей процес повторюється до тих пір, поки він не знайде відповідність, або всі групи не будуть розширені.
Функція «Перевірити доступність агента» призводить до того, що контакт миттєво розширюється до наступної групи розподілу викликів, якщо у поточній групі не знайдено відповідних агентів. Це можна увімкнути під час дії Контакти черги <LINK TO section 3.1.1>у потоці.
Ця настройка призводить до наступних сценаріїв:
- А2 належить командам 1 та КОМАНДІ 2. Якщо A2 вибирає команду 1 для входуAgent Desktop, система розглядає A2 частиною TEAM 1, а отже, лише першу групу розподілу викликів.
- A5 належить TEAM 1, однак, також міг бути частиною якоїсь іншої команди в організації, в яку вони зараз увійшли. Тому A5 не розглядається як частина TEAM 1 і не пов'язаний з цією чергою.
Черги з призначенням команди забезпечують цю потужну можливість агентам переходити між чергами, просто вибираючи команду під час входу в систему.
Доступний шаблон маршрутизації:
Черги, що не засновані на навичках, із призначенням агентів
Черги, що не засновані на навичках, — це тип черги, де пул агентів безпосередньо призначається до черги. На відміну від інших типів черг, які опосередковано визначають пул призначених їм агентів, ці черги дозволяють адміністраторам вибирати агентів безпосередньо та вручну. Наприклад, черги призначення на основі команд призначають агентів на основі їхніх зареєстрованих команд, а черги призначення на основі навичок відповідають агентам на основі необхідних навичок. На відміну від цього, адміністратори можуть безпосередньо додавати агентів до цих черг, щоб стати частиною черги. Це забезпечує простий спосіб управління розподілом агентів, не покладаючись на системні призначення.
Черги з призначенням агента забезпечують прості, але ефективні алгоритми маршрутизації, які допомагають розподілити контакти між пулом агентів. Вони не враховують навички агентів у маршрутизації контактів. Однак агенти можуть бути замовлені в межах кожної черги, і це враховується при маршрутизації контактів до них. У цьому контексті команди в першу чергу служать організаційною конструкцією для керівників, а не фактором асоціації черги агента та рішень щодо маршрутизації контактів, що спрощує управління чергою.
Цей тип черги найкраще підходить там, де статичне призначення агентів та управління асоці ацією агент-черги є можливим і бажаним для оперативного контролю, а вибір алгоритмів маршрути зації підходить для розподілу роботи між агентами. Ці черги також особливо корисні для сценаріїв, коли кілька типів запитів клієнтів вимагають спеціалізованої експертизи, яку може обслуговувати попередньо створений сегмент експертних агентів.
Однак складним організаціям контакт-центру може бути важко вручну керувати призначеннями агентів у цих чергах. Вони могли б отримати більше користі від інших типів черг, які пропонують динамічну маршрутизацію та асоціації черги агента.
У цьому прикладі черга має набір агентів, зіставлених до неї в певному порядку, наприклад A4, A9, A7 тощо. Цей порядок відіграє роль у конкретних алгоритмах маршрутизації, які відповідають вхід ним контактам агентам. Система зіставляє контакти з цими агентами на основі їх доступності та обраного алгоритму маршрутизації.
На відміну від черг із призначенням команди, немає концепції розширення цілі протягом часових інтервалів. Якщо жоден із налаштованих агентів не доступний для маршрутизації цього контакту, він буде припаркований у черзі, доки один із цих агентів не стане доступним для обробки контактів до тайм-ауту паркування. Цільове розширення не застосовується до цих черг.
Доступні шаблони маршрутизації:
Черги на основі навичок
Черги на основі навичок забезпечують можливість перенаправлення контактів до агентів з правильними навичками для задоволення їхніх потреб.
Ви можете налаштувати наступні типи опцій на основі навичок:
Критерії навичок, присвоєні черзі
Адміністратори можуть призначати чергам критерії навичок. Черги на основі навичок з критеріями навичок дозволяють адміністраторам налаштовувати необхідні навички безпосередньо в черзі. Усі агенти в організації, які мають всі необхідні навички черги через прямий профіль навичок, неявно стають частиною цієї черги.
Ця настройка допомагає адміністраторам мати реальний перегляд агентів, що відображаються в черзі завдяки навичкам. У таких ситуаціях, як великий обсяг або низький обсяг, адміністратори можуть розглянути можливість коригування необхідних навичок черги та профілів навичок агента, щоб розширити або зменшити пул агентів за потреби.
Цей тип черги відрізняється від черг на основі призначення команди тим, що немає налаштувань групи розподілу викликів, що означає, що команда не відіграє жодної ролі в асоціації агента до черги. Більше того, необхідні навички статично налаштовані в цій черзі, на відміну від командних черг нави чок, де потік вводить (статичні або змінні) необхідні навички. Отже, технічно навички є частиною черги, а не самого контакту.
Будь-який агент в організації, який повністю задовольняє критеріям кваліфікації черги (маючи навички з прямого профілю навичок) неявно стає пов'язаним з цією чергою. Команда не відіграє жодної ролі в асоціації агентів з цими чергами. Ці агенти можуть бути частиною будь-якої команди для управлінських та операційних цілей.
Кожен контакт, який знаходиться в черзі в цій черзі, автоматично прийматиме критерії навичок, визначені в самій черзі. Окремі контакти не можуть визначити або перевизначити власні вимоги /критерії навичок, на відміну від черг на основі навичок із призначенням команди.
У цьому прикладі
- Тільки агенти A1, A3 і A7 повністю відповідають критеріям навичок, налаштованим у черзі, о тже, лише ці агенти будуть пов'язані з цією чергою.
- Агенти A2, A4 та A6, які частково відповідають критеріям, або А5, які не мають відповідних навичок, не можуть бути пов'язані з цією чергою.
Оновлення профілю навичок агента (так зване перекваліфікацією) таким чином, щоб він відповідав критеріям кваліфікації черги, автоматично та динамічно зробить цього агента частиною цієї черги. Крім того, оновлення самих критеріїв навичок черги таким чином, щоб більше (або менше) агентів відповідали оновленим критеріям навичок, також автоматично та динамічно додавати (або видаляти) агентів із цієї черги.
На відміну від черг із призначенням команди, немає концепції розширення цілі протягом часових інтервалів. Якщо контакт не вдається співвіднести до жодного з асоційованих агентів, він припарковується в черзі, доки один з цих агентів не стане доступним для обробки контактів до тайм-ауту паркування.
Черги, засновані на навичках, найкраще підходять там, де статичне призначення навичок та управління чергою асоціації агентів є можливим і бажаним для оперативного контролю. Вони також підходять, коли вибір алгоритмів маршрутизації підходить для розподілу роботи між агентами. Ці черги також особливо корисні для сценаріїв, коли різні типи запитів клієнтів вимагають певних навичок, які може обслуговувати попередньо виведений сегмент експертних агентів.
Складним організаціям контактного центру може бути легше керувати чергою до призначення агентів у чергах на основі навичок, порівняно з чергами з призначенням агента, де кожного агента потрібно вручну додати до списку, що є громіздким, особливо для більшої організації.
Вимоги до навичок, поставлені в потоці
Черги на основі навичок з вимогами до навичок, призначеними в потоці, є типом черги на основі командних завдань у контактному центрі Webex, де набір команд налаштовується на кількох рівнях, які називаються групами розподілу викликів. Агентам, які увійшли до цих налаштованих команд, призначаються контакти з цієї черги на основі рівня групи розподілу викликів, на якому їх команда налаштована в черзі, якщо вони також повністю задовольняють вимоги до навичок контакту.
У такій черзі команди агентів групуються в групи розподілу дзвінків з налаштованими затри мками часу між ними. Якщо для контакту немає агента, запит припарковано, і після затримки маршрутизація розширюється до наступної групи розподілу викликів. Цей процес триває до тих пір, поки агент не буде призначений або не вичерпані всі групи. Тим часом, якщо агент у попередньо перевіреній групі стає доступним під час цього процесу, цей агент вибирається.
Агенти набувають навичок через профіль навичок, безпосередньо призначений агенту. Навички аген та визначаються на основі вибору команди під час входу.
Кожен контакт може за бажанням вказати вимоги до навичок у потоці, які відповідають нави чкам доступних агентів для вибору найбільш підходящого агента.
Крім того, контакти також можуть вказати розслаблення навичок через налаштовані проміжки часу. Це модифікований набір вимог до навичок, які перезаписують початкові вимоги до навичок контак ту за налаштованими часовими інтервалами. Це дозволяє контакту змінювати (зазвичай використовується для «розслаблення») своїх вимог до навичок під час стоянки в черзі, щоб більше агентів могли відповідати цим розслабленим вимогам до навичок.
Розширення цілі через групи розподілу дзвінків може відбуватися одночасно з циклами розслаблення навичок - обидва спрямовані на швидке узгодження припаркованого контакту з відповідними агентами, таким чином скорочуючи загальний час очікування та покращуючи рівень обслуговування черги.
Як і некваліфіковані черги з призначенням команди, він має три групи розподілу викликів, які дозволяють «цільове розширення», тобто розширення до більшої кількості агентів у різних командах протягом налаштованих часових інтервалів.
- Перша група розсилки викликів містить 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 у КОМАНДІ 1 та A4 у КОМАНДІ 2), або взагалі не володієте цією навичкою (напр. А5, А2 в КОМАНДІ 2).
- З часом, після розслаблення навичок, додатково A2 та A4 тепер також задовольняють «розслаблені» вимоги до навичок контакту.
Для кожного контакту, який потрапляє в чергу в цю чергу, система намагається знайти відповідного агента в першій групі розподілу викликів, який повністю задовольняє поточні вимоги до навичок контакту. Якщо не знайдено відповідного агента, контакт буде припарковано протягом налаштованої тривалості, перш ніж цільове розширення відбудеться для другої групи розподілу викликів. Усі команди, налаштовані у другій групі розподілу викликів, також додаються до існу ючих команд з першої групи. Тепер система намагається знайти відповідного агента в розширеній групі. Зауважте, що поки це відбувається, розслаблення навичок також оновлюватиме вимоги до навичок контакту через налаштовані проміжки часу, і система використовуватиме оновлені вимоги до навичок для відповідності з доступними агентами в поточній групі розподілу викликів.
Це продовжується до тих пір, поки всі налаштовані групи розподілу викликів не будуть розширені та не будуть застосовані всі розслаблення навичок, якщо раніше не знайдено відповідного агента.
Доступні шаблони маршрутизації:
Налаштування черги
Налаштування черг на основі навичок
Призначте критерії навичок черзі
- Створюйте навички та, якщо потрібно, динамічні навички.
- Створіть профілі навичок.
- Призначте профіль навичок безпосередньо агентам.
- Призначте динамічні навички безпосередньо агентам. Динамічні навички не призначаються через профілі навичок.
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Призначте навички та вимоги до динамічних навичок чергам у Центрі управління.
- Перегляд списку агентів, які можуть обробляти контакти в черзі.
- Виберіть алгоритм маршрутизації LAA або BAA. Для BAA налаштуйте ваги для навичок кваліфікації та динамічних навичок, коли це необхідно.
- Додайте до потоку активність «Контакт у черзі» та виберіть цю чергу.
Призначте вимоги до навичок черзі
- Створюйте навички та, якщо потрібно, динамічні навички.
- Створіть профілі навичок.
- Призначте профіль навичок безпосередньо агентам або команді.
- Призначте динамічні навички безпосередньо агентам. Динамічні навички не призначаються через профілі навичок.
- Створіть команду.
- Додайте агентів до команди.
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Додайте команди до черги в одному CDG або декількох CDG.
- Виберіть шаблон маршрутизації LAA або BAA.
- Додайте до потоку активність «Контакт черги» та виберіть чергу, для якої налаштов ано маршрутизацію на основі навичок. Докладніші відомості див. у статті Кон такти в черзі.
- Призначте навички, динамічні навички та розслаблення навичок у діяльності «Контакт у черзі». Для BAA налаштуйте ваги для навичок кваліфікації та динамічних навичок, коли це необхідно.
- Використовуйте Ескалацію активності розподілу викликів у потоці після черги, щоб швидко перейти до наступної групи розси лки викликів або останньої.
Налаштування черг, не заснованих на навичках
Призначення команди до черги
- Створіть команду.
- Додайте агентів до команди.
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Додайте команди до черги в одному CDG або декількох CDG.
- Виберіть шаблон маршрутизації або LAA.
- Додайте до потоку активність «Контакт у черзі» та виберіть цю чергу.
- Використовуйте Ескалацію активності розподілу викликів у потоці після черги, щоб швидко перейти до наступної групи розси лки викликів або останньої.
Призначення агента до потоку черги
- Створіть чергу з типом каналу Телефонія або Чат або Електронна пошта або Соціальна мережа.
- Додайте агентів безпосередньо до черг (Примітка: ні навички, ні команда не використовуються в цьому типі черги).
- Виберіть шаблони маршрутизації, такі як Круговий або Лінійний або Найдовший доступний агент.
Концепції маршрутизації
Сценарій надлишку агента
Сценарій надлишку агента виникає, коли доступних агентів більше, ніж контактів у черзі. У цьому випадку, коли взаємодія з клієнтом (контакт) знаходиться в черзі, система намагається негайно знайти відповідного агента для цього конкретного контакту, і якщо знайдено відповідного агента, контакт не потрібно припарковувати в черзі та чекати, поки відповідний агент стане доступним пізніше.
Кожного разу, коли контакт зазнає розширення через групу розподілу дзвінків або через розслаблення навичок, система знову намагається негайно знайти відповідного агента для цього конкретного контакту.
Пошук відповідного агента для конкретного контакту використовує налаштований шаблон маршрутизації в черзі.
Контактний центр Webex пропонує кілька шаблонів маршрутизації в різних типах черг, що дозволяє організаціям оптимізувати обслуговування клієнтів, мінімізуючи час очікування, балансуючи навантаження агента та забезпечуючи зв'язок клієнтів з агентами, які мають необхідні навички для задоволення їхніх конкретних потреб. Докладну інформацію про шаблони маршрутизації див. у розділі Шаблон маршрутизації.
Сценарій надлишку контактів
Маршрутизація надлишку контактів виникає, коли кількість вхідних взаємодій з клієнтами (або контактів) перевищує доступні агенти. Така ситуація часто виникає під час пікових періодів або несподіваних стрибків об'єму контакту. Основною метою маршрутизації надлишків контактів є ефективне управління цим переповненням, забезпечуючи підтримку стандартів обслуговування клієнтів, незважаючи на надлишковий попит. Для агента, який щойно став доступним на певному каналі, маршрутизація надлишків контактів працює для пошуку та призначення відповідного контакту серед усіх припаркованих контак тів у всіх чергах, з якими пов'язаний цей агент.
Ключовими стратегіями ефективного виконання маршрутизації контактів з обмеженою доступністю аген тів є:
-
Рейтинг черги
Ранжування черг дозволяє адміністраторам вказати відно сну важливість черг. Адміністратори можуть визначати рейтинг черг, щоб встановити порядок маршрути зації викликів від черг до агентів, які увійшли до команд, на основі кожної команди.
Наприклад, припустимо, що агенти, які увійшли в команду A, пов'язані з двома чергами — «Виставлення рахунків» та «Продажі». Адміністратори можуть використовувати ранжування черги, щоб призначити вищий рейтинг черзі «Виставлення рахунків», тому, коли контакти потрапляють у черги, контакти з «Виставлення рахунків» будуть спрямовані до агентів, що належать до команди A, перш ніж контакти з черг «Продажі». Це станеться, навіть якщо у черзі «Продажі» можуть бути старші контакти з вищим пріоритетом, які можуть чекати - лише тому, що черга «Виставлення рахунків» має вищий рейтинг черги, ніж черга «Продажі». Тільки тоді, коли в черзі «Виставлення рахунків» більше немає контактів, агенти команди А будуть перенаправлені контакти з черги «Продажі» (та будь-якої іншої), з якою вони пов'язані.
Нижче наведено деякі важливі характеристики ранжування черг:
-
- Якщо ранг присвоюється лише деяким чергам, виклики в цих чергах матимуть перевагу над викликами в чергах, для яких ранг не вказано.
- Рейтинг черг можна встановити максимум на 50 черг у всіх типах носіїв із значенням від 1 до 50, з 1 як найвищим рангом.
- Ви можете призначити один і той же ранг декільком чергам.
- Якщо ввімкнути ранжування черг, черги, яким не присвоєно жодного явного рангу, будуть розглядатися нижче, ніж усі ранговані черги.
-
Рейтинг черги працює в межах одного типу медіа.
Наприклад, якщо продаж у черзі — це черга типу голосових медіа з рангом 2, а підтримка виставлення рахунків у черзі — черга чату з рангом 1 для команди A, тоді агенти, які доступні на голосовому каналі в команді А, отримують голосовий дзвінок першими, навіть якщо рейтинг до рівнює 2.
Однак розглянемо дві черги чатів для команди B - черга кредитної картки з чергою 2 і чер га дебетової картки з рангом черги 1. Тоді доступним агентам у команді B спочатку будуть запропоновані контакти з дебетової картки черги.
-
Рейтинг в черзі не поширюється на команди, що базуються на потужності.
-
-
Пріоритет контакту
Коли контакт знаходиться в черзі, його пріоритет можна визначити, призначивши ієрархічну важливість від 1 (найвища) до 10 (найнижча, за замовчуванням). Ця пріоритетність гарантує , що певні контакти вирішуються швидше на основі їх важливості, терміновості або стратегічної цінності для організації. Коли агент доступний для обробки наступного контакту серед усіх припаркованих контактів у всіх чергах, з якими пов'язаний агент, контакт з найвищим пріоритетом у всіх чергах перенаправляється до агента (за умови дотримання інших критеріїв, таких як відповідність навичок та інші).
Для контактів, які перебувають у черзі без явного пріоритету, вважається пріоритет за замовчуванням 10 (найнижчий). Серед кількох контактів, які мають однаковий пріоритет, контакт, який че кає в черзі найдовше, перенаправляється спочатку до доступного та відповідного агента.
-
Найдовший очікуваний контакт
Це базова стратегія, яка гарантує, що найдовший очікуваний контакт у всіх чергах, з якими пов'язаний агент, буде спрямований до агента.
Це кінцевий критерій, який визначає контакт, який буде маршрутизований, коли кілька контактів у чергах з однаковим ранжуванням черги та однаковим пріоритетом контактів чекають на обробку.
По суті, маршрутизація надлишку контактів для агента, який щойно став доступним, означає вибір одного контакту, який:
- має той самий медіа-тип, що і той, на якому доступний агент
- припарковано в будь-якій з черг, з якими пов'язаний цей агент
- чиї вимоги до кваліфікації (якщо такі є) задовольняються цим агентом
- припарковано в черзі, чия ранг вищий, ніж інші черги, налаштовані в команді агента
- має найвищий пріоритет серед усіх таких контактів
- найстаріший контакт, що очікує серед контактів з однаковим пріоритетом
У наведеному вище прикладі, який ілюструє сценарій надлишку контактів, агент A1 увійшов до TEAM 1 і став доступним для обробки контактів на декількох типах медіа.
А1 асоціюється з трьома чергами — Q1, Q 2 і Q 3. TEAM 1 також ви значила рейтинг черг, де Q1 займає найвищий рейтинг, потім Q2 та Q 3 відповідно.
У всіх цих чергах вже припарковані контакти, з вимогами до навичок та пріоритетом, визначеними для кожного контакту.
Тепер сценарій надлишку контактів працює наступним чином:
-
Серед усіх припаркованих контактів у цих чергах лише 4 контакти можуть бути спрямовані на A1 — C2, C7 (з ЧЕРГИ 2) та C 3, C8 (з ЧЕРГИ 3).
Тільки вимоги до кваліфікації цих 4 контактів повністю задовольняються навичками А1.
-
Серед цих 4 контактів пріоритет надається контактам з ЧЕРГИ 2 (тобто C2, C7), оскільки ЧЕРГА 2 має вищий рейтинг черги.
Зверніть увагу, що хоча ЧЕРГА 1 є чер гою з найвищим рейтингом, жоден з його припарков аних контактів не може бути спрямований на A1, оскільки їх вимоги до кваліфікації не задовольняються A1.
-
Між C2 і C7 контакт найвищого пріоритету - C 7. Отже, остаточний вибір - С7, і система направляє його на А1.
Це відбувається, навіть якщо C2 був у черзі раніше, оскільки пріоритет контактів має перевагу над часом у черзі.
Змішані мультимедійні профілі
Завдяки налаштуванню мультимедійного профілю, Контактний центр Webex дозволяє агентам обслуговувати контакти з різними типами медіа (голосовий, чат, електронна пошта та соціальна мережа). На основі цієї конфігурації агенти отримують канали, передбачені для кожного типу носія.
Кожен контакт, спрямований на агента, споживає один канал цього типу медіа, доки агент працює над цим контактом. Хоча агенти можуть мати лише один голосовий канал, вони можуть мати до п'яти каналів інших типів медіа.
Налаштування змішаної маршрутизації в мультимедійних профі лів дозволяє адміністраторам керувати тим, як різні канали можуть використовуватися одночасно для кожного агента. Це дозволяє організаціям надавати віддану увагу клієнтам, сприяючи кращій якості обслуговування, покращенню досвіду клієнтів та кращим коефіцієнтам конверсії. Крім того, організації можуть збалансувати навантаження між ме діа-каналами при нерівномірному навантаженні в деяких каналах, що дозволяє ефективно використовувати агенти.
Є три варіанти:
-
Ексклюзив
-
Змішані
-
Змішаний в реальному часі
Докладніші відомості про налаштування мультимедійних профілів див. у розділі Кер ування мультимедійними профілями.
Шаблони маршрутизації
На основі навичок
Шаблони маршрутизації на основі навичок у контактному центрі Webex спрямовують вхідні взаємодії з клієн тами з агентами на основі конкретних навичок, необхідних для вирішення запиту, таких як володіння мовою або технічна експертиза. Ці моделі гарантують, що кожен клієнт підключається до найбільш кваліфікованого агента, підвищуючи ефективність обслуговування та задоволеність клієнтів. Переваги включають скорочення часу обробки, покращення швидкості вирішення та оптимізоване використання ресурсів агента шляхом узгод ження їхнього досвіду з потребами клієнтів.
Маршрутизація на основі навичок може використовувати навички, які агенти отримують із профілів навичок та динамічних навичок , які присвоюються безпосередньо агентам. Динамічні навички представляють атрибути агента, які можуть змінюватися незалежно від профілю навичок агента.
Коли використовуються шаблони маршрутизації на основі навичок, спочатку вимоги до навичок контакту (призначені в потоці) або критерії навичок, призначені для черги, використовуються для фільтрації доступних агентів, чиї навички та динамічні навички повністю задовольняють цим вимогам/критеріям. Потім серед агентів, які фільтруються, вибирається один для контакту на основі налаштованого шаблону маршрутизації.
Для найкращої доступної маршрутизації, навичок кваліфікації та кваліфікації Динамічні навички також можуть використовувати ваги, щоб вплинути на оцінку, яка використовується для вибору агента. Ваги не впливають на найдовшу доступну маршрутизацію; цей шаблон використовує навички та динамічні навички лише для визначення відповідності аген та.
Найдовший доступний
Шаблон маршрутизації на основі найдовших доступних навичок спрямовує контакт до того агента, навички якого повністю задовольняють вимоги до навичок контакту/критерії навичок черги, і який був доступний найдовше з моменту обробки останнього контакту серед усіх відповідних агентів у цій черзі.
Цей шаблон маршрутизації допомагає рівномірно розподілити роботу між агентами, призначаючи взаємодії тим, хто був доступний найдовше, запобігаючи дисбалансу навантаження. Це допомагає підтримувати справедливість у розподілі роботи, гарантуючи, що жоден агент не перевантажений, а інші залишаються вільними.
У наведеному вище прикладі є 4 агенти, які мають навички кваліфікації та некваліфікації з різними значеннями навичок кваліфікації.
Розглянемо контакт, який знаходиться в черзі до черги, заснованої на навичках, з шаблоном маршрутизації «Найдовша доступність»:
- з вищезазначеними вимогами до навичок, призначеними за допомогою потоку, або
- при цьому вищевказані критерії навичок налаштовуються в черзі на основі навичок
У цьому сценарії:
-
Для маршрутизації враховуються лише агенти, які повністю задовольняють вимоги до навичок контакту/критерії навичок черги. Тільки агенти A1, A2 та A4 повністю задовольняють вимоги до навичок контакту/критерії навичок черги.
Агент А3 не має права. У випадку критеріїв навичок, призначених для черги, A3 навіть не пов'яз аний з чергою.
-
Серед A1, A2 та A4 контакт буде спрямований до найдовшого доступного агента - A1, який доступний протягом 10 хвилин, довше, ніж A2 або A4.
Через те, що A1 буде призначений контакт, A1 більше не буде найдовшим доступним агентом у всіх медіа-каналах.
- Наступний контакт з точно такими ж вимогами до навичок буде спрямований до наступного най довшого доступного агента - A2 тощо.
Цей шаблон маршрутизації підтримується в наступних типах черг на основі навичок:
Найкраще доступне
Шаблон маршрутизації на основі найкращих доступних навичок гарантує, що взаємодія з клієнтами спрямована до найбільш кваліфікованого доступного агента. Ця модель оцінює не тільки наявність необхідних навичок серед агентів, але й рівень кваліфікації цих навичок, обчислюючи оцінку кваліфікації для визначення найбільш кваліфікованого («найкращого») агента для кожного контакту.
Цей шаблон фільтрує доступних агентів, навички яких повністю задовольняють вимоги до навичок контакту/критерії навичок черги. Потім оцінка розраховується для кожного відповідного агента, використовуючи значення квалі фікації всіх навичок, зазначених у вимогах до контактних навичків/ критеріях навичок черги. Агент з найвищим балом кваліфікації вважається «найкращим» агентом для кожного контакту.
Ефективно сума значень навичок агента, які відповідають вимогам до навичок контакту /критеріям навичок черги, визначає оцінку.
Деякі ключові моменти для розуміння:
- Зазвичай фактичне значення навичок використовується для розрахунку балів, оскільки вищий бал навичок вказує на сильніший матч. За винятком випадків, коли вимога до навичок використовує умов у менше, ніж дорівнює (< =), це конкретне значення навичок агента інвертується при розрахунку балів, тобто effective_skill_value= (10) мінус (). actual_skill_value Це робиться для того, щоб менший бал вказував на більш сильний матч.
- Якщо кілька агентів, які відповідають вимогам, мають однаковий бал, вибирається найдовший доступний агент серед них
- Для розрахунку балів враховуються лише навички володіння. Будь-які булеві, текстові або енумні навички у вимогах до навичок контакту/критеріях навичок черги не враховуються для розрахунку балів.
У наведеному вище прикладі є чотири агенти, які мають навички кваліфікації та некваліфікації з різними значен нями навичок кваліфікації.
Розглянемо контакт, який знаходиться в черзі до черги на основі навичок з шаблоном маршрутизації «Найкраще доступне»:
- з вищезазначеними вимогами до навичок, призначеними за допомогою потоку, або
- при цьому вищевказані критерії навичок налаштовуються в черзі на основі навичок.
У цьому сценарії:
-
Для маршрутизації враховуються лише агенти, які повністю задовольняють вимоги до навичок контакту/критерії навичок черги. Тільки агенти A1, A2 та A4 повністю задовольняють вимоги до навичок контакту/критерії навичок черги.
Агент А3 не має права. У випадку критеріїв навичок, призначених для черги, A3 навіть не пов'яз аний з чергою.
-
Серед А1, А2 та А4 розрахунок балів здійснюється системою на основі вимог до навичок контакту/критеріїв навичок черги, де враховуються лише навички кваліфікації.
Для розрахунку балів враховуються лише навички, зазначені у вимогах до контактних навичків /критеріях навичок черги, навіть якщо агенти можуть мати додаткові/інші навички кваліфікації.
Також зверніть увагу на інверсію значення навичок при розрахунку балів, коли використовується умова менша, ніж рівна (< =).
-
Контакт перенаправ ляється на A2, оскільки це найкращий доступний агент на основі оцінки. Якщо A2 не доступний/ зайнятий, контакт буде перенаправлений до наступного найкращого доступного агента з другим найвищим балом тощо.
Однак у нас є 2 агенти — А1 та А4 з наступним найвищим балом. Кон такт направляється до найдовшого доступного агента між А1 та А4.
Цей шаблон маршрутизації підтримується в наступних типах черг на основі навичок:
Маршрутизація без навичок
Контактний центр Webex також підтримує різноманітні моделі маршрутизації, що не засновані на навичках, які зосереджені на розподілі вхідних взаємодій з клієнтами без урахування конкретних навичок або досвіду агентів. На відміну від моделей маршрутизації на основі навичок, вони не враховують навички агента або вимагають контакту чи черги для визначення вимог до навички/критеріїв маршрутизації. Швидше, вони надають пріоритет таким факторам, як доступність, розподіл навантаження та заздалегідь визначені послідовності, що дозволяє ефективно обробляти контакти на основі операційної логіки, а не компетенції окремих агентів. Ці шаблони особливо корисні в середовищах, де взаємо дія відносно рівномірна або не вимагає спеціалізованого поводження.
Найдовший доступний
Шаблон маршрутизації «Найдовший доступний» маршрутизує контакт до того агента у черзі, який був доступний найдовше з моменту обробки останнього контакту серед усіх агентів, які доступні та пов'язані з цією чергою.
Цей шаблон маршрутизації забезпечує справедливий і збалансований розподіл навантаження, при значаючи взаємодії агентам, які не працювали найдовше. Запобігаючи дисбалансу навантаження, це гарантує, що жоден агент не перевантажується, а інші залишаються вільними. Цей підхід особливо ефективний у періоди постійного контактного потоку, підтримуючи послідовну взаємодію у пу лі агентів.
Агенти втрачають свої «найдовші доступні» позиції на всіх каналах, коли їм пропонують контакт будь-якого типу медіа. Це означає, що після того, як агент обробляє контакт, наступний контакт будь-якого типу медіа в черзі буде призначений наступному найдовшому доступному агенту в цій черзі.
У наведеному вище прикладі агент A1 є найдовшим доступним агентом (позиція 1) — або цей агент увійшов першим, або йому не присвоєно контакт довше, ніж будь-якому іншому агенту.
Агенти A2 (позиція 2) та A3 (позиція 3) також доступні, але вони або ввій шли в систему, або обробляли контакти після A1. Усі агенти пов'язані з обома чергами, які мають цей шаблон маршрутизації.
Розглянемо наступний сценарій:
-
У момент T0 голосовий контакт C1 перебуває в черзі та направляється до найдовшого доступного агента, тобто A1.
Через те, що A1 присвоєно C1, A1 більше не є найдовшим доступним аген том у всіх медіа-каналах.
- У момент T1 контакт чату C2 перебуває в черзі та направляється до найдовшого доступного агента, який зараз є A2.
-
Нарешті, в момент T2 інший голосовий контакт С 3 стави ться в чергу і направляється на A3.
А1 та А2 нещодавно отримали контакти — на даний момент саме A3 чекав найдовше.
Цей шаблон маршрутизації підтримується в наступних типах черг, не заснованих на навичках:
Циркулярний
Шаблон кругової маршрутизації розподіляє вхідні контакти між групою доступних агентів у порядку кругової обробки. Коли контакт знаходиться в черзі, система призначає його наступному доступному агенту в черзі на основі заздалегідь визначеної послідовності.
Процес починається з агентів у налаштованому порядку. Перший вхідний контакт присвоюється першому доступному агенту в цій послідовності. Для наступних контактів система вибирає наступного доступного аген та, продовжуючи з того місця, де зупинилася у визначеному порядку черги. Цей шаблон повторюється, проходячи через агентів, але завжди починається після останньої позиції обраного агента.
Такий підхід ефективний для справедливого та рівномірного розподілу контактів між агентами. Це допомагає гарантувати, що жоден агент не перевантажений контактами, і що всі агенти мають рівні можливості послідовно обробляти взаємодії. Однак схема кругової маршрути зації не враховує поточне навантаження або інші фактори, які можуть вплинути на здатність агента обробляти певний контакт.
У наведеному вище прикладі агенти налаштовуються в круговій черзі в наступному порядку: A3 → A4 → A5 → A6 → A1 → A2.
Почнемо з того, що початкова позиція - це перший агент в налаштованому порядку (А3). Коли контакти перенаправляються до агентів у цій черзі, позиція переміщується навколо кола, розташована до агента, який знаходиться поруч у налаштованому порядку до агента, якому був спрямований останній контакт .
Розглянемо наступний сценарій:
-
Перший контакт (C1) знаходиться в черзі, і він перенаправляється до агента A3.
Покажчик оновлюється до наступного агента у налаштованому порядку, тобто A4.
-
Коли другий контакт (С2) знаходиться в черзі, система починає знаходити доступні агенти починаючи з А4, тобто A4 → A5 → A6 → A1 → A2 → A3.
Однак A4 і A5 недоступні (або вони навіть не зареєстровані, або в режимі очікування, або повністю зайняті іншими контактами цього типу носія), тому C2 направляється на наступний доступний агент — A6. Покажчик оновлюється до наступного агента у налаштованому порядку, тобто A1.
-
Аналогічно, третій контакт (С3) спрямований на A1, четвертий контакт (C4) спрямов аний на A2. Вказівник знову знаходиться на А3.
Ця логіка продовжується, і контакти розподіляються між доступними агентами за шаблоном «круговий»/«круговий».
Якщо в черзі припарковані контакти, сценарій надлишку агента буде відповідати наступному агенту, який стане доступним для цього типу медіа, з найбільш пріоритетним і найстарішим контактом серед них.
Це не враховує і не впливає на існуюче значення позиції в цій черзі, яке оновлюється лише тоді, коли маршрутизація надлишків контактів успішно збігається з агентом.
Цей шаблон маршрутизації підтримується в наступних типах черг, не заснованих на навичках:
Зверху вниз
Шаблон маршрутизації зверху вниз розподіляє вхідні контакти між групою доступних та в порядкованих агентів у послідовному порядку. Коли контакт знаходиться в черзі, система завжди проходить через упорядкований список агентів з самого початку і зіставляє контакт з першим доступним агентом (який має вільний доступний канал типу медіа контакту) у цій послідовності.
Це відбувається для кожного контакту, який стоїть в черзі. Контакт намагається зіставити завжди, починаючи зверху (перший налаштований агент) і продовжуючи вниз по списку, доки не буде знайдений відповідний агент.
На відміну від кругового шаблону маршрутизації, немає «вказівника», який динамічно змі нює початкову точку на основі позиції останнього вибраного агента.
Цей підхід ефективний для розподілу контактів між агентами, які впорядковані на основі певного упередження/уподобання, визначеного адміністратором. Це допомагає гарантувати, що агенти у верхній частині завжди вважають за краще обробляти контакти над агентами під ними. Однак шаблон маршрутизації зверху вниз не враховує поточне навантаження або інші фактори, які можуть вплинути на здатність агента обробляти певний контакт.
У наведеному вище прикладі агенти налаштовуються в черзі зверху вниз у наступному порядку: A3 → A4 → A5 → A6 → A1 → A2.
Це означає, що адміністратор хоче, щоб кожен контакт був спрямований до першого агента (A3), якщо він доступний, інакше наступного агента (A4), якщо він доступний тощо, у налаштованому порядку.
Розглянемо наступний сценарій:
- Перший контакт (C1) знаходиться в черзі, і він перенаправляється до агента A3, оскільки A3 знаходиться у верхній частині замовлення.
-
Коли другий контакт (C2) знаходиться в черзі, маршрутизація знову проводиться з верх ньої частини замовлення (завжди починаючи з A3).
Якщо A3 має більшу ємність каналу для цього типу медіа, C2 також спрямовується на A3. Однак, якщо A3 повністю зайнятий на цьому типі носія, маршрути зація йде вниз по списку до формату A4.
- Однак A4 і A5 недоступні (вони або навіть не зареєстровані, або в режимі очікування, або повністю зайняті іншими контактами цього типу носія), тому C2 направляється до наступного доступного агента в порядку зверху вниз — A6.
-
Аналогічно, третій контак т (С3) намагається маршрутизувати, починаючи від A3 вниз до нижньої частини. Першим відповідним агентом буде А1.
Ця логіка продовжується до тих пір, поки контакт не знайде доступних агентів до кінця замовлення, і в цьому випадку він припаркований у черзі.
Цей шаблон маршрутизації підтримується в наступних типах черг, не заснованих на навичках:
Маршрутизація на основі агента
Маршрутизація на основі агентів — це можливість, яка прямує контакт до вказаного («бажаного») агента безпосередньо в чергу. Пошук агента за допомогою адреси електронної пошти агента або ідентифікатора агента спрямовує контакт до бажаного агента. Діяльність «Черга до агента» у потоці допомагає досягти маршрутизації на основі агента. Докладніші відомості див. у статті Діяльність агента у чер зі.
Контакт може мати зіставлення до одного або декількох бажаних агентів, якими зазвичай можна керувати у зовнішньому додатку поза контактним центром Webex. Бажаний пошук агента для контакту здійснюється за допомогою активності запиту HTTP, яка отримує відображення із зовнішньої програми. Щоб маршрутизувати або припаркувати контакт з бажаним агентом, налаштуйте активність «Черга до агента» за допомогою ідентифікатора контактного центру Webex або адреси електронної пошти агента. Контакт також може бути припаркований проти бажаного агента, якщо цей бажаний агент не доступний негайно.
Маршрутизація на основі агентів корисна в наступних сценаріях:
- Бажана маршрутизація аген та: Клієнт може призначити контакти спеціальним агентам або керівникам відносин. У таких сценаріях маршрутизація на основі агента спрямовує контакти безпосередньо до цього бажаного агента.
- Маршрутизація останнього аген та: Коли контакт кілька разів передзвонює контакт-центру для взаємодії з агентом, маршрутизація на основі агента може спрямувати контакт до останнього агента, який обробляв цей контакт.
В обох випадках дані контакту та відображення агента зберігаються поза контактним цен тром Webex.
Персоналізована маршрутизація AI
Персоналізована маршрутизація штучного інтелекту в контактному центрі Webex допомагає спрямувати взаємодію до відповідного агента, який, за прогнозами, забезпечить найкращий результат для вибраного бізнес-результату. Результатом може бути операційний показник, такий як час обробки, або показник клієнта чи бізнесу, такий як задоволеність клієнтів або результат користувацької взаємодії.
Персоналізована маршрутизація штучного інтелекту не замінює черги, команду, навички, пріоритет, потужність або конфігурацію потоку. Контактний центр Webex спочатку визначає, які агенти мають право на взаємодію на основі існуючої конфігурації маршрутизації. Потім маршрутизація штучного інтелекту ранжує відповідних агентів для вибраного результату бізнесу та повертає рекомендований список. Контактний центр Webex пропонує взаємодію з агентом, який найдовше очікує у цьому списку рекомендованих.
Коли використовувати маршрутизацію AI
Використовуйте маршрутизацію AI для черг, які мають достатньо історичних даних взаємодії, варіації результатів агента та чітку бізнес-мету. Перш ніж активувати маршрутизацію AI, скористайтеся перевіркою оптимізації, щоб переглянути очікуваний потенціал покращення для черги. Результат з низьким потенціалом є рекомендаційним і не заважає вам використовувати маршрутизацію AI.
Маршрутизація AI та маршрутизація на основі правил
Маршрутизація AI працює з маршрутизацією на основі правил. Маршрутизація на основі правил визначає, які агенти мають право на взаємодію. Маршрутизація штучного інтелекту ранжує тих агентів, які відповідають вимогам для вибраного результату, і рекомендує агентів, які, за прогнозами, забезпечать найсильніший результат.
| Площа | Маршрутизація на основі правил | Маршрутизація AI |
|---|---|---|
| Рішення про маршрутизацію | Маршрутизація за налаштованими правилами, такими як найдовша доступність, найкраща доступність, кругова, зверху вниз, пріоритет або призначення агента. | Рейтингує відповідних агентів за прогнозованим результатом для вибраного бізнес-результату. |
| Право на право агента | Використовує членство в черзі, команди, навички, ємність каналу, доступність та правила потоку. | Спочатку використовує ту саму відповідність, а потім рекомендує найсильніших агентів, які відповідають вимогам для взаємодії. |
| Дані, що використовуються | Використовує налаштовані параметри черги та маршрутизації. | Використовує параметри маршрутизації, а також дані про історичну взаємодію, агента, клієнта та результати. |
| Мета оптимізації | Зосереджується на поведінці операційної маршрутизації. | Фокусується на бізнес-результатах на рівні взаємодії, таких як час обробки, задоволеність клієнтів, вирішення першого контакту або спеціальний KPI. |
| Перевірка | Адміністратори коригують правила вручну та контролюють результуючу поведінку. | Адміністратори використовують режим перевірки та оцінки оптимізації перед активацією маршрутизації AI для реального трафіку. |
Максимізуйте результати бізнесу
Коли ви налаштовуєте маршрутизацію AI, виберіть бізнес-результат, який модель повинна оптимізувати. Результат повинен бути доступний на рівні взаємодії, щоб модель могла вчитися на завершених взаємодіях і послідовно повідомляти про результати.
Ви можете використовувати стандартні результати, такі як час обробки або задоволеність клієнтів, коли вони відповідають цілі маршрутизації для черги. Ви також можете використовувати нестандартні результати взаємодії, такі як успіх оновлення, вартість додаткового продажу або вирішення першого контакту, коли організація отримує цю цінність для завершених взаємодій.
Для користувацьких результатів надішліть значення результату до контактного центру Webex як значення рівня взаємодії. Зберігайте послідовність назви змінної, типу даних та значення бізнесу у всіх взаємодіях. Числові або булеві значення найкраще підходять для власних результатів, які потрібно оцінювати та повідомляти.
Ви можете оновлювати глобальні змінні, що підлягають звітуванню, з потоку, веб-хука або робочого процесу після взаємодії після завершення взаємодії. Для отримання додаткової інформації зверніться до порталу розробників.
Для отримання додаткової інформації відвідайте розділ Н алаштування персоналізованої маршрутизації AI.
Можливості черги та маршрутизації в Flow
У Контактному центрі Webex широкий спектр можливостей маршрутизації, черги та керування викликами можна організувати через потоки.
Різноманітні дії потоку та обробники подій, що надаються в Flow Designer, можуть бути розміщені в потоці для ефективного управління життєвим циклом вхідних та вихідних контактів.
Докладніші відомості про налаштування та використання потоків див. у статті С творення потоків та керування ними за допомогою Flow Designer.
Діяльність по черзі
Контакт в черзі
Діяльність «Контакти черги» надає можливість ставити контакт у черзі до активної в хідної черги з організації, щоб його можна було зіставити та направити до потрібного агента у цій черзі.
За допомогою цієї діяльності можна керувати наступними аспектами черги:
- Пріори тет - присвоєння ієрархічної важливості від 1 (найвища) до 10 (найнижча, за замовчуванням) контакту, що знаходиться в черзі.
- Вимо@@ ги до нави чок - Встановіть критерії навичок, яким повинні відповідати агенти в черзі на основі навичок, щоб вважатися придатними для маршрутизації контакту.
- Розслаблення нави чок - Налаштування, зміна або видалення раніше встановлених вимог до навичок через деякий час, щоб підвищити шанси знайти агента.
- Перевірити доступність аген та - Дозвольте системі миттєво розширюватися через усі групи розподілу дзвінків, де немає доступних агентів, щоб уникнути часу очікування.
Див. Мар шрутизація, щоб отримати додаткову інформацію про те, як пріоритет, конфігурація навичок та доступність агента відіграють роль у маршрутизації контактів.
Після того, як активність «Контакт черги» успішно переведе контакт у чергу,
Якщо відповідний агент вже доступний, система спробує спрямувати контакт до агента.
Це перериває виконання основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
Якщо не знайдено відповідного агента, контакт припаркується в черзі та чекає, поки відповідний агент стане доступним.
Потім виконання потоку продовжується з діями, приєднаними після активності Queue Contact, що забезпечує можливість:
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
PlayMusicдіяльність. - Реєструйте зворотний дзвінок на підставі запиту замовника - приєднавши
Callbackдіяльність. - Повторна черга, тобто видаліть контакт з поточної черги та додайте до нової черги - приєд
навши інший
Queue ContactабоQueue to Agentдіяльність.
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
Коли відповідний агент стає доступним, система намагається спрямувати контакт до агента.
У разі успіху це перериває виконання Основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
У наступних випадках активність «Контакт черги» призводить до збою, і виконання потоку переміщується на шлях обробки помилок:
- До контакту вже призначений агент.
- У потоці передбачена недійсна черга, навик або інша конфігурація.
- Максимально дозволені переходи точки входу та черги (25) для контакту вичерпані.
Після того, як активність «Контакт черги» успішно ставить контакт у черзі, наступні спроби маршрутизації відбуваються поза викон анням діяльності. Якщо контакт неодноразово пропонується агентам і на нього немає відповіді, наприклад, через Ring No Answer (RONA), контактний центр Webex повторно спробує маршрутизацію до максимального ліміту 20 спроб. Коли цей лі міт вичерпується, контакт закінчується ROUTING_LIMIT_EXCEEDED помилкою. Він не переміщується до шляху обробки помилок контактів черги, і подальша логіка потоку не виконується.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Контакт у черзі.
Черга до агента
Діяльність «Черга до агента» надає можливість подавати контакт у чергу безпосередньо до бажаного агента, шукаючи його унікальний ідентифікатор агента або адресу електронної пошти в контактному центрі Webex.
За допомогою цієї діяльності можна керувати наступними аспектами черги:
- Пріори тет - Призначте вище/меншу важливість контактам, що знаходяться в черзі проти того самого агента.
- Черга звітності - Визначте чергу, яка буде використовуватися для конфігурації, такої як запис і типова музика в черзі, а також цілі звіту про контакт.
- Черга відновлення - Визначте чергу, яка буде використана як резервна черга, коли контакт не може бути перенаправлений до вказаного бажаного агента.
Після того, як активність «Черга до агента» успішно переведе контакт у чергу,
Якщо агент вже доступний, контакт перенаправляється до агента.
Це перериває виконання основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
Якщо агент доступний, але вирішив відмовитися, а не відповісти або не отримав контакт, він переміщується до наданої черги відновлення.
У черзі відновлення контакт буде спрямований до найдовшого доступного агента без підтримки навичок.
Якщо агент недоступний і вибр ано параме
Park Contact If Agent Unavailableтр «", контакт буде припарковано і чекає, поки агент стане доступним.Потім виконання потоку продовжується з діями, приєднаними після активності «Черга до агента», що дає можливість:
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
PlayMusicдіяльність. Callbackактивність.- Повторна черга, тобто видаліть контакт з поточної черги та додайте до нової черги - приєд
навши інший
Queue to AgentабоQueue Contactдіяльність.
Після того, як агент стає доступним, система намагається спрямувати контакт до агента.
Це перериває виконання основного потоку, і подальші події можуть викликати відповідні потоки подій, якщо налаштовано.
- Відтворюйте попередньо налаштовану музику клієнту, який чекає в черзі - приєднавши
- Якщо агент недоступний, а параметр
Park Contact If Agent Unavailable"«не вибрано, черга не виконується.
Діяльність «Черга до агента» працює, коли:
- Контакт не призначений і готовий до перенаправлення до агента.
- Бажаний ідентифікатор агента або адреса електронної пошти є дійсними.
- Черга звітності та черга відновлення налаштовані правильно.
- Бажаний агент увійшов у систему, доступний і готовий обробляти контакт.
Налаштуйте чергу відновлення, щоб забезпечити безперебійну маршрутизацію контакту, коли бажаний агент недоступний.
У таких випадках діяльність призводить до збою, і виконання потоку переміщується на шлях обробки помилок.
Докладніші відомості про параметри активності, використання та змінні виводу див. у статті С творення потоків та керування ними > Черга до аген та.
Ескалація групи розподілу дзвінків
Активність «Ескалація групи розподілу викликів» підтримується лише для черг із призначенням команди , і надає можливість негайно оновити групу розподілу викли ків для контакту, замість того, щоб чекати автоматичного оновлення розширення для наступної групи після налаштованої тривалості очікування. Це дозволяє швидко перенаправляти контакт до всіх відповідних агентів у черзі.
За допомогою активності «Ескалація групи розподілу викликів» контакт може бути переведений до:
- Наступна група - Розширення набору команд, щоб включити ті, які додані до групи розподілу найближчих викликів.
- Остання група — Розширення набору команд, щоб включити всі команди, зіставлені між усіма групами розподілу викликів, налаштованими для черги.
Активність «Ескалація групи розподілу дзвінків» працює, коли:
- Контакт вже стоїть в черзі і готовий до ескалації.
- Контакт знаходиться в черзі в черзі, яка використовує групи розсилки викликів.
Для черг, які використовують стандартну маршрутизацію, продовжуйте розподіляти контакти через налаштовану поведінку маршрутизації черги.
У таких випадках діяльність призводить до збою, і виконання потоку переміщується на шлях обробки помилок.
Розглянемо приклад сценарію, коли контакт потрапляє в чергу в чергу з трьома гру пами розподілу викликів, кожна з яких оновлюється через 30 секунд.
У командній частині і немає агентів CDG 2, CDG 1а також
доступний агент, TEAM 3який належить до останньої групи розподілу дзвінків.
Якщо активність Ескалація групи розподілу дзвінків не використовується в потоці, це призводить до тривалого часу очікування, як показано нижче:
Час очікування можна скоротити, використовуючи Ескалацію групи розподілу дзвінків, що використовується наступним чином:
Виходячи з вибраного параметра Наступ на група або Остання група, час очікування контакту значно зменшується, як показано нижче:
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Ескалація групи розподілу викликів.
Діяльність з інформацією про чергу
Отримати інформацію про чергу
Діяльність Отримати інформацію про чергу надає можливість отримати інформацію про чергу в режимі реального часу для певного контак ту, наприклад:
- Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо ще не стоїть у черзі.
- Розрахунковий час очікування (EWT) або тривалість, протягом якої передбачається очікування завдання в черзі, перш ніж отримати відповідь.
- Кількість агентів, які увійшли в систему або доступні в поточній групі розподілу дзвінків контакту.
- Кількість агентів, які увійшли в систему або доступні в усіх групах розподілу викликів для вибраної черги.
- Тривалість, протягом якої чекав найстаріший контакт у черзі.
Ці деталі доступні у виконанні потоку як змінні виводу активності.
Докладніші відомості про використання активності, детальне визначення та метод розрахунку для кожної деталі черги див. у розділі Створення потоків та керування ними > Отримати інформацію про чергу.
Деякі способи використання інформації про чергу можуть бути:
- Оголосити позицію контакту в черзі та передбачуваний час очікування клієн ту, поки він чекає маршрутизації.
- Вирішити, чи можна зареєструвати зворотний дзвінок для клієнта, якщо передбачуваний час очікування занадто довгий.
- Щоб перевести контакт до наступної групи розподілу викликів (CDG), якщо агенти не доступні в командах, пов'язаних з поточною CDG.
Діяльність Отримати інформацію про чергу працює, коли вибрана змінна переходить до дійсної черги.
Налаштуйте шлях обробки помилок, щоб витончено керувати випадками, коли вибрана змінна потребує перевірки або не переходить до доступної черги.
- контакт (ще) не перебуває в черзі, коли виконується дія Отримати інформацію про чергу.
- контакт знаходиться в черзі в черзі, яка не підтримує концепцію груп розсилки викликів.
У цих випадках значення -1 у цих вихідних полях вказує на те, що ця інформація не застосовується.
Розглянемо приклад сценарію, коли клієнт повинен бути повідомлений про довгу EWT в черзі, після кожних 15 секунд, проведених у черзі.
Цього можна досягти за допомогою активності Отримати інформацію про чергу у потоці наступним чином:
Розширена інформація про чергу
Активність Advanced Queue Info надає можливість отримати інформацію про чергу в режимі реального часу для даного контакту, додатково враховуючи критерії навичок контакту, такі як:
- Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо ще не стоїть у черзі.
- Кількість агентів, які увійшли в систему або доступні в поточній групі розподілу дзвінків контакту, що відповідають заданим критеріям кваліфікації.
- Кількість агентів, які увійшли в систему або доступні для всіх груп розподілу викликів для вибраної черги, що відповідають заданим критеріям навичок.
- Поточна група розподілу викликів, де контакт припаркований у передбаченій черзі.
- Загальна кількість груп розсилки дзвінків у передбаченій черзі.
Ці деталі доступні у виконанні потоку як змінні виводу активності.
Докладніші відомості про використання активності, детальне визначення та метод розрахунку для кожної деталі черги див. у розділі Створення та керування потоками > Додаткові відомості про чергу.
Деякі способи використання розширеної інформації про чергу можуть бути:
- Оголосити позицію контакту в черзі замовнику, поки він чекає маршру тизації.
- Щоб перевести контакт до наступної групи розподілу викликів, якщо агенти, які відповідають критеріям навичок, не доступні в командах, пов'язаних з поточною групою розподілу викликів.
- Щоб вирішити, чи можна зареєструвати зворотний дзвінок для клієнта, якщо жоден агент, що відповідає критеріям кваліфікації, не ввійшов у систему у всіх групах розподілу дзвінків.
Активність Додаткова інформація про чергу працює, коли:
- Інформація про чергу запитується для черг, де вимоги до навичок налаштовуються в потоці, а не як критерії навичок рівня черги.
- Якщо контакт вже знаходиться в черзі, інформація запитується для тієї самої черги, де контакт зараз знаходиться в черзі.
- Контакт знаходиться в черзі до черги, а не безпосередньо до бажаного агента.
Налаштуйте шлях обробки помилок для керування запитами, які не відповідають цим вимогам.
У таких випадках діяльність призводить до збою, і виконання потоку переміщується на шлях обробки помилок.
Розглянемо приклад сценарію, коли замовника слід повідомити про отримання зворотного дзвінка, враховуючи, що агенти, що відповідають критеріям кваліфікації, не доступні.
Цього можна досягти, використовуючи активність Додаткові відомості про чергу в потоці наступним чином:
Діяльність контролю дзвінків
Встановити ідентифікатор абонента
Активність «Встановити ідентифікатор абонента» використовується для визначення ідентифікатора абонента, який повинен відображатися під час дзвінка. Активність «Встановити ідентифікатор абонента» повинна використовуватися лише для потоків подій PreDial як термінальну активність , яка позначає кінець потоку подій.
Активність «Встановити ідентифікатор абонента» дозволяє налаштувати необхідну автомати чну ідентифікацію номера (ANI) на основі служби ідентифікації набраного номера (DNIS), типу операції або типу учасника.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Встановлення ідентифікатора абонен та.
Контроль запису
Активність керування записом призначена для використання разом із активністю меню для отримання згоди на запис від абонента. Це забезпечує дотримання правил або політик, що вимагають явної згоди перед початком запису, плавно інтегруючи цей крок у робочий процес.
Активність меню IVR повинна відображати згоду користувача в булеву змінну, яка буде призначена як вхід для активності керування записом. Якщо клієнту потрібно повідомити про згоду користувача у звіті про згоду, значення згоди має зберігатися в глобальній змінній, що підлягає звітності. Крім того, можна використовувати локальну змінну, якщо звітність не потрібна. Такий підхід забезпечує орендарям та клієнтам підвищену гнучкість у ефективному управлінні та використанні змінних.
Коли ця діяльність додається до потоку, згода користувача має перевагу над рівнем орендаря або рівнем черги або налаштуваннями рівня розкладу запису.
Порядок пріоритету такий:
- Якщо згода користувача є у потоці «Так», то дзвінок записується незалежно від конфігурації запису, встановленої на рівні орендаря, черги чи розкладу запису.
- Якщо користувач не дає згоди як відповідь на діяльність, то дзвінок не записується, незалежно від конфігурації запису, встановленої на рівні орендаря, черги чи розкладу запису.
- Якщо в потоці не налаштовано дію «Керування записом», але для конфігурації встановлено значення Так на будь-якому з інших рівнів, наприклад орендаря, черги або графіка запису , виклик записується.
- Якщо в потоці не налаштовано дію керування записом, а для конфігурації встановлено значення Ні на всіх рівнях, таких як орендар, черга та графік запису, виклик не записується.
Цей контроль запису можна проілюструвати, як показано нижче:
Крім того, конфігурації запису, як-от «Продовжити при перенесенні», «Призупинити відновлення», «Призупинити тривалість» та інші, залишаються застосовними відповідно до існуючої ієрархії, включаючи рівні орендаря, черги чи розкладу запису.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Керування записами.
Сліпий трансфер
Blind Transfer — це процес, при якому контакт ефективно перенаправляється на зовнішній номер набору (DN) через систему IVR, що виключає необхідність залучення агента.
Активність Blind Transfer використовується, коли виклик повинен бути перенесений до зовнішнього або стороннього DN. Це кінцева діяльність, тому потік закінчується після виконання передачі.
Активність Blind Transfer не підтримується, коли потік виконується для консультації.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Blind Transfer.
Мостова передача
Активність «Мостова передача» дозволяє тимчасово перенести контакт до зовнішнього пункту призначення, поки потік зберігає контроль над викликом. Зовнішнім пунктом призначення може бути зовнішній міст або послуга інтерактивної голосової відповіді (IVR).
Коли зовнішній пункт призначення закінчує дзвінок, потік дзвінків продовжується далі за потреби, наприклад, подаючи його в чергу до агента.
Активність Bridge Transfer видаляє контакт у черзі під час передачі його до сторонньої системи IVR або автоматичного розподілу дзвінків (ACD). Якщо контакт не обробляється сторонньою системою, його можна переставити в чергу до початкової черги, гарантуючи, що контакт залишається в робочому процесі для належної обробки.
Наприклад, припустимо, що контактний центр має ресурси агента контактного центру Webex та ресурси агента у зовнішньому колл-центрі або Біржі приватних відділень (АТС). Клієнт хоче поставити дзвінок у чергу до черги агентів контактного центру Webex протягом короткого періоду (скажімо, 60 секунд). Якщо агент не доступний протягом цього періоду, виклик може бути переданий мостовиком (з неявним виведенням черги) зовнішньому кол-центру для обробки контакту.
- Активність мостового переказу не підтримується у потоках вихідних викликів та потоках подій.
- Контакти, які вже призначені агенту, не підтримуються для Bridge Transfer через потік.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Мостова передача.
Відключити контакт
Активність «Відключити контакт» забезпечує можливість відключення або припинення активного контак ту безпосередньо від потоку.
Це термінальна діяльність, приєднана до потоку, і може бути корисною для припи нення контактів без втручання агента, підходить для потоків шляху помилок або після реєстрації зворотного дзвінка для клієнта.
Виходячи з конфігурації, опитування після дзвінка або зворотний зв'язок спрацьовує, коли контакт закінчується через цю діяльність.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Відключення контакту.
Встановити пріоритет контактів
Діяльність «Встановити пріоритет контактів» сприяє ефективному управлінню пріоритетом контактів у потоці, дозволяючи призначати контактам конкретні рівні пріоритету. Це дозволяє надавати певним контактам більшу або меншу важливість, гарантуючи, що вони належним чином спрямовуються порівняно з іншими контактами, які очікують, коли агенти стануть доступними. Ця гнучкість дозволяє точно контролювати пріоритетність контактів протягом усього потоку.
Пріоритет встановлюється шляхом присвоєння ієрархічного рівня важливості від 1 (найвищий) до 9 (найнижчий). Контакти з найвищим пріоритетом спрямовуються раніше тих, хто має нижчі пріоритети. Якщо кілька контактів мають однаковий рівень пріоритету, контакт, який чекав найдовше, перенаправляється першим до наступного доступного та відповідного агента. Ця система гарантує, що контакти з вищим пріоритетом отримують оперативну увагу, зберігаючи справедливість між контактами однакового пріоритету залежно від часу їх очікування.
- Активність «Встановити пріоритет контактів» може бути розміщена в будь-якій точці основного потоку або потоку подій.
- Якщо дію «Встановити пріоритет контактів» налаштовано перед дією черги (наприклад, Контакт у черзі або Агент черги), її параметр пріоритету може бути замінений будь-яким пріоритетом, явно налаштованим у наступних діях черги. Однак, якщо наступна дія черги не вказує пріоритет, буде застосовано пріоритет контактів, встановлений попередньою активністю «Встановити пріоритет контактів».
- І навпаки, якщо активність «Встановити пріоритет контактів» налаштовується після дії черги (наприклад, Контакт у черзі або Черга до агента), вона замінить параметр пріоритету, налаштований попередньою діяльністю черги.
- Активність «Встановити пріоритет контактів» наразі не підтримується для контактів зовнішнього дзвінка та кампанії.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Встановити пріоритет контактів.
Діяльність зворотного дзвінка
Зворотний дзвінок
Активність зворотного дзвінка дозволяє абонентам запитувати зворотний дзвінок, а не чекати в очікуванні, значно покращуючи задоволеність клієнтів за рахунок скорочення часу очікування та мінімі зації частоти відмови. Після активації активність зворотного дзвінка створює завдання в черзі, гарантуючи, що доступний агент може повернути дзвінок клієнта.
Конструктор потоку може налаштувати активність так, щоб контакт залишався в первісній черзі, де виклик почався, або призначати його до іншої черги на основі налаштувань. Якщо зворо тний виклик залишається в початковій черзі, контакт зберігає свою позицію, навички, пріоритет та контекстні дані, що дозволяє безперебійно призначити наступному доступному агенту. Однак, якщо вибрано іншу чергу, контакт пересувається до кінця вибраної черги без навичок і з пріоритетом за замовчуванням.
Ця діяльність також дозволяє клієнтам запитувати зворотні дзвінки від своїх бажаних агентів, додаючи особистий штрих до досвіду та підвищуючи задоволеність клієнтів. Цього можна досягти, коли активність зворотного виклику слідує за діяльністю QueueToAgent у потоці. Крім того, активність зворотного дзвінка пропонує додаткову конфігурацію для налаштування автоматичної ідентифікації номера (ANI), що використовується під час процесу зворотного дзвінка. Ця настройка допомагає узгодити бренд та зменшує ймовірність відхилення дзвінка, забезпечуючи впізнаваний іденти фікатор абонента.
Конструктор потоку має можливість включити подію callbackFailed у потік подій. Ця подія спрацьовує, коли спроба зворотного виклику не вдається, що дозволяє дизайнеру потоку реалізовувати повторні спроби через певні проміжки часу. Затримку або інтервал між повторними спробами можна налаш тувати за допомогою активності очікування, з мінімальним інтервалом повторної спроби 10 секунд і максимум 72 години. Система підтримує до 10 спроб повторної спроби протягом максимум 14 днів, використовуючи активність «Очікування».
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Зворотний виклик.
Заплануйте зворотний дзвінок
Діяльність «Запланований зворотний дзвінок» дає можливість клієнтам запропонувати клієнтам зручність запиту зворотного дзвінка в певну майбутню дату та час, усуваючи необхідність негайного підключення до агента. Ця функція покращує досвід клієнтів, дозволяючи їм вибрати зручне вікно зворотного дзвінка, тим самим мінімізуючи уявний час очікування та зменшуючи частоту відмови від дзвінків.
Потік повинен фіксувати вхідні дані абонента, такі як бажана дата та час, через підказки DTMF та передавати їх діяльності після виконання необхідних перевірок введення.
Перш ніж розпочати роботу, переконайтеся, що точка входу зворотного дзвінка за замовчуванням налаштована в розділі Параметри каналу в Центрі управління. Докладніші відомості див. у статті Налаштування точки входу зворотного виклику.
Зворотний виклик можна запланувати за допомогою будь-якої черги телефонії, будь то вхідний або вихідний. Для досягнення найкращих результатів рекомендується додати активність «Відключити» одразу після дії Запланований зворотний дзвінок, щоб переконатися, що поточний дзвінок закінчується належним чином після запланованого зворотного дзвінка. Для отримання додаткової інформації про планування зворотних викликів IVR див. Розклад зворотних викликів IV R.
Коли зворотний дзвінок спрацьовує у запитану майбутню дату та час, створюється новий дзвінок або взаємодія. Ця нова взаємодія буде слідувати стандартному потоку, пов'язаному з точкою входу за замовчуванням зворотного дзвінка. Якщо спроба зворотного виклику не вдається, потік може автоматично повторити виклик за допомогою обробника подій callbackFailed, якщо його налаштов ано у цьому потоці.
Перед передачею вхідних даних до діяльності слід враховувати наступні перевірки вхідних даних:
- Вибір дати — Ви можете вибрати будь-яку дату від сьогодні до 31 дня в майбутньому. Дата повинна бути в такому форматі: РРРРР-ММ-ДД (наприклад, 2025-07-18).
- Час початку та закінчення часового вікна — час, який ви вибрали, повинен починатися щонайменше за 30 хвилин і може тривати від 30 хвилин до 8 годин. Будь ласка, використовуйте 24-годинний формат часу (наприклад
14:30:00). - Часовий пояс — Ви повинні ввести дійсний часовий пояс у форматі IANA (наприклад
America/New_York), щоб ми могли зателефонувати вам у потрібний час.
Довідкова реалізація надається у формі шаблону підпотоку для демонстрації підказок DTMF та основних перевірок, які використовуються разом із діяльністю. Докладніші відомості див. у розділі Шаблон підпотоку запланованого зворотного виклику.
Аналіз прогресу дзвінків
Активність аналізу прогресу дзвінків (CPA) дозволяє виявляти автоматизовані автовідповідачі та живі люд ські голоси під час дзвінків зворотного дзвінка.
Коли при спробі зворотного дзвінка виникає виявлення автовідповідача (AMD) або голосова пошта, система визначає дзвінок як невдалий. Результат виявлення автовідповідача (AMD) фік сується у вихідній змінній reason обробника подій callbackFailed. На основі цієї вихідної змінної конструктор потоку може налаштувати повторні спроби виклику.
- Для ввічливого зворотного дзвінка, CallProgressAnalysis можна розмістити в точці після дії зворотного виклику в основному потоці. Для запланованого зворотного дзвінка або особистого заплан ованого зворотного дзвінка його можна розмістити після NewPhoneContact в основному потоці.
- У потоці подій вона підтримується лише в обробнику подій callbackFailed.
- Якщо в потоці налаштовано опитування клієнтів після дзвінка (активність зворотного зв'язку), воно не буде ініціюватися, якщо на дзвінок відповість AMD або голосова пошта. Це запобігає запуску непотрібних обстежень.
Для отримання додаткової інформації про параметри активності, змінні використання та вихідні змінні див. Створення потоків та керування ними > Аналіз прогресу викликів.
Черга
Огляд
У 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 або голосовою поштою. Це запобігає виникненню непотрібних опитувань.
Для отримання додаткової інформації про налаштування активності, змінні використання та вихідні параметри дивіться у розділі «Створення та керування потоками» > Аналіз прогресу дзвінків.
