У чергах без навичок із призначенням команд можна організовувати агентів у команди та об'єднувати ці команди в групи розподілу викликів (CDG). Ви можете встановити часову затримку між кожною групою, щоб керувати потоком дзвінків.

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

Ви можете налаштувати такі типи команд:

• Окремі команди: Агенти можуть бути організовані в команди, які можуть представляти певну організаційну функцію, яка потім може стати частиною черг, щоб контакти могли бути спрямовані до агентів цих команд. Ви можете позначити агента кількома командами, щоб обробляти контакти з різних черг для ефективної маршрутизації.
• Команди на основі потужності: Команда, заснована на потужності (CBT) — це функція, яка спрямовує голосові дзвінки на прямий номер на основі ємності (DN), де ємність визначає, скільки дзвінків можна обробляти одночасно. Він дає змогу спрямовувати дзвінки на телефонні номери, не вимагаючи від операторів входу в систему, що робить його придатним для сценаріїв, коли на дзвінки відповідають голосова пошта, автовідповідачі або групи пошуку, а не традиційні агенти колл-центру. У цій конфігурації немає конкретних агентів, призначених команді, і вони не використовують Webex Contact Center Agent Desktop.

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

Перша група розподілу дзвінків містить КОМАНДУ 1, в якій налаштовано 3 оператора – А1, А2 і А5.

Друга група розподілу дзвінків містить TEAM 2, в якій налаштовано 3 оператори – А2, А3 та А4.

Третя (і остання) група розподілу дзвінків містить КОМАНДУ 3, в якій налаштовано 2 агента – А6 і А7.

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

Функція під назвою «Перевірити доступність агента» призводить до миттєвого розширення контакту до наступної групи розподілу викликів, якщо в поточній групі немає відповідних агентів. Це можна активувати в активності «Черга контактів» <ПОСИЛАННЯ НА розділ 3.1.1> у потоці.

Результатом такого налаштування є такі сценарії:

1. А2 належить до КОМАНДИ 1 та КОМАНДИ 2. Якщо A2 вибирає TEAM 1 для входу в Agent Desktop, система вважає A2 частиною TEAM 1 і, отже, лише першою групою розподілу дзвінків.
2. A5 належить до TEAM 1, однак також міг бути частиною якоїсь іншої команди в організації, в яку вони зараз увійшли. Тому А5 не розглядається як частина КОМАНДИ 1 і не пов'язана з цією чергою.

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

Доступна схема маршрутизації:

• Найдовший з доступних

Черги, не пов'язані з навичками, — це тип черги, де пул агентів безпосередньо призначається до черги. На відміну від інших типів черг, які опосередковано визначають пул призначених їм агентів, ці черги дозволяють адміністраторам вибирати агентів безпосередньо та вручну. Наприклад, черги завдань на основі команд призначають агентів на основі їхніх зареєстрованих команд, а черги завдань на основі навичок призначають агентів матчу на основі потрібних навичок. На противагу цьому, адміністратори можуть безпосередньо додавати агентів до цих черг, щоб стати частиною черги. Це забезпечує простий спосіб керувати розподілом агентів, не покладаючись на керовані системою завдання.

Черги з призначенням агентів забезпечують прості, але ефективні алгоритми маршрутизації, які допомагають розподілити контакти серед пулу операторів. Вони не враховують навички агентів у маршрутизації контактів. Однак операторів можна замовляти в межах кожної черги, і це враховується при маршрутизації контактів до них. У цьому контексті команди в першу чергу служать організаційною конструкцією для керівників, а не фактором при прийнятті рішень про асоціацію агентів і чергу і маршрутизацію контактів, що спрощує управління чергою.

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

Однак складним організаціям контакт-центрів може бути складно вручну керувати призначеннями агентів у цих чергах. Вони могли б отримати більше користі від інших типів черг, які пропонують динамічну маршрутизацію та зв'язки агент-черга.

У цьому прикладі черга має набір агентів, зіставлених з нею в певному порядку, наприклад A4, A9, A7 і так далі. Цей порядок відіграє роль у специфічних алгоритмах маршрутизації, які зіставляють вхідні контакти з операторами. Система зіставляє контакти з цими агентами на основі їх наявності та обраного алгоритму маршрутизації.

