Разбиране на маршрутизирането и опашките в Webex Contact Center

Опашка

Общ преглед

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

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

Някои от ключовите предимства на ефективното използване на опашки са:

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

Видове опашки

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

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

Има две основни категории опашки:

Опашки, които не са базирани на умения
Опашки, базирани на умения

Опашки, които не са базирани на умения

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

Разпределение на отборите
Назначения на агенти

Опашки без умения с разпределения на отборите

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

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

Можете да създадете такива типове отбори:

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

Диаграма на работния процес за това как работи опашката без умения с разпределение на екипа в Webex Contact Center

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

Първата група за разпределение на обаждания съдържа TEAM 1, който има 3 конфигурирани агента – A1, A2 и A5.

Втората група за разпределение на обажданията включва TEAM 2, който има 3 конфигурирани агента – A2, A3 и A4.

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

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

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

Тази конфигурация води до следните сценарии:

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

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

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

Най-дълго налично

Опашки без умения с назначения на агенти

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

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

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

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

Диаграма на работния процес, показваща как работи пример за опашка без умения с присвояване на агенти в Webex Contact Center

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

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

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

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

Опашки, базирани на умения

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

Можете да конфигурирате следните типове опции, базирани на умения:

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

Критерии за умения, присвоени на опашката

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

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

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

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

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

Диаграма на работния процес, показваща пример за това как работи опашка на умения с критерии за умения в Webex Contact Center

В този пример,

Само агентите A1, A3 и A7 напълно отговарят на критериите за умения, конфигурирани в опашката, затова само тези агенти ще бъдат свързани с тази опашка.
Агенти A2, A4 и A6, които частично отговарят на критериите, или A5, които нямат релевантни умения, не могат да бъдат свързани с тази опашка.

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

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

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

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

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

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

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

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

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

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

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

Диаграма на работния процес, показваща пример за това как работи опашка, базирана на умения, с разпределение на екипи в Webex Contact Center.

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

Първата група за разпределение на обаждания включва TEAM 1, който има 3 конфигурирани агента – A1, A2 и A5.
Втората група за разпределение на обажданията включва TEAM 2, който има 3 конфигурирани агента – A2, A3 и A4.
Третата (и последна) група за разпределение на обаждания включва TEAM 3, който има 2 конфигурирани агента – A6 и A7.

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

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

Докато A2 е конфигуриран да бъде част както от TEAM 1, така и от TEAM 2, в зависимост от избора на отбор, който агентът е направил при влизане, в настоящата си сесия той се счита за част от този отбор и следователно наследява и профила на уменията (и съответно стойностите на уменията) от този отбор (освен ако това не бъде отменено с директна конфигурация на профила на уменията за този агент).

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

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

В този пример,

Контактите се поставят на опашка с начално изискване за умения (sk_1 >=6) по време на ескалация от потока, с релаксация на уменията (sk_1 >= 3) след определен времеви интервал.
Сред всички агенти във всички групи за разпределение на обажданията само A1, A3, A6 и A7 притежават умения, които удовлетворяват първоначалното изискване за умения на опашките контакти.
Останалите агенти или имат умението (sk_1), но не отговарят на изискванията за умения (например A2 в TEAM 1 и A4 в TEAM 2), или изобщо нямат това умение (например A5, A2 в TEAM 2).
С течение на времето, след релаксация на уменията, допълнително A2 и A4 вече удовлетворяват "спокойните" умения на контакта.

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

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

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

Най-дългият наличен
Най-доброто налично

Конфигурация на опашката

Настройте опашки, базирани на умения

Задайте критерии за умения на опашка

Създавай умения.
Създайте профили на умения.
Задайте профил на умения директно на агентите.
Създайте опашка с тип канал: Телефония, чат, имейл или социални контакти.
Задайте изискванията за умения на опашки в Control Hub.
Вижте списъка с агенти, които могат да обработват контактите в опашката.
Изберете алгоритъм за маршрутизиране – LAA или BAA.
Добавете активност Queue Contact във flow и изберете тази опашка.

Задайте изискванията за умения на опашка

Създавай умения.
Създайте профили на умения.
Задайте профил на умения директно на агенти или на екип.
Създайте екип.
Добавете агенти към екипа.
Създайте опашка с тип канал: телефония, чат, имейл или социални мрежи.
Добавете отбори в опашката в един CDG или няколко CDG.
Изберете маршрутизиращ модел – LAA или BAA.
Добавете активност Queue Contact във flow и изберете опашката, за която е конфигуриран маршрутизирането по умения. За повече информация вижте Контакт за опашка.
Задайте умения и релаксация на уменията в активността Queue Contact.
Използвайте Escalate Call Distribution Activity в поток POST опашка, за да преминете бързо към следващата група за разпределение на обаждания или последната.

Настройте опашки без умения

Назначете екипа на опашка

Създайте екип.
Добавете агенти към екипа.
Създайте опашка с тип канал: телефония, чат, имейл или социални мрежи.
Добавете отбори в опашката в един CDG или няколко CDG.
Изберете маршрутизиращ модел или LAA.
Добавете активност Queue Contact във flow и изберете тази опашка.
Използвайте Escalate Call Distribution Activity в поток POST опашката, за да преминете бързо към следващата група за разпределение на обаждания или последната.

Присвояване на агент към поток от опашка

Създайте опашка с тип канал: телефония, чат, имейл или социални мрежи.
Добавете агенти директно към опашки (Забележка: Нито умения, нито екип се използват в този тип опашка).
Изберете маршрутизиращи модели като Кръгов, Линеен или Най-Дълъг наличен агент.

Маршрутизация

Концепции за маршрутизиране

Сценарий с излишък на агент

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

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

Намирането на съвпадащ агент за конкретен контакт използва конфигурирания маршрутизиращ модел в опашката.

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

Сценарий за излишък на контакта

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

Ключовите стратегии за ефективно маршрутизиране на контакти с ограничена наличност на агенти са:

Класиране на опашката
Рангирането на опашката позволява на администраторите да задават относителната важност на опашките. Администраторите могат да дефинират класиране на опашките, за да зададат реда, в който се маршрутизират повикванията от опашки към агенти, влезли в Teams, на база за всеки отбор.
Например, вземете предвид, че агентите, влезли в Team A, са свързани с две опашки – "Фактуриране" и "Продажби". Администраторите могат да използват рангиране на опашките, за да присвоят по-висок ранг на опашката "Фактуриране", така че когато контактите влязат в опашките, контактите от "Фактуриране" да бъдат насочени към агенти от Екип А преди контакти от "Продажби". Това ще се случи, въпреки че може да има по-стари и с по-висок приоритет контакти, които чакат в опашката "Продажби" – просто защото опашката "Фактуриране" има по-висок ранг в опашката от "Продажби". Само когато вече няма чакащи контакти в опашката "Фактуриране", агентите от Екип А ще бъдат насочени към контакти от "Продажби" (и всяка друга) опашка, с която са свързани.
Следват някои от важните характеристики на класирането на опашките:
- - Ако даден ранг се присвоява само на някои от опашките, повикванията в тези опашки ще имат предимство пред повикванията в опашките, за които не е посочен ранг.
  - Рангът на опашката може да бъде зададен на максимум 50 опашки във всички типове медии с стойност между 1 и 50, като 1 е най-висок ранг.
  - Можеш да зададеш един и същ ранг на няколко опашки.
  - Ако активирате ранга в опашките, опашките, които не са присвоени с изричен ранг, се третират по-ниско от всички ранжирани опашки.
  - Рангирането на опашката работи в рамките на един и същ медиен тип.
    
    Например, ако Queue Sale е гласова медийна опашка с ранг 2, а Queue Billing Support е чат опашка с ранг 1 за Team A, тогава агентите, които са налични в гласовия канал в Team A, получават гласово обаждане първи, въпреки че рангът е 2.
    
    Въпреки това, разгледайте две опашки за чатове за Отбор Б – Queue Credit Card с ранг 2 и Queue Debit Card с ранг 1. След това наличните агенти в Екип Б първо ще получат контакти от Queue Debit Card.
  - Рангът в опашката не се прилага за отбори, базирани на капацитет.
Приоритет за контакт
Когато контакт е поставен на опашка, неговият приоритет може да се дефинира чрез присвояване на йерархична важност от 1 (най-висока) до 10 (най-ниска, по подразбиране). Това приоритизиране гарантира, че определени контакти се адресират по-бързо според тяхната важност, спешност или стратегическа стойност за организацията. Когато агент е на разположение да обработва следващия контакт сред всички паркирани контакти във всички опашки, с които агентът е свързан, най-високоприоритетният контакт във всички опашки се пренасочва към агента (при условие че са изпълнени други критерии като съвпадение на умения и други).
За контактите, които са наредени на опашка без изричен приоритет, се разглежда стандартен приоритет 10 (най-нисък). Сред множество контакти с еднакъв приоритет, контактът, който чака в опашката най-дълго, се пренасочва първи към наличния и допустим агент.
Най-дълъг чакащ контакт
Това е основна стратегия, която гарантира, че най-дълго чакащият контакт във всички опашки, с които агентът е свързан, се маршрутизира към агента.
Това е крайният критерий, който определя контакта, който да бъде маршрутизиран, когато няколко контакта в опашки с еднакъв ранг на опашката и еднакъв приоритет чакат да бъдат обработени.

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

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

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

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

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

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

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

Само изискванията за умения на тези 4 контакта са напълно удовлетворени от уменията на A1.
Сред тези 4 контакта предимство се дава на контактите от QUEUE 2 (т.е. C2, C7), тъй като QUEUE 2 има по-висок ранг на опашките.

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

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

Смесени мултимедийни профили

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

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

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

Има три варианта:

Изключващо
Смесване
Blended-Realtime

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

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

Маршрутни модели

Базирано на умения

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

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

Най-дълго налично

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

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

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

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

с горните изисквания за умения, присвоени чрез поток, или
като горните критерии за умения са конфигурирани в опашката за умения, базирани на умения

В този сценарий:

Само агенти, които напълно отговарят на изискванията за умения за контакт / за умението в опашка, се вземат предвид за маршрутизиране. Само агентите A1, A2 и A4 напълно отговарят на изискванията за умения за контакт / опашка за умения.

Агент A3 не е допустим. В случая с критериите за умения, присвоени на опашката, A3 дори не е свързан с опашката.
Сред A1, A2 и A4 контактът ще бъде насочен към най-дълго наличния агент – A1, който е на разположение от 10 минути, по-дълго от A2 или A4.

Поради това, че A1 е назначен като контакт , A1 вече няма да бъде най-дълго наличният агент във всички медийни канали.
Следващият контакт със същите изисквания за умения се насочва към следващия най-дълго наличен агент – A2 и така нататък.

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

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

Най-доброто налично

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

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

На практика, сумата от стойностите на уменията на агента, които съответстват на изискванията за контакт умения / критериите за умението на опашка, определя резултата.

Някои ключови моменти, които трябва да разберете:

Обикновено реалната стойност на умение се използва при изчисляване на резултата, защото по-висок резултат показва по-силно съвпадение. С изключение на това, когато изискването за умение използва условието по-малко от равно на (<=), тази конкретна стойност на умението на агента се обръща при изчисляване на резултата, т.е . effective_skill_value = (10) минус (actual_skill_value). Това се прави, за да се гарантира, че по-ниският резултат означава по-силно съвпадение.
Когато няколко допустими агенти имат еднакъв резултат, се избира най-дълго наличният агент сред тях
За изчисляване на резултатите се вземат предвид само уменията за владеене. Всички булеви, текстови или enum умения в изискванията за контакт умения / критериите за опашка не се вземат предвид за изчисляване на резултата.

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

