В опашки, които не са базирани на умения с присвояване на екипи, можете да организирате агентите в екипи и да комбинирате тези екипи, за да формирате групи за разпределение на повикванията (CDG). Можете да зададете времево забавяне между всяка група, за да управлявате потока на повикванията.

Групите за разпределение на обажданията помагат да се определят множество нива на агенти, които отговарят на условията за работа с контакти в тази опашка за конфигурирани интервали от време. Контактите се присвояват на агентите въз основа на нивото на техния екип. Ако няма налични агенти, контактите се паркират за предварително конфигуриран период от време, преди да се разширят, за да включат следващата група екипи. Този процес продължава, докато не бъде наличен агент или всички групи не бъдат проверени.

Можете да настроите следните типове екипи:

• Отделни екипи: Агентите могат да бъдат организирани в екипи, които могат да представляват конкретна организационна функция, която след това може да стане част от опашки, така че контактите да могат да бъдат насочени към агентите в тези екипи. Можете да маркирате агент в няколко екипа, за да обработвате контакти от различни опашки за ефективно маршрутизиране.
• Екипи, базирани на капацитет: Екипът, базиран на капацитета (CBT) е функция, която насочва гласови повиквания към директен номер, базиран на капацитета (DN), където капацитетът определя колко повиквания могат да бъдат обработени едновременно. Той позволява маршрутизиране на обаждания към телефонни номера, без да се изисква агентите да влизат в системата, което го прави подходящ за сценарии, при които на повикванията се отговаря чрез гласова поща, телефонен секретар или групи за търсене, а не от традиционните агенти на кол центъра. В тази настройка няма конкретни агенти, назначени на екипа, и те не използват Webex Contact Center Agent Desktop.

В този пример има три групи за разпределение на обажданията, които позволяват разширяване на целта, което означава разширяване до повече агенти в екипи през конфигурирани интервали от време.

Първата група за разпределение на обаждания съдържа ЕКИП 1, който има 3 конфигурирани агента – А1, А2 и А5.

Втората група за разпределение на обаждания съдържа ЕКИП 2, който има 3 конфигурирани агента – А2, А3 и А4.

Третата (и последна) група за разпределение на разговори съдържа TEAM 3, който има 2 конфигурирани агента – A6 и A7.

Когато даден контакт е поставен на опашка, системата първо търси съответстващ агент в първата група за разпределение на повиквания. Ако не са намерени агенти, контактът се паркира за конфигурираната продължителност, преди да направи целевото разширение към следващата група. Това добавя нови отбори към съществуващите. Този процес се повтаря, докато намери съвпадение или всички групи се разгънат.

Възможност, наречена "Проверка на наличността на агента", кара контакта незабавно да се разшири до следващата група за разпределение на повикванията, ако в текущата група няма съответстващи агенти. Това може да бъде активирано в активността Контакт на опашката <LINK TO секция 3.1.1> в потока.

Тази настройка води до следните сценарии:

1. A2 принадлежи на TEAM 1 и TEAM 2. Ако А2 избере ЕКИП 1, за да влезе в Agent Desktop, системата счита А2 за част от ЕКИП 1 и следователно само за първата група за разпределение на повикванията.
2. A5 принадлежи към TEAM 1, но може да е бил част и от някой друг отбор в организацията, в която е влязъл в момента. Следователно A5 не се счита за част от TEAM 1 и не е свързан с тази опашка.

Опашките с присвояване на екип предоставят тази мощна възможност на агентите да се движат между опашките, като просто избират екип по време на влизане.

Наличен модел на маршрутизиране:

• Най-дългият наличен

Опашките, които не са базирани на умения, са вид опашка, при която пул от агенти е директно присвоен на опашката. За разлика от други типове опашки, които косвено определят набора от назначени им агенти, тези опашки позволяват на администраторите да избират агенти директно и ръчно. Например опашките за възлагане, базирани на екипи, присвояват агенти въз основа на техните влезли екипи, а опашките за възлагане, базирани на умения, съпоставят агентите въз основа на необходимите умения. За разлика от тях, администраторите могат директно да добавят агенти към тези опашки, за да станат част от опашката. Това осигурява лесен начин за управление на разпределението на агентите, без да се разчита на системно управлявани задачи.

Опашките с присвояване на агенти предоставят прости, но ефективни алгоритми за маршрутизиране, които помагат за разпределението на контактите между пула от агенти. Те не вземат предвид уменията на агентите за маршрутизиране на контакти. Агентите обаче могат да бъдат поръчани във всяка опашка и това се взема предвид при насочване на контакти към тях. В този контекст екипите служат предимно като организационна конструкция за супервайзорите, а не като фактор за асоцииране между агент и опашка и решения за маршрутизиране на контакти, което опростява управлението на опашката.

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