На відміну від черг з командним призначенням, тут немає поняття розширення цілі за часові проміжки. Якщо жоден з налаштованих агентів недоступний для маршрутизації цього контакту, він паркується в черзі, поки один з цих агентів не стане доступним для обробки контактів до тайм-ауту паркування. Цільове розширення до цих черг не застосовується.

Доступні схеми маршрутизації:

• Найдовший з доступних
• Круглий
• Лінійний/Зверху вниз

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

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

Цей тип черги відрізняється від черг на основі призначення команди в тому сенсі, що немає налаштувань групи розподілу викликів, що означає, що команда не відіграє ролі в асоціації агента з чергою. Більше того, необхідні навички статично налаштовані в цій черзі, на відміну від командних черг навичок, де потік вводить (статичні або змінні) необхідні навички. Отже, технічно навички є частиною черги, а не самого контакту.

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

Кожен контакт у черзі в цю чергу автоматично прийме критерії навичок, визначені в самій черзі. Окремі контакти не можуть визначати або змінювати власні вимоги/критерії до навичок, на відміну від черг на основі навичок із командним призначенням.

У цьому прикладі

• Тільки агенти А1, А3 і А7 повністю відповідають критеріям навичок, налаштованим в черзі, отже, тільки ці агенти будуть пов'язані з цією чергою.
• Агенти А2, А4 та А6, які частково відповідають критеріям, або А5, які не мають відповідних навичок, не можуть бути пов'язані з цією чергою.

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

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

Черги, засновані на навичках, найкраще підходять там, де статичне призначення навичок і управління чергою до об'єднання агентів є можливим і бажаним для оперативного контролю. Вони також підходять, коли підбір алгоритмів маршрутизації підходить для розподілу роботи між агентами. Ці черги також особливо корисні для сценаріїв, коли різні типи запитів до клієнтів вимагають певних навичок, які може бути оброблені заздалегідь підготовленим сегментом експертних агентів.

Організаціям складних контакт-центрів може бути простіше керувати завданнями між агентами в чергах на основі навичок, порівняно з чергами з призначенням агентів, де кожного оператора потрібно додавати до списку вручну, що є громіздким, особливо для великої організації.

Черги на основі навичок з вимогами до навичок, призначеними в потоці, — це тип черги на основі командних призначень у Webex Contact Center, де набір команд налаштовується на кількох рівнях, які називаються групами розподілу викликів. Операторам, які увійшли до цих налаштованих команд, призначаються контакти з цієї черги на основі рівня групи розподілу викликів, на якому налаштована їхня команда в черзі, якщо вони також повністю відповідають вимогам до навичок контактної особи.

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

Агенти набувають навичок за допомогою профілю навичок, безпосередньо призначеного агенту. Навички агента визначаються на основі вибору команди під час входу.

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

Крім того, контакти також можуть вказувати послаблення навичок через налаштовані проміжки часу. Це модифікований набір вимог до навичок, які замінюють початкові вимоги до навичок контакту через налаштовані інтервали часу. Це дозволяє контакту змінювати (зазвичай використовується для «послаблення») свої вимоги до навичок під час стоянки в черзі, щоб більше агентів могли відповідати цим послабленим вимогам до навичок.

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

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

• У першій групі розподілу дзвінків знаходиться TEAM 1, в якій налаштовано 3 оператора – А1, А2 і А5.
• Друга група розподілу дзвінків містить TEAM 2, в якій налаштовано 3 оператори – А2, А3 та А4.
• Третя (і остання) група розподілу дзвінків містить КОМАНДУ 3, в якій налаштовано 2 агента – А6 і А7.

Однак слід зазначити дві основні речі:

• Кожен контакт, який потрапить у чергу в цю чергу, визначить свої вимоги до навичок і розслаблення навичок у потоці.
• Агенти можуть мати налаштовані навички (через профіль навичок – прямий або успадкований від зареєстрованої команди).

Хоча 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).
• З часом, після розслаблення навичок, додатково А2 і А4 також тепер задовольняють вимоги до «розслаблених» навичок контакту.

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

Це продовжується до тих пір, поки не будуть розгорнуті всі налаштовані групи розподілу викликів і не будуть застосовані всі послаблення навичок, якщо раніше не буде знайдено відповідного агента.

Доступні схеми маршрутизації:

• Найдовший з доступних
• Найкраще з доступних

