Телефонія

Для телефонії обробка вхідних голосових викликів визначається тим, як дзвінок надійшов до контакт-центру (див. Механізми проникнення нижче) і Webex CC Flow, пов'язаним із точкою входу.

На дзвінок приходить відповідь, а подальші дії виконуються відповідно до визначення CC Flow Webex – це програмне представлення дій, які потрібно виконати під час обробки виклику або до постановки в чергу та маршрутизації до оператора, або сам Flow може обробляти виклик без передачі оператору.

Конструктор ланцюжків у Webex CC дозволяє розробникам визначати потік і призначати його точці входу, через яку надходить виклик Webex CC.

Ці сутності конфігурації та їх використання описано в розділі Сутності конфігурації.

Більш детальну інформацію про Flow Builder можна знайти в наступному розділі IVR Система.

Електронна пошта та обмін повідомленнями

З точки зору Webex CC, Webex Connect надає можливості входу та виходу для всіх цифрових каналів - електронної пошти, каналів обміну повідомленнями, які кінцеві користувачі можуть використовувати для контакт-центру.

Webex Підключіть потік

• Вирішує обробку таких взаємодій, доки взаємодії не будуть поставлені в чергу та спрямовані до операторів. Це включає автоматичну обробку та обробку ботів для всіх форм обміну повідомленнями та взаємодії електронною поштою.

• Застосовує бізнес-логіку до вхідної взаємодії.

• Обробляє контакт перед чергою.

• Flow сам може обробляти взаємодію без передачі живому агенту.

Канали обміну повідомленнями, які підтримує Webex CC:

• Web App / Чат у мобільному додатку

• WhatsApp

• Facebook Messenger

• SMS

Канали електронної пошти, які підтримує Webex CC:

• Gmail

• Офіс 365

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

У цьому розділі розглядаються механізми, за допомогою яких взаємодія може увійти Webex КК. Залежно від типу середовища механізми, за допомогою яких взаємодія досягає Webex КК, різні.

Наприклад, у телефонії існує фізична інфраструктура, необхідна для підключення до ТМЗК, конфігурації телефонних номерів та маршрутизації дзвінків до Webex CC.

Для електронної пошти / каналів обміну повідомленнями конфігурація вхідних повідомлень повинна бути виконана в Webex Connect, і вона включає підготовку електронної пошти / облікового запису обміну повідомленнями та Webex конфігурацію потоку підключення.

Вхідний голосовий зв'язок

Для голосових дзвінків типовим сценарієм є те, що користувачі набирають номер телефону ТМЗК, який потім підключається до контакт-центру. З точки зору проникнення, для цього потрібен механізм для маршрутизації викликів з ТМЗК Webex CC.

На малюнку 1 показано, як відбувається прийом голосового дзвінка в Webex CC.

Послуги голосового зв'язку в Webex CC здійснюють керування викликами третьої сторони за допомогою SIP і відповідають на вхідний дзвінок, а також виконують операції з передачі, конференцій та інших операцій керування викликами.

Логічною точкою входу для викликів у Webex КЦ є сутність конфігурації з іменем 'Entrypoint'. Для передавання голосу ключовою конфігурацією точки входу є пов'язаний з нею номер телефону, який зазвичай є дійсним номером телефону ТМЗК, отриманим від вибраного провайдера ТМЗК.

Це дозволяє виявляти вхідні дзвінки на телефонному номері, пов'язувати дзвінок з точкою входу і використовувати інші параметри конфігурації точки входу для обробки дзвінка відповідно до Webex визначення CC Flow, яке повинно бути запущено для взаємодії.

Примітка.

Для отримання більш детальної інформації про варіанти підключення через ТМЗК відвідайте 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 SBC, що забезпечують високу доступність, і можна додати більше контролерів сеансу для масштабування одночасних обсягів викликів, які будуть підтримуватися.

Максимальна кількість одночасних викликів, які може обробляти VPOP, залежить від кількості запущених контролерів сеансу та викликів, які надсилаються.

Для географічної надмірності підтримується сітка 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 КЦ і запускає Webex потік СС, пов'язаний із точкою входу.

Webex CC Flow Builder надає програмні конструкції/оператори та функціональні блоки, які називаються діями, щоб адміністратори або будь-хто, хто розробляє та реалізує логіку IVR, могли об'єднати ці будівельні блоки та створити визначення Flow.

Програмні конструкції, які підтримує Flow:

• Змінні оголошення та налаштування – стан, пов'язаний з виконанням потоку

  • Вирази Pebble для встановлення значень змінних

• Умовні перевірки