Сложните организации на контактните центрове обаче може да се затруднят ръчно да управляват назначенията на агенти в тези опашки. Те биха могли да се възползват повече от други типове опашки, които предлагат динамично маршрутизиране и асоциации агент-опашка.

В този пример опашката има набор от агенти, съпоставени към нея в определен ред, като A4, A9, A7 и т.н. Този ред играе роля в специфични алгоритми за маршрутизиране, които съпоставят входящите контакти с агентите. Системата съпоставя контактите с тези агенти въз основа на тяхната наличност и избрания алгоритъм за маршрутизиране.

За разлика от опашките с разпределение на екипа, няма концепция за разширяване на целта през времеви интервали. Ако никой от конфигурираните агенти не е наличен за маршрутизиране на този контакт, той се паркира на опашка, докато един от тези агенти стане достъпен за обработка на контакти преди времето за изчакване на паркирането. Разширяването на целта не е приложимо за тези опашки.

Налични модели на маршрутизиране:

• Най-дългият наличен
• Циркуляр
• Линеен/Отгоре надолу

Администраторите могат да присвояват критерии за умения на опашките. Опашките, базирани на умения, с критерии за умения позволяват на администраторите да конфигурират необходимите умения директно в опашката. Всички агенти в организацията, които имат всички необходими умения на опашката чрез директен профил на уменията, имплицитно стават част от тази опашка.

Тази настройка помага на администраторите да имат изглед на живо на агентите, които се съпоставят с опашката по силата на уменията. В ситуации като голям или малък обем, администраторите могат да обмислят коригиране на необходимите умения на опашката и профилите на уменията на агентите, за да разширят или свият набора от агенти въз основа на нуждите.

Този тип опашка се различава от опашките, базирани на екипно присвояване, в смисъл, че няма настройка на група за разпределение на повиквания, което означава, че екипът не играе роля в асоциирането между агент и опашка. Освен това необходимите умения са статично конфигурирани в тази опашка, за разлика от екипните опашки за умения, където потокът инжектира (статични или променливи) необходими умения. Следователно, технически уменията са част от опашката, а не от самия контакт.

Всеки агент в организацията, който напълно отговаря на критериите за умения на опашката (притежаващ умения от пряк профил на уменията), имплицитно се свързва с тази опашка. Екипът не играе никаква роля в асоциацията на агента с тези опашки. Тези агенти могат да бъдат част от всеки екип за управленски и оперативни цели.

Всеки контакт, поставен на опашка в тази опашка, автоматично ще приеме критериите за умения, дефинирани в самата опашка. Отделните контакти не могат да дефинират или отменят собствените си изисквания/критерии за умения, за разлика от опашките, базирани на умения, с екипно присвояване.

В този пример

• Само агенти A1, A3 и A7 напълно отговарят на критериите за умения, конфигурирани в опашката, следователно само тези агенти ще бъдат свързани с тази опашка.
• Агенти А2, А4 и А6, които частично отговарят на критериите, или А5, които нямат съответните умения, не могат да бъдат свързани с тази опашка.

Актуализирането на профила на уменията на агента (наречено преквалификация), така че да отговаря на критериите за умения на опашката, автоматично и динамично ще направи този агент част от тази опашка. Алтернативно, актуализирането на самите критерии за умения на опашката, така че повече (или по-малко) агенти да отговарят на актуализираните критерии за умения, също автоматично и динамично ще добавя (или премахва) агенти от тази опашка.

За разлика от опашките с разпределение на екипа, няма концепция за разширяване на целта през времеви интервали. Ако контактът не може да бъде съпоставен с нито един от свързаните агенти, той се паркира на опашка, докато един от тези агенти не стане на разположение за обработка на контактите преди времето за изчакване на паркирането.

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

Сложните организации на контактния център може да намерят управлението на присвояването на опашки към агенти в опашки, базирани на умения, в сравнение с опашките с присвояване на агенти, където всеки агент трябва да бъде ръчно добавен към списъка, което е тромаво, особено за по-голяма организация.

Опашките, базирани на умения, с изисквания за умения, присвоени в потока, са вид опашка, базирана на екипно назначение в Webex Contact Center, където набор от екипи са конфигурирани на няколко нива, наречени групи за разпределение на повиквания. Агентите, които са влезли в тези конфигурирани екипи, получават контакти от тази опашка въз основа на нивото на групата за разпределение на повикванията, на което техният екип е конфигуриран в опашката, ако те също напълно отговарят на изискванията за умения на контакта.

