Телефония

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

На повикването се отговаря и се извършват по-нататъшни действия съгласно дефиницията на Webex CC Flow – която е програмно представяне на действията, които трябва да се извършат при обработката на повикването или преди опашка и маршрутизиране към агент, или самият поток може да се справи с повикването без прехвърляне към агент.

Flow Builder в Webex CC позволява на разработчиците да определят потока и да го присвоят към входната точка, през която повикването пристига в Webex CC.

Тези конфигурационни обекти и тяхното използване са обхванати в Configuration Entities.

Повече информация за Flow Builder е разгледана в предстоящия раздел на IVR System.

Имейл и съобщения

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

Webex Свързване на потока

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

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

• Обработва контакта преди опашката.

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

Каналите за съобщения, поддържани от Webex CC, са:

• Web App / Мобилно приложение чат

• WhatsApp

• Facebook Messenger

• SMS

Имейл каналите, поддържани от Webex CC, са:

• Е-мейл

• Униформа365

Механизми за проникване

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

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

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

Входящ глас

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

Фигура 1 илюстрира поглъщането на гласови повиквания към Webex CC.

Услугите за гласово проникване в Webex CC извършват контрол на повикванията от трети страни с помощта на SIP и отговарят на входящото повикване, както и извършват операции за прехвърляне, конференция и други операции за контрол на повикванията.

Логическата входна точка за повиквания в Webex CC е конфигурационният обект с име "Entrypoint". За Voice ingress ключовата конфигурация на Entrypoint е телефонният номер, свързан с него, който обикновено е валиден PSTN телефонен номер, получен от избран доставчик на PSTN.

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

Бележка:

За повече подробности относно опциите за свързване на PSTN посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Мащабируемост и наличност на гласова инфраструктура

Инфраструктурата на Webex CC VPOP включва излишни двойки SIP SBCs, осигуряващи висока достъпност и могат да бъдат добавени повече SBCs, за да се мащабират обемите на едновременните повиквания, които трябва да се поддържат.

Максималните едновременни повиквания, които VPOP може да обработи, зависят от броя на SBC, които се изпълняват и към които се изпращат повиквания.

За географска резервираност – поддържа се мрежа от VPOP SBC с връзки между множество двойки в различните региони.

За услугите за проникване на глас те са хоризонтално мащабируеми, за да се справят с нарастващия брой едновременни гласови повиквания, които да бъдат погълнати до Webex CC.

Съображения за сигурност с гласова инфраструктура

Таблицата по-долу съдържа подробности за опциите за свързване към инфраструктурата на Voice Edge.

За повече подробности посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR за системата

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

Webex CC Flow Builder доставя програмните конструкции / оператори и функционални блокове, наречени дейности, така че администраторите или всеки, който проектира и внедрява IVR логика, може да комбинира тези градивни елементи и да създаде дефиницията на потока.

Програмните конструкции, които Flow поддържа, са:

• Деклариране и задаване на променливи – състояние, свързано с изпълнението на потока

  • Pebble Expressions за задаване на стойност на променливи

• Условни проверки

• Looping – използване на Conditionals и Go To (възможност за свързване на дейности заедно)

• Извикване на REST API

• Анализиране на данни – JSON, TOML, обикновено XML използва за анализиране API отговор.

• Композиращи дейности

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

За всяко извикване, което е активно, е активен и екземпляр на изпълнение на потока, докато извикването приключи, което води до едновременно изпълнение на потоци.

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

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

За повече информация относно Webex CC Flow вижте https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Поддръжка на виртуален агент

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

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

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

Входящи цифрови взаимодействия

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

Фигура 2 илюстрира поглъщането на електронна поща, съобщения взаимодействия в Webex CC.

Виртуален агент / BOT интеграции

За взаимодействия по имейл и съобщения / социални канали, виртуалният агент / BOT леченията са конфигурирани в потока Webex Connect.

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

Избор на агент

Опашките в Webex CC поддържат следните алгоритми за избор на агент:

• Най-дълго налично маршрутизиране на агент

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

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

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

Агентите са свързани с опашките чрез екипи.

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

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

Специфични за гласа/телефонията допълнителни възможности

Маршрутизиране, базирано на агент (само за гласови/телефонни канали)

Webex CC Flow, използвайки дейността QueueToAgent, може да маршрутизира взаимодействията директно към избрания агент въз основа на ИД на агента.

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

Разширена информация за опашката

Webex CC Flow, използвайки дейността GetQueueInfo, може да извлича информация в реално време за опашка като Позиция в опашката (PIQ), Очаквано време за изчакване (EWT), брой агенти, налични в опашката, и може да се използва, за да реши дали да нареди контакта на опашка или не.

Учтиво обратно повикване

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

Обработка на препълване

Webex CC поддържа обработка на препълване с помощта на екипи, базирани на капацитет (CBT).

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

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

Agent Desktop операции

Когато агент влезе в Webex CC Agent Desktop, агентът посочва телефонен номер, към който могат да бъдат свързани входящите повиквания към агента. Това може да бъде PSTN телефон, мобилен телефон или разширение, ако агентът е Cisco Webex Calling потребител.

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

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

Например, след като се отговори на повикване, агентът може да извърши следните операции, свързани с повикването.

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

• Инициирайте консултско обаждане и

  • Прехвърляне на повикването на друг телефонен номер (да речем телефонен номер на агента) / Входна точка

  • Конференция друг агент на повикването

• Прехвърляне на повикването в друга опашка

• Край на разговора

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

Архитектура на работния плот

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

Това обикновено са асинхронни API, при които отговорът за извикване идва на работния плот чрез връзка WebSocket.

Webex CC Agent Desktop удостоверява потребителите със Cisco Common Identity (CI) и токенът се предава на всички API извиквания. За персонализирани джаджи също, въз основа на модела за удостоверяване, тя осигурява единичен опит за влизане на агентите, ако моделът за удостоверяване на персонализираната джаджа е интегриран с CI.

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

Устойчивост на работния плот към свързаност и латентност

Асинхронното натискане на API и от страна на сървъра позволява мащабиране и всяка загуба на свързаност към интерфейса на WebSocket се открива и десктоп се опитва да се свърже отново и да влезе отново.

Фигура 2 илюстрира архитектурата на работния плот на агента в Webex CC.

Onboarding клиенти

Webex Control Hub е основният интерфейс, използван от партньори и клиенти за включване на клиенти и активиране или конфигуриране на функции.

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

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

Фигура 1 илюстрира работния поток за осигуряване в Webex CC.

Конфигурационни обекти

Ключовите конфигурационни обекти в Webex CC, с обхват в рамките на една организация, са:

Сайт

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

Всеки потребител и екип трябва да принадлежи към даден сайт.