Сценарій «Надлишок агента» виникає, коли вільних агентів більше, ніж контактів у черзі. У цьому випадку, коли взаємодія з клієнтом (контакт) поставлена в чергу, система намагається негайно знайти відповідного агента для цього конкретного контакту, і якщо відповідний агент знайдений, контакт не потрібно паркувати в черзі і чекати, поки агент підбору буде доступний пізніше.

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

Пошук відповідного агента для конкретного контакту використовує налаштований шаблон маршрутизації в черзі.

Webex Contact Center пропонує кілька шаблонів маршрутизації між різними типами черг, які дозволяють організаціям оптимізувати обслуговування клієнтів, мінімізуючи час очікування, балансуючи робоче навантаження агентів і гарантуючи, що клієнти пов'язані з агентами, які мають необхідні навички для задоволення своїх конкретних потреб. Зверніться до розділу Схеми маршрутизації для отримання детальної інформації про схеми маршрутизації.

Маршрутизація надлишку контактів відбувається, коли кількість вхідних взаємодій з клієнтами (або контактами) перевищує доступну операторську діяльність. Така ситуація часто виникає в пікові періоди або несподівані сплески обсягу контактів. Основна мета маршрутизації надлишків контактів полягає в ефективному управлінні цим переповненням, забезпечуючи дотримання стандартів обслуговування клієнтів, незважаючи на надмірний попит. Для оператора, який щойно став доступним на певному каналі, маршрутизація надлишків контактів працює над пошуком та призначенням відповідного контакту серед усіх припаркованих контактів у всіх чергах, з якими цей агент пов'язаний.

Ключовими стратегіями для ефективного виконання маршрутизації контактів з обмеженою доступністю агентів є:

• Ранжування черги

  Ранжування черг дозволяє адміністраторам вказувати відносну важливість черг. Адміністратори можуть визначати рейтинг черг, щоб встановлювати порядок перенаправлення викликів із черг до агентів, які ввійшли в систему, для кожної команди.

  Наприклад, уявіть, що агенти, які увійшли в команду А, пов'язані з двома чергами – «Білінг» і «Продажі». Адміністратори можуть використовувати ранжування в черзі, щоб призначити більш високе місце в черзі «Виставлення рахунків», тому, коли контакти потрапляють в черги, контакти з розділу «Виставлення рахунків» будуть спрямовуватися до агентів, що належать до команди А, раніше контактів з черги «Продажі». Це станеться, навіть якщо в черзі "Продажі" можуть чекати старіші контакти з вищим пріоритетом - просто тому, що черга "Виставлення рахунків" має вищий рейтинг у черзі, ніж черга "Продажі". Тільки коли в черзі «Виставлення рахунків» більше немає контактів, що очікують, агенти з команди А будуть направляти контакти з черги «Продажі» (і будь-якої іншої), з якою вони пов'язані.

  Нижче наведено деякі з важливих характеристик ранжування в черзі:

  • • Якщо ранг присвоєно лише деяким чергам, виклики в цих чергах матимуть пріоритет над викликами в чергах, для яких не вказано ранг.
    • Ранжування в черзі може бути встановлено максимум на 50 чергах для всіх типів медіа зі значенням від 1 до 50, де 1 є найвищим рангом.
    • Ви можете призначити одне й те саме звання кільком чергам.
    • Якщо ви ввімкнете ранжування черги, черги, яким не присвоєно жодного явного рангу, розглядатимуться нижче, ніж усі ранжовані черги.

    • Queue Ranking працює в межах одного типу медіа.

      Наприклад, якщо «Черга продажу» – це черга голосового медіа з рангом 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 спрямовують вхідні взаємодії з клієнтами до агентів на основі конкретних навичок, необхідних для вирішення запиту, таких як володіння мовою або технічні знання. Ці моделі гарантують, що кожен клієнт зв'яжеться з найкваліфікованішим агентом, підвищуючи ефективність обслуговування та задоволеність клієнтів. Переваги включають скорочення часу обробки, покращення показників вирішення проблем та оптимізоване використання ресурсів агентів шляхом узгодження їхньої експертизи з потребами клієнтів.

Коли використовуються шаблони маршрутизації на основі навичок, спочатку використовуються вимоги до навичок контакту (призначені в потоці) або критерії навичок, призначені черзі, для фільтрації доступних агентів, чиї навички повністю відповідають цим вимогам/критеріям. Потім серед відфільтрованих агентів для контакту вибирається один на основі налаштованого шаблону маршрутизації.

