У чергах без навичок із призначенням команд можна організовувати агентів у команди та об'єднувати ці команди в групи розподілу викликів (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 для команди А, то агенти, доступні на голосовому каналі в команді А, отримують голосовий дзвінок першими, навіть якщо ранг 2.

      Однак розглянемо дві черги чатів для команди Б - кредитна картка черги з рангом черги 2 і дебетова картка черги з рангом черги 1. Потім доступним агентам у команді Б спочатку будуть запропоновані контакти з дебетової картки черги.

    • Ранжування в черзі не застосовується до команд на основі місткості.

• Пріоритет контактів

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

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

• Найдовше очікування контакту

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

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

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

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

У наведеному вище прикладі, який ілюструє сценарій надлишку контактів, агент А1 увійшов до КОМАНДИ 1 і став доступним для обробки контактів на кількох типах медіа.

А1 пов'язаний з 3 чергами – Q1, Q2 і Q3. TEAM 1 також визначила ранжування черги, де Q1 займає найвищий рейтинг, потім Q2 і Q3 відповідно.

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

Тепер сценарій з надлишком контакту працює наступним чином:

• Серед усіх припаркованих контактів у цих чергах лише 4 контакти можуть бути спрямовані на A1–C2,C7 (з ЧЕРГИ 2) таC3,C8 (з ЧЕРГИ 3).

  Тільки вимоги до навичок цих 4 контактів повністю задовольняються навичками А1.

• Серед цих 4 контактів пріоритет віддається контактам з ЧЕРГИ 2 (тобто С2, С7), оскільки ЧЕРГА 2 має більш високе ранжування в черзі.

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

• Між С2 і С7 найбільш пріоритетним контактом є С7. Отже, остаточний вибір – С7 , і система направляє його на А1.

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

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

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

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

Є три варіанти:

• Ексклюзивний

• Змішаний

• Змішаний у реальному часі

Докладнішу інформацію про налаштування мультимедійних профілів можна знайти в розділі Керування мультимедійними профілями.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Як тільки активність «Черга до агента» успішно ставить контакт у чергу,

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

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

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

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

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

  Потім виконання потоку продовжується з активностями, приєднаними після активності Queue To Agent, що дає можливість:

  • Відтворюйте заздалегідь налаштовану музику для клієнта, який чекає в черзі - прикріпивши активність 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 спрацьовує, коли контакт завершується через цю активність.

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

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

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

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

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

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

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

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

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

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

Потік повинен фіксувати вхідні дані абонента, такі як бажана дата та час, за допомогою підказок DTMF та передавати їх активності після виконання необхідних перевірок введення.

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

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

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

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

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

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