Екип

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

Всеки отбор трябва да принадлежи към даден сайт.

Служители

Потребители, които могат да влязат, за да Agent Desktop и да се справят с взаимодействията между типовете носители, конфигурирани в Webex CC.

Надзорници

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

Опашка

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

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

Входна точка

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

Тека

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

За канали, които не са телефонни (имейл, съобщения / социални), Flow се избира като част от конфигурацията на активите в Webex Connect.

Контрол на достъпа за контактни центрове с множество обекти

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

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

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

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

Настолни вградени конектори: CRM приложение като основен интерфейс

В този режим на работа агентът влиза в CRM конзолата като основно приложение.

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

При получаване на повикване или искане за разговор, интеграцията на CRM извършва следните действия на CRM конзолата

• Екранът показва записа на клиента, свързан с ANI или други данни, свързани с повикването.

• Метаданни за публикуване на повикване като бележки за дейност в записа на клиента

• Позволете на агента да "кликне, за да се обади", като кликнете върху контакта в CRM и инициирате изходящо повикване към клиента

• Осчетоводяване на записи на повиквания в таблиците за отчитане на CRM за първично отчитане в CRM.

• Осигурява пълната функционалност на контролите за Agent Desktop и повикване (вградена и минимизирана версия на приложението за десктоп)

Основният начин на интеграция със CRM е чрез вграждане Webex приложението CC Desktop в отделен iFrame.

Освен това приложението Webex CC Desktop изпълнява персонализирана джаджа без глава (без потребителски интерфейс), която работи във фонов режим, взаимодействайки с основната CRM система за извършване на автоматизирани действия от името на агента.

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

• Webex CC Desktop JS SDK: Това е JavaScript SDK, предоставен от Webex CC, за да регистрира слушателите на събития за агентски и контактни действия.

• CRM JS SDK: Това е SDK на CRM клиента, приложим за CRM, който извлича REST API повиквания с CRM. Например за salesforce библиотеката CTI JS, предоставена от Salesforce, се използва за извършване на действия и слушане на събития в CRM.

Фигура 1 илюстрира CRM вградената Webex CC архитектура на работния плот и конектора

Webex CC поддържа следните CRM решения за гореспоменатата интеграция:

• Слезфорс

• Сервиз сега

• Майкрософт Дайнамикс 365

• Зендеск

• Фрешбюро

За повече подробности посетете https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

За повече информация относно конфигурирането на оформленията на работния плот Webex CC за разрешаване на CRM конектора, наборите от функции и регистрационните файлове на промените, посетете https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Глобална наличност на CRM конектори

CRM конекторите са налични във всички географски райони и региони Webex където CC работи.

Еластична скала и производителност

Webex CC хоства персонализираната джаджа, която позволява двупосочна комуникация между CRM приложението и работния плот Webex CC в AWS CloudFront CDN, осигурявайки висока достъпност на джаджата AWS в зоните и регионите на наличност.

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

Защита

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

Например, за да разрешите приспособлението за действия на Salesforce, администраторът може да включи настройката на параметъра за оформление на работния плот sfdcWidgetEnabled на true.

Инсталиране на пакет

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

Всички вградени конектори за настолни компютри са налични на пазара на CRM.

Например

СервизСега: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Зендеск: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

Интеграция на потока чрез HTTPs конектори в IVR

Конструкторът Webex CC Flow поддържа двупосочни потоци от данни между Webex CC и CRM системата, използвайки HTTPs конектори Webex конфигурирани в Control Hub и използвани в Webex CC Flow.

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

По подразбиране Webex CC поддържа HTTP конектора на Salesforce в контролния концентратор. Другите CRM конектори могат да се добавят като персонализирани конектори на Webex контролен концентратор.

За повече информация относно HTTP конекторите посетете https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP конектори:

• Salesforce IVR HTTP конектор (вграден): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Гласова инфраструктура в Edge

Компонентите на Voice Edge позволяват на SIP стволовете от клиентската мрежа / PSTN превозвачите да прекратят и това е активирано въз основа на Ips в белия списък, на които е позволено да се свързват с компонентите на ръба.

Изчисляване на сигурността на инфраструктурата

Webex CC изчислителни инстанции са предвидени в AWS и услуги се изпълняват като шушулки в Kubernetes клъстер, който има множество пространства от имена и достъп до всяко пространство от имена е ограничен с отделни идентификационни данни.

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

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

Нито един от инфраструктурните компоненти / услуги не е пряко изложен извън AWS VPC и само публично изложени интерфейси са API и WebSocket сървъри, които се контролират и управляват с помощта на API шлюз,

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

Удостоверяване и оторизация за потребителски интерфейси

Всички потребителски интерфейси, използвани от различни потребители на контактния център (агенти, надзорници, администратори, анализатори), са защитени от Cisco Common Identity based bearer token authentication (OAuth flows).

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

Данни в транзит

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

Изберете услуги, с http API разкриват тези интерфейси чрез шлюз и всички входящи https (включително тези на WebSocket) се прекратяват в ALB и вътрешен трафик през http се насочва към услугите.

Всички изходящи взаимодействия са през https / TLS (за неhttp протоколи).

Вътре в VPC, вътрешната комуникация между услугите – през http / custom TCP протокол – е през обикновен TCP сокет.

Данни в покой

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

Фигура 1 илюстрира модела на потока от данни и сигурността както за транзита, така и за покой.

Лични данни на крайния потребител

Webex CC Flow, който е програмен контролер за обработка на взаимодействия, може да се използва за събиране на потребителски данни, които могат да бъдат присвоени на променливи на потока, специално маркирани като "Съдържа чувствителни данни". Стойностите за такива данни са криптирани и никакви услуги в транзитния път на данните няма да имат достъп до тези данни.

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

Контакт център Агент / супервайзор PII данни

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

Фактори за мащаба

За Webex CC факторите, които оказват влияние върху скалата, са:

• Едновременен брой регистрирани агенти

• Едновременен брой взаимодействия в ход

  • Действия, извършени по отношение на тези взаимодействия

• Едновременен брой действия, които надзорниците / агентите извършват, извън обработката на взаимодействията

• Обем на генерираните и запазени данни

Архитектурни аспекти, позволяващи мащаба

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

Архитектура, задвижвана от събития

Услугите в Webex CC комуникират чрез съобщения и критичните потоци за обработка на съобщения не включват никакви блокиращи IO операции и състоянието, необходимо за обработка на съобщенията, се локализира в екземпляра на услугата, която обработва съобщението.

Услуги без гражданство (или външно състояние)

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

Еластична инфраструктура

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

Проекция на натоварването и редовно валидиране

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

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

Телефония

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