Webex Contact Center також підтримує різноманітні шаблони маршрутизації, що не базуються на навичках, які зосереджені на розподілі вхідних взаємодій з клієнтами без урахування конкретних навичок чи досвіду агентів. На відміну від шаблонів маршрутизації на основі навичок, ці не враховують навички агента та не вимагають від контактної особи чи черги визначення вимог до навичок/критеріїв для маршрутизації. Швидше, вони надають пріоритет таким факторам, як доступність, розподіл робочого навантаження та попередньо визначені послідовності, що дозволяє ефективно обробляти контакти на основі операційної логіки, а не компетенцій окремих агентів. Ці шаблони особливо корисні в середовищах, де взаємодії є відносно однорідними або не потребують спеціалізованої обробки.

Маршрутизація на основі агентів — це можливість, яка направляє або ставить контакт у чергу безпосередньо до вказаного («бажаного») агента. Пошук агента за адресою електронної пошти агента або його ідентифікатором спрямовує контакт до бажаного агента. Діяльність «Черга до агента» в потоці допомагає досягти маршрутизації на основі агентів. Для отримання додаткової інформації див. активність Черга до агента .

Контакт може мати зіставлення з одним або кількома бажаними агентами, якими зазвичай можна керувати в зовнішній програмі поза межами Webex Contact Center. Пошук бажаного агента для контакту здійснюється через дію HTTP-запит , яка отримує зіставлення із зовнішньої програми. Щоб спрямувати або припаркувати контакт для потрібного агента, налаштуйте дію «Додати до черги до агента», використовуючи ідентифікатор агента Webex Contact Center або адресу електронної пошти. Контакт також можна припаркувати для бажаного агента, якщо цей бажаний агент зараз недоступний.

Маршрутизація на основі агентів корисна в таких сценаріях:

• Маршрутизація бажаних агентів: Клієнт може призначити контакти виділеним агентам або менеджерам з взаємодії. У таких сценаріях маршрутизація на основі агентів спрямовує контакти безпосередньо до цього бажаного агента.
• Маршрутизація останнього агента: Коли контакт кілька разів передзвонює до контакт-центру для взаємодії з агентом, маршрутизація на основі агента може спрямувати контакт до останнього агента, який обробляв цей контакт.

В обох випадках використання дані контакту та зіставлення агента зберігаються поза межами Webex Contact Center.

Дія «Додати контакт до черги» надає можливість додавати контакт до активної черги вхідних повідомлень з організації, щоб його можна було зіставити та спрямувати до потрібного агента в цій черзі.

За допомогою цієї дії можна керувати такими аспектами черг:

• Пріоритет – призначення контакту, що ставиться в чергу, ієрархічної важливості від 1 (найвищий) до 10 (найнижчий, за замовчуванням).
• Вимоги до навичок – встановлення критеріїв навичок, яким повинні відповідати агенти в черзі на основі навичок, щоб вважатися придатними для маршрутизації контакту.
• Послаблення вимог до навичок – налаштування, зміна або видалення раніше встановлених вимог до навичок через певний проміжок часу для покращення шансів знайти агента.
• Перевірка доступності агента - Дозволяє системі миттєво розширюватися по всіх групах розподілу викликів, де не знайдено доступних агентів, щоб уникнути часу очікування.

Див. розділ Маршрутизація для отримання додаткової інформації про те, яку роль у маршрутизації контактів відіграють пріоритет, конфігурація навичок та доступність агента.

Після того, як дія «Контакт у черзі» успішно поставить контакт у чергу,

• Якщо відповідний агент вже доступний, система намагається спрямувати контакт до агента.

  Це перериває виконання основного потоку , і подальші події можуть запускати відповідні потоки подій, якщо вони налаштовані.

• Якщо відповідного агента не знайдено, контакт ставиться в чергу та очікує, поки з'явиться відповідний агент.

  Виконання потоку потім продовжується з діями, доданими після дії контакту з чергою, що надає можливість:

  • Відтворити попередньо налаштовану музику для клієнта, який чекає в черзі, шляхом додавання дії PlayMusic.
  • Зареєструйте зворотний дзвінок на основі запиту клієнта, додавши дію зворотного дзвінка.
  • Переставити в чергу, тобто видалити контакт із поточної черги та додати його до нової черги, – шляхом додавання іншого контакту з черги або черги до дії агента.