Помислете за контакт, който е поставен в опашка, базирана на умения, с модел на маршрутизиране "Best Available":

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

В този сценарий:

Само агенти, които напълно отговарят на изискванията за умения за контакт / за умението в опашка, се вземат предвид за маршрутизиране. Само агентите A1, A2 и A4 напълно отговарят на изискванията за умения за контакт / опашка за умения.

Агент A3 не е допустим. В случая с критериите за умения, присвоени на опашката, A3 дори не е свързан с опашката.
Сред A1, A2 и A4 изчисляването на резултата се извършва от системата въз основа на изискванията за умения за контакт / умения в опашка, като се вземат предвид само уменията за владеене.

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

Също така обърнете внимание на инверсията на стойността на уменията при изчисляване на резултата, когато се използва условие по-малко от равно на (<=).
Контактът се насочва към A2 , тъй като това е най-добрият наличен агент според рейтинга. Ако A2 не е наличен или е зает, контактът ще бъде насочен към следващия най-добър наличен агент с втори най-висок резултат и така нататък.

Въпреки това имаме 2 агенти – A1 и A4 с следващия най-висок резултат. Контактът се пренасочва към най-дългия наличен агент между A1 и A4.

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

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

Маршрутизиране без умения

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

Най-дълго налично

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

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

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

В горния пример агент A1 е най-дълго наличният агент (позиция 1) – или този агент е влязъл първи, или не е получил контакт по-дълго от друг агент.

Агенти A2 (позиция 2) и A3 (позиция 3) също са налични, но те или са влезли в системата, или са обработвали контакти след A1. Всички агенти са свързани и с двете опашки, които имат този маршрутизиращ модел.

Разгледайте следния сценарий:

В момент T0 се поставя гласов контакт C1 на опашка и се пренасочва към най-дълго наличния агент, т.е. A1.

Поради това, че A1 получава C1, A1 вече не е най-дълго достъпният агент във всички медийни канали.
В момент T1 чат контакт C2 се поставя на опашка и се пренасочва към най-дълго наличния агент, който вече е A2.
Накрая, в момент T2, друг гласов контакт C3 се поставя на опашка и се пренасочва към A3.

A1 и A2 наскоро получиха контакти – в момента именно A3 чака най-дълго.

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

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

Разпределение на отбора
Назначаване на агент

Циркуляр

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

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

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

В горния пример агентите са конфигурирани в кръгова опашка в следния ред: A3 → A4 → A5 → A6 → A1 → A2.

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

Разгледайте следния сценарий:

Първият контакт (C1) се поставя в опашка и се пренасочва към агент A3.

Указателят се обновява към следващия агент в конфигуриран ред, т.е. A4.
Когато вторият контакт (C2) бъде поставен на опашка, системата започва да намира налични агенти, започвайки от A4 , т.е. A4 → A5 → A6 → A1 → A2 → A3.

Въпреки това, A4 и A5 не са налични (или дори не са логирани, или са в покой, или са напълно заети с други контакти от този медиен тип), така че C2 се маршрутизира към следващия наличен агент – A6. Указателят се обновява към следващия агент в конфигуриран ред, т.е. A1.
По същия начин третият контакт (C3) се маршрутизира къмA1 , а четвъртият контакт (C4) къмA2 . Показалецът отново е на A3 .

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

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

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

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

Назначаване на агент

Отгоре надолу

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

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

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

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

В горния пример агентите са конфигурирани в опашка отгоре надолу в следния ред: A3 → A4 → A5 → A6 → A1 → A2.

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

Разгледайте следния сценарий:

Първият контакт (C1) се поставя в опашка и се пренасочва към агент A3, тъй като A3 е в началото на поръчката.
Когато вторият контакт (C2) е поставен на опашка, маршрутизацията отново се опитва отгоре на поръчката (винаги започвайки с A3).

Ако A3 има по-голям капацитет на канала за този тип медия, C2 също се маршрутизира към A3. Въпреки това, ако A3 е напълно заета с този медиен тип, маршрутизацията продължава надолу по списъка до A4.
Въпреки това, A4 и A5 не са налични (те или дори не са логирани, или са в покой, или са напълно заети с други контакти от този медиен тип), затова C2 се маршрутизира към следващия наличен агент в реда отгоре надолу – A6 .
По същия начин третият контакт (C3) се опитва да бъде прокаран, започвайки от A3 надолу към дъното. Първият съвпадящ агент би бил A1.

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

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

Назначаване на агент

Маршрутизация, базирана на агент

Маршрутизирането, базирано на агенти, е възможност, която маршрутизира или поставя контакт директно на опашка към определен ("предпочитан") агент. Търсене на агент с имейл адреса на агента или ID на агента насочва контакт към предпочитания агент. Активността от опашка към агент в потока помага за постигане на маршрутизиране, базирано на агенти. За повече информация вижте Queue To Agent активност.

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

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

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

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

Опашка

Общ преглед

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

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

Някои от основните предимства на ефективното използване на опашки са:

По-добро потребителско изживяване: Управлявайте времето за изчакване и оставете клиентите да знаят, че са на линия, за да им помогнат.
Повишена ефективност: Да се гарантира, че обажданията се обработват по организиран начин, като се намали хаосът и лошото управление.
Справедливо разпределение на контактите: Разпределете повикванията равномерно между агентите, за да избегнете претоварване на всеки един агентът.
Приоритетно третиране: Позволява приоритизиране на определени обаждания, като ВИП клиенти или спешни въпроси.

Видове опашки

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

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

Има две широки категории опашки:

Неквалифицирани опашки
Умения-базирани опашки

Неквалифицирани опашки

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

Задачи на екипа
Назначения на агенти

Неквалифицирани опашки с екипни задачи

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

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

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

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

Диаграма на работния процес за това как работи неквалифицираната опашка с назначаване на екип в Webex Contact Center

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

Първата група за разпространение на повиквания съдържа TEAM1, който има 3 конфигурирани агенти – A1, A2 и A5.