На повикването се отговаря и се извършват по-нататъшни действия съгласно дефиницията на Webex CC Flow – която е програмно представяне на действията, които трябва да се извършат при обработката на повикването или преди опашка и маршрутизиране към агент, или самият поток може да се справи с повикването без прехвърляне към агент.

Flow Builder в Webex CC позволява на разработчиците да определят потока и да го присвоят към входната точка, през която повикването пристига в Webex CC.

Тези конфигурационни обекти и тяхното използване са обхванати в Configuration Entities.

Повече информация за Flow Builder е разгледана в предстоящия раздел на IVR System.

Имейл и съобщения

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

Webex Свързване на потока

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

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

• Обработва контакта преди опашката.

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

Каналите за съобщения, поддържани от Webex CC, са:

• Web App / Мобилно приложение чат

• WhatsApp

• Facebook Messenger

• SMS

Имейл каналите, поддържани от Webex CC, са:

• Е-мейл

• Униформа365

Механизми за проникване

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

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

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

Входящ глас

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

Фигура 1 илюстрира поглъщането на гласови повиквания към Webex CC.

Услугите за гласово проникване в Webex CC извършват контрол на повикванията от трети страни с помощта на SIP и отговарят на входящото повикване, както и извършват операции за прехвърляне, конференция и други операции за контрол на повикванията.

Логическата входна точка за повиквания в Webex CC е конфигурационният обект с име "Entrypoint". За Voice ingress ключовата конфигурация на Entrypoint е телефонният номер, свързан с него, който обикновено е валиден PSTN телефонен номер, получен от избран доставчик на PSTN.

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

Бележка:

За повече подробности относно опциите за свързване на PSTN посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Мащабируемост и наличност на гласова инфраструктура

Инфраструктурата на Webex CC VPOP включва излишни двойки SIP SBCs, осигуряващи висока достъпност и могат да бъдат добавени повече SBCs, за да се мащабират обемите на едновременните повиквания, които трябва да се поддържат.

Максималните едновременни повиквания, които VPOP може да обработи, зависят от броя на SBC, които се изпълняват и към които се изпращат повиквания.

За географска резервираност – поддържа се мрежа от VPOP SBC с връзки между множество двойки в различните региони.

За услугите за проникване на глас те са хоризонтално мащабируеми, за да се справят с нарастващия брой едновременни гласови повиквания, които да бъдат погълнати до Webex CC.

Съображения за сигурност с гласова инфраструктура

Таблицата по-долу съдържа подробности за опциите за свързване към инфраструктурата на Voice Edge.

За повече подробности посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR за системата

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

Webex CC Flow Builder доставя програмните конструкции / оператори и функционални блокове, наречени дейности, така че администраторите или всеки, който проектира и внедрява IVR логика, може да комбинира тези градивни елементи и да създаде дефиницията на потока.

Програмните конструкции, които Flow поддържа, са:

• Деклариране и задаване на променливи – състояние, свързано с изпълнението на потока

  • Pebble Expressions за задаване на стойност на променливи

• Условни проверки

• Looping – използване на Conditionals и Go To (възможност за свързване на дейности заедно)

• Извикване на REST API

• Анализиране на данни – JSON, TOML, обикновено XML използва за анализиране API отговор.

• Композиращи дейности

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

За всяко извикване, което е активно, е активен и екземпляр на изпълнение на потока, докато извикването приключи, което води до едновременно изпълнение на потоци.

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

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

За повече информация относно Webex CC Flow вижте https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Поддръжка на виртуален агент

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

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

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

Входящи цифрови взаимодействия

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

Фигура 2 илюстрира поглъщането на електронна поща, съобщения взаимодействия в Webex CC.

Виртуален агент / BOT интеграции

За взаимодействия по имейл и съобщения / социални канали, виртуалният агент / BOT леченията са конфигурирани в потока Webex Connect.

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

Избор на агент

Опашките в Webex CC поддържат следните алгоритми за избор на агент:

• Най-дълго налично маршрутизиране на агент

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

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

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

Агентите са свързани с опашките чрез екипи.

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

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

Специфични за гласа/телефонията допълнителни възможности

Маршрутизиране, базирано на агент (само за гласови/телефонни канали)

Webex CC Flow, използвайки дейността QueueToAgent, може да маршрутизира взаимодействията директно към избрания агент въз основа на ИД на агента.

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

Разширена информация за опашката

Webex CC Flow, използвайки дейността GetQueueInfo, може да извлича информация в реално време за опашка като Позиция в опашката (PIQ), Очаквано време за изчакване (EWT), брой агенти, налични в опашката, и може да се използва, за да реши дали да нареди контакта на опашка или не.

Учтиво обратно повикване

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

Обработка на препълване

Webex CC поддържа обработка на препълване с помощта на екипи, базирани на капацитет (CBT).

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

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

Agent Desktop операции

Когато агент влезе в Webex CC Agent Desktop, агентът посочва телефонен номер, към който могат да бъдат свързани входящите повиквания към агента. Това може да бъде PSTN телефон, мобилен телефон или разширение, ако агентът е Cisco Webex Calling потребител.

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

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

Например, след като се отговори на повикване, агентът може да извърши следните операции, свързани с повикването.

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

• Инициирайте консултско обаждане и

  • Прехвърляне на повикването на друг телефонен номер (да речем телефонен номер на агента) / Входна точка

  • Конференция друг агент на повикването

• Прехвърляне на повикването в друга опашка

• Край на разговора

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

Архитектура на работния плот

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

Това обикновено са асинхронни API, при които отговорът за извикване идва на работния плот чрез връзка WebSocket.

Webex CC Agent Desktop удостоверява потребителите със Cisco Common Identity (CI) и токенът се предава на всички API извиквания. За персонализирани джаджи също, въз основа на модела за удостоверяване, тя осигурява единичен опит за влизане на агентите, ако моделът за удостоверяване на персонализираната джаджа е интегриран с CI.

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

Устойчивост на работния плот към свързаност и латентност

Асинхронното натискане на API и от страна на сървъра позволява мащабиране и всяка загуба на свързаност към интерфейса на WebSocket се открива и десктоп се опитва да се свърже отново и да влезе отново.

Фигура 2 илюстрира архитектурата на работния плот на агента в Webex CC.

Onboarding клиенти

Webex Control Hub е основният интерфейс, използван от партньори и клиенти за включване на клиенти и активиране или конфигуриране на функции.

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

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

Фигура 1 илюстрира работния поток за осигуряване в Webex CC.

Конфигурационни обекти

Ключовите конфигурационни обекти в Webex CC, с обхват в рамките на една организация, са:

Сайт

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

Всеки потребител и екип трябва да принадлежи към даден сайт.

Екип

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

Всеки отбор трябва да принадлежи към даден сайт.

Служители