Коли з'являється відповідний агент, система намагається спрямувати контакт до агента.

У разі успіху це перериває виконання основного потоку , і подальші події можуть запускати відповідні потоки подій, якщо вони налаштовані.

У таких випадках дія призводить до збою, і виконання потоку переходить до шляху Обробка помилок .

Щоб отримати додаткові відомості про налаштування активності, використання та вихідні змінні, див. розділ Створення та керування потоками > Контакт черги.

Дія «Черга до агента» надає можливість додавати контакт безпосередньо до потрібного агента, шукаючи його унікальний ідентифікатор агента або адресу електронної пошти в Webex Contact Center.

За допомогою цієї дії можна керувати такими аспектами черг:

• Пріоритет - Призначення вищої/нижчої важливості контактам, що стоять у черзі з тим самим агентом.
• Черга звітності - Визначте чергу, яка буде використовуватися для налаштування, такого як запис і музика в черзі за замовчуванням, а також повідомте про мету контакту.
• Черга відновлення - Визначити чергу, яка буде використовуватися як резервний варіант, коли контакт не вдається перенаправити до вказаного бажаного агента.

Після успішного розміщення контакту в черзі, дія «До агента» успішно

• Якщо агент вже доступний, контакт перенаправляється до агента.

  Це перериває Основний потік виконання та подальші події можуть ініціювати відповідні Потоки подій, якщо налаштовано.

• Якщо агент доступний, але вирішує відмовити, не відповідати або не може отримати контакт, він переміщується до наданої черги відновлення.

  У черзі відновлення контакт буде перенаправлено до агента, доступного найдовше, без будь-якої підтримки навичок.

• Якщо агент недоступний і " Контактна особа парку, якщо агент недоступний "варіант є вибраний, контакт паркується та чекає, поки агент стане доступним.

  Виконання потоку потім продовжується з діями, доданими після дії «Додати до агента в чергу», що дає можливість:

  • Відтворити попередньо налаштовану музику для клієнта, який чекає в черзі, – приєднавши PlayMusic діяльність.
  • Зворотний дзвінок діяльність.
  • Переставити в чергу, тобто видалити контакт із поточної черги та додати його до нової черги, додавши інший Черга до агента або Контакт у черзі діяльність.

  Щойно агент стає доступним, система намагається спрямувати контакт до агента.

  Це перериває виконання Основного потоку , а подальші події можуть запускати відповідні Потоки подій, якщо вони налаштовані.

• Якщо агент недоступний, а опція " Паркувати контакт, якщо агент недоступний " не вибрана , черга не вдається.

У таких випадках активність призводить до збою, і виконання потоку переходить на шлях обробки помилок.

Для отримання додаткової інформації про налаштування активності, використання та вихідні змінні дивіться статтю Створення та керування потоками > Черга до агента».

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

Використовуючи активність групи розподілу викликів, контакт можна перенести на:

• Наступна група: розширення набору команд за рахунок включення тих, що були додані до групи розподілу викликів безпосередньо.
• Остання група — розширення набору команд, щоб включити всі команди, зіставлені з усіма групами розподілу викликів, налаштованими для черги.

У таких випадках активність призводить до збою, і виконання потоку переходить на шлях обробки помилок.

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

У командній частині CDG 1 і CDG 2 немає агентів, а агент доступний у TEAM 3 , яка належить до останньої групи розподілу дзвінків.

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

Час очікування можна зменшити, використовуючи активність групи розподілу викликів Escalate, яка використовується таким чином:

Залежно від обраної опції Наступна група або Остання група , час очікування контакту значно скорочується, як показано нижче:

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статтю Створення та керування потоками > групі розподілу викликів Escalate Call Distribution Group.

Активність «Отримати інформацію про чергу» надає можливість отримувати інформацію про чергу в реальному часі для певного контакту, наприклад:

• Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо вона ще не поставлена в чергу.
• Приблизний час очікування (EWT) або тривалість, протягом якої, за оцінками, завдання має чекати в черзі, перш ніж отримати відповідь.
• Кількість операторів, які увійшли в систему або доступні в поточній групі розподілу викликів контакту.
• Кількість агентів, які увійшли в систему або доступні в усіх групах розподілу викликів для вибраної черги.
• Час, протягом якого чекає найстарший контакт у черзі.