В рамките на такава опашка екипите на агентите се групират в групи за разпределение на повикванията с конфигурируеми закъснения във времето между тях. Ако няма наличен агент за контакта, заявката се паркира и след забавянето маршрутизирането се разширява до следващата група за разпределение на повиквания. Този процес продължава, докато не бъде назначен агент или всички групи не бъдат изчерпани. Междувременно, ако агент в предварително проверена група стане достъпен по време на този процес, този агент се избира.

Агентите придобиват умения чрез профил на умения, директно присвоен на агента. Уменията на агента се определят въз основа на избора на екип по време на влизане.

Всеки контакт може по желание да посочи изисквания за умения в потока, които се съпоставят с уменията на наличните агенти за избор на най-подходящия агент.

Освен това контактите могат също да определят облекчения на уменията на конфигурирани интервали от време. Това са модифициран набор от изисквания за умения, които ще заменят първоначалните изисквания за умения на контакта при конфигурирани интервали от време. Това позволява на контакта да променя (обикновено се използва за "отпускане") изискванията си за умения, докато е паркиран на опашка, така че повече агенти да могат да съответстват на тези облекчени изисквания за умения.

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

Подобно на неквалифицираните опашки с присвояване на екипи, той има три групи за разпределение на обажданията, които позволяват "разширяване на целта", т.е. разширяване до повече агенти в екипите през конфигурирани интервали от време.

• Първата група за разпределение на обаждания съдържа ЕКИП 1, който има 3 конфигурирани агента – А1, А2 и А5.
• Втората група за разпределение на обаждания съдържа ЕКИП 2, който има 3 конфигурирани агента – А2, А3 и А4.
• Третата (и последна) група за разпределение на разговори съдържа TEAM 3, който има 2 конфигурирани агента – A6 и A7.

Има обаче две основни неща, които трябва да се отбележат:

• Всеки контакт, който попадне на опашка в тази опашка, ще определи своите изисквания за умения и отпускане на уменията по време на потока.
• Агентите могат да имат конфигурирани умения (чрез профил на умения – директен или наследен от влезлия екип).

Докато А2 е конфигуриран да бъде част от ОТБОР 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 е най-високият ранг.
    • Можете да зададете един и същ ранг на няколко опашки.
    • Ако разрешите класирането на опашките, опашките, на които не е присвоен изричен ранг, се третират по-ниско от всички класирани опашки.

    • Класирането на опашката работи в рамките на един и същ тип медия.

      Например, ако "Продажба на опашка" е опашка от тип гласов носител с ранг 2, а поддръжката за фактуриране на опашката е опашка за чат с ранг 1 за екип А, тогава агентите, които са на разположение на гласовия канал в екип А, получават гласово обаждане първи, въпреки че рангът е 2.

      Въпреки това, помислете за две опашки за чат за екип Б - кредитна карта на опашка с ранг на опашка 2 и дебитна карта на опашка с ранг на опашка 1. След това на наличните агенти в екип Б първо ще бъдат предложени контакти от дебитната карта на опашката.

    • Класирането на опашката не се прилага за екипи, базирани на капацитет.

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

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

  За контактите, които са поставени на опашка без изричен приоритет, се взема предвид приоритет по подразбиране от 10 (най-нисък). Сред множество контакти, които имат еднакъв приоритет, контактът, който чака на опашката за най-дълго време, се насочва първо към наличния и отговарящ на условията агент.

• Най-дълго чакащ контакт

  Това е основна стратегия, която гарантира, че най-дълго чакащият контакт във всички опашки, с които е свързан агентът, се насочва към агента.

  Това е крайният критерий, който определя контакта, който трябва да бъде маршрутизиран, когато множество контакти в опашки с едно и също класиране на опашката и един и същ приоритет на контакта чакат да бъдат обработени.

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

• е от същия тип носител като тази, на която агентът е наличен
• е паркиран в някоя от опашките, с които е свързан този агент
• чиито изисквания за умения (ако има такива) са изпълнени от този агент
• е паркиран в опашка, чийто ранг е по-висок от другите опашки, конфигурирани в екипа на агента
• има най-висок приоритет сред всички такива контакти
• е най-старият чакащ контакт сред контактите със същия приоритет

В горния пример, който илюстрира сценарий за излишък на контакти, агент A1 е влязъл в TEAM 1 и е станал достъпен за работа с контакти на множество типове носители.

A1 е свързан с 3 опашки – Q1, Q2 и Q3. ОТБОР 1 също така определи класиране на опашките, където Q1 е класиран най-високо, след това Q2 и Q3 съответно.

Има контакти, които вече са паркирани във всички тези опашки, с изисквания за умения и приоритет, определени за всеки контакт.

Сега сценарият за излишък на контакт работи по следния начин:

• От всички паркирани контакти в тези опашки само 4 контакта могат да бъдат насочени към A1 – C2 , C7 (от ОПАШКА 2) и C3 , C8 (от ОПАШКА 3).

  Само изискванията за умения на тези 4 контакта са напълно удовлетворени от уменията на А1.

• Сред тези 4 контакта предимство се дава на контактите от ОПАШКА 2 (т.е. C2, C7), тъй като ОПАШКА 2 има по-високо класиране на опашката.

  Имайте предвид, че въпреки че ОПАШКА 1 е опашката с най-висок ранг, нито един от нейните паркирани контакти не може да бъде насочен към А1, тъй като изискванията им за умения не са удовлетворени от А1.

• Между C2 и C7 контактът с най-висок приоритет е C7. И така, окончателният избор е C7 и системата го насочва към A1.

  Това се случва, въпреки че C2 е бил поставен на опашка по-рано, тъй като приоритетът на контакта има предимство пред времето на опашка.

Чрез конфигурацията на мултимедиен профил Webex Contact Center позволява на агентите да обслужват контакти в различни типове медии (глас, чат, имейл и социални мрежи). Въз основа на тази конфигурация агентите получават канали, осигурени за тип носител.

Всеки контакт, насочен към агент, консумира един канал от този тип медия, докато агентът работи върху този контакт. Докато агентите могат да имат само един гласов канал, те могат да имат до пет канала от други видове медии.

Настройката за смесено маршрутизиране в мултимедийните профили позволява на администраторите да контролират как различните канали могат да се използват едновременно за всеки агент. Това позволява на организациите да предоставят специално внимание на клиентите, насърчавайки по-добро качество на услугата, подобрено клиентско изживяване и по-добри проценти на реализация. Също така, организациите могат да балансират натоварването между медийните канали, когато изпитват неравномерно натоварване в някои канали, което позволява ефективно използване на агентите.

Има три възможности за избор:

• Ексклузивно – само един контакт от всякакъв тип носител може да бъде обработен едновременно от агента.

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

• Смесен – Произволен брой контакти от всеки тип носител може да се обработва едновременно, до капацитета на конфигурираните канали.

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

• Blended-Realtime – Същото като смесено, но гласът и чатът са взаимно изключващи се. Ако се обработва глас, контактите в чата няма да бъдат представени и обратното.

  Това е полезно, когато организацията очаква агентите да изпълняват няколко задачи едновременно, но все пак позволява на агента да се съсредоточи върху един контакт в реално време (глас или чат), така че агентът да може да обърне пълно внимание на крайния клиент от другата страна.

За повече информация относно конфигурирането на мултимедийни профили вижте Управление на мултимедийни профили.

Моделите на маршрутизиране, базирани на умения, в Webex Contact Center насочват входящите взаимодействия с клиентите към агентите въз основа на специфични умения, необходими за разрешаване на запитването, като владеене на език или техническа експертиза. Тези модели гарантират, че всеки клиент се свързва с най-квалифицирания агент, повишавайки ефективността на обслужването и удовлетвореността на клиентите. Предимствата включват намалено време за обработка, подобрени нива на разрешаване и оптимизирано използване на ресурсите на агента чрез привеждане на техния опит в съответствие с нуждите на клиентите.

Когато се използват модели на маршрутизиране, базирани на умения, първо изискването за умения на контакта (присвоено в потока) или критериите за умения, присвоени на опашка, се използват за филтриране на наличните агенти, чиито умения отговарят изцяло на тези изисквания/критерии. След това, сред агентите, които са филтрирани, се избира един за контакта въз основа на конфигурирания модел на маршрутизиране.

Webex Contact Center също така поддържа различни модели на маршрутизиране, които не са базирани на умения, които се фокусират върху разпространението на входящите взаимодействия с клиентите, без да се вземат предвид специфичните умения или опит на агентите. За разлика от моделите на маршрутизиране, базирани на умения, те не вземат предвид уменията на агента и не изискват контакта или опашката, за да дефинират изисквания за умения/критерии за маршрутизиране. По-скоро те дават приоритет на фактори като наличност, разпределение на работното натоварване и предварително дефинирани последователности, което позволява ефективно управление на контактите въз основа на оперативна логика, а не на индивидуални компетенции на агента. Тези модели са особено полезни в среди, където взаимодействията са относително равномерни или не изискват специализирана обработка.

Базираното на агент маршрутизиране е възможност, която маршрутизира или поставя директно контакт на опашка към определен ("предпочитан") агент. Търсене на агент с имейл адреса на агента или ИД на агента насочва контакт към предпочитания агент. Дейността Опашка към агент в потока помага за постигане на маршрутизиране, базирано на агент. За повече информация вижте Дейност на опашка към агент .