Потребители, които могат да влязат, за да Agent Desktop и да се справят с взаимодействията между типовете носители, конфигурирани в Webex CC.

Надзорници

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

Опашка

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

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

Входна точка

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

Тека

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

За канали, които не са телефонни (имейл, съобщения / социални), Flow се избира като част от конфигурацията на активите в Webex Connect.

Контрол на достъпа за контактни центрове с множество обекти

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

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

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

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

Настолни вградени конектори: CRM приложение като основен интерфейс

В този режим на работа агентът влиза в CRM конзолата като основно приложение.

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

При получаване на повикване или искане за разговор, интеграцията на CRM извършва следните действия на CRM конзолата

• Екранът показва записа на клиента, свързан с ANI или други данни, свързани с повикването.

• Метаданни за публикуване на повикване като бележки за дейност в записа на клиента

• Позволете на агента да "кликне, за да се обади", като кликнете върху контакта в CRM и инициирате изходящо повикване към клиента

• Осчетоводяване на записи на повиквания в таблиците за отчитане на CRM за първично отчитане в CRM.

• Осигурява пълната функционалност на контролите за Agent Desktop и повикване (вградена и минимизирана версия на приложението за десктоп)

Основният начин на интеграция със CRM е чрез вграждане Webex приложението CC Desktop в отделен iFrame.

Освен това приложението Webex CC Desktop изпълнява персонализирана джаджа без глава (без потребителски интерфейс), която работи във фонов режим, взаимодействайки с основната CRM система за извършване на автоматизирани действия от името на агента.

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

• Webex CC Desktop JS SDK: Това е JavaScript SDK, предоставен от Webex CC, за да регистрира слушателите на събития за агентски и контактни действия.

• CRM JS SDK: Това е SDK на CRM клиента, приложим за CRM, който извлича REST API повиквания с CRM. Например за salesforce библиотеката CTI JS, предоставена от Salesforce, се използва за извършване на действия и слушане на събития в CRM.

Фигура 1 илюстрира CRM вградената Webex CC архитектура на работния плот и конектора

Webex CC поддържа следните CRM решения за гореспоменатата интеграция:

• Слезфорс

• Сервиз сега

• Майкрософт Дайнамикс 365

• Зендеск

• Фрешбюро

За повече подробности посетете https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

За повече информация относно конфигурирането на оформленията на работния плот Webex CC за разрешаване на CRM конектора, наборите от функции и регистрационните файлове на промените, посетете https://github.com/CiscoDevNet/webex-contact-center-crm-integrationshttps://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

Глобална наличност на CRM конектори

CRM конекторите са налични във всички географски райони и региони Webex където CC работи.

Еластична скала и производителност

Webex CC хоства персонализираната джаджа, която позволява двупосочна комуникация между CRM приложението и работния плот Webex CC в AWS CloudFront CDN, осигурявайки висока достъпност на джаджата AWS в зоните и регионите на наличност.

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

Защита

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

Например, за да разрешите приспособлението за действия на Salesforce, администраторът може да включи настройката на параметъра за оформление на работния плот sfdcWidgetEnabled на true.

Инсталиране на пакет

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

Всички вградени конектори за настолни компютри са налични на пазара на CRM.

Например

СервизСега: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Зендеск: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

Интеграция на потока чрез HTTPs конектори в IVR

Конструкторът Webex CC Flow поддържа двупосочни потоци от данни между Webex CC и CRM системата, използвайки HTTPs конектори Webex конфигурирани в Control Hub и използвани в Webex CC Flow.

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

По подразбиране Webex CC поддържа HTTP конектора на Salesforce в контролния концентратор. Другите CRM конектори могат да се добавят като персонализирани конектори на Webex контролен концентратор.

За повече информация относно HTTP конекторите посетете https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP конектори:

• Salesforce IVR HTTP конектор (вграден): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Гласова инфраструктура в Edge

Компонентите на Voice Edge позволяват на SIP стволовете от клиентската мрежа / PSTN превозвачите да прекратят и това е активирано въз основа на Ips в белия списък, на които е позволено да се свързват с компонентите на ръба.

Изчисляване на сигурността на инфраструктурата

Webex CC изчислителни инстанции са предвидени в AWS и услуги се изпълняват като шушулки в Kubernetes клъстер, който има множество пространства от имена и достъп до всяко пространство от имена е ограничен с отделни идентификационни данни.

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

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

Нито един от инфраструктурните компоненти / услуги не е пряко изложен извън AWS VPC и само публично изложени интерфейси са API и WebSocket сървъри, които се контролират и управляват с помощта на API шлюз,

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

Удостоверяване и оторизация за потребителски интерфейси

Всички потребителски интерфейси, използвани от различни потребители на контактния център (агенти, надзорници, администратори, анализатори), са защитени от Cisco Common Identity based bearer token authentication (OAuth flows).

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

Данни в транзит

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

Изберете услуги, с http API разкриват тези интерфейси чрез шлюз и всички входящи https (включително тези на WebSocket) се прекратяват в ALB и вътрешен трафик през http се насочва към услугите.

Всички изходящи взаимодействия са през https / TLS (за неhttp протоколи).

Вътре в VPC, вътрешната комуникация между услугите – през http / custom TCP протокол – е през обикновен TCP сокет.

Данни в покой

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

Фигура 1 илюстрира модела на потока от данни и сигурността както за транзита, така и за покой.

Лични данни на крайния потребител

Webex CC Flow, който е програмен контролер за обработка на взаимодействия, може да се използва за събиране на потребителски данни, които могат да бъдат присвоени на променливи на потока, специално маркирани като "Съдържа чувствителни данни". Стойностите за такива данни са криптирани и никакви услуги в транзитния път на данните няма да имат достъп до тези данни.

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

Контакт център Агент / супервайзор PII данни

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

Фактори за мащаба

За Webex CC факторите, които оказват влияние върху скалата, са:

• Едновременен брой регистрирани агенти

• Едновременен брой взаимодействия в ход

  • Действия, извършени по отношение на тези взаимодействия

• Едновременен брой действия, които надзорниците / агентите извършват, извън обработката на взаимодействията

• Обем на генерираните и запазени данни

Архитектурни аспекти, позволяващи мащаба

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

Архитектура, задвижвана от събития

Услугите в Webex CC комуникират чрез съобщения и критичните потоци за обработка на съобщения не включват никакви блокиращи IO операции и състоянието, необходимо за обработка на съобщенията, се локализира в екземпляра на услугата, която обработва съобщението.

Услуги без гражданство (или външно състояние)

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

Еластична инфраструктура

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

Проекция на натоварването и редовно валидиране

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

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

Телефония

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