Ці деталі доступні під час виконання потоку як змінні виведення активності.

Докладнішу інформацію про використання активності, детальне визначення та метод розрахунку для кожної деталі черги можна знайти в статті Створення та керування потоками > Отримання інформації про чергу.

Деякі зі способів використання інформації про чергу можуть бути такими:

• Щоб повідомити клієнту про місцезнаходження контакту в черзі та орієнтовний час очікування, поки він очікує на маршрут.
• Щоб вирішити, чи можна зареєструвати зворотний дзвінок для клієнта, якщо передбачуваний час очікування занадто довгий.
• Щоб перенести контакт до наступної групи розподілу викликів (CDG), якщо в командах, зіставлених із поточною CDG, немає доступних агентів.

У цих випадках значення -1 у цих полях виводу вказує на те, що ця інформація не застосовується.

Розглянемо приклад сценарію, коли клієнт повинен бути проінформований про довгий EWT в черзі, після кожних 15 секунд, проведених в черзі.

Цього можна досягти за допомогою активності «Отримати інформацію в черзі» в потоці наступним чином:

Активність «Розширена інформація про чергу» надає можливість отримувати інформацію про чергу в реальному часі для певного контакту, додатково враховуючи критерії навичок контакту, такі як:

• Поточна позиція контакту в черзі (PIQ) або потенційна позиція, якщо вона ще не поставлена в чергу.
• Кількість операторів, які увійшли в систему або доступні в поточній групі розподілу викликів контакту, що відповідає заданим критеріям кваліфікації.
• Кількість агентів, які увійшли в систему або доступні в усіх групах розподілу викликів для вибраної черги, що відповідає заданим критеріям кваліфікації.
• Поточна група розподілу викликів, у якій контакт припарковано в наданій черзі.
• Загальна кількість груп розподілу дзвінків у наданій черзі.

Ці деталі доступні під час виконання потоку як змінні виведення активності.

Для отримання додаткової інформації про використання активності, детальне визначення та метод розрахунку для кожної деталі черги дивіться статтю Створення та керування потоками > Розширена інформація про чергу.

Деякі зі способів використання розширеної інформації про чергу можуть бути такими:

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

У таких випадках активність призводить до збою, і виконання потоку переходить на шлях обробки помилок.

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

Цього можна досягти, використовуючи активність Advanced Queue Info у потоці наступним чином:

Параметр «Встановити активність ідентифікатора абонента» використовується для визначення ідентифікатора абонента, який має відображатися під час виклику. Активність «Встановити ідентифікатор абонента» має використовуватися лише в потоках подій PreDial як термінальна активність, яка позначає кінець потоку подій.

Активність «Встановити ідентифікатор абонента» дає змогу налаштувати необхідну автоматичну ідентифікацію номера (ANI) на основі служби ідентифікації набраного номера (DNIS), типу операції або типу учасника.

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статті Створення та керування потоками > Налаштування ідентифікатора абонента.

Активність «Керування записом» призначена для використання разом із діями в меню для отримання згоди на запис від абонента. Це забезпечує відповідність нормативним актам або політикам, які вимагають явної згоди перед початком запису, легко інтегруючи цей крок у робочий процес.

Активність у меню IVR має фіксувати згоду користувача на внутрішню змінну, яку буде призначено як вхідні дані для активності керування записом. Якщо клієнту потрібно повідомити про згоду користувача у звіті про згоду, значення згоди має зберігатися у звітній глобальній змінній. Крім того, можна використовувати локальну змінну, якщо звітність не потрібна. Цей підхід надає орендарям і клієнтам підвищену гнучкість в управлінні та ефективному використанні змінних.

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

Черговість виглядає наступним чином:

• Якщо в потоці згода користувача Yes, то дзвінок записується, незалежно від конфігурації запису, встановленої на рівні клієнта або черги, або графіка запису.
• Якщо користувач не дає згоди у відповідь на активність, то дзвінок не записується, незалежно від конфігурації запису, встановленої на рівні клієнта або черги, а також рівня розкладу запису.
• Якщо активність «Керування записом» не налаштована в потоці, але встановлено конфігурацію «Так» на будь-якому з інших рівнів, таких як клієнт, черга або графік запису, то дзвінок записується.
• Якщо активність контролю запису не налаштована в потоці, а для конфігурації встановлено значення Ні на всіх рівнях, таких як клієнт, черга та розклад запису, дзвінок не записується.