Втората група за разпространение на повиквания съдържа TEAM2, който има 3 конфигурирани агенти – A2, A3, и A4.

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

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

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

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

А принадлежи2 на TEAM 1 и TEAM 2. Ако A избере2 TEAM да 1 влезе в Agent Desktop, системата счита A за част2 от TEAM 1 и следователно само първата Call Distribution Group.
А5 принадлежи към TEAM1, обаче, може да е част и от друг екип в организацията, в която в момента са влезли. Следователно, А не5 се счита за част от TEAM и 1 не е свързан с тази опашка.

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

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

Най-дълго на разположение

Неквалифицирани опашки с назначения на агенти

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

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

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

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

Диаграма на работния поток, показваща как работи примерна опашка с назначаване на агенти в Webex Contact Center

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

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

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

Най-дълго на разположение
Кръгови
Линеен/отгоре-надолу

Умения-базирани опашки

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

Можете да конфигурирате следните видове опции, базирани на умения:

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

Критерии за умения, определени за опашката

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

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

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

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

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

Диаграма на работния поток, показваща пример за това как работи Skill-based queue с критерии за умения в Webex Contact Center

В този пример,

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

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

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

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

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

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

Базираните на умения Опашките с изисквания за умения, определени в потока, са вид опашка, базирана на задачи в Контактния център на Webex, където набор от екипи са конфигурирани на множество нива, наречени Call Distribution Groups. Агентите, които са влезли в тези конфигурирани екипи, получават контакти от тази опашка въз основа на нивото на Групата за разпространение на повиквания, на което екипът им е конфигуриран в опашката, ако отговарят напълно на изискванията за умения на контакта.

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

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

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

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

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

Диаграма на работния поток, изобразяваща пример за това как работи опашката със задачи на екипа в Webex Contact Center.

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

Първата група за разпространение на повиквания съдържа TEAM1, който има 3 конфигурирани агенти – A1, A2 и A5.
Втората група за разпространение на повиквания съдържа TEAM2, който има 3 конфигурирани агенти – A2, A3, и A4.
Третата (и последната) група за разпространение на повиквания съдържа TEAM3, която има 2 конфигурирани агенти – A6 и A7.

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

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

Докато А е2 конфигуриран да бъде част както от TEAM1 , така и 2TEAM, в зависимост от избора на екипа, който този агент е направил по време на влизане, в текущата си сесия той се счита за част от този екип и следователно ще наследи профила на уменията (и по този начин стойностите на уменията) от този екип (освен ако това не е преодоляно с директна конфигурация на профила на уменията за този агент).

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

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

В този пример,

Контактите са подредени в опашка с начално изискване за умения (sk_1 >= 6) по време на ескалация от потока, с релаксация на уменията (sk_1 >= 3) след конфигуриран интервал от време.
Във всички агенти във всички групи за разпространение на повиквания само A1, A3, A и6 A имат7 умения, които отговарят на първоначалното изискване за умения за контакти в опашката.
Останалите агенти или притежават уменията (sk_1), но не отговарят на изискванията за умения (напр. А2 в ЕКИП 1 и А4 в ЕКИП2), или изобщо нямат това умение (напр. А5, А2 в ЕКИП 2).
С течение на времето, при релаксация на уменията, допълнително2 А и4 А също сега отговарят на "релаксираните" изисквания за умения на контакта.

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

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

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

Най-дълго на разположение
Най-добрите налични

Настройки на опашката

Създаване на опашки, базирани на умения

Задаване на критерии за умения на опашката

Създаване на умения и, ако е необходимо, динамични умения.
Създаване Профили на уменията...
Директно присвояване на профила на уменията на агентите.
Възложете динамични умения директно на агентите. Динамичните умения не се присвояват чрез профилите на уменията.
Създайте опашка с канал тип Telephony или Chat, или Email или Social.
Задайте умения и изисквания за динамични умения на опашки в контролния център.
Преглед на списък на агенти, които могат да се справят с контактите в опашката.
Изберете алгоритъм за маршрутизиране Или LAA или BAA. За BAA, конфигурирайте теглата за умения за владеене и умения за динамични умения, когато е необходимо.
Добавяне на Опашка Контактна активност в потока и изберете тази опашка.

Задайте изисквания за умения на опашка

Създаване на умения и, ако е необходимо, динамични умения.
Създаване Профили на уменията...
Задайте профил на уменията на Агентите директно или на Екип.
Възложете динамични умения директно на агентите. Динамичните умения не се присвояват чрез профилите на уменията.
Създаване на Екип...
Добавете агенти към екипа.
Създаване на опашка с канал тип Telephony или Chat, или Email или Social.
Добавяне на екипи към опашката в един CDG или няколко CDGs.
Изберете маршрутизиращ модел или LAA или BAA.
Добавете активност на Queue Contact в потока и изберете опашката, за която е конфигурирано маршрутизиране въз основа на уменията. За повече информация вижте Опашка Контакт...
Присвояване на умения, динамични умения и релаксация на умения в Queue Contact дейност. За BAA, конфигурирайте теглата за умения за владеене и умения за динамични умения, когато е необходимо.
Използвайте Escalate Call Distribution Activity в опашката след потока, за да преминете бързо към следващата група за разпространение на повиквания или последната.

Създаване на опашки, базирани на умения

Присвояване на екип на опашка

Създаване на Екип...
Добавете агенти към екипа.
Създаване на опашка с канал тип Telephony или Chat, или Email или Social.
Добавяне на екипи към опашката в един CDG или няколко CDGs.
Изберете маршрутизиращ модел или LAA.
Добавяне на Опашка Контактна активност в потока и изберете тази опашка.
Използвайте Escalate Call Distribution Activity в опашката след потока, за да преминете бързо към следващата група за разпространение на повиквания или последната.

Присвояване на агент към потока на опашката

