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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В този пример

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

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

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

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

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

Опашките, базирани на умения, с изисквания за умения, зададени в потока, са тип опашка, базирана на командно назначаване в 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).
• С течение на времето, при релаксация на уменията, допълнително А2 и А4 вече също отговарят на "спокойните" изисквания за умения на контакта.

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

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

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

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

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

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

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

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

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

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

• Класиране на опашката

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

  Например, помислете, че агентите, влезли в екип А, са свързани с две опашки – "Таксуване" и "Продажби". Администраторите могат да използват класиране на опашката, за да присвоят по-високо класиране на опашката "Таксуване", така че когато контактите влязат в опашките, контактите от "Фактуриране" ще бъдат насочени към агенти, принадлежащи към екип А, преди контактите от опашките "Продажби". Това ще се случи, въпреки че може да има по-стари контакти с по-висок приоритет, които може да чакат в опашката "Продажби" - само защото опашката "Таксуване" има по-високо класиране на опашката от опашката "Продажби". Само когато в опашката "Таксуване" вече няма чакащи контакти, агентите от екип А ще бъдат насочвани контакти от опашката "Продажби" (и всяка друга) опашка, с която са свързани.

  Следват някои от важните характеристики на класирането на опашката:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Изключващо

• Смесване

• Смесено в реално време

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Редът на приоритет е следният:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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