На повикването се отговаря и се извършват по-нататъшни действия съгласно дефиницията на Webex CC Flow – която е програмно представяне на действията, които трябва да се извършат при обработката на повикването или преди опашка и маршрутизиране към агент, или самият поток може да се справи с повикването без прехвърляне към агент.

Flow Builder в Webex CC позволява на разработчиците да определят потока и да го присвоят към входната точка, през която повикването пристига в Webex CC.

Тези конфигурационни обекти и тяхното използване са обхванати в Configuration Entities.

Повече информация за Flow Builder е разгледана в предстоящия раздел на IVR System.

Имейл и съобщения

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

Webex Свързване на потока

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

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

• Обработва контакта преди опашката.

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

Каналите за съобщения, поддържани от Webex CC, са:

• Web App / Мобилно приложение чат

• WhatsApp

• Facebook Messenger

• SMS

Имейл каналите, поддържани от Webex CC, са:

• Е-мейл

• Униформа365

Механизми за проникване

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

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

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

Входящ глас

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

Следващата фигура илюстрира поглъщането на гласови повиквания към Webex CC.

Услугите за гласово проникване в Webex CC извършват контрол на повикванията от трети страни с помощта на SIP и отговарят на входящото повикване, както и извършват операции за прехвърляне, конференция и други операции за контрол на повикванията.

Логическата входна точка за повиквания в Webex CC е конфигурационният обект с име "Entrypoint". За Voice ingress ключовата конфигурация на Entrypoint е телефонният номер, свързан с него, който обикновено е валиден PSTN телефонен номер, получен от избран доставчик на PSTN.

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

Бележка:

За повече подробности относно опциите за свързване на PSTN посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Мащабируемост и наличност на гласова инфраструктура

Инфраструктурата на Webex CC VPOP включва излишни двойки SIP SBCs, осигуряващи висока достъпност и могат да бъдат добавени повече SBCs, за да се мащабират обемите на едновременните повиквания, които трябва да се поддържат.

Максималните едновременни повиквания, които VPOP може да обработи, зависят от броя на SBC, които се изпълняват и към които се изпращат повиквания.

За географска резервираност – поддържа се мрежа от VPOP SBC с връзки между множество двойки в различните региони.

За услугите за проникване на глас те са хоризонтално мащабируеми, за да се справят с нарастващия брой едновременни гласови повиквания, които да бъдат погълнати до Webex CC.

Съображения за сигурност с гласова инфраструктура

Таблицата по-долу съдържа подробности за опциите за свързване към инфраструктурата на Voice Edge.

За повече подробности посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR за системата

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

Webex CC Flow Builder доставя програмните конструкции / оператори и функционални блокове, наречени дейности, така че администраторите или всеки, който проектира и внедрява IVR логика, може да комбинира тези градивни елементи и да създаде дефиницията на потока.

Програмните конструкции, които Flow поддържа, са:

• Деклариране и задаване на променливи – състояние, свързано с изпълнението на потока

  • Pebble Expressions за задаване на стойност на променливи

• Условни проверки

• Looping – използване на Conditionals и Go To (възможност за свързване на дейности заедно)

• Извикване на REST API

• Анализиране на данни – JSON, TOML, обикновено XML използва за анализиране API отговор.

• Композиращи дейности

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

За всяко извикване, което е активно, е активен и екземпляр на изпълнение на потока, докато извикването приключи, което води до едновременно изпълнение на потоци.

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

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

За повече информация относно Webex CC Flow вижте https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Поддръжка на виртуален агент

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

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

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

Входящи цифрови взаимодействия

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

Следващата фигура илюстрира поглъщането на електронна поща, взаимодействия със съобщения в Webex CC.

Виртуален агент / BOT интеграции

За взаимодействия по имейл и съобщения / социални канали, виртуалният агент / BOT леченията са конфигурирани в потока Webex Connect.

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

Избор на агент

Опашките в Webex CC поддържат следните алгоритми за избор на агент:

• Най-дълго налично маршрутизиране на агент

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

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

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

Агентите са свързани с опашките чрез екипи.

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

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

Специфични за гласа/телефонията допълнителни възможности

Маршрутизиране, базирано на агент (само за гласови/телефонни канали)

Webex CC Flow, използвайки дейността QueueToAgent, може да маршрутизира взаимодействията директно към избрания агент въз основа на ИД на агента.

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

Разширена информация за опашката

Webex CC Flow, използвайки дейността GetQueueInfo, може да извлича информация в реално време за опашка като Позиция в опашката (PIQ), Очаквано време за изчакване (EWT), брой агенти, налични в опашката, и може да се използва, за да реши дали да нареди контакта на опашка или не.

Учтиво обратно повикване

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

Обработка на препълване

Webex CC поддържа обработка на препълване с помощта на екипи, базирани на капацитет (CBT).

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

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

Agent Desktop операции

Когато агент влезе в Webex CC Agent Desktop, агентът посочва телефонен номер, към който могат да бъдат свързани входящите повиквания към агента. Това може да бъде PSTN телефон, мобилен телефон или разширение, ако агентът е Cisco Webex Calling потребител.

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

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

Например, след като се отговори на повикване, агентът може да извърши следните операции, свързани с повикването.

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

• Инициирайте консултско обаждане и

  • Прехвърляне на повикването на друг телефонен номер (да речем телефонен номер на агента) / Входна точка

  • Конференция друг агент на повикването

• Прехвърляне на повикването в друга опашка

• Край на разговора

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

Архитектура на работния плот

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

Това обикновено са асинхронни API, при които отговорът за извикване идва на работния плот чрез връзка WebSocket.

Webex CC Agent Desktop удостоверява потребителите със Cisco Common Identity (CI) и токенът се предава на всички API извиквания. За персонализирани джаджи също, въз основа на модела за удостоверяване, тя осигурява единичен опит за влизане на агентите, ако моделът за удостоверяване на персонализираната джаджа е интегриран с CI.

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

Устойчивост на работния плот към свързаност и латентност

Асинхронното натискане на API и от страна на сървъра позволява мащабиране и всяка загуба на свързаност към интерфейса на WebSocket се открива и десктоп се опитва да се свърже отново и да влезе отново.

Следващата фигура илюстрира архитектурата на работния плот на агента в Webex CC.

Onboarding клиенти

Webex Control Hub е основният интерфейс, използван от партньори и клиенти за включване на клиенти и активиране или конфигуриране на функции.

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

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

Следващата фигура илюстрира работния поток за осигуряване в Webex CC.

Конфигурационни обекти

Ключовите конфигурационни обекти в Webex CC, с обхват в рамките на една организация, са:

Сайт

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

Всеки потребител и екип трябва да принадлежи към даден сайт.

Екип

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

Всеки отбор трябва да принадлежи към даден сайт.

Служители