Създаване на опашка с канал тип Telephony или Chat, или Email или Social.
Добавяне на агенти директно към опашките (Забележка: Нито Умения, нито екип се използват в този тип опашка).
Изберете модели на маршрутизиране, като кръгови или линейни или най-дългите налични агенти.

Маршрутизиране

Концепции за маршрутизиране

Агент Излишък Сценарий

Сценарият Agent Surplus се случва, когато има повече налични агенти, отколкото има контакти в опашката. В този случай, когато взаимодействието на клиента (контакт) е поставено на опашка, системата се опитва незабавно да намери съответен агент за този конкретен контакт, а ако бъде намерен съответен агент, контактът не трябва да бъде паркиран в опашка и да изчака да бъде наличен такъв агент по-късно.

Всеки път, когато даден контакт се разширява чрез Call Distribution Group или чрез релаксация на уменията, системата отново се опитва да намери подходящ агент за този конкретен контакт веднага.

Намирането на подходящ агент за конкретен контакт използва конфигурирания модел на маршрутизиране в опашката.

Webex Contact Center предлага множество модели на маршрутизиране в различни видове опашки, които позволяват на организациите да оптимизират обслужването на клиентите, като минимизират времето за изчакване, балансират натоварването на агенти и гарантират, че клиентите са свързани с агенти, които имат необходимите умения, за да отговорят на техните специфични нужди. Вижте раздела Routing Pattern за подробна информация за routing patterns.

Contact Surplus Scenario

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

Ключовите стратегии за ефективно маршрутизиране на контактите с ограничена наличност на агенти са:

Класиране на опашката
Класирането на опашките позволява на администраторите да определят относителната важност на опашките. Администраторите могат да определят класирането на опашки, за да определят реда, в който обажданията се маршрутизират от опашки до регистрирани агенти до екипи, на база на екип.
Например, имайте предвид, че агентите, влезли в Екип А, са свързани с две опашки – "Фактуриране" и "Продажби". Администраторите могат да използват ранглиста на опашката, за да присвоят по-висока ранглиста на опашката "Фактуриране", така че когато контактите влязат в опашката, контактите от "Фактуриране" ще бъдат пренасочени към агенти, принадлежащи към екип А преди контактите от опашката "Продажби". Това ще се случи, въпреки че може да има по-стари и с по-висок приоритет контакти, които могат да чакат в опашката "Продажби" - просто защото опашката "Фактуриране" има по-висок ранг на опашката от опашката "Продажби". Само когато няма повече чакащи контакти в опашката "Фактуриране", агенти от Екип А ще бъдат маршрутизирани контакти от опашката "Продажби" (и всяка друга), с която са свързани.
По-долу са някои от важните характеристики на класирането на опашката:
- - Ако рангът се присвоява само на някои от опашките, обажданията в тези опашки ще имат предимство пред обажданията в опашките, за които не е определен ранг.
  - Класирането на опашки може да бъде зададено на максимум опашки 50 във всички видове медии със стойност, варираща между 1 и 50 с 1 най-висок ранг.
  - Можете да присвоите един и същ ранг на няколко опашки.
  - Ако разрешите класирането на опашките, опашките, които не са определени изрично класирани, се третират по-ниско от всички класирани опашки.
  - Класирането на опашката работи в рамките на един и същ вид медии.
    
    Например, ако Queue Sale е гласова медия тип опашка с ранг и 2 Queue Billing Support е чат опашка с ранг 1 за Team A, тогава агентите, които са на разположение на гласовия канал в Team A получават гласово повикване първо, въпреки че рангът е 2.
    
    Въпреки това, помислете за две опашки за Team B - Queue Credit Card с ранг на опашката 2 и Queue Debit Card с ранг на опашката 1. След това наличните агенти в Екип Б ще бъдат предложени първо контакти от Queue Debit Card.
  - Класирането на опашката не се прилага за екипи, базирани на капацитет.
Приоритет на контактите
Когато контактът е поставен в опашка, приоритетът му може да се определи чрез определяне на йерархична важност, варираща от 1 (най-висока) до 10 (най-ниска, по подразбиране). Това приоритизиране гарантира, че определени контакти се адресират по-бързо въз основа на тяхната важност, неотложност или стратегическа стойност за организацията. Когато агентът е на разположение да се справи със следващия контакт между всички паркирани контакти във всички опашки, с които агентът е свързан, най-високият приоритетен контакт във всички опашки се насочва към агентът (при условие че са изпълнени други критерии, като например съвпадение на уменията и други).
За контактите, които са в опашка без изричен приоритет, се счита приоритет по подразбиране 10 на (най-нисък). Сред множество контакти, които имат един и същ приоритет, контактът, чакащ в опашката за най-дълго време, се пренасочва първо към наличния и допустим агент.
Най-дълго чакащ контакт
Това е основна стратегия, която гарантира, че най-дългият чакащ контакт във всички опашки, с които агентът е свързан, се насочва към агентът.
Това е крайният критерий, който определя контакта, който трябва да бъде маршрутизиран, когато няколко контакта между опашките с едно и също класиране на опашката и един и същ приоритет на контакта чакат да бъдат обработени.

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

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

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

А се1 свързва с опашките 3 – Q1, Q2 и Q3. TEAM 1 също така определи класирането на опашката, където Q1 е класирано най-високо, след2 това и3 съответно.

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

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

Сред всички паркирани контакти по тези опашки, могат да 4 бъдат маршрутизирани само до A1 – C2, C7 (от QUEUE 2) и C3, C8 (от QUEUE 3).

Само изискванията за умения на тези 4 контакти са напълно удовлетворени от уменията на А1.
Сред тези контакти4 , предимство се дава на контактите от QUEUE 2 (т.е. C2, C7), защото QUEUE 2 има по-висок ранг.

Имайте предвид, че въпреки че QUEUE 1 е най-високо класираната опашка, нито един от нейните паркирани контакти не може да бъде маршрутизиран до А1 , тъй като техните изисквания за умения не са изпълнени от А1.
Между C2 и C7, контактът с най-висок приоритет е C7. Така че, крайният избор е С7, а системата го насочва към А1.

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