Контактът може да има съпоставяне с един или повече предпочитани агенти, които обикновено могат да се управляват във външно приложение извън Webex Contact Center. Търсенето на предпочитан агент за контакт се извършва чрез дейността HTTP заявка , която извлича картографирането от външно приложение. За да маршрутизирате или паркирате контакта с предпочитания агент, конфигурирайте дейността Опашка към агент, като използвате Webex Contact Center ID или имейл адреса на агента. Контактът може също да бъде паркиран срещу предпочитан агент, ако този предпочитан агент не е на разположение веднага.

Маршрутизирането, базирано на агент, е полезно в следните сценарии:

• Предпочитано маршрутизиране на агенти: Клиентът може да възложи контакти на специални агенти или ръководители на връзки. В такива сценарии маршрутизирането, базирано на агент, насочва контактите директно към предпочитания агент.
• Последно маршрутизиране на агент: Когато контакт се обади на контактния център няколко пъти, за да взаимодейства с агент, маршрутизирането, базирано на агент, може да насочи контакта към последния агент, който е обработил този контакт.

И в двата случая на употреба подробностите за контакта и картографирането на агента се съхраняват извън Webex Contact Center.

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

Следните аспекти на опашката могат да бъдат управлявани чрез тази дейност:

• Приоритет - Присвояване на йерархична важност, варираща от 1 (най-висока) до 10 (най-ниска, по подразбиране) на контакта, който се поставя на опашка.
• Изисквания за умения- Задайте критериите за умения, които трябва да бъдат изпълнени от агентите в опашка, базирана на умения, за да се считат за допустими за маршрутизиране на контакта.
• Отпускане на умения - Настройка, промяна или премахване на предварително зададени изисквания за умения след определен период от време, за да се подобрят шансовете за намиране на агент.
• Проверете наличността на агента - Позволете на системата незабавно да се разшири през всички групи за разпределение на обажданията, където няма налични агенти, за да избегнете време за изчакване.

Вижте Маршрутизиране за повече информация относно това как приоритетът, конфигурацията на уменията и наличността на агентите играят роля при маршрутизирането на контактите.

След като дейността Контакт на опашката успешно постави контакта на опашка,

• Ако съответстващ агент вече е наличен, системата се опитва да насочи контакта към агент.

  Това прекъсва изпълнението на основния поток и по-нататъшни събития могат да задействат съответните потоци от събития, ако са конфигурирани.

• Ако не бъде намерен съвпадащ агент, контактът се паркира на опашката и изчаква съответстващ агент да стане достъпен.

  След това изпълнението на потока продължава с дейностите, прикачени след дейността Queue Contact, която предоставя възможност за:

  • Пуснете предварително конфигурирана музика на клиента, който чака на опашка - като прикачите дейност на PlayMusic .
  • Регистрирайте обратно повикване въз основа на заявката на клиента - като прикачите активност за обратно повикване.
  • Повторно опашка, т.е. премахнете контакта от текущата опашка и добавете в нова опашка - като прикачите друг контакт на опашката или опашка към агентската дейност.

Когато съответстващ агент стане достъпен, системата се опитва да насочи контакта към агента.

Когато е успешно, това прекъсва изпълнението на основния поток и по-нататъшни събития могат да задействат съответните потоци от събития, ако са конфигурирани.

В такива случаи дейността води до неуспех и изпълнението на потока се премества в пътя за обработка на грешки.

За повече информация относно настройките на дейността, променливите за използване и изхода вижте Изграждане и управление на потоци > Контакт на опашката.

Дейността от опашка към агент предоставя възможност за поставяне на контакта директно на опашка към предпочитан агент, като се търси неговият уникален идентификатор на агент или имейл адрес в Webex Contact Center.

Следните аспекти на опашката могат да бъдат управлявани чрез тази дейност:

• Приоритет - Придайте по-висока/по-ниска важност на контактите, поставени на опашка срещу същия агент.
• Опашка за отчитане- Определете опашката, която ще се използва за конфигурация, като запис и музика по подразбиране в опашката, и докладвайте за целите на контакта.
• Опашка за възстановяване- Идентифицирайте опашката, която да се използва като резервен вариант, когато контактът не може да бъде насочен към посочения предпочитан агент.

След като дейността "Опашка към агент" успешно постави контакта на опашка,

• Ако агентът вече е на разположение, контактът се насочва към агента.

  Това прекъсва изпълнението на основния поток и по-нататъшни събития могат да задействат съответните потоци от събития, ако са конфигурирани.

