Телефонія

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

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

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

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

Телефонія

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

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

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

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

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

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

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

Webex Connect Flow

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

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

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

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

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

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

• WhatsApp

• Facebook Messenger

• SMS

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

• Gmail

• Офіс 365

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

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

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

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

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

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

На рисунку нижче показано, як ви приймаєте голосові виклики в Webex CC.

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

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

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

Примітка.

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

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 надає дію для передачі взаємодії віртуальному агенту, попередньо налаштовану в Control Hub Webex.

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

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

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

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

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

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

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

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

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

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

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

• Маршрутизація на основі навичок

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agent Desktop Operations

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

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

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

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

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

• Ініціюйте дзвінок та

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

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

• Перевести дзвінок в іншу чергу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сайт

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

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

Команда

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

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

Агентів

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

Керівники

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

Черга

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

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

Точка входу

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

Текти

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

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

Контроль доступу для контакт-центрів, що працюють на кількох сайтах

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

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

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

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

Десктопні вбудовані конектори: додаток CRM як основний інтерфейс

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

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

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

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

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

• Дозвольте оператору «Натисніть, щоб зателефонувати», натиснувши на контакт у CRM та ініціювавши вихідний дзвінок клієнту

• Розміщення записів дзвінків у таблиці звітності CRM для первинної звітності по CRM.

• Забезпечує повну функціональність Agent Desktop та керування дзвінками (вбудована та зменшена версія десктопної програми)

Основним способом інтеграції з CRM є вбудовування програми Webex CC Desktop в окремий iFrame.

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

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

• Webex CC Desktop JS SDK: це JavaScript SDK, який надає Webex CC для реєстрації прослуховувачів подій для дій агента та контактної особи.

• CRM JS SDK: Це пакет SDK клієнта CRM, який застосовується для CRM, який абстрагує виклики API REST з CRM. Наприклад, для salesforce використовується бібліотека CTI JS, надана Salesforce, для виконання дій і прослуховування подій усередині CRM.

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

Webex CC підтримує такі CRM-рішення для вищезазначеної інтеграції:

• Salesforce

• СервісЗараз

• Microsoft Dynamics 365

• Дзендеск

• 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 із вбудованим у програму CRM робочим столом Webex CC.

Безпека

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

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

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

Щоб інтеграція працювала в двох напрямках, на консолі CRM потрібно встановити вбудований додаток. Це передбачено для підтримки завантаження програми для настільних комп'ютерів у 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.

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

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

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

За замовчуванням Webex CC підтримує HTTP-з'єднувач Salesforce на 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-транків від операторів мережі / PSTN клієнта, і це включено на основі IP-адрес з білого списку, яким дозволено підключатися до периферійних компонентів.

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

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

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

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

Жоден з компонентів / сервісів інфраструктури не виставляється безпосередньо за межами AWS VPC, і лише загальнодоступні інтерфейси - це API та WebSocket Servers, які контролюються та керуються за допомогою 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 CC фактори, які впливають на масштаб:

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

• Одночасна кількість взаємодій у процесі

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

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

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

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

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

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

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

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