Смесени мултимедийни профили

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

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

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

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

Изключващо
Смесване
Blended Real Time

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

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

Маршрутизатори

Въз основа на умения

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

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

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

За най-Доброто Налично маршрутизиране, умения за владеене и умения Dynamic Skills също може да използва тежести, за да повлияе на резултата, използван за подбор на агенти. Теглата не засягат най-дългото Налично Маршрутизиране; този модел използва умения и динамични умения Само За определяне на допустимостта на агента.

Най-дълго на разположение

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

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

В горния пример има агенти с умения 4 за владеене и невладеене с различни стойности на умения за владеене.

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

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

В този сценарий:

Само агенти, които напълно отговарят на изискванията за умения за контакт / критерии за умения за опашка, се считат за маршрутизиране. Само агенти А1, А2 и А4 отговарят изцяло на изискванията за умения за контакт / критерии за умения за опашка.

Агент А3 не е допустим. В случай на Критерии за умения, определени за опашката, А3Дори не е свързан с опашката.
Сред А1, А2 и А4 контактът ще бъде маршрутизиран до най-дългия наличен агент – А1 , който е на разположение от минути10 , по-дълго от А2 или А4.

По силата на назначения1 контакт, А вече няма да1 бъде най-дългият наличен агент във всички медийни канали.
Следващият контакт с точно същите изисквания за умения ще бъде пренасочен към следващия най-дълъг наличен агент – А2, и т.н.

Този модел на маршрутизиране се поддържа в следните видове опашки, базирани на умения:

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

Най-добрите налични

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

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

Ефективно, сумата от стойностите на уменията на агента, които отговарят на изискванията за умения за контакт / критерии за умения за опашка, определя резултата.

Някои ключови точки, които трябва да разберете:

Обикновено действителната стойност на уменията се използва при изчисляването на резултата, тъй като по-високата оценка на уменията показва по-силен мач. С изключение на случаите, когато изискването за умения използва условието по-малко от равно на (<=), тази специфична стойност на уменията на агента се инвертира при изчисляване на оценката, т.е. effective_skill_value = (10) минус (actual_skill_value). Това се прави, за да се гарантира, че по-нисък резултат показва по-силен мач.
Когато няколко допустими агенти имат една и съща оценка, се избира най-дългият наличен агент сред тях.
Само умения за владеене се вземат предвид за изчисляване на резултата. Никакви булеви, текстови или енум умения в изискванията за умения за контакт / критерии за умения за опашка не се считат за изчисляване на резултата.

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

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

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

В този сценарий:

Само агенти, които напълно отговарят на изискванията за умения за контакт / критерии за умения за опашка, се считат за маршрутизиране. Само агенти А1, А2 и А4 отговарят изцяло на изискванията за умения за контакт / критерии за умения за опашка.

Агент А3 не е допустим. В случай на Критерии за умения, определени за опашката, А3Дори не е свързан с опашката.
Сред A1, A2 и A4 изчисляването на резултата се извършва от системата въз основа на изискванията за умения за контакт / критерии за умения за опашка, където се разглеждат само умения за владеене.

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

Също така обърнете внимание на инверсията на стойността на уменията при изчисляване на резултата, когато се използва по-малко от равно на (<=) условие.
Контактът е маршрутизиран до А2, тъй като това е най-добрият наличен агент въз основа на резултата. Ако А2 не е наличен / зает, контактът ще бъде пренасочен към следващия най-добър наличен агент с втория най-висок резултат и т.н.

Имаме обаче агенти – 2 А и А1 със следващия4 най-висок резултат. Контактът е маршрутизиран до най-дългия наличен агент между А1 и А4.

Този модел на маршрутизиране се поддържа в следните видове опашки, базирани на умения:

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

Неквалифицирана маршрутизация

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

Най-дълго на разположение

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

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

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

В горния пример агент А е най1-дългият наличен агент (позиция1) – или този агент е влязъл първо, или не е бил назначен за контакт по-дълго от всеки друг агент.

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

Помислете за следния сценарий:

По време на T0, гласовият контакт C се1 опашка и се насочва към най-дългия наличен агент, т.е. A1.

По силата на А1 е назначен В1, А1 вече не е най-дългият наличен агент във всички медийни канали.
По време на T1, чат контакт с C2 се опашка и се насочва към най-дългия наличен агент, който сега е A2.
Накрая, по време на T2, друг глас контакт C3 се опашка и се маршрутизира до A3.

А1 и А2 наскоро получиха контакти – в този момент А3 чака най-дълго.

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

Този модел на маршрутизиране се поддържа в следните видове опашки, които не са базирани на умения:

Назначаване на екип
Назначаване на агент

Кръгови

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

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

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

В горния пример агентите са конфигурирани в кръгова опашка в следния ред: A3 → A4 → A5 → A6 → A1 → A2.

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

Помислете за следния сценарий:

Първият контакт (C1) е в опашка и е маршрутизиран до агент А3.

Указателят се актуализира до следващия агент в конфигуриран ред, т.е. А4.
Когато вторият контакт (C2) е в опашка, системата започва да намира налични агенти, започващи от A4 , т.е. A4 → A5 → A6 → A1 → A2 → A3 .

Въпреки това, A4 и A5 са недостъпни (или те дори не са влезли в системата, или са напълно заети с други контакти от този тип медии), така че C2 се пренасочва към следващия наличен агент – A6. Указателят се актуализира до следващия агент в конфигуриран ред, т.е. А1.
По същия начин третият контакт (В3) е маршрутизиран до А1, четвъртият контакт (В4) е маршрутизиран до А2. Показалецът отново е на3 А.

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

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

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

Този модел на маршрутизиране се поддържа в следните видове опашки, които не са базирани на умения:

Назначаване на агент

Отгоре надолу

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

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

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

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