• Циклічність – використання умовних операторів та Go To (можливість об'єднувати дії в ланцюжок)

• Виклик REST API

• Аналіз даних – JSON, TOML XML зазвичай використовується для аналізу API відповіді.

• Композиторська діяльність

Репрезентативним набором заходів, які пропонує Flow, є: Відтворювати повідомлення Збір даних користувачів Переадресація дзвінка на інший пункт призначення або номер телефону Надішліть дзвінок віртуальному агенту Поставте виклик у чергу, щоб на нього відповів оператор.

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

Кожен екземпляр виконання ланцюжка забезпечує ізольоване середовище для даних/станів, пов'язаних з потоком і там викликом.

Протягом усього життєвого циклу дзвінка 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 Control Hub.

Після того, як дзвінок з'єднано з віртуальним агентом, він надає користувачеві розмовний IVR, і дія завершується або припиненням дзвінка, або переходом виклику до оператора.

У разі ескалації потік можна налаштувати так, щоб він ставив виклик у чергу, на який потім відповідає оператор.

Вхідні цифрові взаємодії

Для електронної пошти та каналу обміну повідомленнями вхідних взаємодій Webex CC використовує Webex Connect для ініціалізації активів, flow для обробки вхідних взаємодій, а потім спрямовує взаємодію до Webex CC, коли потік Webex Connect явно ставить взаємодію в чергу, щоб її міг обробити агент.

На малюнку 2 показано, як відбувається взаємодія електронної пошти та обміну повідомленнями в Webex КЦ.

Інтеграція віртуальних агентів / ботів

Для електронної пошти та обміну повідомленнями/взаємодії з соціальними каналами обробки віртуального агента/бота налаштовуються в ланцюжку Webex Connect.

Як і у випадку з Virtual Agents for Voice, якщо обробка BOT закінчується ескалацією в результаті, то взаємодія ставиться в чергу і спрямовується до агента.

Підбір агента

Черги в Webex КЦ підтримують наступні алгоритми вибору агентів:

• Найдовша доступна маршрутизація агентів

• Кваліфікована маршрутизація

  • Найдовший доступний агент (LAA)

  • Найкращий доступний агент (BAA)

Агенти пов'язані з чергами через Teams.

Черзі можна призначити кілька груп розподілу викликів (при цьому кожна група має одну або кілька команд), послідовно з налаштованим очікуванням додавання групи розподілу викликів до черги, щоб простір пошуку відповідного агента розширювався за рахунок додаткових груп розподілу викликів з плином часу.

Для маршрутизації на основі навичок серед агентів, пов'язаних із чергою, вибирається агент на основі конфігурації LAA або BAA.

Додаткові можливості для голосу/телефонії

Маршрутизація на основі агентів (тільки для каналів голосового зв'язку/телефонії)

Webex CC Flow, використовуючи активність QueueToAgent, може спрямовувати взаємодії безпосередньо до обраного агента на основі ідентифікатора агента.

Якщо агент недоступний для обробки взаємодій, взаємодію можна припаркувати в певній черзі агента, чекаючи, поки агент стане доступним

Розширена інформація про чергу

Webex CC Flow, використовуючи активність GetQueueInfo, може отримувати інформацію в режимі реального часу для черги, як-от Position in Queue (PIQ), Estimate Wait Time (EWT), кількість агентів, доступних у черзі, і може використовуватися для прийняття рішення про те, чи ставити контакт у чергу чи ні.

Зворотній дзвінок з люб'язності

Webex CC Flow, використовуючи активність Callback, дозволяє клієнту відключитися від дзвінка, зберігаючи позицію в черзі, і отримати зворотний дзвінок, коли віртуальна взаємодія в черзі спрямовується до оператора.

Обробка переливу

Webex CC підтримує обробку переповнень за допомогою Capacity Based Teams (CBT).

КПТ схожа на звичайну команду з потенціалом і пов'язаним з ним зовнішнім DN, який обслуговує цю потужність. Його можна налаштувати разом з іншими командами в циклах розподілу викликів черги.

Зазвичай, цей параметр налаштовується як останній цикл так, щоб він діяв як переповнення, якщо оператор недоступний, навіть після того, як усі налаштовані групи розподілу викликів не змогли знайти доступного агента-відповідника для обробки взаємодії.

Agent Desktop Операційна діяльність

Коли агент входить Webex Agent Desktop CC, він вказує номер телефону, до якого можна підключити вхідні дзвінки оператору. Це може бути телефон ТМЗК, мобільний телефон або розширення, якщо Агент є користувачем Cisco Webex Calling.

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

Залежно від типу взаємодії, яку обробляє агент, віджети у стільниці агента надають можливість виконувати певні дії з керування мультимедіа.

Наприклад, після відповіді на дзвінок оператор може виконати наступні операції, пов'язані з викликом.

• Перевести дзвінок на утримання

• Ініціюйте консультативний дзвінок і

  • Перевести дзвінок на інший номер телефону (скажімо, номер телефону агента) / Точка входу

  • Зв'язатися з іншим агентом на дзвінок

• Перевести виклик в іншу чергу

• Завершіть дзвінок

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

Архітектура робочого столу

Agent desktop — це односторінковий додаток на основі мікроінтерфейсу, який розміщує віджети, побудовані на основі архітектури веб-компонентів. Усі стандартні/стокові віджети працюють на даних, які витягуються API або механізмами надсилання на стороні сервера.

Це, як правило, асинхронні API, де відповідь на виклик надходить на робочий стіл через з'єднання WebSocket.

Webex CC Agent Desktop автентифікує користувачів за допомогою Cisco Common Identity (CI), і токен передається всім API викликам. Для користувацьких віджетів також, на основі моделі автентифікації, він забезпечує єдиний вхід агентам, якщо модель автентифікації користувацького віджета інтегрована з CI.

Як тільки агент стає частиною взаємодії, всі оновлення цього стану взаємодії або пов'язаних з ним даних також надсилаються на робочий стіл через з'єднання WebSocket.

Стійкість робочого столу до підключення та затримки

Асинхронний API та надсилання на стороні сервера дозволяє масштабувати та виявляти будь-яку втрату з'єднання з інтерфейсом WebSocket, а робочий стіл намагається повторно підключитися та повторно увійти в систему.

На рисунку 2 зображено архітектуру робочого столу агента у Webex CC.

Онбординг клієнтів

Webex Control Hub — це основний інтерфейс, який використовується партнерами та клієнтами для реєстрації клієнтів і ввімкнення або налаштування функцій.

Після того, як функції організації та контакт-центру будуть підготовлені в Control Hub, він запустить робочий процес у Webex CC, який виконує решту кроків у забезпеченні всіх можливостей контакт-центру відповідно до пропозицій, обраних клієнтом.

Все ініціалізацію контакт-центру здійснюється за допомогою механізму робочих процесів BPM, який забезпечує декларативний спосіб визначення необхідних кроків, робить усі етапи ініціалізації стійкими до збоїв і забезпечує цілісність даних.

На рисунку 1 показаний робочий процес ініціалізації в Webex КЦ.

Сутності конфігурації

Ключовими сутностями конфігурації в Webex КЦ, що охоплюються в межах організації, є:

Сайт

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

Кожен користувач і команда повинні належати до сайту.

Команда

Група користувачів. Команди використовуються для розподілу взаємодії між агентами за допомогою черг.

Кожна команда повинна належати до сайту.

Агентів

Користувачі, які можуть входити в систему, щоб Agent Desktop і обробляти взаємодії між типами медіафайлів, налаштованими в Webex CC.

Керівники

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

Черга

Черга — це логічна сутність, де можна проводити взаємодії, очікуючи на доступність агентів, які потім спрямовуються до агента.

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

Точка входу

Точка входу - це логічна сутність, що представляє собою точку входу для взаємодій, що надходять Webex КК. Для телефонії це в першу чергу пов'язано з номером телефону, на який надходять дзвінки, а для каналів електронної пошти / обміну повідомленнями точка входу вказує на конфігурацію активу в Webex Connect.

Текти

Потік, пов'язаний з точкою входу (через Routing Strategy), яка визначає кроки, пов'язані з обробкою взаємодій.

Для каналів, не пов'язаних з телефонією (електронна пошта, обмін повідомленнями/соціальні мережі), Flow вибирається як частина конфігурації Об'єкта в Webex Connect.

Контроль доступу для багатопрофільних контакт-центрів

Webex Адміністратори CC можуть налаштовувати профілі користувачів з правами доступу до певних сайтів, команд, черг і точок входу. Крім того, у зв'язку з ієрархічним характером сайтів і команд, після надання доступу до конкретних сайтів користувач може отримати доступ лише до команд або дат, що стосуються команд, що належать до цих сайтів або явно визначеної підмножини таких команд.

Для черг і точок входу вони є глобальними на рівні організації, тому для різних географічних локацій (сайтів, де знаходяться конкретні агенти і команди) можуть бути налаштовані окремі точки входу і черги, а супервайзери / користувачі можуть мати доступ до тих сутностей, які застосовуються для конкретних сайтів.

Рисунок 2 ілюструє ключові сутності конфігурації та профіль користувача, який посилається на ці сутності.

Крім обмеження доступу до цих сутностей, адміністратори Webex КЦ можуть контролювати конкретні можливості/модулі, до яких користувач може отримати доступ в інтерфейсі адміністрування, тим самим маючи користувачів з правами адміністрування/конфігурації на конкретні сутності, а також розділами/можливостями інтерфейсу адміністрування Webex CC.

Настільні вбудовані конектори: CRM-додаток як основний інтерфейс

У цьому режимі роботи агент авторизується в консолі CRM як основний додаток.

Webex CC — це вбудована програма (також звана вбудованою настільною програмою або вбудованим софтфоном), яка в основному використовується для входу в контакт-центр і отримання Webex взаємодії з контакт-центром CC.

Отримавши дзвінок або запит на розмову, інтеграція CRM виконує наступні дії на консолі CRM

• Відкрийте на екрані запис клієнта, прив'язаний до ANI або інших даних, пов'язаних із викликом.

• Публікація метаданих виклику як приміток про активність у записі клієнта

• Дозвольте оператору «Click to Call», натиснувши на Контакт всередині 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-рішення для вищезгаданої інтеграції:

• Відділ продажів

• ServiceNow

• Microsoft Dynamics 365

• Zendesk (Зендеск)

• Freshdesk (Свіжий стіл)

Для отримання більш детальної інформації відвідайте 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 викликаються через макет робочого столу агента CC Webex, а необов'язкові параметри передаються через макет робочого столу у віджет для вмикання та вимикання функцій.

Наприклад, щоб увімкнути віджет дій Salesforce, адміністратор може ввімкнути параметр макета робочого столу sfdcWidgetEnabled на true.

Встановлення пакету

Щоб інтеграція працювала в двох напрямках, в CRM Console потрібно встановити вбудований додаток. Це потрібно для підтримки завантаження програми для настільних комп'ютерів у iFrame.

Всі конектори Desktop Embedded доступні на маркетплейсі CRM.

наприклад

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Установка програми маркетплейс активує необхідні плагіни та імпортує необхідні файли XML в консоль CRM для підтримки звітності записів дзвінків по CRM.

Інтеграція потоку через HTTP-конектори в IVR

Конструктор Webex CC Flow підтримує двонаправлені потоки даних між Webex CC і CRM-системою за допомогою HTTP-конекторів, налаштованих Webex Control Hub і використовуваних на Webex CC Flow.

Вони в основному використовуються для персоналізації голосової взаємодії та індивідуальної маршрутизації в межах IVR.

За замовчуванням Webex CC підтримує Salesforce HTTP Connector на Control Hub. Інші з'єднувачі CRM можна додати як спеціальні з'єднувачі Webex Control Hub.

Для отримання додаткової інформації про HTTP Connectors, відвідайте https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

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

• Salesforce IVR HTTP Connector (вбудований): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

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

Компоненти Voice Edge дозволяють завершувати роботу SIP-транків від операторів клієнтської мережі / ТМЗК, і це вмикається на основі IP-адрес із білого списку, яким дозволено підключатися до периферійних компонентів.

Безпека обчислювальної інфраструктури

Webex екземпляри обчислень CC надаються в AWS, а сервіси працюють як поди в кластері Kubernetes, який має кілька просторів імен, і доступ до кожного простору імен обмежений окремими обліковими даними.

Все забезпечення інфраструктури здійснюється за допомогою коду – без ручних кроків – і жоден з облікових даних не може бути доступний вручну.

Існує центральне сховище облікових даних з певними шляхами, налаштованими для конкретного набору служб / команд, а доступ до самого сховища облікових даних обмежений і налаштований як секрети в системах збірки та розгортання.

Жоден із компонентів/сервісів інфраструктури не піддається безпосередньому впливу за межами AWS VPC, і лише загальнодоступні інтерфейси є API та серверами WebSocket, які контролюються та керуються за допомогою API-шлюзу,

Крім того, розробники використовують певні внутрішні системи та інтерфейси, які використовуються для перегляду журналів, метрик, деталей розгортання, стану збірки та результатів тестування, які захищені за допомогою ролей та груп та інтегровані з внутрішніми системами автентифікації Cisco.

Автентифікація та авторизація інтерфейсів користувача

Всі інтерфейси користувача, що використовуються різними користувачами контакт-центру (агентами, супервізорами, адміністраторами, аналітиками), захищені аутентифікацією на основі Cisco Common Identity на пред'явника (OAuth flows).

Авторизація здійснюється за допомогою ролей користувача, який отримав токен, і областей видимості, призначених токену.

Дані під час передавання

Жоден з інтерфейсів розгорнутого компонента сервісів / інфраструктури не піддається прямому впливу зовнішнього вхідного трафіку.

Вибрані сервіси з http API відкривають ці інтерфейси через шлюз, і всі вхідні https (включаючи WebSocket) завершуються в ALB, а внутрішній трафік через http спрямовується до служб.

Всі вихідні взаємодії здійснюються через https / TLS (для протоколів, відмінних від http).

Усередині VPC внутрішній зв'язок між службами – через протокол http / користувальницької TCP – здійснюється через звичайний TCP сокет.

Дані в стані спокою

Усі дані, які зберігаються, шифруються на рівні зберігання. Крім того, ті сховища даних, які знаходяться за межами VPC, захищені, а контроль доступу та авторизація з обліковими даними надійно зберігаються та керуються в секретному сховищі.

На малюнку 1 показана модель потоку даних і безпеки як для транзиту, так і в стані спокою.

Ідентифікаційні дані кінцевого користувача

Webex CC Flow, який є програмним контролером для обробки взаємодій, може використовуватися для збору даних користувача, які можуть бути призначені змінним потоку, спеціально позначеним як «Містить конфіденційні дані». Значення для таких даних зашифровані, і жодні служби на шляху передачі даних не матимуть доступу до цих даних.

Крім того, такі дані ніколи не зберігаються Webex сховищі даних звітності CC, а інфраструктура журналів/повідомлень матиме зашифровані дані, а чіткі текстові дані не зберігаються ніде в межах Webex CC.

Ідентифікаційні дані агента/супервайзера контакт-центру

Дані, пов'язані з користувачами контакт-центру, редагуються в журналах, але доступні для аналізу та візуалізації даних у сховищі даних Webex CC.

Фактори масштабу

Для Webex КЦ факторами, що впливають на шкалу, є:

• Одночасна кількість агентів, які увійшли в систему

• Одночасна кількість виконуваних взаємодій

  • Дії, виконані під час цих взаємодій

• Одночасна кількість дій, які виконують супервізори/агенти, поза обробкою взаємодій

• Обсяг згенерованих і збережених даних

Архітектурні аспекти, що сприяють масштабуванню

Принципи, на основі яких будується та проектується Webex CC, дозволяють рішенню динамічно масштабуватися за потреби в межах, передбачених інфраструктурою, наданою для різних сервісів та компонентів платформи.

Архітектура, керована подіями

Сервіси в Webex CC обмінюються даними за допомогою повідомлень, і критичні потоки обробки повідомлень не передбачають жодних блокуючих операцій вводу-виводу, а стан, необхідний для обробки повідомлень, локалізується для екземпляра служби, яка обробляє повідомлення.

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

Сервіси без стану забезпечують еластичність, легко додаючи або видаляючи додаткові екземпляри служб. Є певні сервіси, які за своєю суттю є державними, і ті, що мають екстерналізоване сховище станів, а інфраструктура також підтримує динамічні зміни кількості екземплярів таких сервісів з автоматичним перебалансуванням/перенесенням стану/локалізацією стану до інстансу, який потребує стану.

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

Усі сервіси працюють у Kubernetes та інфраструктура, також відома як вузли Kubernetes, автоматично масштабуються залежно від використання, і це дозволяє динамічно додавати більше обчислювальних вузлів до максимально високого порогу, який попередньо налаштований.

Проекція навантаження та регулярна валідація

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

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

Телефонія

Для телефонії обробка вхідних голосових викликів визначається тим, як дзвінок надійшов до контакт-центру (див. Механізми проникнення нижче) і Webex CC Flow, пов'язаним із точкою входу.

На дзвінок приходить відповідь, а подальші дії виконуються відповідно до визначення CC Flow Webex – це програмне представлення дій, які потрібно виконати під час обробки виклику або до постановки в чергу та маршрутизації до оператора, або сам Flow може обробляти виклик без передачі оператору.

Конструктор ланцюжків у Webex CC дозволяє розробникам визначати потік і призначати його точці входу, через яку надходить виклик Webex CC.

Ці сутності конфігурації та їх використання описано в розділі Сутності конфігурації.

Більш детальну інформацію про Flow Builder можна знайти в наступному розділі IVR Система.

Електронна пошта та обмін повідомленнями

З точки зору Webex CC, Webex Connect надає можливості входу та виходу для всіх цифрових каналів - електронної пошти, каналів обміну повідомленнями, які кінцеві користувачі можуть використовувати для контакт-центру.

Webex Підключіть потік

• Вирішує обробку таких взаємодій, доки взаємодії не будуть поставлені в чергу та спрямовані до операторів. Це включає автоматичну обробку та обробку ботів для всіх форм обміну повідомленнями та взаємодії електронною поштою.

• Застосовує бізнес-логіку до вхідної взаємодії.

• Обробляє контакт перед чергою.

• Flow сам може обробляти взаємодію без передачі живому агенту.

Канали обміну повідомленнями, які підтримує Webex CC:

• Web App / Чат у мобільному додатку

• WhatsApp

• Facebook Messenger

• SMS

Канали електронної пошти, які підтримує Webex CC:

• Gmail

• Офіс 365

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

У цьому розділі розглядаються механізми, за допомогою яких взаємодія може увійти Webex КК. Залежно від типу середовища механізми, за допомогою яких взаємодія досягає Webex КК, різні.

Наприклад, у телефонії існує фізична інфраструктура, необхідна для підключення до ТМЗК, конфігурації телефонних номерів та маршрутизації дзвінків до Webex CC.

Для електронної пошти / каналів обміну повідомленнями конфігурація вхідних повідомлень повинна бути виконана в Webex Connect, і вона включає підготовку електронної пошти / облікового запису обміну повідомленнями та Webex конфігурацію потоку підключення.

Вхідний голосовий зв'язок

Для голосових дзвінків типовим сценарієм є те, що користувачі набирають номер телефону ТМЗК, який потім підключається до контакт-центру. З точки зору проникнення, для цього потрібен механізм для маршрутизації викликів з ТМЗК Webex CC.

На малюнку 1 показано, як відбувається прийом голосового дзвінка в Webex CC.

Послуги голосового зв'язку в Webex CC здійснюють керування викликами третьої сторони за допомогою SIP і відповідають на вхідний дзвінок, а також виконують операції з передачі, конференцій та інших операцій керування викликами.

Логічною точкою входу для викликів у Webex КЦ є сутність конфігурації з іменем 'Entrypoint'. Для передавання голосу ключовою конфігурацією точки входу є пов'язаний з нею номер телефону, який зазвичай є дійсним номером телефону ТМЗК, отриманим від вибраного провайдера ТМЗК.

Це дозволяє виявляти вхідні дзвінки на телефонному номері, пов'язувати дзвінок з точкою входу і використовувати інші параметри конфігурації точки входу для обробки дзвінка відповідно до Webex визначення CC Flow, яке повинно бути запущено для взаємодії.

Примітка.

Для отримання більш детальної інформації про варіанти підключення через ТМЗК відвідайте 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 SBC, що забезпечують високу доступність, і можна додати більше контролерів сеансу для масштабування одночасних обсягів викликів, які будуть підтримуватися.

Максимальна кількість одночасних викликів, які може обробляти VPOP, залежить від кількості запущених контролерів сеансу та викликів, які надсилаються.

Для географічної надмірності підтримується сітка 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 КЦ і запускає Webex потік СС, пов'язаний із точкою входу.

Webex CC Flow Builder надає програмні конструкції/оператори та функціональні блоки, які називаються діями, щоб адміністратори або будь-хто, хто розробляє та реалізує логіку IVR, могли об'єднати ці будівельні блоки та створити визначення Flow.

Програмні конструкції, які підтримує Flow:

• Змінні оголошення та налаштування – стан, пов'язаний з виконанням потоку

  • Вирази Pebble для встановлення значень змінних

• Умовні перевірки

• Циклічність – використання умовних операторів та Go To (можливість об'єднувати дії в ланцюжок)

• Виклик REST API

• Аналіз даних – JSON, TOML XML зазвичай використовується для аналізу API відповіді.

• Композиторська діяльність

Репрезентативним набором заходів, які пропонує Flow, є: Відтворювати повідомлення Збір даних користувачів Переадресація дзвінка на інший пункт призначення або номер телефону Надішліть дзвінок віртуальному агенту Поставте виклик у чергу, щоб на нього відповів оператор.

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

Кожен екземпляр виконання ланцюжка забезпечує ізольоване середовище для даних/станів, пов'язаних з потоком і там викликом.

Протягом усього життєвого циклу дзвінка 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 Control Hub.

Після того, як дзвінок з'єднано з віртуальним агентом, він надає користувачеві розмовний IVR, і дія завершується або припиненням дзвінка, або переходом виклику до оператора.

У разі ескалації потік можна налаштувати так, щоб він ставив виклик у чергу, на який потім відповідає оператор.

Вхідні цифрові взаємодії

Для електронної пошти та каналу обміну повідомленнями вхідних взаємодій Webex CC використовує Webex Connect для ініціалізації активів, flow для обробки вхідних взаємодій, а потім спрямовує взаємодію до Webex CC, коли потік Webex Connect явно ставить взаємодію в чергу, щоб її міг обробити агент.

На малюнку 2 показано, як відбувається взаємодія електронної пошти та обміну повідомленнями в Webex КЦ.

Інтеграція віртуальних агентів / ботів

Для електронної пошти та обміну повідомленнями/взаємодії з соціальними каналами обробки віртуального агента/бота налаштовуються в ланцюжку Webex Connect.

Як і у випадку з Virtual Agents for Voice, якщо обробка BOT закінчується ескалацією в результаті, то взаємодія ставиться в чергу і спрямовується до агента.

Підбір агента

Черги в Webex КЦ підтримують наступні алгоритми вибору агентів:

• Найдовша доступна маршрутизація агентів

• Кваліфікована маршрутизація

  • Найдовший доступний агент (LAA)

  • Найкращий доступний агент (BAA)

Агенти пов'язані з чергами через Teams.

Черзі можна призначити кілька груп розподілу викликів (при цьому кожна група має одну або кілька команд), послідовно з налаштованим очікуванням додавання групи розподілу викликів до черги, щоб простір пошуку відповідного агента розширювався за рахунок додаткових груп розподілу викликів з плином часу.

Для маршрутизації на основі навичок серед агентів, пов'язаних із чергою, вибирається агент на основі конфігурації LAA або BAA.

Додаткові можливості для голосу/телефонії

Маршрутизація на основі агентів (тільки для каналів голосового зв'язку/телефонії)

Webex CC Flow, використовуючи активність QueueToAgent, може спрямовувати взаємодії безпосередньо до обраного агента на основі ідентифікатора агента.

Якщо агент недоступний для обробки взаємодій, взаємодію можна припаркувати в певній черзі агента, чекаючи, поки агент стане доступним

Розширена інформація про чергу

Webex CC Flow, використовуючи активність GetQueueInfo, може отримувати інформацію в режимі реального часу для черги, як-от Position in Queue (PIQ), Estimate Wait Time (EWT), кількість агентів, доступних у черзі, і може використовуватися для прийняття рішення про те, чи ставити контакт у чергу чи ні.

Зворотній дзвінок з люб'язності

Webex CC Flow, використовуючи активність Callback, дозволяє клієнту відключитися від дзвінка, зберігаючи позицію в черзі, і отримати зворотний дзвінок, коли віртуальна взаємодія в черзі спрямовується до оператора.

Обробка переливу

Webex CC підтримує обробку переповнень за допомогою Capacity Based Teams (CBT).

КПТ схожа на звичайну команду з потенціалом і пов'язаним з ним зовнішнім DN, який обслуговує цю потужність. Його можна налаштувати разом з іншими командами в циклах розподілу викликів черги.

Зазвичай, цей параметр налаштовується як останній цикл так, щоб він діяв як переповнення, якщо оператор недоступний, навіть після того, як усі налаштовані групи розподілу викликів не змогли знайти доступного агента-відповідника для обробки взаємодії.

Agent Desktop Операційна діяльність

Коли агент входить Webex Agent Desktop CC, він вказує номер телефону, до якого можна підключити вхідні дзвінки оператору. Це може бути телефон ТМЗК, мобільний телефон або розширення, якщо Агент є користувачем Cisco Webex Calling.

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

Залежно від типу взаємодії, яку обробляє агент, віджети у стільниці агента надають можливість виконувати певні дії з керування мультимедіа.

Наприклад, після відповіді на дзвінок оператор може виконати наступні операції, пов'язані з викликом.

• Перевести дзвінок на утримання

• Ініціюйте консультативний дзвінок і

  • Перевести дзвінок на інший номер телефону (скажімо, номер телефону агента) / Точка входу

  • Зв'язатися з іншим агентом на дзвінок

• Перевести виклик в іншу чергу

• Завершіть дзвінок

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

Архітектура робочого столу

Agent desktop — це односторінковий додаток на основі мікроінтерфейсу, який розміщує віджети, побудовані на основі архітектури веб-компонентів. Усі стандартні/стокові віджети працюють на даних, які витягуються API або механізмами надсилання на стороні сервера.

Це, як правило, асинхронні API, де відповідь на виклик надходить на робочий стіл через з'єднання WebSocket.

Webex CC Agent Desktop автентифікує користувачів за допомогою Cisco Common Identity (CI), і токен передається всім API викликам. Для користувацьких віджетів також, на основі моделі автентифікації, він забезпечує єдиний вхід агентам, якщо модель автентифікації користувацького віджета інтегрована з CI.

Як тільки агент стає частиною взаємодії, всі оновлення цього стану взаємодії або пов'язаних з ним даних також надсилаються на робочий стіл через з'єднання WebSocket.

Стійкість робочого столу до підключення та затримки

Асинхронний API та надсилання на стороні сервера дозволяє масштабувати та виявляти будь-яку втрату з'єднання з інтерфейсом WebSocket, а робочий стіл намагається повторно підключитися та повторно увійти в систему.

На рисунку 2 зображено архітектуру робочого столу агента у Webex CC.

Онбординг клієнтів

Webex Control Hub — це основний інтерфейс, який використовується партнерами та клієнтами для реєстрації клієнтів і ввімкнення або налаштування функцій.

Після того, як функції організації та контакт-центру будуть підготовлені в Control Hub, він запустить робочий процес у Webex CC, який виконує решту кроків у забезпеченні всіх можливостей контакт-центру відповідно до пропозицій, обраних клієнтом.

Все ініціалізацію контакт-центру здійснюється за допомогою механізму робочих процесів BPM, який забезпечує декларативний спосіб визначення необхідних кроків, робить усі етапи ініціалізації стійкими до збоїв і забезпечує цілісність даних.

На рисунку 1 показаний робочий процес ініціалізації в Webex КЦ.

Сутності конфігурації

Ключовими сутностями конфігурації в Webex КЦ, що охоплюються в межах організації, є:

Сайт

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

Кожен користувач і команда повинні належати до сайту.

Команда

Група користувачів. Команди використовуються для розподілу взаємодії між агентами за допомогою черг.

Кожна команда повинна належати до сайту.

Агентів

Користувачі, які можуть входити в систему, щоб Agent Desktop і обробляти взаємодії між типами медіафайлів, налаштованими в Webex CC.

Керівники

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

Черга

Черга — це логічна сутність, де можна проводити взаємодії, очікуючи на доступність агентів, які потім спрямовуються до агента.

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

Точка входу

Точка входу - це логічна сутність, що представляє собою точку входу для взаємодій, що надходять Webex КК. Для телефонії це в першу чергу пов'язано з номером телефону, на який надходять дзвінки, а для каналів електронної пошти / обміну повідомленнями точка входу вказує на конфігурацію активу в Webex Connect.

Текти

Потік, пов'язаний з точкою входу (через Routing Strategy), яка визначає кроки, пов'язані з обробкою взаємодій.

Для каналів, не пов'язаних з телефонією (електронна пошта, обмін повідомленнями/соціальні мережі), Flow вибирається як частина конфігурації Об'єкта в Webex Connect.

Контроль доступу для багатопрофільних контакт-центрів

Webex Адміністратори CC можуть налаштовувати профілі користувачів з правами доступу до певних сайтів, команд, черг і точок входу. Крім того, у зв'язку з ієрархічним характером сайтів і команд, після надання доступу до конкретних сайтів користувач може отримати доступ лише до команд або дат, що стосуються команд, що належать до цих сайтів або явно визначеної підмножини таких команд.

Для черг і точок входу вони є глобальними на рівні організації, тому для різних географічних локацій (сайтів, де знаходяться конкретні агенти і команди) можуть бути налаштовані окремі точки входу і черги, а супервайзери / користувачі можуть мати доступ до тих сутностей, які застосовуються для конкретних сайтів.

Рисунок 2 ілюструє ключові сутності конфігурації та профіль користувача, який посилається на ці сутності.

Крім обмеження доступу до цих сутностей, адміністратори Webex КЦ можуть контролювати конкретні можливості/модулі, до яких користувач може отримати доступ в інтерфейсі адміністрування, тим самим маючи користувачів з правами адміністрування/конфігурації на конкретні сутності, а також розділами/можливостями інтерфейсу адміністрування Webex CC.

Настільні вбудовані конектори: CRM-додаток як основний інтерфейс

У цьому режимі роботи агент авторизується в консолі CRM як основний додаток.

Webex CC — це вбудована програма (також звана вбудованою настільною програмою або вбудованим софтфоном), яка в основному використовується для входу в контакт-центр і отримання Webex взаємодії з контакт-центром CC.

Отримавши дзвінок або запит на розмову, інтеграція CRM виконує наступні дії на консолі CRM

• Відкрийте на екрані запис клієнта, прив'язаний до ANI або інших даних, пов'язаних із викликом.

• Публікація метаданих виклику як приміток про активність у записі клієнта

• Дозвольте оператору «Click to Call», натиснувши на Контакт всередині 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-рішення для вищезгаданої інтеграції:

• Відділ продажів

• ServiceNow

• Microsoft Dynamics 365

• Zendesk (Зендеск)

• Freshdesk (Свіжий стіл)

Для отримання більш детальної інформації відвідайте 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 викликаються через макет робочого столу агента CC Webex, а необов'язкові параметри передаються через макет робочого столу у віджет для вмикання та вимикання функцій.

Наприклад, щоб увімкнути віджет дій Salesforce, адміністратор може ввімкнути параметр макета робочого столу sfdcWidgetEnabled на true.

Встановлення пакету

Щоб інтеграція працювала в двох напрямках, в CRM Console потрібно встановити вбудований додаток. Це потрібно для підтримки завантаження програми для настільних комп'ютерів у iFrame.

Всі конектори Desktop Embedded доступні на маркетплейсі CRM.

наприклад

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Установка програми маркетплейс активує необхідні плагіни та імпортує необхідні файли XML в консоль CRM для підтримки звітності записів дзвінків по CRM.

Інтеграція потоку через HTTP-конектори в IVR

Конструктор Webex CC Flow підтримує двонаправлені потоки даних між Webex CC і CRM-системою за допомогою HTTP-конекторів, налаштованих Webex Control Hub і використовуваних на Webex CC Flow.

Вони в основному використовуються для персоналізації голосової взаємодії та індивідуальної маршрутизації в межах IVR.

За замовчуванням Webex CC підтримує Salesforce HTTP Connector на Control Hub. Інші з'єднувачі CRM можна додати як спеціальні з'єднувачі Webex Control Hub.

Для отримання додаткової інформації про HTTP Connectors, відвідайте https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

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

• Salesforce IVR HTTP Connector (вбудований): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

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

Компоненти Voice Edge дозволяють завершувати роботу SIP-транків від операторів клієнтської мережі / ТМЗК, і це вмикається на основі IP-адрес із білого списку, яким дозволено підключатися до периферійних компонентів.

Безпека обчислювальної інфраструктури

Webex екземпляри обчислень CC надаються в AWS, а сервіси працюють як поди в кластері Kubernetes, який має кілька просторів імен, і доступ до кожного простору імен обмежений окремими обліковими даними.

Все забезпечення інфраструктури здійснюється за допомогою коду – без ручних кроків – і жоден з облікових даних не може бути доступний вручну.

Існує центральне сховище облікових даних з певними шляхами, налаштованими для конкретного набору служб / команд, а доступ до самого сховища облікових даних обмежений і налаштований як секрети в системах збірки та розгортання.

Жоден із компонентів/сервісів інфраструктури не піддається безпосередньому впливу за межами AWS VPC, і лише загальнодоступні інтерфейси є API та серверами WebSocket, які контролюються та керуються за допомогою API-шлюзу,

Крім того, розробники використовують певні внутрішні системи та інтерфейси, які використовуються для перегляду журналів, метрик, деталей розгортання, стану збірки та результатів тестування, які захищені за допомогою ролей та груп та інтегровані з внутрішніми системами автентифікації Cisco.

Автентифікація та авторизація інтерфейсів користувача

Всі інтерфейси користувача, що використовуються різними користувачами контакт-центру (агентами, супервізорами, адміністраторами, аналітиками), захищені аутентифікацією на основі Cisco Common Identity на пред'явника (OAuth flows).

Авторизація здійснюється за допомогою ролей користувача, який отримав токен, і областей видимості, призначених токену.

Дані під час передавання

Жоден з інтерфейсів розгорнутого компонента сервісів / інфраструктури не піддається прямому впливу зовнішнього вхідного трафіку.

Вибрані сервіси з http API відкривають ці інтерфейси через шлюз, і всі вхідні https (включаючи WebSocket) завершуються в ALB, а внутрішній трафік через http спрямовується до служб.

Всі вихідні взаємодії здійснюються через https / TLS (для протоколів, відмінних від http).

Усередині VPC внутрішній зв'язок між службами – через протокол http / користувальницької TCP – здійснюється через звичайний TCP сокет.

Дані в стані спокою

Усі дані, які зберігаються, шифруються на рівні зберігання. Крім того, ті сховища даних, які знаходяться за межами VPC, захищені, а контроль доступу та авторизація з обліковими даними надійно зберігаються та керуються в секретному сховищі.

На малюнку 1 показана модель потоку даних і безпеки як для транзиту, так і в стані спокою.

Ідентифікаційні дані кінцевого користувача

Webex CC Flow, який є програмним контролером для обробки взаємодій, може використовуватися для збору даних користувача, які можуть бути призначені змінним потоку, спеціально позначеним як «Містить конфіденційні дані». Значення для таких даних зашифровані, і жодні служби на шляху передачі даних не матимуть доступу до цих даних.

Крім того, такі дані ніколи не зберігаються Webex сховищі даних звітності CC, а інфраструктура журналів/повідомлень матиме зашифровані дані, а чіткі текстові дані не зберігаються ніде в межах Webex CC.

Ідентифікаційні дані агента/супервайзера контакт-центру

Дані, пов'язані з користувачами контакт-центру, редагуються в журналах, але доступні для аналізу та візуалізації даних у сховищі даних Webex CC.

Фактори масштабу

Для Webex КЦ факторами, що впливають на шкалу, є:

• Одночасна кількість агентів, які увійшли в систему

• Одночасна кількість виконуваних взаємодій

  • Дії, виконані під час цих взаємодій

• Одночасна кількість дій, які виконують супервізори/агенти, поза обробкою взаємодій

• Обсяг згенерованих і збережених даних

Архітектурні аспекти, що сприяють масштабуванню

Принципи, на основі яких будується та проектується Webex CC, дозволяють рішенню динамічно масштабуватися за потреби в межах, передбачених інфраструктурою, наданою для різних сервісів та компонентів платформи.

Архітектура, керована подіями

Сервіси в Webex CC обмінюються даними за допомогою повідомлень, і критичні потоки обробки повідомлень не передбачають жодних блокуючих операцій вводу-виводу, а стан, необхідний для обробки повідомлень, локалізується для екземпляра служби, яка обробляє повідомлення.

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

Сервіси без стану забезпечують еластичність, легко додаючи або видаляючи додаткові екземпляри служб. Є певні сервіси, які за своєю суттю є державними, і ті, що мають екстерналізоване сховище станів, а інфраструктура також підтримує динамічні зміни кількості екземплярів таких сервісів з автоматичним перебалансуванням/перенесенням стану/локалізацією стану до інстансу, який потребує стану.

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

Усі сервіси працюють у Kubernetes та інфраструктура, також відома як вузли Kubernetes, автоматично масштабуються залежно від використання, і це дозволяє динамічно додавати більше обчислювальних вузлів до максимально високого порогу, який попередньо налаштований.

Проекція навантаження та регулярна валідація

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

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

Телефонія

Для телефонії обробка вхідних голосових викликів визначається тим, як дзвінок надійшов до контакт-центру (див. Механізми проникнення нижче) і Webex CC Flow, пов'язаним із точкою входу.

На дзвінок приходить відповідь, а подальші дії виконуються відповідно до визначення CC Flow Webex – це програмне представлення дій, які потрібно виконати під час обробки виклику або до постановки в чергу та маршрутизації до оператора, або сам Flow може обробляти виклик без передачі оператору.

Конструктор ланцюжків у Webex CC дозволяє розробникам визначати потік і призначати його точці входу, через яку надходить виклик Webex CC.

Ці сутності конфігурації та їх використання описано в розділі Сутності конфігурації.

Більш детальну інформацію про Flow Builder можна знайти в наступному розділі IVR Система.

Електронна пошта та обмін повідомленнями

З точки зору Webex CC, Webex Connect надає можливості входу та виходу для всіх цифрових каналів - електронної пошти, каналів обміну повідомленнями, які кінцеві користувачі можуть використовувати для контакт-центру.

Webex Підключіть потік

• Вирішує обробку таких взаємодій, доки взаємодії не будуть поставлені в чергу та спрямовані до операторів. Це включає автоматичну обробку та обробку ботів для всіх форм обміну повідомленнями та взаємодії електронною поштою.

• Застосовує бізнес-логіку до вхідної взаємодії.

• Обробляє контакт перед чергою.

• Flow сам може обробляти взаємодію без передачі живому агенту.

Канали обміну повідомленнями, які підтримує Webex CC:

• Web App / Чат у мобільному додатку

• WhatsApp

• Facebook Messenger

• SMS

Канали електронної пошти, які підтримує Webex CC:

• Gmail

• Офіс 365

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

У цьому розділі розглядаються механізми, за допомогою яких взаємодія може увійти Webex КК. Залежно від типу середовища механізми, за допомогою яких взаємодія досягає Webex КК, різні.

Наприклад, у телефонії існує фізична інфраструктура, необхідна для підключення до ТМЗК, конфігурації телефонних номерів та маршрутизації дзвінків до Webex CC.

Для електронної пошти / каналів обміну повідомленнями конфігурація вхідних повідомлень повинна бути виконана в Webex Connect, і вона включає підготовку електронної пошти / облікового запису обміну повідомленнями та Webex конфігурацію потоку підключення.

Вхідний голосовий зв'язок

Для голосових дзвінків типовим сценарієм є те, що користувачі набирають номер телефону ТМЗК, який потім підключається до контакт-центру. З точки зору проникнення, для цього потрібен механізм для маршрутизації викликів з ТМЗК Webex CC.

На наступному малюнку показано, як відбувається прийом голосового дзвінка в Webex CC.

Послуги голосового зв'язку в Webex CC здійснюють керування викликами третьої сторони за допомогою SIP і відповідають на вхідний дзвінок, а також виконують операції з передачі, конференцій та інших операцій керування викликами.

Логічною точкою входу для викликів у Webex КЦ є сутність конфігурації з іменем 'Entrypoint'. Для передавання голосу ключовою конфігурацією точки входу є пов'язаний з нею номер телефону, який зазвичай є дійсним номером телефону ТМЗК, отриманим від вибраного провайдера ТМЗК.

Це дозволяє виявляти вхідні дзвінки на телефонному номері, пов'язувати дзвінок з точкою входу і використовувати інші параметри конфігурації точки входу для обробки дзвінка відповідно до Webex визначення CC Flow, яке повинно бути запущено для взаємодії.

Примітка.

Для отримання більш детальної інформації про варіанти підключення через ТМЗК відвідайте 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 SBC, що забезпечують високу доступність, і можна додати більше контролерів сеансу для масштабування одночасних обсягів викликів, які будуть підтримуватися.

Максимальна кількість одночасних викликів, які може обробляти VPOP, залежить від кількості запущених контролерів сеансу та викликів, які надсилаються.

Для географічної надмірності підтримується сітка 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 КЦ і запускає Webex потік СС, пов'язаний із точкою входу.

Webex CC Flow Builder надає програмні конструкції/оператори та функціональні блоки, які називаються діями, щоб адміністратори або будь-хто, хто розробляє та реалізує логіку IVR, могли об'єднати ці будівельні блоки та створити визначення Flow.

Програмні конструкції, які підтримує Flow:

• Змінні оголошення та налаштування – стан, пов'язаний з виконанням потоку

  • Вирази Pebble для встановлення значень змінних

• Умовні перевірки

• Циклічність – використання умовних операторів та Go To (можливість об'єднувати дії в ланцюжок)

• Виклик REST API

• Аналіз даних – JSON, TOML XML зазвичай використовується для аналізу API відповіді.

• Композиторська діяльність

Репрезентативним набором заходів, які пропонує Flow, є: Відтворювати повідомлення Збір даних користувачів Переадресація дзвінка на інший пункт призначення або номер телефону Надішліть дзвінок віртуальному агенту Поставте виклик у чергу, щоб на нього відповів оператор.

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

Кожен екземпляр виконання ланцюжка забезпечує ізольоване середовище для даних/станів, пов'язаних з потоком і там викликом.

Протягом усього життєвого циклу дзвінка 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 Control Hub.

Після того, як дзвінок з'єднано з віртуальним агентом, він надає користувачеві розмовний IVR, і дія завершується або припиненням дзвінка, або переходом виклику до оператора.

У разі ескалації потік можна налаштувати так, щоб він ставив виклик у чергу, на який потім відповідає оператор.

Вхідні цифрові взаємодії

Для електронної пошти та каналу обміну повідомленнями вхідних взаємодій Webex CC використовує Webex Connect для ініціалізації активів, flow для обробки вхідних взаємодій, а потім спрямовує взаємодію до Webex CC, коли потік Webex Connect явно ставить взаємодію в чергу, щоб її міг обробити агент.

Наступний малюнок ілюструє взаємодію електронної пошти та обміну повідомленнями в Webex CC.

Інтеграція віртуальних агентів / ботів

Для електронної пошти та обміну повідомленнями/взаємодії з соціальними каналами обробки віртуального агента/бота налаштовуються в ланцюжку Webex Connect.

Як і у випадку з Virtual Agents for Voice, якщо обробка BOT закінчується ескалацією в результаті, то взаємодія ставиться в чергу і спрямовується до агента.

Підбір агента

Черги в Webex КЦ підтримують наступні алгоритми вибору агентів:

• Найдовша доступна маршрутизація агентів

• Кваліфікована маршрутизація

  • Найдовший доступний агент (LAA)

  • Найкращий доступний агент (BAA)

Агенти пов'язані з чергами через Teams.

Черзі можна призначити кілька груп розподілу викликів (при цьому кожна група має одну або кілька команд), послідовно з налаштованим очікуванням додавання групи розподілу викликів до черги, щоб простір пошуку відповідного агента розширювався за рахунок додаткових груп розподілу викликів з плином часу.

Для маршрутизації на основі навичок серед агентів, пов'язаних із чергою, вибирається агент на основі конфігурації LAA або BAA.

Додаткові можливості для голосу/телефонії

Маршрутизація на основі агентів (тільки для каналів голосового зв'язку/телефонії)

Webex CC Flow, використовуючи активність QueueToAgent, може спрямовувати взаємодії безпосередньо до обраного агента на основі ідентифікатора агента.

Якщо агент недоступний для обробки взаємодій, взаємодію можна припаркувати в певній черзі агента, чекаючи, поки агент стане доступним

Розширена інформація про чергу

Webex CC Flow, використовуючи активність GetQueueInfo, може отримувати інформацію в режимі реального часу для черги, як-от Position in Queue (PIQ), Estimate Wait Time (EWT), кількість агентів, доступних у черзі, і може використовуватися для прийняття рішення про те, чи ставити контакт у чергу чи ні.

Зворотній дзвінок з люб'язності

Webex CC Flow, використовуючи активність Callback, дозволяє клієнту відключитися від дзвінка, зберігаючи позицію в черзі, і отримати зворотний дзвінок, коли віртуальна взаємодія в черзі спрямовується до оператора.

Обробка переливу

Webex CC підтримує обробку переповнень за допомогою Capacity Based Teams (CBT).

КПТ схожа на звичайну команду з потенціалом і пов'язаним з ним зовнішнім DN, який обслуговує цю потужність. Його можна налаштувати разом з іншими командами в циклах розподілу викликів черги.

Зазвичай, цей параметр налаштовується як останній цикл так, щоб він діяв як переповнення, якщо оператор недоступний, навіть після того, як усі налаштовані групи розподілу викликів не змогли знайти доступного агента-відповідника для обробки взаємодії.

Agent Desktop Операційна діяльність

Коли агент входить Webex Agent Desktop CC, він вказує номер телефону, до якого можна підключити вхідні дзвінки оператору. Це може бути телефон ТМЗК, мобільний телефон або розширення, якщо Агент є користувачем Cisco Webex Calling.

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

Залежно від типу взаємодії, яку обробляє агент, віджети у стільниці агента надають можливість виконувати певні дії з керування мультимедіа.

Наприклад, після відповіді на дзвінок оператор може виконати наступні операції, пов'язані з викликом.

• Перевести дзвінок на утримання

• Ініціюйте консультативний дзвінок і

  • Перевести дзвінок на інший номер телефону (скажімо, номер телефону агента) / Точка входу

  • Зв'язатися з іншим агентом на дзвінок

• Перевести виклик в іншу чергу

• Завершіть дзвінок

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

Архітектура робочого столу

Agent desktop — це односторінковий додаток на основі мікроінтерфейсу, який розміщує віджети, побудовані на основі архітектури веб-компонентів. Усі стандартні/стокові віджети працюють на даних, які витягуються API або механізмами надсилання на стороні сервера.

Це, як правило, асинхронні API, де відповідь на виклик надходить на робочий стіл через з'єднання WebSocket.

Webex CC Agent Desktop автентифікує користувачів за допомогою Cisco Common Identity (CI), і токен передається всім API викликам. Для користувацьких віджетів також, на основі моделі автентифікації, він забезпечує єдиний вхід агентам, якщо модель автентифікації користувацького віджета інтегрована з CI.

Як тільки агент стає частиною взаємодії, всі оновлення цього стану взаємодії або пов'язаних з ним даних також надсилаються на робочий стіл через з'єднання WebSocket.

Стійкість робочого столу до підключення та затримки

Асинхронний API та надсилання на стороні сервера дозволяє масштабувати та виявляти будь-яку втрату з'єднання з інтерфейсом WebSocket, а робочий стіл намагається повторно підключитися та повторно увійти в систему.

На наступному малюнку показана архітектура робочого столу агента в Webex CC.

Онбординг клієнтів

Webex Control Hub — це основний інтерфейс, який використовується партнерами та клієнтами для реєстрації клієнтів і ввімкнення або налаштування функцій.

Після того, як функції організації та контакт-центру будуть підготовлені в Control Hub, він запустить робочий процес у Webex CC, який виконує решту кроків у забезпеченні всіх можливостей контакт-центру відповідно до пропозицій, обраних клієнтом.

Все ініціалізацію контакт-центру здійснюється за допомогою механізму робочих процесів BPM, який забезпечує декларативний спосіб визначення необхідних кроків, робить усі етапи ініціалізації стійкими до збоїв і забезпечує цілісність даних.

На наступному малюнку показаний робочий процес ініціалізації в Webex CC.

Сутності конфігурації

Ключовими сутностями конфігурації в Webex КЦ, що охоплюються в межах організації, є:

Сайт

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

Кожен користувач і команда повинні належати до сайту.

Команда

Група користувачів. Команди використовуються для розподілу взаємодії між агентами за допомогою черг.

Кожна команда повинна належати до сайту.

Агентів

Користувачі, які можуть входити в систему, щоб Agent Desktop і обробляти взаємодії між типами медіафайлів, налаштованими в Webex CC.

Керівники

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

Черга

Черга — це логічна сутність, де можна проводити взаємодії, очікуючи на доступність агентів, які потім спрямовуються до агента.

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

Точка входу

Точка входу - це логічна сутність, що представляє собою точку входу для взаємодій, що надходять Webex КК. Для телефонії це в першу чергу пов'язано з номером телефону, на який надходять дзвінки, а для каналів електронної пошти / обміну повідомленнями точка входу вказує на конфігурацію активу в Webex Connect.

Текти

Потік, пов'язаний з точкою входу (через Routing Strategy), яка визначає кроки, пов'язані з обробкою взаємодій.

Для каналів, не пов'язаних з телефонією (електронна пошта, обмін повідомленнями/соціальні мережі), Flow вибирається як частина конфігурації Об'єкта в Webex Connect.

Контроль доступу для багатопрофільних контакт-центрів

Webex Адміністратори CC можуть налаштовувати профілі користувачів з правами доступу до певних сайтів, команд, черг і точок входу. Крім того, у зв'язку з ієрархічним характером сайтів і команд, після надання доступу до конкретних сайтів користувач може отримати доступ лише до команд або дат, що стосуються команд, що належать до цих сайтів або явно визначеної підмножини таких команд.

Для черг і точок входу вони є глобальними на рівні організації, тому для різних географічних локацій (сайтів, де знаходяться конкретні агенти і команди) можуть бути налаштовані окремі точки входу і черги, а супервайзери / користувачі можуть мати доступ до тих сутностей, які застосовуються для конкретних сайтів.

На наступному малюнку показані основні сутності конфігурації та профіль користувача, які посилаються на ці сутності.

Крім обмеження доступу до цих сутностей, адміністратори Webex КЦ можуть контролювати конкретні можливості/модулі, до яких користувач може отримати доступ в інтерфейсі адміністрування, тим самим маючи користувачів з правами адміністрування/конфігурації на конкретні сутності, а також розділами/можливостями інтерфейсу адміністрування Webex CC.

Настільні вбудовані конектори: CRM-додаток як основний інтерфейс

У цьому режимі роботи агент авторизується в консолі CRM як основний додаток.

Webex CC — це вбудована програма (також звана вбудованою настільною програмою або вбудованим софтфоном), яка в основному використовується для входу в контакт-центр і отримання Webex взаємодії з контакт-центром CC.

Отримавши дзвінок або запит на розмову, інтеграція CRM виконує наступні дії на консолі CRM

• Відкрийте на екрані запис клієнта, прив'язаний до ANI або інших даних, пов'язаних із викликом.

• Публікація метаданих виклику як приміток про активність у записі клієнта

• Дозвольте оператору «Click to Call», натиснувши на Контакт всередині 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-рішення для вищезгаданої інтеграції:

• Відділ продажів

• ServiceNow

• Microsoft Dynamics 365

• Zendesk (Зендеск)

• Freshdesk (Свіжий стіл)

Для отримання більш детальної інформації відвідайте 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 викликаються через макет робочого столу агента CC Webex, а необов'язкові параметри передаються через макет робочого столу у віджет для вмикання та вимикання функцій.

Наприклад, щоб увімкнути віджет дій Salesforce, адміністратор може ввімкнути параметр макета робочого столу sfdcWidgetEnabled на true.

Встановлення пакету

Щоб інтеграція працювала в двох напрямках, в CRM Console потрібно встановити вбудований додаток. Це потрібно для підтримки завантаження програми для настільних комп'ютерів у iFrame.

Всі конектори Desktop Embedded доступні на маркетплейсі CRM.

наприклад

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Установка програми маркетплейс активує необхідні плагіни та імпортує необхідні файли XML в консоль CRM для підтримки звітності записів дзвінків по CRM.

Інтеграція потоку через HTTP-конектори в IVR

Конструктор Webex CC Flow підтримує двонаправлені потоки даних між Webex CC і CRM-системою за допомогою HTTP-конекторів, налаштованих Webex Control Hub і використовуваних на Webex CC Flow.

Вони в основному використовуються для персоналізації голосової взаємодії та індивідуальної маршрутизації в межах IVR.

За замовчуванням Webex CC підтримує Salesforce HTTP Connector на Control Hub. Інші з'єднувачі CRM можна додати як спеціальні з'єднувачі Webex Control Hub.

Для отримання додаткової інформації про HTTP Connectors, відвідайте https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

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

• Salesforce IVR HTTP Connector (вбудований): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

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

Компоненти Voice Edge дозволяють завершувати роботу SIP-транків від операторів клієнтської мережі / ТМЗК, і це вмикається на основі IP-адрес із білого списку, яким дозволено підключатися до периферійних компонентів.

Безпека обчислювальної інфраструктури

Webex екземпляри обчислень CC надаються в AWS, а сервіси працюють як поди в кластері Kubernetes, який має кілька просторів імен, і доступ до кожного простору імен обмежений окремими обліковими даними.

Все забезпечення інфраструктури здійснюється за допомогою коду – без ручних кроків – і жоден з облікових даних не може бути доступний вручну.

Існує центральне сховище облікових даних з певними шляхами, налаштованими для конкретного набору служб / команд, а доступ до самого сховища облікових даних обмежений і налаштований як секрети в системах збірки та розгортання.

Жоден із компонентів/сервісів інфраструктури не піддається безпосередньому впливу за межами AWS VPC, і лише загальнодоступні інтерфейси є API та серверами WebSocket, які контролюються та керуються за допомогою API-шлюзу,

Крім того, розробники використовують певні внутрішні системи та інтерфейси, які використовуються для перегляду журналів, метрик, деталей розгортання, стану збірки та результатів тестування, які захищені за допомогою ролей та груп та інтегровані з внутрішніми системами автентифікації Cisco.

Автентифікація та авторизація інтерфейсів користувача

Всі інтерфейси користувача, що використовуються різними користувачами контакт-центру (агентами, супервізорами, адміністраторами, аналітиками), захищені аутентифікацією на основі Cisco Common Identity на пред'явника (OAuth flows).

Авторизація здійснюється за допомогою ролей користувача, який отримав токен, і областей видимості, призначених токену.

Дані під час передавання

Жоден з інтерфейсів розгорнутого компонента сервісів / інфраструктури не піддається прямому впливу зовнішнього вхідного трафіку.

Вибрані сервіси з http API відкривають ці інтерфейси через шлюз, і всі вхідні https (включаючи WebSocket) завершуються в ALB, а внутрішній трафік через http спрямовується до служб.

Всі вихідні взаємодії здійснюються через https / TLS (для протоколів, відмінних від http).

Усередині VPC внутрішній зв'язок між службами – через протокол http / користувальницької TCP – здійснюється через звичайний TCP сокет.

Дані в стані спокою

Усі дані, які зберігаються, шифруються на рівні зберігання. Крім того, ті сховища даних, які знаходяться за межами VPC, захищені, а контроль доступу та авторизація з обліковими даними надійно зберігаються та керуються в секретному сховищі.

Наступний малюнок ілюструє потік даних і модель безпеки як для транзиту, так і в стані спокою.

Ідентифікаційні дані кінцевого користувача

Webex CC Flow, який є програмним контролером для обробки взаємодій, може використовуватися для збору даних користувача, які можуть бути призначені змінним потоку, спеціально позначеним як «Містить конфіденційні дані». Значення для таких даних зашифровані, і жодні служби на шляху передачі даних не матимуть доступу до цих даних.

Крім того, такі дані ніколи не зберігаються Webex сховищі даних звітності CC, а інфраструктура журналів/повідомлень матиме зашифровані дані, а чіткі текстові дані не зберігаються ніде в межах Webex CC.

Ідентифікаційні дані агента/супервайзера контакт-центру

Дані, пов'язані з користувачами контакт-центру, редагуються в журналах, але доступні для аналізу та візуалізації даних у сховищі даних Webex CC.

Фактори масштабу

Для Webex КЦ факторами, що впливають на шкалу, є:

• Одночасна кількість агентів, які увійшли в систему

• Одночасна кількість виконуваних взаємодій

  • Дії, виконані під час цих взаємодій

• Одночасна кількість дій, які виконують супервізори/агенти, поза обробкою взаємодій

• Обсяг згенерованих і збережених даних

Архітектурні аспекти, що сприяють масштабуванню

Принципи, на основі яких будується та проектується Webex CC, дозволяють рішенню динамічно масштабуватися за потреби в межах, передбачених інфраструктурою, наданою для різних сервісів та компонентів платформи.

Архітектура, керована подіями

Сервіси в Webex CC обмінюються даними за допомогою повідомлень, і критичні потоки обробки повідомлень не передбачають жодних блокуючих операцій вводу-виводу, а стан, необхідний для обробки повідомлень, локалізується для екземпляра служби, яка обробляє повідомлення.

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

Сервіси без стану забезпечують еластичність, легко додаючи або видаляючи додаткові екземпляри служб. Є певні сервіси, які за своєю суттю є державними, і ті, що мають екстерналізоване сховище станів, а інфраструктура також підтримує динамічні зміни кількості екземплярів таких сервісів з автоматичним перебалансуванням/перенесенням стану/локалізацією стану до інстансу, який потребує стану.

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

Усі сервіси працюють у Kubernetes та інфраструктура, також відома як вузли Kubernetes, автоматично масштабуються залежно від використання, і це дозволяє динамічно додавати більше обчислювальних вузлів до максимально високого порогу, який попередньо налаштований.

Проекція навантаження та регулярна валідація

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

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

Телефонія

Для телефонії обробка вхідних голосових викликів визначається тим, як дзвінок надійшов до контакт-центру (див. Механізми проникнення нижче) і Webex CC Flow, пов'язаним із точкою входу.

На дзвінок приходить відповідь, а подальші дії виконуються відповідно до визначення CC Flow Webex – це програмне представлення дій, які потрібно виконати під час обробки виклику або до постановки в чергу та маршрутизації до оператора, або сам Flow може обробляти виклик без передачі оператору.

Конструктор ланцюжків у Webex CC дозволяє розробникам визначати потік і призначати його точці входу, через яку надходить виклик Webex CC.

Ці сутності конфігурації та їх використання описано в розділі Сутності конфігурації.

Більш детальну інформацію про Flow Builder можна знайти в наступному розділі IVR Система.

Електронна пошта та обмін повідомленнями

З точки зору Webex CC, Webex Connect надає можливості входу та виходу для всіх цифрових каналів - електронної пошти, каналів обміну повідомленнями, які кінцеві користувачі можуть використовувати для контакт-центру.

Webex Підключіть потік

• Вирішує обробку таких взаємодій, доки взаємодії не будуть поставлені в чергу та спрямовані до операторів. Це включає автоматичну обробку та обробку ботів для всіх форм обміну повідомленнями та взаємодії електронною поштою.

• Застосовує бізнес-логіку до вхідної взаємодії.

• Обробляє контакт перед чергою.

• Flow сам може обробляти взаємодію без передачі живому агенту.

Канали обміну повідомленнями, які підтримує Webex CC:

• Web App / Чат у мобільному додатку

• WhatsApp

• Facebook Messenger

• SMS

Канали електронної пошти, які підтримує Webex CC:

• Gmail

• Офіс 365

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

У цьому розділі розглядаються механізми, за допомогою яких взаємодія може увійти Webex КК. Залежно від типу середовища механізми, за допомогою яких взаємодія досягає Webex КК, різні.

Наприклад, у телефонії існує фізична інфраструктура, необхідна для підключення до ТМЗК, конфігурації телефонних номерів та маршрутизації дзвінків до Webex CC.

Для електронної пошти / каналів обміну повідомленнями конфігурація вхідних повідомлень повинна бути виконана в Webex Connect, і вона включає підготовку електронної пошти / облікового запису обміну повідомленнями та Webex конфігурацію потоку підключення.

Вхідний голосовий зв'язок

Для голосових дзвінків типовим сценарієм є те, що користувачі набирають номер телефону ТМЗК, який потім підключається до контакт-центру. З точки зору проникнення, для цього потрібен механізм для маршрутизації викликів з ТМЗК Webex CC.

На наступному малюнку показано, як відбувається прийом голосового дзвінка в Webex CC.

Послуги голосового зв'язку в Webex CC здійснюють керування викликами третьої сторони за допомогою SIP і відповідають на вхідний дзвінок, а також виконують операції з передачі, конференцій та інших операцій керування викликами.

Логічною точкою входу для викликів у Webex КЦ є сутність конфігурації з іменем 'Entrypoint'. Для передавання голосу ключовою конфігурацією точки входу є пов'язаний з нею номер телефону, який зазвичай є дійсним номером телефону ТМЗК, отриманим від вибраного провайдера ТМЗК.

Це дозволяє виявляти вхідні дзвінки на телефонному номері, пов'язувати дзвінок з точкою входу і використовувати інші параметри конфігурації точки входу для обробки дзвінка відповідно до Webex визначення CC Flow, яке повинно бути запущено для взаємодії.

Примітка.

Для отримання більш детальної інформації про варіанти підключення через ТМЗК відвідайте 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 SBC, що забезпечують високу доступність, і можна додати більше контролерів сеансу для масштабування одночасних обсягів викликів, які будуть підтримуватися.

Максимальна кількість одночасних викликів, які може обробляти VPOP, залежить від кількості запущених контролерів сеансу та викликів, які надсилаються.

Для географічної надмірності підтримується сітка 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 КЦ і запускає Webex потік СС, пов'язаний із точкою входу.

Webex CC Flow Builder надає програмні конструкції/оператори та функціональні блоки, які називаються діями, щоб адміністратори або будь-хто, хто розробляє та реалізує логіку IVR, могли об'єднати ці будівельні блоки та створити визначення Flow.

Програмні конструкції, які підтримує Flow:

• Змінні оголошення та налаштування – стан, пов'язаний з виконанням потоку

  • Вирази Pebble для встановлення значень змінних

• Умовні перевірки

• Циклічність – використання умовних операторів та Go To (можливість об'єднувати дії в ланцюжок)

• Виклик REST API

• Аналіз даних – JSON, TOML XML зазвичай використовується для аналізу API відповіді.

• Композиторська діяльність

Репрезентативним набором заходів, які пропонує Flow, є: Відтворювати повідомлення Збір даних користувачів Переадресація дзвінка на інший пункт призначення або номер телефону Надішліть дзвінок віртуальному агенту Поставте виклик у чергу, щоб на нього відповів оператор.

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

Кожен екземпляр виконання ланцюжка забезпечує ізольоване середовище для даних/станів, пов'язаних з потоком і там викликом.

Протягом усього життєвого циклу дзвінка 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 Control Hub.

Після того, як дзвінок з'єднано з віртуальним агентом, він надає користувачеві розмовний IVR, і дія завершується або припиненням дзвінка, або переходом виклику до оператора.

У разі ескалації потік можна налаштувати так, щоб він ставив виклик у чергу, на який потім відповідає оператор.

Вхідні цифрові взаємодії

Для електронної пошти та каналу обміну повідомленнями вхідних взаємодій Webex CC використовує Webex Connect для ініціалізації активів, flow для обробки вхідних взаємодій, а потім спрямовує взаємодію до Webex CC, коли потік Webex Connect явно ставить взаємодію в чергу, щоб її міг обробити агент.

Наступний малюнок ілюструє взаємодію електронної пошти та обміну повідомленнями в Webex CC.

Інтеграція віртуальних агентів / ботів

Для електронної пошти та обміну повідомленнями/взаємодії з соціальними каналами обробки віртуального агента/бота налаштовуються в ланцюжку Webex Connect.

Як і у випадку з Virtual Agents for Voice, якщо обробка BOT закінчується ескалацією в результаті, то взаємодія ставиться в чергу і спрямовується до агента.

Підбір агента

Черги в Webex КЦ підтримують наступні алгоритми вибору агентів:

• Найдовша доступна маршрутизація агентів

• Кваліфікована маршрутизація

  • Найдовший доступний агент (LAA)

  • Найкращий доступний агент (BAA)

Агенти пов'язані з чергами через Teams.

Черзі можна призначити кілька груп розподілу викликів (при цьому кожна група має одну або кілька команд), послідовно з налаштованим очікуванням додавання групи розподілу викликів до черги, щоб простір пошуку відповідного агента розширювався за рахунок додаткових груп розподілу викликів з плином часу.

Для маршрутизації на основі навичок серед агентів, пов'язаних із чергою, вибирається агент на основі конфігурації LAA або BAA.

Додаткові можливості для голосу/телефонії

Маршрутизація на основі агентів (тільки для каналів голосового зв'язку/телефонії)

Webex CC Flow, використовуючи активність QueueToAgent, може спрямовувати взаємодії безпосередньо до обраного агента на основі ідентифікатора агента.

Якщо агент недоступний для обробки взаємодій, взаємодію можна припаркувати в певній черзі агента, чекаючи, поки агент стане доступним

Розширена інформація про чергу

Webex CC Flow, використовуючи активність GetQueueInfo, може отримувати інформацію в режимі реального часу для черги, як-от Position in Queue (PIQ), Estimate Wait Time (EWT), кількість агентів, доступних у черзі, і може використовуватися для прийняття рішення про те, чи ставити контакт у чергу чи ні.

Зворотній дзвінок з люб'язності

Webex CC Flow, використовуючи активність Callback, дозволяє клієнту відключитися від дзвінка, зберігаючи позицію в черзі, і отримати зворотний дзвінок, коли віртуальна взаємодія в черзі спрямовується до оператора.

Обробка переливу

Webex CC підтримує обробку переповнень за допомогою Capacity Based Teams (CBT).

КПТ схожа на звичайну команду з потенціалом і пов'язаним з ним зовнішнім DN, який обслуговує цю потужність. Його можна налаштувати разом з іншими командами в циклах розподілу викликів черги.

Зазвичай, цей параметр налаштовується як останній цикл так, щоб він діяв як переповнення, якщо оператор недоступний, навіть після того, як усі налаштовані групи розподілу викликів не змогли знайти доступного агента-відповідника для обробки взаємодії.

Agent Desktop Операційна діяльність

Коли агент входить Webex Agent Desktop CC, він вказує номер телефону, до якого можна підключити вхідні дзвінки оператору. Це може бути телефон ТМЗК, мобільний телефон або розширення, якщо Агент є користувачем Cisco Webex Calling.

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

Залежно від типу взаємодії, яку обробляє агент, віджети у стільниці агента надають можливість виконувати певні дії з керування мультимедіа.

Наприклад, після відповіді на дзвінок оператор може виконати наступні операції, пов'язані з викликом.

• Перевести дзвінок на утримання

• Ініціюйте консультативний дзвінок і

  • Перевести дзвінок на інший номер телефону (скажімо, номер телефону агента) / Точка входу

  • Зв'язатися з іншим агентом на дзвінок

• Перевести виклик в іншу чергу

• Завершіть дзвінок

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

Архітектура робочого столу

Agent desktop — це односторінковий додаток на основі мікроінтерфейсу, який розміщує віджети, побудовані на основі архітектури веб-компонентів. Усі стандартні/стокові віджети працюють на даних, які витягуються API або механізмами надсилання на стороні сервера.

Це, як правило, асинхронні API, де відповідь на виклик надходить на робочий стіл через з'єднання WebSocket.

Webex CC Agent Desktop автентифікує користувачів за допомогою Cisco Common Identity (CI), і токен передається всім API викликам. Для користувацьких віджетів також, на основі моделі автентифікації, він забезпечує єдиний вхід агентам, якщо модель автентифікації користувацького віджета інтегрована з CI.

Як тільки агент стає частиною взаємодії, всі оновлення цього стану взаємодії або пов'язаних з ним даних також надсилаються на робочий стіл через з'єднання WebSocket.

Стійкість робочого столу до підключення та затримки

Асинхронний API та надсилання на стороні сервера дозволяє масштабувати та виявляти будь-яку втрату з'єднання з інтерфейсом WebSocket, а робочий стіл намагається повторно підключитися та повторно увійти в систему.

На наступному малюнку показана архітектура робочого столу агента в Webex CC.

Онбординг клієнтів

Webex Control Hub — це основний інтерфейс, який використовується партнерами та клієнтами для реєстрації клієнтів і ввімкнення або налаштування функцій.

Після того, як функції організації та контакт-центру будуть підготовлені в Control Hub, він запустить робочий процес у Webex CC, який виконує решту кроків у забезпеченні всіх можливостей контакт-центру відповідно до пропозицій, обраних клієнтом.

Все ініціалізацію контакт-центру здійснюється за допомогою механізму робочих процесів BPM, який забезпечує декларативний спосіб визначення необхідних кроків, робить усі етапи ініціалізації стійкими до збоїв і забезпечує цілісність даних.

На наступному малюнку показаний робочий процес ініціалізації в Webex CC.

Сутності конфігурації

Ключовими сутностями конфігурації в Webex КЦ, що охоплюються в межах організації, є:

Сайт

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

Кожен користувач і команда повинні належати до сайту.

Команда

Група користувачів. Команди використовуються для розподілу взаємодії між агентами за допомогою черг.

Кожна команда повинна належати до сайту.

Агентів

Користувачі, які можуть входити в систему, щоб Agent Desktop і обробляти взаємодії між типами медіафайлів, налаштованими в Webex CC.

Керівники

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

Черга

Черга — це логічна сутність, де можна проводити взаємодії, очікуючи на доступність агентів, які потім спрямовуються до агента.

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

Точка входу

Точка входу - це логічна сутність, що представляє собою точку входу для взаємодій, що надходять Webex КК. Для телефонії це в першу чергу пов'язано з номером телефону, на який надходять дзвінки, а для каналів електронної пошти / обміну повідомленнями точка входу вказує на конфігурацію активу в Webex Connect.

Текти

Потік, пов'язаний з точкою входу (через Routing Strategy), яка визначає кроки, пов'язані з обробкою взаємодій.

Для каналів, не пов'язаних з телефонією (електронна пошта, обмін повідомленнями/соціальні мережі), Flow вибирається як частина конфігурації Об'єкта в Webex Connect.

Контроль доступу для багатопрофільних контакт-центрів

Webex Адміністратори CC можуть налаштовувати профілі користувачів з правами доступу до певних сайтів, команд, черг і точок входу. Крім того, у зв'язку з ієрархічним характером сайтів і команд, після надання доступу до конкретних сайтів користувач може отримати доступ лише до команд або дат, що стосуються команд, що належать до цих сайтів або явно визначеної підмножини таких команд.

Для черг і точок входу вони є глобальними на рівні організації, тому для різних географічних локацій (сайтів, де знаходяться конкретні агенти і команди) можуть бути налаштовані окремі точки входу і черги, а супервайзери / користувачі можуть мати доступ до тих сутностей, які застосовуються для конкретних сайтів.

На наступному малюнку показані основні сутності конфігурації та профіль користувача, які посилаються на ці сутності.

Крім обмеження доступу до цих сутностей, адміністратори Webex КЦ можуть контролювати конкретні можливості/модулі, до яких користувач може отримати доступ в інтерфейсі адміністрування, тим самим маючи користувачів з правами адміністрування/конфігурації на конкретні сутності, а також розділами/можливостями інтерфейсу адміністрування Webex CC.

Настільні вбудовані конектори: CRM-додаток як основний інтерфейс

У цьому режимі роботи агент авторизується в консолі CRM як основний додаток.

Webex CC — це вбудована програма (також звана вбудованою настільною програмою або вбудованим софтфоном), яка в основному використовується для входу в контакт-центр і отримання Webex взаємодії з контакт-центром CC.

Отримавши дзвінок або запит на розмову, інтеграція CRM виконує наступні дії на консолі CRM

• Відкрийте на екрані запис клієнта, прив'язаний до ANI або інших даних, пов'язаних із викликом.

• Публікація метаданих виклику як приміток про активність у записі клієнта

• Дозвольте оператору «Click to Call», натиснувши на Контакт всередині 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-рішення для вищезгаданої інтеграції:

• Відділ продажів

• ServiceNow

• Microsoft Dynamics 365

• Zendesk (Зендеск)

• Freshdesk (Свіжий стіл)

Для отримання більш детальної інформації відвідайте 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 викликаються через макет робочого столу агента CC Webex, а необов'язкові параметри передаються через макет робочого столу у віджет для вмикання та вимикання функцій.

Наприклад, щоб увімкнути віджет дій Salesforce, адміністратор може ввімкнути параметр макета робочого столу sfdcWidgetEnabled на true.

Встановлення пакету

Щоб інтеграція працювала в двох напрямках, в CRM Console потрібно встановити вбудований додаток. Це потрібно для підтримки завантаження програми для настільних комп'ютерів у iFrame.

Всі конектори Desktop Embedded доступні на маркетплейсі CRM.

наприклад

ServiceNow: https://store.servicenow.com/sn_appstore_store.do#!/store/application/6c8e2a4edbc73410e1c75e25ca961947/1.0.5?

Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/

Установка програми маркетплейс активує необхідні плагіни та імпортує необхідні файли XML в консоль CRM для підтримки звітності записів дзвінків по CRM.

Інтеграція потоку через HTTP-конектори в IVR

Конструктор Webex CC Flow підтримує двонаправлені потоки даних між Webex CC і CRM-системою за допомогою HTTP-конекторів, налаштованих Webex Control Hub і використовуваних на Webex CC Flow.

Вони в основному використовуються для персоналізації голосової взаємодії та індивідуальної маршрутизації в межах IVR.

За замовчуванням Webex CC підтримує Salesforce HTTP Connector на Control Hub. Інші з'єднувачі CRM можна додати як спеціальні з'єднувачі Webex Control Hub.

Для отримання додаткової інформації про HTTP Connectors, відвідайте https://github.com/CiscoDevNet/webex-contact-center-crm-integrations.

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

• Salesforce IVR HTTP Connector (вбудований): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector

• Zendesk IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector

• ServiceNow IVR HTTP Connector (Custom): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector

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

Компоненти Voice Edge дозволяють завершувати роботу SIP-транків від операторів клієнтської мережі / ТМЗК, і це вмикається на основі IP-адрес із білого списку, яким дозволено підключатися до периферійних компонентів.

Безпека обчислювальної інфраструктури

Webex екземпляри обчислень CC надаються в AWS, а сервіси працюють як поди в кластері Kubernetes, який має кілька просторів імен, і доступ до кожного простору імен обмежений окремими обліковими даними.

Все забезпечення інфраструктури здійснюється за допомогою коду – без ручних кроків – і жоден з облікових даних не може бути доступний вручну.

Існує центральне сховище облікових даних з певними шляхами, налаштованими для конкретного набору служб / команд, а доступ до самого сховища облікових даних обмежений і налаштований як секрети в системах збірки та розгортання.

Жоден із компонентів/сервісів інфраструктури не піддається безпосередньому впливу за межами AWS VPC, і лише загальнодоступні інтерфейси є API та серверами WebSocket, які контролюються та керуються за допомогою API-шлюзу,

Крім того, розробники використовують певні внутрішні системи та інтерфейси, які використовуються для перегляду журналів, метрик, деталей розгортання, стану збірки та результатів тестування, які захищені за допомогою ролей та груп та інтегровані з внутрішніми системами автентифікації Cisco.

Автентифікація та авторизація інтерфейсів користувача

Всі інтерфейси користувача, що використовуються різними користувачами контакт-центру (агентами, супервізорами, адміністраторами, аналітиками), захищені аутентифікацією на основі Cisco Common Identity на пред'явника (OAuth flows).

Авторизація здійснюється за допомогою ролей користувача, який отримав токен, і областей видимості, призначених токену.

Дані під час передавання

Жоден з інтерфейсів розгорнутого компонента сервісів / інфраструктури не піддається прямому впливу зовнішнього вхідного трафіку.

Вибрані сервіси з http API відкривають ці інтерфейси через шлюз, і всі вхідні https (включаючи WebSocket) завершуються в ALB, а внутрішній трафік через http спрямовується до служб.

Всі вихідні взаємодії здійснюються через https / TLS (для протоколів, відмінних від http).

Усередині VPC внутрішній зв'язок між службами – через протокол http / користувальницької TCP – здійснюється через звичайний TCP сокет.

Дані в стані спокою

Усі дані, які зберігаються, шифруються на рівні зберігання. Крім того, ті сховища даних, які знаходяться за межами VPC, захищені, а контроль доступу та авторизація з обліковими даними надійно зберігаються та керуються в секретному сховищі.

Наступний малюнок ілюструє потік даних і модель безпеки як для транзиту, так і в стані спокою.

Ідентифікаційні дані кінцевого користувача

Webex CC Flow, який є програмним контролером для обробки взаємодій, може використовуватися для збору даних користувача, які можуть бути призначені змінним потоку, спеціально позначеним як «Містить конфіденційні дані». Значення для таких даних зашифровані, і жодні служби на шляху передачі даних не матимуть доступу до цих даних.

Крім того, такі дані ніколи не зберігаються Webex сховищі даних звітності CC, а інфраструктура журналів/повідомлень матиме зашифровані дані, а чіткі текстові дані не зберігаються ніде в межах Webex CC.

Ідентифікаційні дані агента/супервайзера контакт-центру

Дані, пов'язані з користувачами контакт-центру, редагуються в журналах, але доступні для аналізу та візуалізації даних у сховищі даних Webex CC.

Фактори масштабу

Для Webex КЦ факторами, що впливають на шкалу, є:

• Одночасна кількість агентів, які увійшли в систему

• Одночасна кількість виконуваних взаємодій

  • Дії, виконані під час цих взаємодій

• Одночасна кількість дій, які виконують супервізори/агенти, поза обробкою взаємодій

• Обсяг згенерованих і збережених даних

Архітектурні аспекти, що сприяють масштабуванню

Принципи, на основі яких будується та проектується Webex CC, дозволяють рішенню динамічно масштабуватися за потреби в межах, передбачених інфраструктурою, наданою для різних сервісів та компонентів платформи.

Архітектура, керована подіями

Сервіси в Webex CC обмінюються даними за допомогою повідомлень, і критичні потоки обробки повідомлень не передбачають жодних блокуючих операцій вводу-виводу, а стан, необхідний для обробки повідомлень, локалізується для екземпляра служби, яка обробляє повідомлення.

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

Сервіси без стану забезпечують еластичність, легко додаючи або видаляючи додаткові екземпляри служб. Є певні сервіси, які за своєю суттю є державними, і ті, що мають екстерналізоване сховище станів, а інфраструктура також підтримує динамічні зміни кількості екземплярів таких сервісів з автоматичним перебалансуванням/перенесенням стану/локалізацією стану до інстансу, який потребує стану.

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

Усі сервіси працюють у Kubernetes та інфраструктура, також відома як вузли Kubernetes, автоматично масштабуються залежно від використання, і це дозволяє динамічно додавати більше обчислювальних вузлів до максимально високого порогу, який попередньо налаштований.

Проекція навантаження та регулярна валідація

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

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