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

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

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

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

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

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

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

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

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

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

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

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

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

За повече информация относно настройките на активността, използването и изходните променливи, вижте Build and manage flows > Queue Contact.

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

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

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

След като активността Queue To Agent успешно постави контакта в опашка,

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

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

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

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

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

  Изпълнението на потока продължава с дейностите, свързани след активността Queue To Agent, което дава възможност да:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

За повече информация относно настройките на активността, използването и изходните променливи, вижте Build and manage flows > Set Caller ID.

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

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

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

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

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

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

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

За повече информация относно настройките на активността, използването и изходните променливи, вижте Build and manage flows > Recording Control.

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

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

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

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

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

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

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

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

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

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

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

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

За повече информация относно настройките на активността, променливите за използване и изход, вижте Build and manage flows > Disconnect контакт.

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

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

За повече информация относно настройките на активността, променливите за използване и изход, вижте Build and manage flows > Set Contact Priority.

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

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

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

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

За повече информация относно настройките на активността, променливите за използване и изход, вижте Build and manage flows > Callback.

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

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

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

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

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

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

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

За повече информация относно настройките на активността, използването и изходните променливи, вижте Build and manage flows > Analysis Progress Call Progress.