• Ако агентът е на разположение, но избере да откаже, да не отговори или не получи контакта, той се премества в предоставената опашка за възстановяване.

  В опашката за възстановяване контактът ще бъде насочен към най-дългия наличен агент, без никаква поддръжка за умения.

• Ако агентът не е на разположение и е избрана опцията " Паркиране на контакт, ако агентът не е наличен", контактът се паркира и изчаква агентът да стане свободен.

  След това изпълнението на потока продължава с дейностите, прикачени след дейността Queue To Agent (Опашка към агент), което дава възможност да:

  • Пуснете предварително конфигурирана музика на клиента, който чака на опашка - като прикачите дейност на PlayMusic .
  • Активност за обратно повикване.
  • Повторно опашка, т.е. премахване на контакта от текущата опашка и добавяне в нова опашка - чрез прикачване на друга опашка към активността на агента или контакта на опашката .

  След като агентът стане достъпен, системата се опитва да насочи контакта към агента.

  Това прекъсва изпълнението на основния поток и по-нататъшни събития могат да задействат съответните потоци от събития, ако са конфигурирани.

• Ако агентът не е наличен и опцията " Паркиране на контакт, ако агентът не е наличен", опашката е неуспешна.

В такива случаи дейността води до неуспех и изпълнението на потока се премества в пътя за обработка на грешки.

За повече информация относно настройките на дейността, използването и изходните променливи вижте Изграждане и управление на потоци > Queue To Agent.

Дейността Escalate Call Distribution Group се поддържа само за опашки с присвояване на екип и предоставя възможност за незабавно актуализиране на групата за разпределение на повиквания за контакта, вместо да се чака автоматичната актуализация на разширението да се случи за следващата група след конфигурираната продължителност на изчакване. Това позволява бързо да се насочи контактът към всички отговарящи на условията агенти на опашката.

С помощта на дейността Escalate Call Distribution Group контактът може да бъде ескалиран до:

• Следваща група – Разширяване на набора от екипи, за да се включат тези, добавени в групата за разпределение на незабавно следващо повикване.
• Последна група – Разширяване на набора от екипи, за да включи всички екипи, картографирани във всички групи за разпределение на повикванията, конфигурирани за опашката.

В такива случаи дейността води до неуспех и изпълнението на потока се премества в пътя за обработка на грешки.

Помислете за примерен сценарий, при който контакт попада на опашка в опашка с три групи за разпределение на повиквания, всяка от които се актуализира след период от 30 секунди.

Няма налични агенти в екипната част на CDG 1 и CDG 2, а агент е наличен в TEAM 3 , който принадлежи към групата за разпределение на последните обаждания.

Когато дейността на групата за разпределение на повикванията за ескалиране не се използва в потока, това води до дълго време на изчакване, както е показано по-долу:

Времето за изчакване може да бъде намалено с помощта на дейността на групата за разпределение на повикванията се използва, както следва:

Въз основа на избраната опция Следваща група или Последна група , времето за изчакване на контакта се намалява значително, както е показано по-долу:

За повече информация относно настройките на дейността, променливите за използване и изхода вижте Изграждане и управление на потоци > групата за разпределение на повиквания.

Дейността "Получаване на информация за опашката" предоставя възможност за извличане на информация за опашката в реално време за даден контакт, като например:

• Текущата позиция на контакта в опашката (PIQ) или потенциалната позиция, ако все още не е на опашка.
• Очакваното време за изчакване (EWT) или продължителността, за която се очаква дадена задача да изчака на опашката, преди да получи отговор.
• Броят на агентите, които са влезли или са налични в текущата група за разпределение на обаждания на контакта.
• Броят на агентите, влезли или налични във всички групи за разпределение на повикванията за избраната опашка.
• Продължителността, за която е чакал най-старият контакт на опашката.

Тези подробности са достъпни при изпълнението на потока като изходни променливи на дейността.

За повече информация относно използването на дейността, подробната дефиниция и метода на изчисление за всеки детайл от опашката вижте Изграждане и управление на потоци > Получаване на информация за опашката.

Някои от начините за използване на информацията за опашката могат да бъдат:

• За да обявите позицията на контакта на опашката и очакваното време за изчакване на клиента, докато чака да бъде маршрутизиран.
• За да решите дали обратно повикване може да бъде регистрирано за клиента, ако очакваното време за изчакване е твърде дълго.
• За да ескалирате контакта към следващата група за разпределение на повиквания (CDG), ако няма налични агенти в екипи, картографирани към текущия CDG.

В тези случаи стойността на -1 в тези изходни полета показва, че тази информация не е приложима.

Помислете за примерен сценарий, при който клиентът трябва да бъде информиран за дълъг EWT в опашката, след всеки 15 секунди, прекарани в опашката.

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