В горния пример агентите са конфигурирани в опашка отгоре надолу в следния ред: A3 → A4 → A5 → A6 → A1 → A2.

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

Помислете за следния сценарий:

Първият контакт (C1) е в опашка и е маршрутизиран до агент А3, тъй като3 А е на върха на поръчката.
Когато вторият контакт (C2) е в опашка, маршрутизирането отново се опитва от върха на поръчката (винаги започвайки с A3).

Ако А има3 повече капацитет на канала за този тип медии, С2 също се маршрутизира до А3. Въпреки това, ако А3 е напълно зает с този тип медии, маршрутизирането продължава надолу по списъка до А4.
Въпреки това, A4 и A5 са недостъпни (те или дори не са влезли в системата, или са напълно заети с други контакти от този тип медии), така че C2 се пренасочва към следващия наличен агент в реда отгоре надолу – A6.
По същия начин, третият контакт (C3) се опитва да бъде маршрутизиран, започвайки от A3 надолу към дъното. Първият съвпадащ агент ще бъде А1.

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

Този модел на маршрутизиране се поддържа в следните видове опашки, които не са базирани на умения:

Назначаване на агент

Маршрутизиране на базата на агенти

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

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

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

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

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

Възможности за опашки и маршрутизиране в поток

Възможности за опашка и маршрутизиране в потока

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

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

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

Дейности на опашката

Контакт на опашката

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

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

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

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

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

Ако вече е налице съответен агент, системата се опитва да пренасочи контакта към агент.
Това прекъсва Main flow изпълнение и по-нататъшни събития могат да задействат съответния Event Flows, ако е конфигуриран.
Ако не се намери съвпадение агент, контактът се паркира в опашката и чака да стане наличен съвпадение агент.
Изпълнението на потока след това продължава с дейностите, свързани след дейността на Queue Contact, която осигурява възможност за:
- Възпроизвеждане на предварително конфигурирана музика на клиента, който чака в опашката - като прикрепите PlayMusic дейност.
- Регистрирайте обратно обаждане въз основа на заявка на клиента - като прикачите Callback дейност.
- Повторно опашка, т.е. премахнете контакта от текущата опашка и добавете в нова опашка - като прикрепите друга опашка Queue Contact или Queue to Agent дейност.

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

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

Дейността на Queue Contact работи, когато:

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

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

В такива случаи дейността води до неуспех и изпълнението на потока преминава към Error Handling път.

Възможности като Изисквания за умения, Релаксация на умения и Наличност на агент за проверка са налични в Queue Contact Activity само когато са избрани опашки с назначаване на екип.

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

Опашка към агент

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

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

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

След като Опашката Към Агента успешно опашка контакта,

Ако агентът вече е на разположение, контактът се пренасочва към агентът.
Това прекъсва Main flow изпълнение и по-нататъшни събития могат да задействат съответния Event Flows, ако е конфигуриран.
Ако агентът е на разположение, но реши да откаже, не отговори или не получи контакта, той се премества в предвидената опашка за възстановяване.
В опашката за възстановяване контактът ще бъде маршрутизиран до най-дългия наличен агент, без никаква подкрепа за умения.
Ако агентът не е на разположение и "Park Contact If Agent Unavailable" опция е selected, контакта се паркира и чака агента да бъде на разположение.
Изпълнението на потока след това продължава с дейностите, прикрепени след Опашката Към Дейността на агента, което дава възможност за:
- Възпроизвеждане на предварително конфигурирана музика на клиента, който чака в опашката - като прикрепите PlayMusic дейност.
- Callback дейност.
- Повторно опашка, т.е. премахнете контакта от текущата опашка и добавете в нова опашка - като прикрепите друга опашка Queue to Agent или Queue Contact дейност.
След като агентът стане достъпен, системата се опитва да пренасочи контакта към агентът.
Това прекъсва Main flow изпълнение и по-нататъшни събития могат да задействат съответния Event Flows, ако е конфигуриран.
Ако агентът не е на разположение и "Park Contact If Agent Unavailable" опция е not selectedОпашката се проваля.

Действието На Опашката На Агента работи, когато:

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

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

В такива случаи дейността води до неуспех и изпълнението на потока преминава към Error Handling път.

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

Escalate Call Distribution Group

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

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

Next Group—Разширяване на набора от екипи, за да включи тези, добавени в следващата група за разпространение на повиквания.
Last Group—Разширяване на набора от екипи, така че да включва всички екипи, картографирани във всички групи за разпространение на повиквания, конфигурирани за опашката.

Дейността на групата за разпространение на повиквания по ескалация работи, когато:

Контактът вече е на опашка и е готов за ескалация.
Контактът е опасан в опашка, която използва групи за разпространение.

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

В такива случаи дейността води до неуспех и изпълнението на потока преминава към Error Handling път.

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

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

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

Времето за изчакване може да бъде намалено, като се използва активността на Escalate Call Distribution Group, както следва:

Въз основа на Next Group или Last Group избран вариант, времето за изчакване на контакта се намалява значително, както е показано по-долу:

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

Информационни дейности по опашката

Получаване на информация за опашката

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

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

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

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

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

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

Дейността Get Queue Info работи, когато избраната променлива се реши на валидна опашка.

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

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

контакта не е (все още) в опашката, когато се изпълнява дейността Get Queue Info.
контакта е опашка в опашка, която не подкрепя концепцията за групи за разпространение на повиквания.

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

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

Това може да се постигне с помощта на дейността Get Queue Info в потока, както следва:

Допълнителна информация за опашката

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

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

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

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

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

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

Дейността Advanced Queue Info работи, когато:

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

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

В такива случаи дейността води до неуспех и изпълнението на потока преминава към Error Handling път.

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

Това може да се постигне чрез използване на Advanced Queue Info дейност в потока, както следва:

Дейности за контрол на обажданията

Задаване на идентификатор на обаждащия се