Потребители, които могат да влязат, за да Agent Desktop и да се справят с взаимодействията между типовете носители, конфигурирани в Webex CC.

Надзорници

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

Опашка

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

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

Входна точка

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

Тека

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

За канали, които не са телефонни (имейл, съобщения / социални), Flow се избира като част от конфигурацията на активите в Webex Connect.

Контрол на достъпа за контактни центрове с множество обекти

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

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

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

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

Настолни вградени конектори: CRM приложение като основен интерфейс

В този режим на работа агентът влиза в CRM конзолата като основно приложение.

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

При получаване на повикване или искане за разговор, интеграцията на CRM извършва следните действия на CRM конзолата

• Екранът показва записа на клиента, свързан с ANI или други данни, свързани с повикването.

• Метаданни за публикуване на повикване като бележки за дейност в записа на клиента

• Позволете на агента да "кликне, за да се обади", като кликнете върху контакта в CRM и инициирате изходящо повикване към клиента

• Осчетоводяване на записи на повиквания в таблиците за отчитане на CRM за първично отчитане в CRM.

• Осигурява пълната функционалност на контролите за Agent Desktop и повикване (вградена и минимизирана версия на приложението за десктоп)

Основният начин на интеграция със CRM е чрез вграждане Webex приложението CC Desktop в отделен iFrame.

Освен това приложението Webex CC Desktop изпълнява персонализирана джаджа без глава (без потребителски интерфейс), която работи във фонов режим, взаимодействайки с основната CRM система за извършване на автоматизирани действия от името на агента.

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

• Webex CC Desktop JS SDK: Това е JavaScript SDK, предоставен от Webex CC, за да регистрира слушателите на събития за агентски и контактни действия.

• CRM JS SDK: Това е SDK на CRM клиента, приложим за CRM, който извлича REST API повиквания с CRM. Например за salesforce библиотеката CTI JS, предоставена от Salesforce, се използва за извършване на действия и слушане на събития в CRM.

Следващата фигура илюстрира CRM, вграден Webex архитектурата на работния плот и конектора CC

Webex CC поддържа следните CRM решения за гореспоменатата интеграция:

• Слезфорс

• Сервиз сега

• Майкрософт Дайнамикс 365

• Зендеск

• Фрешбюро

За повече подробности посетете https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

За повече информация относно конфигурирането на оформленията на работния плот Webex CC за разрешаване на CRM конектора, наборите от функции и регистрационните файлове на промените, посетете https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Глобална наличност на CRM конектори

CRM конекторите са налични във всички географски райони и региони Webex където CC работи.

Еластична скала и производителност

Webex CC хоства персонализираната джаджа, която позволява двупосочна комуникация между CRM приложението и работния плот Webex CC в AWS CloudFront CDN, осигурявайки висока достъпност на джаджата AWS в зоните и регионите на наличност.

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

Защита

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

Например, за да разрешите приспособлението за действия на Salesforce, администраторът може да включи настройката на параметъра за оформление на работния плот sfdcWidgetEnabled на true.

Инсталиране на пакет

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

Всички вградени конектори за настолни компютри са налични на пазара на CRM.

Например

СервизСега: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Зендеск: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

Интеграция на потока чрез HTTPs конектори в IVR

Конструкторът Webex CC Flow поддържа двупосочни потоци от данни между Webex CC и CRM системата, използвайки HTTPs конектори Webex конфигурирани в Control Hub и използвани в Webex CC Flow.

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

По подразбиране Webex CC поддържа HTTP конектора на Salesforce в контролния концентратор. Другите CRM конектори могат да се добавят като персонализирани конектори на Webex контролен концентратор.

За повече информация относно HTTP конекторите посетете https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP конектори:

• Salesforce IVR HTTP конектор (вграден): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Гласова инфраструктура в Edge

Компонентите на Voice Edge позволяват на SIP стволовете от клиентската мрежа / PSTN превозвачите да прекратят и това е активирано въз основа на Ips в белия списък, на които е позволено да се свързват с компонентите на ръба.

Изчисляване на сигурността на инфраструктурата

Webex CC изчислителни инстанции са предвидени в AWS и услуги се изпълняват като шушулки в Kubernetes клъстер, който има множество пространства от имена и достъп до всяко пространство от имена е ограничен с отделни идентификационни данни.

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

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

Нито един от инфраструктурните компоненти / услуги не е пряко изложен извън AWS VPC и само публично изложени интерфейси са API и WebSocket сървъри, които се контролират и управляват с помощта на API шлюз,

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

Удостоверяване и оторизация за потребителски интерфейси

Всички потребителски интерфейси, използвани от различни потребители на контактния център (агенти, надзорници, администратори, анализатори), са защитени от Cisco Common Identity based bearer token authentication (OAuth flows).

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

Данни в транзит

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

Изберете услуги, с http API разкриват тези интерфейси чрез шлюз и всички входящи https (включително тези на WebSocket) се прекратяват в ALB и вътрешен трафик през http се насочва към услугите.

Всички изходящи взаимодействия са през https / TLS (за неhttp протоколи).

Вътре в VPC, вътрешната комуникация между услугите – през http / custom TCP протокол – е през обикновен TCP сокет.

Данни в покой

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

Следващата фигура илюстрира модела на потока от данни и сигурността както за транзита, така и в покой.

Лични данни на крайния потребител

Webex CC Flow, който е програмен контролер за обработка на взаимодействия, може да се използва за събиране на потребителски данни, които могат да бъдат присвоени на променливи на потока, специално маркирани като "Съдържа чувствителни данни". Стойностите за такива данни са криптирани и никакви услуги в транзитния път на данните няма да имат достъп до тези данни.

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

Контакт център Агент / супервайзор PII данни

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

Фактори за мащаба

За Webex CC факторите, които оказват влияние върху скалата, са:

• Едновременен брой регистрирани агенти

• Едновременен брой взаимодействия в ход

  • Действия, извършени по отношение на тези взаимодействия

• Едновременен брой действия, които надзорниците / агентите извършват, извън обработката на взаимодействията

• Обем на генерираните и запазени данни

Архитектурни аспекти, позволяващи мащаба

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

Архитектура, задвижвана от събития

Услугите в Webex CC комуникират чрез съобщения и критичните потоци за обработка на съобщения не включват никакви блокиращи IO операции и състоянието, необходимо за обработка на съобщенията, се локализира в екземпляра на услугата, която обработва съобщението.

Услуги без гражданство (или външно състояние)

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

Еластична инфраструктура

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

Проекция на натоварването и редовно валидиране

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

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

Телефония

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

На повикването се отговаря и се извършват по-нататъшни действия съгласно дефиницията на Webex CC Flow – която е програмно представяне на действията, които трябва да се извършат при обработката на повикването или преди опашка и маршрутизиране към агент, или самият поток може да се справи с повикването без прехвърляне към агент.