Дейността Advanced Queue Info предоставя възможност за извличане на информация за опашката в реално време за даден контакт, като допълнително се вземат предвид критериите за умения на контакта, като например:

• Текущата позиция на контакта в опашката (PIQ) или потенциалната позиция, ако все още не е на опашка.
• Броят на агентите, влезли или налични в текущата група за разпределение на обажданията на контакта, съответстващи на дадените критерии за умения.
• Броят на агентите, влезли или налични във всички групи за разпределение на повикванията за избраната опашка, съответстващи на дадените критерии за умения.
• Текущата група за разпределение на повикванията, където контактът е паркиран на предоставена опашка.
• Общият брой групи за разпределение на повикванията в предоставена опашка.

Тези подробности са достъпни при изпълнението на потока като изходни променливи на дейността.

За повече информация относно използването на дейността, подробната дефиниция и метода на изчисление за всеки детайл на опашката вижте Изграждане и управление на потоци > Разширена информация за опашката.

Някои от начините за използване на разширената информация за опашката могат да бъдат:

• За да съобщите позицията на контакта на опашката на клиента, докато чака да бъде маршрутизиран.
• За да ескалирате контакта към следващата група за разпределение на повикванията, ако няма налични агенти, отговарящи на критериите за умения в екипи, съпоставени с текущата група за разпределение на повикванията.
• За да решите дали обратното повикване може да бъде регистрирано за клиента, ако не са влезли агенти, отговарящи на критериите за умения, във всички групи за разпределение на повикванията.

В такива случаи дейността води до неуспех и изпълнението на потока се премества в пътя за обработка на грешки.

Помислете за примерен сценарий, при който клиентът трябва да бъде информиран за получаване на обратно обаждане, като се има предвид, че няма налични агенти, отговарящи на критериите за умения.

Това може да се постигне чрез използване на дейността Разширена информация за опашката в потока, както следва:

Дейността Задаване на ИД на повикващия се се използва за дефиниране на ИД на повикващия, който трябва да се показва по време на разговор. Активността Задаване на ИД на повикващия трябва да се използва само при потоци на събития преди набиране като терминална дейност, която маркира края на потока на събитието.

Активността "Задаване на идентификация на обаждащия се" позволява конфигуриране на необходимата автоматична идентификация на номера (ANI) въз основа на услугата за идентификация на набран номер (DNIS), типа операция или типа участник.

За повече информация относно настройките на дейността, променливите за използване и изхода вижте Изграждане и управление на потоци > Задаване на ИД на повикващия.

Дейността за контрол на записа е предназначена да се използва заедно с дейност в менюто за улавяне на съгласие за запис от обаждащия се. Това гарантира съответствие с разпоредбите или политиките, изискващи изрично съгласие преди началото на записа, като безпроблемно интегрира тази стъпка в работния процес.

Дейността на Меню IVR трябва да улавя съгласието на потребителя в булева променлива, която ще бъде присвоена като вход за дейността по контрол на записа. Ако клиентът трябва да докладва съгласието на потребителя в отчет за съгласие, стойността на съгласието трябва да се съхранява в глобална променлива за отчитане. Като алтернатива може да се използва локална променлива, ако не се изисква отчитане. Този подход предоставя на наемателите и клиентите подобрена гъвкавост при ефективното управление и използване на променливите.

Когато тази дейност се добави към потока, съгласието на потребителя има предимство пред настройките за конфигурация на ниво клиент или ниво опашка или запис на график.

Редът за старшинство е следният:

• Ако съгласието на потребителя е Да в потока, тогава повикването се записва, независимо от конфигурацията на записа, зададена на ниво клиент или опашка или график за запис.
• Ако потребителят не даде съгласието си като отговор на дейността, тогава повикването не се записва, независимо от конфигурацията на записа, зададена на ниво клиент или опашка или график за запис.
• Ако дейността за управление на записа не е конфигурирана в потока, но конфигурацията е зададена на Да на някое от другите нива, като например клиент или опашка или график за запис, тогава повикването се записва.
• Ако дейността за управление на записа не е конфигурирана в потока и конфигурацията е зададена на Не на всички нива, като например клиент, опашка и график за запис, повикването не се записва.

Този контрол на записа може да бъде илюстриран по следния начин:

Освен това конфигурациите за запис като Продължаване при прехвърляне, Активирано възобновяване на пауза, Продължителност на пауза и други остават приложими според съществуващата йерархия, включително нива на график за клиент, опашка или запис.

За повече информация относно настройките на активността, променливите за използване и изхода вижте Изграждане и управление на потоци > Контрол на записа.

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