Активността на Set Caller ID се използва за определяне на ID на обаждащия се, който трябва да се показва по време на повикване. Активността на Set Caller ID трябва да се използва само в PreDial Event Flows като терминална дейност, която маркира края на потока от събития.

Дейността Set Caller ID позволява конфигуриране на изискваната автоматична идентификация на номера (ANI) въз основа на услугата за идентификация на номера (DNIS), типа на операцията или типа на участника.

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

Контрол на запис

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

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

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

Редът за предимство е, както следва:

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

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

Освен това, конфигурации за запис като Continue On Transfer, Pause Resume Enabled, Pause Duration и други остават приложими според съществуващата йерархия, включително наемател, опашка или нива на график за запис.

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

Сляп трансфер

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

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

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

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

Бридж трансфер

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

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

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

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

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

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

Разкачване на контакт

Функцията Disconnect Contact осигурява възможност за изключване или прекратяване на активен контакт директно от потока.

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

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

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

Задаване на приоритет на контакт

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

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

Приоритетната дейност Set Contact Priority може да бъде поставена във всяка точка от основния поток или потока на събитията.
Ако приоритетната дейност на Set Contact Priority е конфигурирана преди дадена дейност на опашката (като например Queue Contact или Queue To Agent), нейното приоритизиране може да бъде преодоляно от всеки приоритет, изрично конфигуриран в последващите дейности на опашката. Въпреки това, ако следната дейност по опашката не указва приоритет, се прилага приоритетът за контакт, определен от по-ранната дейност по приоритета за контакт.
Обратно, ако приоритетната дейност на Set Contact Priority е конфигурирана след дейност на опашката (като например Queue Contact или Queue To Agent), тя ще замени задаването на приоритет, конфигурирано от предишната дейност на опашката.
В момента дейността на Set Contact Priority не се поддържа за външни контакти и контакти с кампании.

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

Дейности за обратно повикване

Обратно повикване

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

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

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

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

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

Разписание на обажданията

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

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

Преди да започнете, моля уверете се, че Callback Default Entry Point е конфигуриран под Channel Settings в контролния център. За повече информация вижте Задаване на входна точка за обаждане...

Обаждането може да бъде планирано с помощта на всяка телефонна опашка – независимо дали е входяща или изходяща. За най-добри резултати се препоръчва да добавите Disconnect активност веднага след Scheduled Callback активност, за да се гарантира, че текущото повикване завършва правилно, след като е планирано обратното повикване. За повече информация относно планирането на IVR повиквания вижте График IVR Callbacks...

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

Преди преминаване на входящите данни към дейността трябва да се вземат предвид следните входящи данни:

Избор на дата – Можете да изберете всяка дата от днес до 31 дни в бъдеще. Датата трябва да бъде в този формат: ГГГГ-ММ-ДД (например, 2025-07-18).
Време Window Start и End Time – Времето, което изберете, трябва да започне най-малко 30 минути от сега и може да продължи навсякъде между 30 минути и 8 часове. Моля, използвайте 24формат за час (като 14:30:00).
Часова зона – Трябва да въведете валидна часова зона във формат IANA (като America/New_York), за да можем да ви се обадим в точното време.

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

Call Progress Analysis

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

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

За любезно обаждане, CallProgressAnalysis може да бъде поставен в точка след дейността на CallBack в основния поток. За планирано обратно обаждане или лично планирано обратно обаждане, то може да бъде поставено след NewPhoneContact в основния поток.
В потока на събитията тя се поддържа само в CallbackFailed event handler.
Ако в потока е конфигурирано проучване на клиента след повикване (дейност за обратна връзка), то няма да се инициира, ако повикването е отговорено от AMD или гласова поща. Това предотвратява ненужните проучвания.

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

Опашка

Общ преглед

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

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

Някои от основните предимства на ефективното използване на опашки са:

По-добро потребителско изживяване: Управлявайте времето за изчакване и оставете клиентите да знаят, че са на линия, за да им помогнат.
Повишена ефективност: Да се гарантира, че обажданията се обработват по организиран начин, като се намали хаосът и лошото управление.
Справедливо разпределение на контактите: Разпределете повикванията равномерно между агентите, за да избегнете претоварване на всеки един агентът.
Приоритетно третиране: Позволява приоритизиране на определени обаждания, като ВИП клиенти или спешни въпроси.

Видове опашки

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

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

Има две широки категории опашки:

Неквалифицирани опашки
Умения-базирани опашки

Неквалифицирани опашки

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

Задачи на екипа
Назначения на агенти

Неквалифицирани опашки с екипни задачи

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

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

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

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

Диаграма на работния процес за това как работи неквалифицираната опашка с назначаване на екип в Webex Contact Center

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

Първата група за разпространение на повиквания съдържа TEAM1, който има 3 конфигурирани агенти – A1, A2 и A5.

Втората група за разпространение на повиквания съдържа TEAM2, който има 3 конфигурирани агенти – A2, A3, и A4.

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

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

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

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

А принадлежи2 на TEAM 1 и TEAM 2. Ако A избере2 TEAM да 1 влезе в Agent Desktop, системата счита A за част2 от TEAM 1 и следователно само първата Call Distribution Group.
А5 принадлежи към TEAM1, обаче, може да е част и от друг екип в организацията, в която в момента са влезли. Следователно, А не5 се счита за част от TEAM и 1 не е свързан с тази опашка.

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

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

Най-дълго на разположение

Неквалифицирани опашки с назначения на агенти

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

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

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

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

Диаграма на работния поток, показваща как работи примерна опашка с назначаване на агенти в Webex Contact Center

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

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

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

Най-дълго на разположение
Кръгови
Линеен/отгоре-надолу

Умения-базирани опашки

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

Можете да конфигурирате следните видове опции, базирани на умения:

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

Критерии за умения, определени за опашката

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

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

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

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

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

Диаграма на работния поток, показваща пример за това как работи Skill-based queue с критерии за умения в Webex Contact Center

В този пример,

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