Цей елемент керування записом можна проілюструвати так:

Крім того, такі конфігурації запису, як «Продовжити передачу», «Пауза Відновлення ввімкнено», «Тривалість паузи» та інші, залишаються застосовними відповідно до існуючої ієрархії, включаючи рівні клієнта, черги або графіка запису.

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статтю Створення та керування потоками > Керування записом.

Сліпа передача – це процес, під час якого контакт ефективно спрямовується на зовнішній номер набору (DN) через систему IVR, усуваючи потребу в участі агента.

Активність «Сліпа передача» використовується, коли дзвінок має бути переадресований на зовнішній або сторонній DN. Це термінальна активність, тому потік завершується після виконання передачі.

Активність «Сліпий переказ» не підтримується, коли потік виконується для консультації.

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статтю Створення та керування потоками > Сліпий переказ.

Активність Bridged Transfer дає змогу тимчасово перенаправити контакт до зовнішнього пункту призначення, зберігаючи контроль над дзвінком. Зовнішнім пунктом призначення може бути зовнішній міст або служба Interactive Voice Response (IVR).

Коли зовнішній одержувач завершує дзвінок, потік викликів продовжується за потреби, наприклад, ставлячи його в чергу до оператора.

Активність Bridge Transfer виводить контакт із черги під час перенаправлення його до сторонньої системи IVR або автоматичного розподілу викликів (ACD). Якщо контакт не обробляється сторонньою системою, його можна повторно поставити в чергу назад у вихідну чергу, гарантуючи, що контакт залишиться в робочому процесі для відповідної обробки.

Наприклад, припустимо, що контакт-центр має ресурси Webex Contact Center агентів і ресурси агентів у зовнішньому колл-центрі або приватній біржі філій (АТС). Клієнт хоче поставити дзвінок у чергу з операторів Webex Contact Center протягом короткого періоду часу (скажімо, 60 секунд). Якщо протягом цього періоду оператор недоступний, дзвінок може бути переданий мостом (з неявною чергою) до зовнішнього колл-центру для обробки контакту.

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статтю Створення та керування потоками > Bridged Transfer.

Активність «Відключити контакт» надає можливість відключити або завершити активний контакт безпосередньо від потоку.

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

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

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статтю Створення та керування потоками > Відключити контакт.

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

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

Активність також дозволяє клієнтам замовляти зворотні дзвінки у своїх улюблених агентів, додаючи індивідуальний підхід до досвіду та підвищуючи задоволеність клієнтів. Це може бути досягнуто, коли активність зворотного виклику слідує за активністю QueueToAgent у потоці. Крім того, активність зворотного дзвінка пропонує додаткову конфігурацію для налаштування автоматичної ідентифікації номера (ANI), яка використовується під час процесу зворотного дзвінка. Це налаштування допомагає забезпечити цілісність бренду та зменшує ймовірність відхилення дзвінка, забезпечуючи впізнаваний ідентифікатор абонента.

Дизайнер ланцюжків має можливість включити подію CallbackFailed у ланцюжок подій. Ця подія спрацьовує, коли спроба зворотного виклику зазнає невдачі, що дозволяє дизайнеру потоку реалізовувати повторні спроби через певні проміжки часу. Затримку або інтервал між повторними спробами можна налаштувати за допомогою активності «Очікування» з мінімальним інтервалом повторних спроб 10 секунд і максимальним 72 години. Система підтримує до 10 спроб повторних спроб протягом максимум 14 днів з використанням активності «Очікування».

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статтю Створення та керування потоками > Зворотний дзвінок.

Активність аналізу ходу виклику (CPA) дає змогу виявляти автоматизовані системи автовідповідача та живі людські голоси під час дзвінків зворотного виклику.

Коли під час спроби зворотного виклику виникає функція виявлення автовідповідача (AMD) або голосова пошта, система визначає дзвінок як невдалий. Результат виявлення автовідповідача (AMD) фіксується у вихідній змінній reason обробника події CallbackFailed. На основі цієї вихідної змінної дизайнер потоку може налаштувати повтори зворотного виклику.

Щоб дізнатися більше про налаштування активності, використання та вихідні змінні, перегляньте статтю Створення та керування потоками > Аналіз прогресу викликів.