Flow Builder в Webex CC позволява на разработчиците да определят потока и да го присвоят към входната точка, през която повикването пристига в Webex CC.

Тези конфигурационни обекти и тяхното използване са обхванати в Configuration Entities.

Повече информация за Flow Builder е разгледана в предстоящия раздел на IVR System.

Имейл и съобщения

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

Webex Свързване на потока

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

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

• Обработва контакта преди опашката.

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

Каналите за съобщения, поддържани от Webex CC, са:

• Web App / Мобилно приложение чат

• WhatsApp

• Facebook Messenger

• SMS

Имейл каналите, поддържани от Webex CC, са:

• Е-мейл

• Униформа365

Механизми за проникване

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

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

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

Входящ глас

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

Следващата фигура илюстрира поглъщането на гласови повиквания към Webex CC.

Услугите за гласово проникване в Webex CC извършват контрол на повикванията от трети страни с помощта на SIP и отговарят на входящото повикване, както и извършват операции за прехвърляне, конференция и други операции за контрол на повикванията.

Логическата входна точка за повиквания в Webex CC е конфигурационният обект с име "Entrypoint". За Voice ingress ключовата конфигурация на Entrypoint е телефонният номер, свързан с него, който обикновено е валиден PSTN телефонен номер, получен от избран доставчик на PSTN.

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

Бележка:

За повече подробности относно опциите за свързване на PSTN посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

Мащабируемост и наличност на гласова инфраструктура

Инфраструктурата на Webex CC VPOP включва излишни двойки SIP SBCs, осигуряващи висока достъпност и могат да бъдат добавени повече SBCs, за да се мащабират обемите на едновременните повиквания, които трябва да се поддържат.

Максималните едновременни повиквания, които VPOP може да обработи, зависят от броя на SBC, които се изпълняват и към които се изпращат повиквания.

За географска резервираност – поддържа се мрежа от VPOP SBC с връзки между множество двойки в различните региони.

За услугите за проникване на глас те са хоризонтално мащабируеми, за да се справят с нарастващия брой едновременни гласови повиквания, които да бъдат погълнати до Webex CC.

Съображения за сигурност с гласова инфраструктура

Таблицата по-долу съдържа подробности за опциите за свързване към инфраструктурата на Voice Edge.

За повече подробности посетете https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html.

IVR за системата

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

Webex CC Flow Builder доставя програмните конструкции / оператори и функционални блокове, наречени дейности, така че администраторите или всеки, който проектира и внедрява IVR логика, може да комбинира тези градивни елементи и да създаде дефиницията на потока.

Програмните конструкции, които Flow поддържа, са:

• Деклариране и задаване на променливи – състояние, свързано с изпълнението на потока

  • Pebble Expressions за задаване на стойност на променливи

• Условни проверки

• Looping – използване на Conditionals и Go To (възможност за свързване на дейности заедно)

• Извикване на REST API

• Анализиране на данни – JSON, TOML, обикновено XML използва за анализиране API отговор.

• Композиращи дейности

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

За всяко извикване, което е активно, е активен и екземпляр на изпълнение на потока, докато извикването приключи, което води до едновременно изпълнение на потоци.

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

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

За повече информация относно Webex CC Flow вижте https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee.

Поддръжка на виртуален агент

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

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

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

Входящи цифрови взаимодействия

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

Следващата фигура илюстрира поглъщането на електронна поща, взаимодействия със съобщения в Webex CC.

Виртуален агент / BOT интеграции

За взаимодействия по имейл и съобщения / социални канали, виртуалният агент / BOT леченията са конфигурирани в потока Webex Connect.

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

Избор на агент

Опашките в Webex CC поддържат следните алгоритми за избор на агент:

• Най-дълго налично маршрутизиране на агент

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

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

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

Агентите са свързани с опашките чрез екипи.

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

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

Специфични за гласа/телефонията допълнителни възможности

Маршрутизиране, базирано на агент (само за гласови/телефонни канали)

Webex CC Flow, използвайки дейността QueueToAgent, може да маршрутизира взаимодействията директно към избрания агент въз основа на ИД на агента.

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

Разширена информация за опашката

Webex CC Flow, използвайки дейността GetQueueInfo, може да извлича информация в реално време за опашка като Позиция в опашката (PIQ), Очаквано време за изчакване (EWT), брой агенти, налични в опашката, и може да се използва, за да реши дали да нареди контакта на опашка или не.

Учтиво обратно повикване

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

Обработка на препълване

Webex CC поддържа обработка на препълване с помощта на екипи, базирани на капацитет (CBT).

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

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

Agent Desktop операции

Когато агент влезе в Webex CC Agent Desktop, агентът посочва телефонен номер, към който могат да бъдат свързани входящите повиквания към агента. Това може да бъде PSTN телефон, мобилен телефон или разширение, ако агентът е Cisco Webex Calling потребител.

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

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

Например, след като се отговори на повикване, агентът може да извърши следните операции, свързани с повикването.

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

• Инициирайте консултско обаждане и

  • Прехвърляне на повикването на друг телефонен номер (да речем телефонен номер на агента) / Входна точка

  • Конференция друг агент на повикването

• Прехвърляне на повикването в друга опашка

• Край на разговора

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

Архитектура на работния плот

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

Това обикновено са асинхронни API, при които отговорът за извикване идва на работния плот чрез връзка WebSocket.

Webex CC Agent Desktop удостоверява потребителите със Cisco Common Identity (CI) и токенът се предава на всички API извиквания. За персонализирани джаджи също, въз основа на модела за удостоверяване, тя осигурява единичен опит за влизане на агентите, ако моделът за удостоверяване на персонализираната джаджа е интегриран с CI.

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

Устойчивост на работния плот към свързаност и латентност

Асинхронното натискане на API и от страна на сървъра позволява мащабиране и всяка загуба на свързаност към интерфейса на WebSocket се открива и десктоп се опитва да се свърже отново и да влезе отново.

Следващата фигура илюстрира архитектурата на работния плот на агента в Webex CC.

Onboarding клиенти

Webex Control Hub е основният интерфейс, използван от партньори и клиенти за включване на клиенти и активиране или конфигуриране на функции.

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

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

Следващата фигура илюстрира работния поток за осигуряване в Webex CC.

Конфигурационни обекти

Ключовите конфигурационни обекти в Webex CC, с обхват в рамките на една организация, са:

Сайт

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

Всеки потребител и екип трябва да принадлежи към даден сайт.

Екип

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

Всеки отбор трябва да принадлежи към даден сайт.

Служители