Дейността Blind Transfer се използва, когато повикването трябва да бъде прехвърлено към външен DN или DN на трета страна. Това е крайна дейност, така че потокът приключва, след като трансферът бъде изпълнен.

Дейността за сляпо прехвърляне не се поддържа, когато потокът се изпълнява за консултация.

За повече информация относно настройките на дейността, променливите за използване и изхода вижте Изграждане и управление на потоци > Сляпо прехвърляне.

Дейността за прехвърляне с мост позволява контакт да бъде временно прехвърлен към външна дестинация, докато потокът запазва контрола върху повикването. Външната дестинация може да бъде външен мост или услуга за Interactive Voice Response (IVR).

Когато външната дестинация прекрати повикването, потокът на повикването продължава по-нататък, ако е необходимо, като поставяне на опашка на агент.

Дейността за прехвърляне на мост премахва контакта, докато го прехвърля към IVR или система за автоматично разпределение на повикванията (ACD) на трета страна. Ако контактът не се обработва от системата на трета страна, той може да бъде поставен отново на опашка обратно в първоначалната опашка, като се гарантира, че контактът остава в работния процес за подходяща обработка.

Например, да предположим, че контактният център има Webex Contact Center ресурси на агент и ресурси на агент във външен кол център или частен клон Exchange (PBX). Клиентът иска да постави на опашка обаждане срещу опашка от Webex Contact Center агенти за кратък период от време (да речем 60 секунди). Ако през този период няма наличен агент, обаждането може да бъде прехвърлено (с неявно премахване на опашката) към външния кол център за обработка на контакта.

За повече информация относно настройките на дейността, променливите за използване и изхода вижте Изграждане и управление на потоци > мостово прехвърляне.

Дейността Прекъсване на контакта предоставя възможност за прекъсване или прекратяване на активен контакт директно от потока.

Това е терминална дейност, свързана с потока и може да бъде полезна при прекратяване на контакти без намеса на агент, подходяща за потоците на пътя на грешката или след регистриране на обратно повикване за клиента.

Въз основа на конфигурацията проучването на обаждането POST или обратната връзка се задейства, когато контактът приключи чрез тази дейност.

За повече информация относно настройките на дейността, променливите за използване и изхода вижте Изграждане и управление на потоци > Прекъсване на контакта.

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

Дизайнерът на поток може да конфигурира дейността или да запази контакта в първоначалната опашка, откъдето произхожда повикването, или да го присвои на друга опашка въз основа на предпочитанията. Ако обратното повикване остане в първоначалната опашка, контактът запазва своята позиция, умения, приоритет и контекстуални данни, което позволява безпроблемно присвояване на следващия наличен агент. Ако обаче е избрана друга опашка, контактът се изпраща до края на избраната опашка без умения и с приоритет по подразбиране.

Дейността също така позволява на клиентите да поискат обратно обаждане от предпочитаните от тях агенти, добавяйки личен щрих към изживяването и повишавайки удовлетвореността на клиентите. Това може да се постигне, когато дейността за обратно извикване следва дейност на QueueToAgent в потока. Освен това дейността за обратно повикване предлага допълнителна конфигурация за персонализиране на автоматичната идентификация на номера (ANI), използвана по време на процеса на обратно повикване. Това персонализиране помага за последователността на марката и намалява вероятността от отхвърляне на обаждане, като осигурява разпознаваем идентификатор на обаждащия се.

Дизайнерът на потока има опцията да включи събитие CallbackFailed в потока на събитието. Това събитие се задейства, когато опитът за обратно повикване е неуспешен, което позволява на разработчика на потока да прилага повторни опити на определени интервали. Забавянето или интервалът между повторните опити може да бъде конфигуриран с помощта на дейността Изчакване, с минимален интервал на повторни опити от 10 секунди и максимум 72 часа. Системата поддържа до 10 опита за повторение в рамките на максимален период от 14 дни, като използва дейността Wait.

За повече информация относно настройките на активността, променливите за използване и изхода вижте Изграждане и управление на потоци > обратно повикване.

Дейността за анализ на напредъка на повикването (CPA) позволява откриването на автоматизирани системи за отговаряне и човешки гласове на живо при повиквания с обратно повикване.

Когато опит за обратно повикване срещне откриване на телефонен секретар (AMD) или гласова поща, системата идентифицира обаждането като неуспешно. Резултатът от откриването на телефонен секретар (AMD) се записва в изходната променлива причина на манипулатора на събития CallbackFailed. Въз основа на тази изходна променлива дизайнерът на потока може да конфигурира повторни извиквания.

За повече информация относно настройките на дейността, променливите за използване и изхода вижте Изграждане и управление на потоци > Анализ на напредъка на повикването.