Потребители, които могат да влязат, за да Agent Desktop и да се справят с взаимодействията между типовете носители, конфигурирани в Webex CC.

Надзорници

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

Опашка

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

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

Входна точка

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

Тека

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

За канали, които не са телефонни (имейл, съобщения / социални), Flow се избира като част от конфигурацията на активите в Webex Connect.

Контрол на достъпа за контактни центрове с множество обекти

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

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

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

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

Настолни вградени конектори: CRM приложение като основен интерфейс

В този режим на работа агентът влиза в CRM конзолата като основно приложение.

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

При получаване на повикване или искане за разговор, интеграцията на CRM извършва следните действия на CRM конзолата

• Екранът показва записа на клиента, свързан с ANI или други данни, свързани с повикването.

• Метаданни за публикуване на повикване като бележки за дейност в записа на клиента

• Позволете на агента да "кликне, за да се обади", като кликнете върху контакта в CRM и инициирате изходящо повикване към клиента

• Осчетоводяване на записи на повиквания в таблиците за отчитане на CRM за първично отчитане в CRM.

• Осигурява пълната функционалност на контролите за Agent Desktop и повикване (вградена и минимизирана версия на приложението за десктоп)

Основният начин на интеграция със CRM е чрез вграждане Webex приложението CC Desktop в отделен iFrame.

Освен това приложението Webex CC Desktop изпълнява персонализирана джаджа без глава (без потребителски интерфейс), която работи във фонов режим, взаимодействайки с основната CRM система за извършване на автоматизирани действия от името на агента.

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

• Webex CC Desktop JS SDK: Това е JavaScript SDK, предоставен от Webex CC, за да регистрира слушателите на събития за агентски и контактни действия.

• CRM JS SDK: Това е SDK на CRM клиента, приложим за CRM, който извлича REST API повиквания с CRM. Например за salesforce библиотеката CTI JS, предоставена от Salesforce, се използва за извършване на действия и слушане на събития в CRM.

Следващата фигура илюстрира CRM, вграден Webex архитектурата на работния плот и конектора CC

Webex CC поддържа следните CRM решения за гореспоменатата интеграция:

• Слезфорс

• Сервиз сега

• Майкрософт Дайнамикс 365

• Зендеск

• Фрешбюро

За повече подробности посетете https://help.webex.com/en-us/result/integrate%20with%20webex%20contact%20center?offset=10.

За повече информация относно конфигурирането на оформленията на работния плот Webex CC за разрешаване на CRM конектора, наборите от функции и регистрационните файлове на промените, посетете https://github.com/Ciscodevnet/webex-contact-center-crm-integrations.

Глобална наличност на CRM конектори

CRM конекторите са налични във всички географски райони и региони Webex където CC работи.

Еластична скала и производителност

Webex CC хоства персонализираната джаджа, която позволява двупосочна комуникация между CRM приложението и работния плот Webex CC в AWS CloudFront CDN, осигурявайки висока достъпност на джаджата AWS в зоните и регионите на наличност.

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

Защита

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

Например, за да разрешите приспособлението за действия на Salesforce, администраторът може да включи настройката на параметъра за оформление на работния плот sfdcWidgetEnabled на true.

Инсталиране на пакет

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

Всички вградени конектори за настолни компютри са налични на пазара на CRM.

Например

СервизСега: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Зендеск: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

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

Интеграция на потока чрез HTTPs конектори в IVR

Конструкторът Webex CC Flow поддържа двупосочни потоци от данни между Webex CC и CRM системата, използвайки HTTPs конектори Webex конфигурирани в Control Hub и използвани в Webex CC Flow.

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

По подразбиране Webex CC поддържа HTTP конектора на Salesforce в контролния концентратор. Другите CRM конектори могат да се добавят като персонализирани конектори на Webex контролен концентратор.

За повече информация относно HTTP конекторите посетете https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

IVR HTTP конектори:

• Salesforce IVR HTTP конектор (вграден): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP конектор (по избор): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

Гласова инфраструктура в Edge

Компонентите на Voice Edge позволяват на SIP стволовете от клиентската мрежа / PSTN превозвачите да прекратят и това е активирано въз основа на Ips в белия списък, на които е позволено да се свързват с компонентите на ръба.

Изчисляване на сигурността на инфраструктурата

Webex CC изчислителни инстанции са предвидени в AWS и услуги се изпълняват като шушулки в Kubernetes клъстер, който има множество пространства от имена и достъп до всяко пространство от имена е ограничен с отделни идентификационни данни.

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

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

Нито един от инфраструктурните компоненти / услуги не е пряко изложен извън AWS VPC и само публично изложени интерфейси са API и WebSocket сървъри, които се контролират и управляват с помощта на API шлюз,

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

Удостоверяване и оторизация за потребителски интерфейси

Всички потребителски интерфейси, използвани от различни потребители на контактния център (агенти, надзорници, администратори, анализатори), са защитени от Cisco Common Identity based bearer token authentication (OAuth flows).

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

Данни в транзит

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

Изберете услуги, с http API разкриват тези интерфейси чрез шлюз и всички входящи https (включително тези на WebSocket) се прекратяват в ALB и вътрешен трафик през http се насочва към услугите.

Всички изходящи взаимодействия са през https / TLS (за неhttp протоколи).

Вътре в VPC, вътрешната комуникация между услугите – през http / custom TCP протокол – е през обикновен TCP сокет.

Данни в покой

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

Следващата фигура илюстрира модела на потока от данни и сигурността както за транзита, така и в покой.

Лични данни на крайния потребител

Webex CC Flow, който е програмен контролер за обработка на взаимодействия, може да се използва за събиране на потребителски данни, които могат да бъдат присвоени на променливи на потока, специално маркирани като "Съдържа чувствителни данни". Стойностите за такива данни са криптирани и никакви услуги в транзитния път на данните няма да имат достъп до тези данни.

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

Контакт център Агент / супервайзор PII данни

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

Фактори за мащаба

За Webex CC факторите, които оказват влияние върху скалата, са:

• Едновременен брой регистрирани агенти

• Едновременен брой взаимодействия в ход

  • Действия, извършени по отношение на тези взаимодействия

• Едновременен брой действия, които надзорниците / агентите извършват, извън обработката на взаимодействията

• Обем на генерираните и запазени данни

Архитектурни аспекти, позволяващи мащаба

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

Архитектура, задвижвана от събития

Услугите в Webex CC комуникират чрез съобщения и критичните потоци за обработка на съобщения не включват никакви блокиращи IO операции и състоянието, необходимо за обработка на съобщенията, се локализира в екземпляра на услугата, която обработва съобщението.

Услуги без гражданство (или външно състояние)

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

Еластична инфраструктура

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

Проекция на натоварването и редовно валидиране

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

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