- 首頁
- /
- 文章
Webex Contact Center 架構
Webex Contact Center 運用雲端型微型服務架構,在所有客戶通道中提供一致的體驗。本文詳述其云端設計,概述功能元件、整合、部署選項、安全性協議和合規注意事項。
Cisco Webex Contact Center(Webex CC)是一種聯絡中心即服務(CCaaS),使組織能夠在整個客戶旅程中實現更智慧、主動和個人化的交互。
Webex CC 是從頭開始構建、設計和開發的,作為雲原生解決方案,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
安全性原生內置於系統的構建和部署方式中,數據在傳輸中和靜態時受到保護,以及 Webex CC 擁有的安全性/合規性認證。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與其他 Cisco Webex 集成,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文檔中的後續部分將擴展上述每個功能 Webex 以及 CC 體系結構如何實現相同的功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆聯繫組織,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如 WhatsApp,Facebook Messenger,Apple Business Chat,來自 Twitter 的直接消息)直接聊天
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化 IVR 系統,用於電話/聊天的虛擬代理,內置可程式設計性以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以提前主動向座席提供數據,是聯絡中心解決方案發展方式的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
圖 1 說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下各節描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)作為使用者與聯絡中心互動的各種管道。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話而言,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的入口機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流定義執行進一步的操作 - CC 流定義是在排隊和路由到代理之前處理呼叫時要執行的操作的程式設計表示形式,或者流本身可以在不轉接到代理的情況下處理呼叫。
Webex CC 中的 Flow Builder 允許開發人員定義流程,並將其指定給通話到達 CC Webex 入口點。
配置實體中介紹了 這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中 介紹 IVR 系統。
電子郵件與訊息
Webex 從 CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以將其用於 Contact Center。
Webex 連接流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息管道包括:
-
Web App / 移動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
Webex 抄送支援的電子郵件管道包括:
-
Gmail
-
辦公室 365
入口機制
本節介紹互動進入 CC Webex 機制。根據媒體類型,互動到達 CC Webex 機制是不同的。
例如,在電話中,需要物理基礎結構預配來啟用 PSTN 連接,配置電話號碼以及將呼叫路由到 Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和 Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到 Webex CC 的機制。
圖 1 說明瞭將語音呼叫攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連通性 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源 IP 位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現 IVR 邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML 通常用於解析 API 回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置 Webex 虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話 IVR 體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到 Webex CC。
圖 2 說明瞭在 Webex CC 中攝取電子郵件和消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
圖 1 說明瞭排隊和路由體系結構。
代理選擇
CC Webex 佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop 作業
當代理登入 Webex CC Agent Desktop 時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為 Cisco Webex Calling 使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop 使用 Cisco Common Identity(CI)對使用者進行身份驗證,並將權杖隨之傳遞到所有 API 叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步 API 和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
圖 2 說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
圖 1 說明瞭 Webex CC 中的資源調配工作流。
組態實體
CC Webex 中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者(代理/監督員)所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動 Agent Desktop 的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex 交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流量
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
圖 2 說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
圖 1 說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理(CRM)系統整合的模式。
-
桌面嵌入式連接器
-
透過 IVR 中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,它使用 CRM 抽象 REST API 調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
圖 1 說明瞭 CRM 嵌入式 Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於 CRM 集成的計算都在瀏覽器上進行,代理使用 CRM 應用程式 Webex 並在 CRM 應用程式中嵌入 CC 桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在 CRM 市場上找到。
例如:
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的 XML 檔導入 CRM 控制台,以支援在 CRM 上報告通話記錄。
透過 IVR 中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器 Webex 支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和 IVR 中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器 IVR ServiceNow(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充 Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
欲瞭解更多詳情,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他 API 集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中環
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
-
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
圖 1 顯示了使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中環 |
溫哥華 多倫多 |
中環 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
*有關下一代媒體服務的區域可用性的詳細資訊,請參閱 下一代語音媒體平臺。
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證(OAuth 流)的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在 VPC 內部,服務之間的內部通信 - 通過 HTTP /自定義 TCP 協定 - 通過普通 TCP 套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
圖 1 說明瞭傳輸中和靜態時的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在 CC 報告數據存儲 Webex 並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在 CC Webex 內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有 Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使 Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC 的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
圖 1 顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊 Webex 請參閱 Contact Center 服務隱私數據表 。
Cisco Webex Contact Center(Webex CC)是一種聯絡中心即服務(CCaaS),使組織能夠在整個客戶旅程中實現更智慧、主動和個人化的交互。
Webex CC 是從頭開始構建、設計和開發的,作為雲原生解決方案,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
安全性原生內置於系統的構建和部署方式中,數據在傳輸中和靜態時受到保護,以及 Webex CC 擁有的安全性/合規性認證。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與其他 Cisco Webex 集成,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文檔中的後續部分將擴展上述每個功能 Webex 以及 CC 體系結構如何實現相同的功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆聯繫組織,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如 WhatsApp,Facebook Messenger,Apple Business Chat,來自 Twitter 的直接消息)直接聊天
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化 IVR 系統,用於電話/聊天的虛擬代理,內置可程式設計性以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以提前主動向座席提供數據,是聯絡中心解決方案發展方式的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
圖 1 說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下各節描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)作為使用者與聯絡中心互動的各種管道。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話而言,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的入口機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流定義執行進一步的操作 - CC 流定義是在排隊和路由到代理之前處理呼叫時要執行的操作的程式設計表示形式,或者流本身可以在不轉接到代理的情況下處理呼叫。
Webex CC 中的 Flow Builder 允許開發人員定義流程,並將其指定給通話到達 CC Webex 入口點。
配置實體中介紹了 這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中 介紹 IVR 系統。
電子郵件與訊息
Webex 從 CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以將其用於 Contact Center。
Webex 連接流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息管道包括:
-
Web App / 移動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
Webex 抄送支援的電子郵件管道包括:
-
Gmail
-
辦公室 365
入口機制
本節介紹互動進入 CC Webex 機制。根據媒體類型,互動到達 CC Webex 機制是不同的。
例如,在電話中,需要物理基礎結構預配來啟用 PSTN 連接,配置電話號碼以及將呼叫路由到 Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和 Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到 Webex CC 的機制。
圖 1 說明瞭將語音呼叫攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連通性 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源 IP 位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現 IVR 邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML 通常用於解析 API 回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置 Webex 虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話 IVR 體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到 Webex CC。
圖 2 說明瞭在 Webex CC 中攝取電子郵件和消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
圖 1 說明瞭排隊和路由體系結構。
代理選擇
CC Webex 佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop 作業
當代理登入 Webex CC Agent Desktop 時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為 Cisco Webex Calling 使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop 使用 Cisco Common Identity(CI)對使用者進行身份驗證,並將權杖隨之傳遞到所有 API 叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步 API 和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
圖 2 說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
圖 1 說明瞭 Webex CC 中的資源調配工作流。
組態實體
CC Webex 中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者(代理/監督員)所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動 Agent Desktop 的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex 交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流量
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
圖 2 說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
圖 1 說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理(CRM)系統整合的模式。
-
桌面嵌入式連接器
-
透過 IVR 中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,它使用 CRM 抽象 REST API 調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
圖 1 說明瞭 CRM 嵌入式 Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於 CRM 集成的計算都在瀏覽器上進行,代理使用 CRM 應用程式 Webex 並在 CRM 應用程式中嵌入 CC 桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在 CRM 市場上找到。
例如:
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的 XML 檔導入 CRM 控制台,以支援在 CRM 上報告通話記錄。
透過 IVR 中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器 Webex 支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和 IVR 中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器 IVR ServiceNow(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充 Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
欲瞭解更多詳情,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他 API 集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中環
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
-
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
圖 1 顯示了使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中環 |
溫哥華 多倫多 |
中環 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
*有關下一代媒體服務的區域可用性的詳細資訊,請參閱 下一代語音媒體平臺。
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證(OAuth 流)的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在 VPC 內部,服務之間的內部通信 - 通過 HTTP /自定義 TCP 協定 - 通過普通 TCP 套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
圖 1 說明瞭傳輸中和靜態時的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在 CC 報告數據存儲 Webex 並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在 CC Webex 內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有 Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使 Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC 的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
圖 1 顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊 Webex 請參閱 Contact Center 服務隱私數據表 。
Cisco Webex Contact Center(Webex CC)是一種聯絡中心即服務(CCaaS),使組織能夠在整個客戶旅程中實現更智慧、主動和個人化的交互。
Webex CC 是從頭開始構建、設計和開發的,作為雲原生解決方案,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
安全性原生內置於系統的構建和部署方式中,數據在傳輸中和靜態時受到保護,以及 Webex CC 擁有的安全性/合規性認證。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與其他 Cisco Webex 集成,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文檔中的後續部分將擴展上述每個功能 Webex 以及 CC 體系結構如何實現相同的功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆聯繫組織,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如 WhatsApp,Facebook Messenger,Apple Business Chat,來自 Twitter 的直接消息)直接聊天
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化 IVR 系統,用於電話/聊天的虛擬代理,內置可程式設計性以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以提前主動向座席提供數據,是聯絡中心解決方案發展方式的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
下圖說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下各節描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)作為使用者與聯絡中心互動的各種管道。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話而言,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的入口機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流定義執行進一步的操作 - CC 流定義是在排隊和路由到代理之前處理呼叫時要執行的操作的程式設計表示形式,或者流本身可以在不轉接到代理的情況下處理呼叫。
Webex CC 中的 Flow Builder 允許開發人員定義流程,並將其指定給通話到達 CC Webex 入口點。
配置實體 中介紹了這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中 介紹 IVR 系統。
電子郵件與訊息
Webex 從 CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以將其用於 Contact Center。
Webex 連接流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息管道包括:
-
Web App / 移動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
Webex 抄送支援的電子郵件管道包括:
-
Gmail
-
辦公室 365
入口機制
本節介紹互動進入 CC Webex 機制。根據媒體類型,互動到達 CC Webex 機制是不同的。
例如,在電話中,需要物理基礎結構預配來啟用 PSTN 連接,配置電話號碼以及將呼叫路由到 Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和 Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到 Webex CC 的機制。
下圖說明瞭語音通話攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連通性 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源 IP 位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現 IVR 邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML 通常用於解析 API 回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置 Webex 虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話 IVR 體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到 Webex CC。
下圖說明瞭電子郵件的引入,Webex CC 中的消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
下圖說明瞭佇列和路由體系結構。
代理選擇
CC Webex 佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop 作業
當代理登入 Webex CC Agent Desktop 時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為 Cisco Webex Calling 使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop 使用 Cisco Common Identity(CI)對使用者進行身份驗證,並將權杖隨之傳遞到所有 API 叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步 API 和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
下圖說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
下圖說明瞭 Webex CC 中的置備工作流。
組態實體
CC Webex 中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者(代理/監督員)所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動 Agent Desktop 的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex 交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流量
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
下圖說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
下圖說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理(CRM)系統整合的模式。
-
桌面嵌入式連接器
-
透過 IVR 中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,它使用 CRM 抽象 REST API 調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
下圖說明瞭 CRM 嵌入式 Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於 CRM 集成的計算都在瀏覽器上進行,代理使用 CRM 應用程式 Webex 並在 CRM 應用程式中嵌入 CC 桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在 CRM 市場上找到。
例如:
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的 XML 檔導入 CRM 控制台,以支援在 CRM 上報告通話記錄。
透過 IVR 中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器 Webex 支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和 IVR 中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器 IVR ServiceNow(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充 Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
欲瞭解更多詳情,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他 API 集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中環
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
- 新加坡
-
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
下圖說明瞭使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中環 |
溫哥華 多倫多 |
中環 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證(OAuth 流)的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在 VPC 內部,服務之間的內部通信 - 通過 HTTP /自定義 TCP 協定 - 通過普通 TCP 套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
下圖說明瞭傳輸和靜態的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在 CC 報告數據存儲 Webex 並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在 CC Webex 內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有 Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使 Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC 的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
下圖顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊 Webex 請參閱 Contact Center 服務隱私數據表 。
Cisco Webex Contact Center(Webex CC)是一種聯絡中心即服務(CCaaS),使組織能夠在整個客戶旅程中實現更智慧、主動和個人化的交互。
Webex CC 是從頭開始構建、設計和開發的,作為雲原生解決方案,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
安全性原生內置於系統的構建和部署方式中,數據在傳輸中和靜態時受到保護,以及 Webex CC 擁有的安全性/合規性認證。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與其他 Cisco Webex 集成,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文檔中的後續部分將擴展上述每個功能 Webex 以及 CC 體系結構如何實現相同的功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆聯繫組織,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如 WhatsApp,Facebook Messenger,Apple Business Chat,來自 Twitter 的直接消息)直接聊天
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化 IVR 系統,用於電話/聊天的虛擬代理,內置可程式設計性以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以提前主動向座席提供數據,是聯絡中心解決方案發展方式的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
下圖說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下各節描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)作為使用者與聯絡中心互動的各種管道。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話而言,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的入口機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流定義執行進一步的操作 - CC 流定義是在排隊和路由到代理之前處理呼叫時要執行的操作的程式設計表示形式,或者流本身可以在不轉接到代理的情況下處理呼叫。
Webex CC 中的 Flow Builder 允許開發人員定義流程,並將其指定給通話到達 CC Webex 入口點。
配置實體 中介紹了這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中 介紹 IVR 系統。
電子郵件與訊息
Webex 從 CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以將其用於 Contact Center。
Webex 連接流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息管道包括:
-
Web App / 移動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
Webex 抄送支援的電子郵件管道包括:
-
Gmail
-
辦公室 365
入口機制
本節介紹互動進入 CC Webex 機制。根據媒體類型,互動到達 CC Webex 機制是不同的。
例如,在電話中,需要物理基礎結構預配來啟用 PSTN 連接,配置電話號碼以及將呼叫路由到 Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和 Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到 Webex CC 的機制。
下圖說明瞭語音通話攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連通性 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源 IP 位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現 IVR 邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML 通常用於解析 API 回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置 Webex 虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話 IVR 體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到 Webex CC。
下圖說明瞭電子郵件的引入,Webex CC 中的消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
下圖說明瞭佇列和路由體系結構。
代理選擇
CC Webex 佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop 作業
當代理登入 Webex CC Agent Desktop 時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為 Cisco Webex Calling 使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop 使用 Cisco Common Identity(CI)對使用者進行身份驗證,並將權杖隨之傳遞到所有 API 叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步 API 和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
下圖說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
下圖說明瞭 Webex CC 中的置備工作流。
組態實體
CC Webex 中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者(代理/監督員)所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動 Agent Desktop 的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex 交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流量
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
下圖說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
下圖說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理(CRM)系統整合的模式。
-
桌面嵌入式連接器
-
透過 IVR 中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,它使用 CRM 抽象 REST API 調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
下圖說明瞭 CRM 嵌入式 Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於 CRM 集成的計算都在瀏覽器上進行,代理使用 CRM 應用程式 Webex 並在 CRM 應用程式中嵌入 CC 桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在 CRM 市場上找到。
例如:
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的 XML 檔導入 CRM 控制台,以支援在 CRM 上報告通話記錄。
透過 IVR 中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器 Webex 支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和 IVR 中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器 IVR ServiceNow(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充 Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
欲瞭解更多詳情,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他 API 集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中環
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
- 新加坡
-
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
下圖說明瞭使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中環 |
溫哥華 多倫多 |
中環 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證(OAuth 流)的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在 VPC 內部,服務之間的內部通信 - 通過 HTTP /自定義 TCP 協定 - 通過普通 TCP 套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
下圖說明瞭傳輸和靜態的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在 CC 報告數據存儲 Webex 並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在 CC Webex 內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有 Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使 Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC 的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
下圖顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊 Webex 請參閱 Contact Center 服務隱私數據表 。
Cisco Webex Contact Center(Webex CC)是一種聯絡中心即服務(CCaaS),使組織能夠在整個客戶旅程中實現更智慧、主動和個人化的交互。
Webex CC 是從頭開始構建、設計和開發的,作為雲原生解決方案,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
安全性原生內置於系統的構建和部署方式中,數據在傳輸中和靜態時受到保護,以及 Webex CC 擁有的安全性/合規性認證。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與其他 Cisco Webex 集成,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文檔中的後續部分將擴展上述每個功能 Webex 以及 CC 體系結構如何實現相同的功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆聯繫組織,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如 WhatsApp,Facebook Messenger,Apple Business Chat,來自 Twitter 的直接消息)直接聊天
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化 IVR 系統,用於電話/聊天的虛擬代理,內置可程式設計性以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以提前主動向座席提供數據,是聯絡中心解決方案發展方式的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
下圖說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下各節描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)作為使用者與聯絡中心互動的各種管道。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話而言,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的入口機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流定義執行進一步的操作 - CC 流定義是在排隊和路由到代理之前處理呼叫時要執行的操作的程式設計表示形式,或者流本身可以在不轉接到代理的情況下處理呼叫。
Webex CC 中的 Flow Builder 允許開發人員定義流程,並將其指定給通話到達 CC Webex 入口點。
配置實體 中介紹了這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中 介紹 IVR 系統。
電子郵件與訊息
Webex 從 CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以將其用於 Contact Center。
Webex 連接流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息管道包括:
-
Web App / 移動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
Webex 抄送支援的電子郵件管道包括:
-
Gmail
-
辦公室 365
入口機制
本節介紹互動進入 CC Webex 機制。根據媒體類型,互動到達 CC Webex 機制是不同的。
例如,在電話中,需要物理基礎結構預配來啟用 PSTN 連接,配置電話號碼以及將呼叫路由到 Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和 Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到 Webex CC 的機制。
下圖說明瞭語音通話攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連接 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源 IP 位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現 IVR 邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML 通常用於解析 API 回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置 Webex 虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話 IVR 體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到 Webex CC。
下圖說明瞭電子郵件的引入,Webex CC 中的消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
下圖說明瞭佇列和路由體系結構。
代理選擇
CC Webex 佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop 作業
當代理登入 Webex CC Agent Desktop 時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為 Cisco Webex Calling 使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop 使用 Cisco Common Identity(CI)對使用者進行身份驗證,並將權杖隨之傳遞到所有 API 叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步 API 和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
下圖說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
下圖說明瞭 Webex CC 中的置備工作流。
組態實體
CC Webex 中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者(代理/監督員)所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動 Agent Desktop 的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex 交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
下圖說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
下圖說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理(CRM)系統整合的模式。
-
桌面嵌入式連接器
-
透過 IVR 中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,它使用 CRM 抽象 REST API 調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
下圖說明瞭 CRM 嵌入式 Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於 CRM 集成的計算都在瀏覽器上進行,代理使用 CRM 應用程式 Webex 並在 CRM 應用程式中嵌入 CC 桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在 CRM 市場上找到。
比如
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的 XML 檔導入 CRM 控制台,以支援在 CRM 上報告通話記錄。
透過 IVR 中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器 Webex 支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和 IVR 中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器 IVR ServiceNow(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充 Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
欲瞭解更多詳情,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他 API 集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
- 新加坡
-
可以使用互聯網或 Amazon Web Services(AWS)Direct Connect 建立與 AWS 託管 Webex 聯絡中心的連接。 借助 AWS Direct Connect,數據通過本地客戶網路與聯絡中心之間的私有網路連接傳輸 Webex 從而改善了連接。 有關更多詳細資訊,請參閱 Webex Contact Center 的 AWS Direct Connect。
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
下圖說明瞭使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中 |
溫哥華 多倫多 |
中 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證(OAuth 流)的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在 VPC 內部,服務之間的內部通信 - 通過 HTTP /自定義 TCP 協定 - 通過普通 TCP 套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
下圖說明瞭傳輸和靜態的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在 CC 報告數據存儲 Webex 並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在 CC Webex 內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有 Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使 Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC 的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
下圖顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊 Webex 請參閱 Contact Center 服務隱私數據表 。
Cisco Webex Contact Center (Webex CC) 是一種聯絡中心即服務 (CCaaS),可讓組織在整個客戶旅程中實現更智慧、主動和個人化的互動。
Webex CC 作為雲原生解決方案從頭開始構建、設計和開發,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
在構建和部署系統的方式中原生內置安全性,在傳輸中和靜態數據以及 Webex CC 擁有的安全性/合規性認證中受到保護。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與 Cisco Webex 的其他部分整合,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文件中的後續部分將詳細介紹上述各項功能,以及 Webex CC 架構如何實現此功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆地與組織聯繫,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道進行聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如WhatsApp,Facebook Messenger,Apple Business Chat,來自Twitter的直接消息)直接聊天
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化IVR系統,用於電話/聊天的虛擬代理,內置可程式設計性,以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動的自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以主動向座席預先提供數據,是聯絡中心解決方案不斷發展的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
下圖說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下部分描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)等各種管道,使用者可透過這些管道與聯絡中心進行互動。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的輸入機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流程定義執行進一步的操作 - 這是在處理通話之前要執行的操作的程式設計表示形式,在排隊和路由到代理之前,或者流程本身可以在不轉接到代理的情況下處理通話。
Webex CC 中的流程構建器允許開發人員定義流程並將其指定給通話到達 Webex CC 的入口點。
配置實體 中介紹了這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中介紹 IVR 系統。
電子郵件與訊息
從 Webex CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以使用這些功能來聯繫Contact Center。
Webex Connect 流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息傳遞管道包括:
-
網路應用程式/行動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
Webex CC 支援的電子郵件管道包括:
-
Gmail
-
辦公室365
入口機制
本節介紹互動進入 Webex CC 的機制。 根據媒體類型,互動到達 Webex CC 的機制也不同。
例如,在電話中,需要物理基礎設施配置來啟用 PSTN 連接,配置電話號碼以及將通話路由到 Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和 Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到 Webex CC 的機制。
下圖說明瞭語音通話攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連通性 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源 IP 位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現 IVR 邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML 通常用於解析 API 回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置 Webex 虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話 IVR 體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到 Webex CC。
下圖說明瞭電子郵件的引入,Webex CC 中的消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
下圖說明瞭佇列和路由體系結構。
代理選擇
CC Webex 佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop 作業
當代理登入 Webex CC Agent Desktop 時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為 Cisco Webex Calling 使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop 使用 Cisco Common Identity(CI)對使用者進行身份驗證,並將權杖隨之傳遞到所有 API 叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步 API 和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
下圖說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
下圖說明瞭 Webex CC 中的置備工作流。
組態實體
CC Webex 中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者(代理/監督員)所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動 Agent Desktop 的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex 交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流量
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
下圖說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
下圖說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理(CRM)系統整合的模式。
-
桌面嵌入式連接器
-
透過 IVR 中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,它使用 CRM 抽象 REST API 調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
下圖說明瞭 CRM 嵌入式 Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於 CRM 集成的計算都在瀏覽器上進行,代理使用 CRM 應用程式 Webex 並在 CRM 應用程式中嵌入 CC 桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在 CRM 市場上找到。
例如:
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的 XML 檔導入 CRM 控制台,以支援在 CRM 上報告通話記錄。
透過 IVR 中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器 Webex 支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和 IVR 中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器 IVR ServiceNow(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充 Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
欲瞭解更多詳情,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他 API 集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中環
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
- 新加坡
-
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
下圖說明瞭使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中環 |
溫哥華 多倫多 |
中環 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證(OAuth 流)的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在 VPC 內部,服務之間的內部通信 - 通過 HTTP /自定義 TCP 協定 - 通過普通 TCP 套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
下圖說明瞭傳輸和靜態的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在 CC 報告數據存儲 Webex 並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在 CC Webex 內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有 Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使 Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC 的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
下圖顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊 Webex 請參閱 Contact Center 服務隱私數據表 。
Cisco Webex Contact Center (Webex CC) 是一種聯絡中心即服務 (CCaaS),可讓組織在整個客戶旅程中實現更智慧、主動和個人化的互動。
Webex CC 作為雲原生解決方案從頭開始構建、設計和開發,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
在構建和部署系統的方式中原生內置安全性,在傳輸中和靜態數據以及 Webex CC 擁有的安全性/合規性認證中受到保護。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與 Cisco Webex 的其他部分整合,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文件中的後續部分將詳細介紹上述各項功能,以及 Webex CC 架構如何實現此功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆地與組織聯繫,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道進行聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如WhatsApp,Facebook Messenger,Apple Business Chat,來自Twitter的直接消息)直接聊天
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化IVR系統,用於電話/聊天的虛擬代理,內置可程式設計性,以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動的自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以主動向座席預先提供數據,是聯絡中心解決方案不斷發展的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
下圖說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下部分描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)等各種管道,使用者可透過這些管道與聯絡中心進行互動。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的輸入機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流程定義執行進一步的操作 - 這是在處理通話之前要執行的操作的程式設計表示形式,在排隊和路由到代理之前,或者流程本身可以在不轉接到代理的情況下處理通話。
Webex CC 中的流程構建器允許開發人員定義流程並將其指定給通話到達 Webex CC 的入口點。
配置實體 中介紹了這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中介紹 IVR 系統。
電子郵件與訊息
從 Webex CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以使用這些功能來聯繫Contact Center。
Webex Connect 流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息傳遞管道包括:
-
網路應用程式/行動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
Webex CC 支援的電子郵件管道包括:
-
Gmail
-
辦公室365
入口機制
本節介紹互動進入 Webex CC 的機制。 根據媒體類型,互動到達 Webex CC 的機制也不同。
例如,在電話中,需要物理基礎設施配置來啟用 PSTN 連接,配置電話號碼以及將通話路由到 Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和 Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到 Webex CC 的機制。
下圖說明瞭語音通話攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連通性 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源 IP 位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現 IVR 邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML 通常用於解析 API 回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置 Webex 虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話 IVR 體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到 Webex CC。
下圖說明瞭電子郵件的引入,Webex CC 中的消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
下圖說明瞭佇列和路由體系結構。
代理選擇
CC Webex 佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop 作業
當代理登入 Webex CC Agent Desktop 時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為 Cisco Webex Calling 使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop 使用 Cisco Common Identity(CI)對使用者進行身份驗證,並將權杖隨之傳遞到所有 API 叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步 API 和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
下圖說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
下圖說明瞭 Webex CC 中的置備工作流。
組態實體
CC Webex 中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者(代理/監督員)所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動 Agent Desktop 的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex 交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流量
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
下圖說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
下圖說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理(CRM)系統整合的模式。
-
桌面嵌入式連接器
-
透過 IVR 中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,它使用 CRM 抽象 REST API 調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
下圖說明瞭 CRM 嵌入式 Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於 CRM 集成的計算都在瀏覽器上進行,代理使用 CRM 應用程式 Webex 並在 CRM 應用程式中嵌入 CC 桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在 CRM 市場上找到。
例如:
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的 XML 檔導入 CRM 控制台,以支援在 CRM 上報告通話記錄。
透過 IVR 中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器 Webex 支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和 IVR 中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器 IVR ServiceNow(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充 Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
欲瞭解更多詳情,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他 API 集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中環
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
- 新加坡
-
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
下圖說明瞭使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中環 |
溫哥華 多倫多 |
中環 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證(OAuth 流)的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在 VPC 內部,服務之間的內部通信 - 通過 HTTP /自定義 TCP 協定 - 通過普通 TCP 套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
下圖說明瞭傳輸和靜態的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在 CC 報告數據存儲 Webex 並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在 CC Webex 內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有 Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使 Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC 的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
下圖顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊 Webex 請參閱 Contact Center 服務隱私數據表 。
Cisco Webex Contact Center (Webex CC) 是一種聯絡中心即服務 (CCaaS),使組織能夠在整個客戶旅程中實現更智慧、主動和個人化的交互。
Webex CC 是從頭開始構建、設計和開發的,作為雲原生解決方案,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
安全性原生內置於系統的構建和部署方式中,數據在傳輸中和靜態時受到保護,以及 Webex CC 擁有的安全性/合規性認證。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與其他Cisco Webex集成,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文檔中的後續部分將擴展上述每個功能Webex以及CC體系結構如何實現相同的功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆聯繫組織,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如WhatsApp,Facebook Messenger,Apple Messages for Business)直接聊天。
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化IVR系統,用於電話/聊天的虛擬代理,內置可程式設計性以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以提前主動向座席提供數據,是聯絡中心解決方案發展方式的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
下圖說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下各節描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)作為使用者與聯絡中心互動的各種管道。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話而言,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的入口機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流定義執行進一步的操作 - CC 流定義是在排隊和路由到代理之前處理呼叫時要執行的操作的程式設計表示形式,或者流本身可以在不轉接到代理的情況下處理呼叫。
Webex CC 中的 Flow Builder 允許開發人員定義流程,並將其指定給通話到達 CC Webex入口點。
配置實體 中介紹了這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中 介紹IVR系統。
電子郵件與訊息
Webex從 CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以將其用於Contact Center。
Webex連接流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息管道包括:
-
Web App / 移動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
-
Apple Business 留言
Webex 抄送支援的電子郵件管道包括:
-
Gmail
-
辦公室365
入口機制
本節介紹互動進入 CC Webex機制。根據媒體類型,互動到達 CC Webex機制是不同的。
例如,在電話中,需要物理基礎結構預配來啟用 PSTN 連接,配置電話號碼以及將呼叫路由到Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到Webex CC 的機制。
下圖說明瞭語音通話攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘 – 支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連接 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源IP位址) IPSec 虛擬專用網路 (VPN) 或透過通用路由封裝 (GRE) IPSec 站點到站點 (S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點 (P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現IVR邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數 – 與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環 – 使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據 – JSON、TOML XML通常用於解析API回應。
-
作曲活動
Flow 提供的一組代表性活動是:
|
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置Webex虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話IVR體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到Webex CC。
下圖說明瞭電子郵件的引入,Webex CC 中的消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列 – 僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
下圖說明瞭佇列和路由體系結構。
代理選擇
CC Webex佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理 (LAA)
-
最佳可用代理 (BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置 (PIQ)、估計等待時間 (EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組 (CBT) 進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop作業
當代理登入 Webex CC Agent Desktop時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為Cisco Webex Calling使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop使用 Cisco Common Identity (CI) 對使用者進行身份驗證,並將權杖隨之傳遞到所有API叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步API和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
下圖說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
下圖說明瞭 Webex CC 中的置備工作流。
組態實體
CC Webex中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者 (代理/監督員) 所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動Agent Desktop的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
下圖說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
下圖說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理 (CRM) 系統整合的模式。
-
桌面嵌入式連接器
-
透過IVR中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個CRM的CRM用戶端SDK,它使用CRM抽象REST API調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
下圖說明瞭 CRM 嵌入式Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於CRM集成的計算都在瀏覽器上進行,代理使用CRM應用程式Webex並在CRM應用程式中嵌入CC桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在CRM市場上找到。
比如
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的XML檔導入CRM控制台,以支援在CRM上報告通話記錄。
透過IVR中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器Webex支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和IVR中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器IVR ServiceNow (自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
有關更多資訊,請參閱 在Webex Contact Center中配置語音輸出活動模式。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
有關更多詳細資訊,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他API集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
- 新加坡
-
可以使用互聯網或 Amazon Web Services(AWS)Direct Connect 建立與 AWS 託管Webex聯絡中心的連接。 借助 AWS Direct Connect,數據通過本地客戶網路與聯絡中心之間的私有網路連接傳輸Webex從而改善了連接。 有關更多詳細資訊,請參閱 Webex Contact Center 的 AWS Direct Connect。
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
下圖說明瞭使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務 (AWS 區域) |
Media Edge (Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中 |
溫哥華 多倫多 |
中 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證 (OAuth 流) 的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在VPC內部,服務之間的內部通信 - 通過HTTP /自定義TCP協定 - 通過普通TCP套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
下圖說明瞭傳輸和靜態的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在CC報告數據存儲Webex並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在CC Webex內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
下圖顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊Webex請參閱 Contact Center 服務隱私數據表 。
簡介
Cisco Webex Contact Center(Webex CC)是一種聯絡中心即服務(CCaaS),使組織能夠在整個客戶旅程中實現更智慧、主動和個人化的交互。
Webex CC 是從頭開始構建、設計和開發的,作為雲原生解決方案,具有以下核心架構原則。
-
服務:一組獨立的服務,每個服務為其使用者提供一組小的內聚功能。
-
事件驅動:所有服務都使用消息傳遞相互通信,但在 Web 應用程式中,應用程式使用 HTTPs 介面(REST API、通過 WebSocket 介面推送數據)用於特定用例。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 docker 容器中運行,能夠自動擴展並恢復一個或多個服務實例的故障。
-
可觀察:所有服務以及支援部署此類服務的基礎架構元件都可通過標準機制進行觀察,以測量、檢測和預防影響聯絡中心功能的情況,並在發生中斷時快速排除故障和恢復服務。
-
隔離/鬆散耦合:每個服務都可以獨立構建、驗證和部署/更新,無需停機即可實現聯絡中心功能。
Webex CC 服務部署在 AWS 中,並由支援以下功能的雲原生平臺提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎設施服務和應用程式的彈性,支援動態擴展功能
-
安全性原生內置於系統的構建和部署方式中,數據在傳輸中和靜態時受到保護,以及 Webex CC 擁有的安全性/合規性認證。
-
用於電話/語音整合的可擴充且安全的邊緣基礎架構
-
通過主動監控和警報實現可觀察性,從而為客戶提供聯絡中心服務的高可用性。
-
與其他Cisco Webex集成,用於使用者身份驗證/授權、管理和提供聯絡中心功能。
本文檔中的後續部分將擴展上述每個功能Webex以及CC體系結構如何實現相同的功能。
邏輯架構
聯絡中心解決方案必須具備的核心功能是使客戶能夠通過常用的通信方式輕鬆聯繫組織,並以快速有效的方式解決查詢/問題。
但是,為確保實現此基本原則,使用聯絡中心的組織必須有權訪問多個幕後功能。 這些是:
-
客戶開始互動的機制
-
將電話呼叫連接到聯絡中心系統的已發佈和操作電話號碼
-
客戶可以向其發送電子郵件的電子郵件位址,以及檢測新傳入電子郵件的機制。
-
客戶能夠透過各種數位管道聯繫,包括但不限於
-
從網站/應用程式聊天
-
通過流行的消息用戶端(如WhatsApp,Facebook Messenger,Apple Messages for Business)直接聊天。
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化IVR系統,用於電話/聊天的虛擬代理,內置可程式設計性以定義處理交互所涉及的工作流程。
-
最後,如果需要,必須將交互上報給代理,該代理具有處理交互的最佳技能。
-
-
代理能夠指示處理交互的可用性,以及主管監視、指導代理並獲取實現高效交互的操作指標的能力。
-
管理員可以設定及提供各種聯絡中心功能,使代理與監督員可以如預期般執行工作。
除此之外,現代企業還需要增加功能,通過訪問可視化和跟蹤關鍵運營指標的數據和見解來優化聯絡中心運營。
此外,能夠與專門的聯絡中心生態系統功能集成,例如運行主動自動外傳呼叫、使用 AI 增強座席和主管體驗、檢測和瞭解客戶旅程以提前主動向座席提供數據,是聯絡中心解決方案發展方式的明顯差異化因素。
關於消費模式,聯絡中心產品作為雲交付的軟體服務使用,確保可用性、可靠性和自動化臨時擴展要求的能力需要最先進的監控和警報機制,從而能夠持續驗證和檢測即將發生的問題,並防止/最小化對客戶運營的影響。
下圖說明瞭 Webex CC 的邏輯體系結構。
功能元件
以下各節描述了 Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和訊息傳遞(社交管道)作為使用者與聯絡中心互動的各種管道。
對於所有通道,初始處理可由系統完成,然後交互可升級為代理。
媒體類型
電話
對於電話而言,入站語音通話處理由通話進入聯絡中心的方式(請參閱下面的入口機制)和與入口點關聯的 Webex CC 流程決定。
通話將得到接聽,並且會根據 Webex CC 流定義執行進一步的操作 - CC 流定義是在排隊和路由到代理之前處理呼叫時要執行的操作的程式設計表示形式,或者流本身可以在不轉接到代理的情況下處理呼叫。
Webex CC 中的 Flow Builder 允許開發人員定義流程,並將其指定給通話到達 CC Webex入口點。
配置實體 中介紹了這些配置實體及其用法。
有關 Flow Builder 的更多資訊將在下一節中 介紹IVR系統。
電子郵件與訊息
Webex從 CC 的角度來看,Webex Connect 為所有數位管道(電子郵件、訊息傳遞管道)提供入口和出口功能,最終使用者可以將其用於Contact Center。
Webex連接流程
-
決定此類交互的處理方式,直到交互排入佇列並路由到代理為止。 這包括對所有形式的消息傳遞和電子郵件交互的自動處理和 BOT 處理。
-
將業務邏輯應用於傳入交互。
-
在排隊前處理聯絡。
-
流本身可以處理交互,而無需轉移到即時代理。
Webex CC 支援的消息管道包括:
-
Web App / 移動應用程式聊天
-
微信
-
Facebook Messenger
-
SMS
-
Apple Business 留言
Webex 抄送支援的電子郵件管道包括:
-
Gmail
-
辦公室365
入口機制
本節介紹互動進入 CC Webex機制。根據媒體類型,互動到達 CC Webex機制是不同的。
例如,在電話中,需要物理基礎結構預配來啟用 PSTN 連接,配置電話號碼以及將呼叫路由到Webex CC。
對於電子郵件/消息傳遞通道,入口配置必須在 Webex Connect 中完成,它涉及電子郵件/消息帳戶預配和Webex Connect 流配置。
撥入語音
對於語音通話,典型的場景是使用者撥打 PSTN 電話號碼,然後連接到聯絡中心。 從入口角度來看,這需要一種將呼叫從 PSTN 路由到Webex CC 的機制。
下圖說明瞭語音通話攝取到 Webex CC。
Webex CC 中的語音入口服務使用 SIP 執行第三方通話控制並接聽來電,以及執行轉接、會議和其他通話控制作業。
Webex CC 中通話的邏輯入口點是名稱為「入口點」的組態實體。 對於語音入口,入口點的關鍵組態是與其關聯的電話號碼,通常是從所選的 PSTN 提供者取得的有效 PSTN 電話號碼。
這樣可以檢測電話號碼上的來電,將通話關聯到入口點,並使用入口點的其他配置參數根據應為交互觸發的 Webex CC 流定義處理通話。
附註:
有關 PSTN 連接選項的更多詳細資訊,請訪問 https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴充性和可用性
Webex CC VPOP 基礎架構包括冗餘對的 SIP SBC,可確保高可用性,並且可以添加更多 SBC 以擴展要支援的併發通話量。
VPOP 可以處理的最大併發呼叫數取決於正在運行的 SBC 數以及要向其發送的呼叫。
對於地理冗餘–支援 VPOP SBC 網格,該網格具有跨區域的多個對的互連。
對於語音入口服務,它們可水平擴展,以處理要引入 Webex CC 的越來越多的併發語音呼叫。
語音邊緣基礎結構的安全注意事項
下表包含有關語音邊緣基礎架構連接選項的詳細資訊。
連接 |
類型 |
---|---|
公共互聯網 |
直接(包含列入白名單的源IP位址) IPSec 虛擬專用網路(VPN)或透過通用路由封裝(GRE)IPSec 站點到站點(S2S) SRTP/SIP TLS |
專用連線 |
MPLS 點對點(P2P) VPLS SD-WAN 私人廣域網 資料中心交叉連接 Equinix 結構連接 |
IVR 系統
進入與入口點關聯的電話號碼的每個語音通話都會被 Webex CC 接聽,並且與入口點關聯的 Webex CC 流程的執行都會開始。
Webex CC Flow Builder 提供程式設計構造/運算子和功能塊(稱為活動),以便管理員或設計和實現IVR邏輯的任何人都可以組合這些構建塊並創建流定義。
Flow 支援的程式設計結構包括:
-
聲明和設定變數–與流執行關聯的狀態
-
用於設定變數值的 Pebble 運算式
-
-
條件檢查
-
循環–使用條件和轉到(能夠將活動連結在一起)
-
叫用 REST API
-
解析數據–JSON、TOML XML通常用於解析API回應。
-
作曲活動
Flow 提供的一組代表性活動是:
-
播放訊息
-
收集使用者資料
-
將通話轉接至其他目的地/電話號碼
-
將呼叫傳送到虛擬代理
-
將通話排入佇列,以便代理可以接聽。
對於每個處於活動狀態的調用,流執行的實例也處於活動狀態,直到調用結束,從而導致併發執行流。
流執行的每個實例都為與流相關聯的數據/狀態提供了隔離的環境並在那裡通過調用。
在呼叫的整個生命週期中,流還支持回應發生的某些事件並對其進行處理 - 例如,當呼叫被代理應答時,事件處理程式可以在代理桌面介面中觸發屏幕彈出。
虛擬代理支援
Flow 提供一項活動,用於將交互移交給 Control Hub 中預先配置Webex虛擬代理。
呼叫連接到虛擬代理后,它將為使用者提供對話IVR體驗,並且活動以呼叫終止或將呼叫升級為代理而結束。
若發生升級,可將流程配置為將通話排入佇列,然後代理接聽該通話。
入站數位互動
對於傳入交互的電子郵件和消息傳遞通道,Webex CC 使用 Webex Connect 來預配資產和流來處理傳入的交互,然後在 Webex Connect 流將交互顯式排隊以便代理可以處理交互時將交互路由到Webex CC。
下圖說明瞭電子郵件的引入,Webex CC 中的消息傳遞交互。
Virtual Agent / BOT 整合
對於電子郵件和消息傳遞/社交管道交互,虛擬代理/BOT 處理在 Webex Connect 流中配置。
與語音虛擬代理一樣,如果 BOT 處理以升級結果結束,則交互將排隊並路由到代理。
路由和佇列
Webex CC 會將傳入的聯絡人視為流程中所定義的自動處理程序,並且流程可能會決定將聯絡人排入佇列/直接排入代理佇列(特定於代理的佇列–僅支援電話/語音交互)。
在佇列中,若代理可用,則會保留該代理,並將互動路由至該代理。 如果沒有可用的代理,交互將駐留在佇列中,Flow 將繼續使用附加到佇列活動的處理程式來處理客戶。
當代理可用時,處理程式將被中斷,並且將交互提供給代理。
下圖說明瞭佇列和路由體系結構。
代理選擇
CC Webex佇列支援下列代理選擇演算法:
-
最長的可用代理路由
-
基於技術的路由
-
最長可用代理(LAA)
-
最佳可用代理(BAA)
-
代理透過小組關聯至佇列。
可依序為佇列指派多個通話分派群組(每個群組有一個或多個小組),並設定等候通話分派群組加入佇列,以便相符代理的搜尋空間會隨著時間的推移而擴展到其他通話分派群組。
對於基於技能的路由,在與佇列關聯的客服匹配的技能需求中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話專屬的附加功能
基於代理的路由(僅適用於語音/電話通道)
Webex CC 流使用活動 QueueToAgent,可以根據代理 ID 將互動直接路由到選擇的代理。
如果代理無法處理互動,互動可以駐留在代理特定的佇列中,等待代理可用
進階佇列資訊
Webex CC Flow 使用活動 GetQueueInfo 可以獲取佇列的即時資訊,例如佇列中的位置(PIQ)、估計等待時間(EWT)、佇列中可用的代理數,並可用於決定是否將聯繫人排入佇列。
禮貌回電
Webex CC Flow 使用活動回調,允許客戶斷開通話,同時保持佇列中的位置,並在佇列中的虛擬交互路由到代理時接收回調。
溢流處理
Webex CC 支援使用基於容量的小組(CBT)進行溢位處理。
CBT 就像一個具有容量的常規團隊,以及為該容量提供服務的關聯外部 DN。 它可以與佇列通話分配週期中的其他團隊一起配置。
通常,這會設定為最後一個循環,以便在所有設定的通話分派群組都找不到可用的相符代理來處理互動之後,若無代理可用,它就會變成溢出。
Agent Desktop作業
當代理登入 Webex CC Agent Desktop時,代理會指定可以接通代理來電的電話號碼。 這可以是 PSTN 電話、行動電話或分機(如果代理為Cisco Webex Calling使用者)。
請注意,此號碼必須是可以路由通話的有效電話號碼。 否則代理將無法接聽來電。
根據代理正在處理的互動類型,代理桌面中的小部件提供了執行某些媒體控制操作的功能。
例如,一旦通話獲接聽,代理就可以執行以下與該通話相關的操作。
-
保留通話
-
發起諮詢通話,然後
-
將通話轉接至其他電話號碼(如代理電話號碼)/進入點
-
召集其他代理加入通話
-
-
將通話轉接至其他佇列
-
結束通話
Agent Desktop 透過延伸桌面功能並使其成為代理以高效方式完成工作所需的小工具的統一集合,允許管理員在其中添加自訂小工具。
桌面架構
Agent Desktop 是基於微前端的單頁應用程式,它承載基於 Web 元件體系結構構建的小部件。 所有標準/庫存小部件都由 API 或伺服器端推送機制檢索的數據提供支援。
這些通常是異步 API,其中調用的回應通過 WebSocket 連接進入桌面。
CC Webex Agent Desktop使用 Cisco Common Identity (CI) 對使用者進行身份驗證,並將權杖隨之傳遞到所有API叫用。 同樣對於自定義小組件,基於身份驗證模型,如果自定義小組件的身份驗證模型與 CI 集成,它將為代理提供單點登錄體驗。
代理成為交互的一部分后,對該交互狀態或關聯數據的所有更新也會通過 WebSocket 連接推送到桌面。
桌面對連接性和延遲的彈性
異步API和伺服器端推送支援縮放,檢測到 WebSocket 介面的任何連接丟失,桌面嘗試重新連接並重新登錄。
下圖說明瞭 Webex CC 中的代理桌面體系結構。
管理與設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或配置功能的主要介面。
在 Control Hub 中配置組織和聯絡中心功能後,它將在 Webex CC 中觸發工作流程,該工作流程會根據客戶選擇的產品/服務執行配置所有聯絡中心功能的其餘步驟。
所有聯絡中心配置都是使用 BPM 工作流引擎完成的,該引擎支援一種聲明性方式來定義所涉及的步驟,並使整個配置步驟能夠靈活應對故障並確保數據完整性。
下圖說明瞭 Webex CC 中的置備工作流。
組態實體
CC Webex中的關鍵設定實體(作用域在組織內)包括:
站點
資料中心是指一個或多個小組、使用者 (代理/監督員) 所在的位置。
每個用戶和團隊都必須屬於一個網站。
團隊
一組使用者。 團隊用於通過佇列將交互分發給代理。
每個小組都必須屬於一個網站。
代理
可以登入及處理在 Webex CC 中所設定之媒體類型間互動Agent Desktop的使用者。
監督員
監督員被指派給小組,可以監控/指導代理,並可存取小組層級狀態與隸屬於監督員所屬小組的代理統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留交互,同時等待代理可用,然後再將代理路由到代理。
佇列對應至小組(此為代理的搜尋空間),並可透過將其他小組新增至搜尋空間,根據已用的時間臨界值擴充搜尋範圍。
入口點
入口點是一個邏輯實體,表示要進入 CC Webex交互的入口點。對於電話,這主要映射到呼叫到達的電話號碼,對於電子郵件/消息傳遞管道,入口點指向 Webex Connect 中的資產配置。
流
與入口點(通過路由策略)關聯的流,它決定處理交互所涉及的步驟。
對於非電話管道(電子郵件、消息/社交),在 Webex Connect 中選擇流作為資產配置的一部分。
多站點聯絡中心的存取控制
Webex CC 管理員可以配置具有對特定網站、團隊、佇列和入口點的訪問許可權的使用者配置檔。 此外,由於網站和團隊的分層性質,一旦提供了對特定網站的訪問許可權,使用者只能訪問屬於這些網站或此類團隊的明確指定子集的團隊或與團隊相關的日期。
對於佇列和進入點,它們在組織級別是全域的,因此對於不同的地理位置(特定代理和團隊所在的網站),可以配置單獨的進入點和佇列,並且監督員/使用者可以訪問適用於特定網站的那些實體。
下圖說明瞭引用這些實體的關鍵配置實體和使用者配置檔。
除了限制對這些實體的訪問外,Webex CC 管理員還可以控制使用者可以在管理介面中訪問的特定功能/模組,從而使使用者具有特定實體的管理/配置許可權以及 Webex CC 管理介面的部分/功能。
回報與分析
Webex CC 使用一系列即時流處理服務處理各種服務在交互生命週期中生成的離散事件,並生成一組已定義的實時數據集,這些數據集將發佈到訂閱用戶端。
此外,這些事件被進一步處理、轉換和聚合,生成的數據集被持久化,然後通過數據消耗 API 以及報告和數據可視化介面(Analyzer)進行檢索。
下圖說明瞭 Webex CC 中的數據處理和使用介面
整合
與 WxCC 的所有外部整合都是使用標準發佈的 API,以增強和增強客戶可以使用的功能。
Webex CC 中可用的 API 介面類型為:
-
REST API
-
伺服器端推送使用
-
網路鉤子
-
WebSocket 訊息
-
客戶關係管理整合
Webex CC 支援兩種與客戶關係管理 (CRM) 系統整合的模式。
-
桌面嵌入式連接器
-
透過IVR中的 HTTPs 連接器進行流程整合
桌面嵌入式連接器: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:這是 Webex CC 提供的 JavaScript SDK,用於為代理和聯繫人操作註冊事件偵聽器。
-
CRM JS SDK:這是適用於每個CRM的CRM用戶端SDK,它使用CRM抽象REST API調用。 例如,對於 salesforce,Salesforce 提供的 CTI JS 庫用於執行操作並偵聽 CRM 中的事件。
下圖說明瞭 CRM 嵌入式Webex CC 桌面和連接器體系結構
Webex CC 為上述整合支援以下 CRM 解決方案:
-
Salesforce
-
服務現在
-
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 託管自定義小組件,該小組件在 AWS CloudFront CDN 中啟用 CRM 應用程式與 Webex CC 桌面之間的雙向通信,確保小組件 AWS 跨可用區和區域的高可用性。
所有特定於CRM集成的計算都在瀏覽器上進行,代理使用CRM應用程式Webex並在CRM應用程式中嵌入CC桌面。
安全性
CRM 連接器通過 Webex CC 代理桌面佈局調用,可選參數通過桌面佈局傳遞到小部件中以打開和關閉功能。
例如,要啟用 Salesforce 操作小組件,管理員可以將桌面佈局參數設置為 sfdcWidgetEnabled 為 true。
套件安裝
要使集成雙向工作,CRM 控制台需要安裝嵌入式應用程式。 這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面嵌入式連接器都可以在CRM市場上找到。
比如
禪台: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
市場應用程式安裝啟動所需的外掛程式並將所需的XML檔導入CRM控制台,以支援在CRM上報告通話記錄。
透過IVR中的 HTTPs 連接器進行流程整合
Webex CC 流程構建器使用在 Control Hub 中配置並在 Webex CC 流程上使用的 HTTPs 連接器Webex支援 Webex CC 和 CRM 系統之間的雙向資料流。
這些主要用於語音交互中的個人化和IVR中的自訂路由。
依預設,Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。 其他 CRM 連接器可以作為自訂連接器新增到 Webex Control Hub 上。
有關 HTTP 連接器的更多資訊,請存取 https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內置): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
HTTP 連接器IVR ServiceNow (自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外撥活動管理
Webex CC 使用 Acqueon 的行銷活動管理解決方案支援外傳預覽活動。
有關更多資訊,請參閱 在Webex Contact Center中配置語音輸出活動模式。
Workforce Optimization
Webex CC 支援來自領先行業供應商的工作流程優化和品質管理解決方案。
擴充Agent Desktop
Webex CC 代理及監督員桌面可在桌面內開發及執行自訂小工具,以延伸桌面功能。
有關更多詳細資訊,請訪問 https://developer.webex-cx.com/documentation/guides/desktop。
其他介面
有關可在 Webex CC 中執行的其他API集成的詳細資訊,請訪問 https://developer.webex-cx.com/documentation/getting-started/。
部署與連線
Webex CC 部署在 AWS 中,目前在以下區域可用
-
美國
-
美國-東弗吉尼亞州
-
美國西北部 N 加利福尼亞(僅限語音媒體入口)
-
-
加拿大
-
中
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太區
-
東京
-
悉尼
- 新加坡
-
可以使用互聯網或 Amazon Web Services(AWS)Direct Connect 建立與 AWS 託管Webex聯絡中心的連接。 借助 AWS Direct Connect,數據通過本地客戶網路與聯絡中心之間的私有網路連接傳輸Webex從而改善了連接。 有關更多詳細資訊,請參閱 Webex Contact Center 的 AWS Direct Connect。
電話的多區域連線
為了使代理和客戶位於多個地理位置的全球性組織成為可能,Webex CC 支援將媒體保留在本地區域中,適用於運行語音媒體邊緣和入口服務的區域。
下圖說明瞭使用區域媒體的多區域部署。
媒體邊緣和入口服務部署在以下地域。
地理區域 |
Webex CC 服務 (AWS 區域) |
Media Edge (Voice POP) |
下一代媒體服務(AWS 區域)* |
---|---|---|---|
美國 |
北弗吉尼亞州 |
紐約 洛杉磯 |
北弗吉尼亞州 北加州 |
加拿大 |
中 |
溫哥華 多倫多 |
中 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟買 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
悉尼 |
墨爾本 悉尼 |
悉尼 |
安全和隱私
基礎設施安全
邊緣的語音基礎架構
語音邊緣元件允許來自客戶網路/PSTN 運營商的 SIP 中繼終止,這是根據允許連接到邊緣元件的列入白名單的 IP 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中預置,服務在具有多個命名空間的 Kubernetes 集群中作為 Pod 運行,並且使用單獨的憑證限制對每個命名空間的訪問。
所有基礎架構配置都是使用代碼完成的,無需手動步驟,並且無法手動訪問任何憑據。
有一個中央憑據存儲,其中包含為一組特定服務/團隊配置的特定路徑,並且對憑據存儲本身的訪問受到限制,並在構建和部署系統中配置為機密。
沒有任何基礎設施元件/服務直接暴露在 AWS VPC 之外,只有公開的介面是使用 API 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員還使用某些內部系統和介面,用於查看日誌、指標、部署詳細資訊、構建狀態和測試結果,這些系統和介面使用角色和組進行保護,並與思科內部身份驗證系統集成。
使用者介面的身份驗證和授權
各聯絡中心使用者(客服、監督人員、管理員、分析師)使用的所有 UI 均受 Cisco Common Identity 持有者令牌身份驗證 (OAuth 流) 的保護。
授權是使用獲取令牌的使用者的角色和分配給令牌的作用域完成的。
資料安全
傳輸中的資料
部署的服務/基礎設施元件的任何介面都不會直接暴露給外部傳入流量。
使用 HTTP API 選擇服務,通過閘道公開這些介面,所有傳入的 HTTPs(包括 WebSocket 的 HTTPs)在 ALB 中終止,並且通過 HTTP 的內部流量將路由到服務。
所有對外互動都透過 https / TLS(對於非 HTTP 協定)。
在VPC內部,服務之間的內部通信 - 通過HTTP /自定義TCP協定 - 通過普通TCP套接字。
靜態資料
存儲的所有數據都在存儲層加密。 此外,VPC 外部的數據存儲受到保護,訪問控制和授權,憑據安全地存儲在機密存儲中並進行管理。
下圖說明瞭傳輸和靜態的數據流和安全模型。
資料隱私
一般使用者 PII 資料
Webex CC Flow 是用於處理交互的程式設計控制器,可用於收集用戶數據,這些數據可以分配給專門標記為“包含敏感數據”的流變數。 此類數據的值已加密,數據的傳輸路徑中的任何服務都無法訪問此數據。
此外,此類數據永遠不會保留在CC報告數據存儲Webex並且日誌/消息傳遞基礎結構將具有加密數據並且明文數據不會存儲在CC Webex內的任何地方。
聯絡中心代理/監督員 PII 資料
聯絡中心使用者的相關資料在紀錄中會進行編輯,但可用於 Webex CC 資料儲存中的數據分析與可視化。
擴充能力
規模因素
對於 Webex CC,影響刻度的因素包括:
-
同時登入的代理數
-
進行中的同時互動數
-
對這些互動執行的操作
-
-
監督員/代理在處理互動之外執行的併發動作數
-
產生並保留的資料量
實現延伸的架構方面
Webex CC 的架構和設計所基於的原則使解決方案能夠在為各種服務和平臺元件預配的基礎結構強制實施的限制內根據需要動態擴展。
事件驅動架構
Webex CC 中的服務使用消息進行通信,關鍵消息處理流不涉及任何阻塞 IO 操作,並且處理消息所需的狀態已當地語系化為處理消息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務通過輕鬆添加/刪除服務的其他實例來實現彈性。 某些服務本質上是有狀態的,這些服務具有外部化的狀態存儲,並且基礎設施也支援動態更改此類服務的實例數量,並自動重新平衡/狀態傳輸/將狀態當地語系化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中運行,基礎設施(即 Kubernetes 節點)會根據使用方式自動擴展,這樣可以動態添加更多計算節點,直至達到預配置的最大高閾值。
負載預測和定期驗證
所有服務都針對性能特徵進行了基準測試,並在服務級別驗證了擴展模式。
進行進一步的持續驗證、峰值負載和耐久性測試,測試參數針對影響規模屬性的預計增長進行調整,從而能夠識別瓶頸,計劃更新基礎設施資源使用的高閾值,併為比賽日做好準備。
可靠性與可用性
事件驅動型架構和無狀態服務可實現復原能力和彈性。 但是,為了確保在功能受到影響之前檢測到故障並採取措施,Webex CC 採用以下策略。
-
基礎架構可用性和可靠性
-
所有Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用區中。
-
這使Webex CC 能夠靈活應對可用區故障,並且在發生故障時,故障實例將自動替換為較新的實例。
-
-
-
持續監控和警報
-
服務和基礎結構元件的內部和外部探測,在發生故障時觸發警報。
-
從服務和基礎架構元件捕獲並通過規則引擎處理的指標,該引擎檢測匹配規則並觸發警報。
-
-
持續驗證和警報
-
運行定期測試,任何失敗都會導致觸發警報
-
這些警報會創建主動事件,並作為影響客戶的真實事件進行處理。
-
這可以預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可以在 Webex CC 中快速可靠地構建、驗證和部署服務/更改服務。
-
執行完全自動化部署的能力 - 從代碼到生產環境,以及所有必需的驗證,在需要部署更改以回應故障時,可降低風險並最大限度地減少解決問題的時間。
-
-
-
斷路器和終止開關
-
系統的各個部分/Webex CC的某些功能可以有選擇地為所有客戶或選定的客戶禁用,以盡量減少故障的級聯效應。
-
這樣可以最大程度地減少故障表面,並實現核心聯絡中心功能對客戶的可用性。
-
-
監控與故障偵測
下圖顯示了針對 Webex CC 的連續監視、驗證和警報機制。
業務連續性和災難恢復
災難恢復和業務連續性流程可確保檢測區域內的任何大規模中斷,並採取必要的步驟來確保向該區域的客戶恢復服務。
根據災難恢復和管理流程定期記錄、驗證和更新恢復步驟。
Webex CC 服務部署在一個 AWS 區域內的三個獨立可用區中。 每個可用區都是區域中不同的物理位置,具有獨立的實用程式。
如果 AWS 區域完全發生故障,Webex CC 依靠 AWS 來恢復區域,對於涉及整個區域的長期中斷,將在新的 AWS 區域中預置 Webex CC 數據中心,並還原關鍵客戶配置和數據,以便聯絡中心可供新 AWS 區域中的客戶運行。
這涉及自動化,但需要手動干預來觸發流程,以及監控和確保恢復所需的配置和數據,以使聯絡中心為客戶運行。
合規性和認證
Webex Contact 擁有廣泛的安全認證清單。 這些認證會定期保持最新狀態。
-
PCI DSS QSA
-
CAIQ
-
海帕和高科技
-
CSA 星級 1 級
-
CSA 星級 2(第三方獨立評估)
-
SOC2
-
ISO27001(國際資訊安全標準)
-
ISO27017(雲端服務提供者的安全標準)
-
ISO27018(專注於保護雲中個人數據的安全標準)
-
ISO27701(資料隱私延伸)
-
C5 德國標準,展示了抵禦網路攻擊的操作安全性
有關更多詳細資訊Webex請參閱 Contact Center 服務隱私數據表 。
簡介
Cisco Webex Contact Center (Webex CC) 是一種Contact Center 即服務 (CCaaS),可讓組織在整個客戶全程體驗中實現更智慧、更主動的個人化互動。
Webex CC 是全新架構、設計和開發的雲端原生解決方案,具有以下核心架構原則。
-
服務:獨立的服務集,每個服務向其使用者提供一小部分連線的功能。
-
活動導向:所有服務都使用訊息傳遞相互通訊,除了在 Web 應用程式中應用程式針對特定用例使用 https 介面(REST API、透過 WebSocket 介面推送資料)的情況下。
-
無狀態/外部化狀態:服務部署在 Kubernetes 中,在 Docker 容器中執行,能夠自動調整一個或多個服務實例的故障並具有彈性。
-
可觀察的:所有服務及啟用此類服務的部署的基礎設施元件都是可觀察的,並透過標準機制進行測量、偵測和防止影響客服中心功能的狀況,並在中斷情況下快速進行疑難排解和還原服務。
-
隔離/松藕合:可以獨立構建、驗證和部署/更新每項服務,而不會影響客服中心的功能。
Webex CC 服務部署在 AWS 中,並由可啟用以下功能的雲端原生平台提供支援:
-
跨多個可用區的基礎架構服務和應用程式的可用性
-
基礎架構服務和應用程式的彈性,可實現動態擴充功能
-
安全性原生地內置在系統的建立和部署方式中, Webex CC 具有的安全性/合規認證在傳輸中和靜態資料中受到保護。
-
用於電話/語音整合的可擴展且安全的邊緣基礎架構
-
具有主動監控和警報的可觀察性,為其客戶提供客服客服中心服務的高可用性。
-
與Cisco Webex的其餘部分整合,以實現使用者驗證/授權、管理和佈建客服中心功能。
本文件中的其它章節對上述每項功能進行了擴展,以及Webex CC 架構如何啟用這些功能。
邏輯架構
客服中心解決方案必須具有的核心功能是讓客戶能夠透過常用的通訊方式輕鬆與組織聯絡,並以快速有效的方式解決查詢/問題。
但是,要確保實現此基本原則,使用客服中心的組織必須有權存取多種幕後功能。這些是:
-
客戶開始互動的機制
-
將電話呼叫連接至客服中心系統的已公佈及可運作電話號碼
-
客戶可傳送電子郵件的電子郵件地址以及偵測新收到的電子郵件的機制。
-
能夠讓客戶透過各種數位通道(包括但不限於
-
從網站/應用程式聊天
-
透過常用的傳訊用戶端(例如 WhatsApp、Facebook Messenger、Apple Messages for Business)直接聊天。
-
-
-
能夠偵測新的互動並有效處理它們
-
這些將包括自動化IVR系統、電話/聊天的虛擬代理,內建可編程功能,以定義處理互動所涉及的工作流程。
-
最後,如果需要,必須將互動上報給最擅長處理互動的客服。
-
-
客服人員能夠指示處理互動的線上狀態,並讓主管進行監控、指導客服人員並獲取實現高效互動的運營指標。
-
能夠讓管理員配置和佈建各種客服中心功能,使客服和主管如預期執行其工作。
除了這些之外,現代企業還需要新增功能,透過存取可可視化和追踪關鍵運營指標的資料和見解,來最佳化客服中心的運營。
此外,能夠與專門的客服中心生態系統功能整合,例如執行主動式自動外撥通話、使用 AI 增強客服和主管體驗、偵測和了解客戶全程體驗以主動向客服人員預先提供資料,這些都是客服中心解決方案的明顯差異化方式。正在演變。
關於使用模式,其中客服中心產品作為雲端提供的軟體服務使用,因此能夠確保可用性、可靠性和自動特定規模需求,需要最先進的監控和警報機制,從而持續驗證和檢測即將發生的問題,並防止/最大限度減少對客戶運營的影響。
下圖說明了Webex CC 的邏輯架構。
功能元件
下列章節描述Webex CC 的各種功能元件。
互動管理
Webex CC 支援電話、電子郵件和傳訊(社交通道),作為使用者可與客服中心互動的各種通道。
對於所有通道,可由系統完成初始處理,然後可以將互動上報給代理。
媒體類型
電話
對於電話,入埠語音通話的處理由來電進入客服中心的方式(請參閱下方的輸入機制)以及與進入點關聯的Webex CC Flow 決定。
通話會被接聽並根據Webex CC Flow 定義完成進一步的動作 – 這是在排隊和路由至代理之前,或者 Flow 本身可以處理通話時,以程式化方式表示處理通話時要執行的動作。不轉接給代理。
Webex CC 中的「流程建立器」可讓開發人員定義流程,並將其指定給通話到達Webex CC 的進入點。
這些組態實體及其用法在組態實體。
有關 Flow Builder 的更多資訊,將在即將推出的小節中涵蓋: IVR系統。
電子郵件和傳訊
從Webex CC 的角度來看, Webex Connect 為所有數位通道(電子郵件、傳訊通道)提供了輸入和輸出功能,最終使用者可使用這些通道來客服中心。
Webex Connect Flow
-
決定此類互動的處理方式,直到互動被排隊並路由給客服為止。這包括針對所有形式的傳訊和電子郵件互動的自動處理和 BOT 處理。
-
將業務邏輯套用至傳入的互動。
-
在排隊前處理聯絡。
-
Flow 本身可以處理互動,而無需轉移至在場代理。
Webex CC 支援的傳訊通道為:
-
Web 應用程式/行動應用程式 聊天
-
WhatsApp
-
Facebook Messenger
-
SMS
-
企業版 Apple Messages
Webex CC 支援的電子郵件通道為:
-
Gmail
-
Office365
入口機制
本節涵蓋互動進入Webex CC 的機制。根據媒體類型的不同,互動到達Webex CC 的機制也不同。
例如,在電話領域,需要佈建實體基礎設施來啟用 PSTN 連線、設定電話號碼以及將呼叫路由至Webex CC。
對於電子郵件/傳訊通道,必須在Webex Connect 中完成輸入設定,並且涉及電子郵件/傳訊帳戶Webex Connect 流程設定。
接入語音
對於語音通話,通常的情況是使用者撥打 PSTN電話號碼,然後連線至客服中心。從輸入的角度來看,這需要一種將通話路由從 PSTN 路由至Webex CC 的機制。
下圖說明了對Webex CC 的語音呼叫擷取。
Webex CC 中的 Voice Ingress 服務使用SIP執行第三方通話控制、傳入的呼叫以及執行轉接、會議和其他通話控制操作。
Webex CC 中通話的邏輯進入點是名為「入口點」的組態實體。對於語音輸入,入口點的關鍵設定是與其關聯的電話號碼,該電話號碼通常是從選擇的 PSTN 提供者處獲取的有效 PSTN電話號碼。
這樣可啟用偵測電話號碼上的來電、將通話與入口點關聯,並使用進入點的其他組態參數來根據應針對互動觸發的Webex CC Flow 定義來處理通話。
附註:
如需 PSTN 連線選項的相關詳細資訊,請造訪https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/Voiceonboarding2/wcc-voice-onboarding-2-book/wcc_b__voiceonboarding_private_conn.html。
語音邊緣基礎架構的可擴展性和可用性
Webex CC VPOP 基礎結構包括冗餘的SIP SBC 配對,可確保高可用性,而且可以新增更多的 SBC 來調整要支援的並行通話量。
VPOP 可以處理的最大並行通話取決於正在執行的 SBC 數以及通話所傳送的目標。
對於地理冗餘 – 支援跨地區跨地區多對具有互連的 VPOP SBC 網格。
語音輸入服務方面,可水平擴充,以處理越來越多的要擷取至Webex CC 的並行語音通話。
語音邊緣基礎架構的安全性考量
下表包含有關 Voice Edge 基礎結構的連線選項的詳細資料。
連線能力 |
類型 |
---|---|
公用網際網路 |
直接(使用白名單的來源IP位址) IPSec虛擬專用網路 (VPN) 或IPSec透過一般路由封裝 (GRE) 站點到站點 (S2S) SRTP/ SIP TLS |
私人連線 |
MPLS 點對點 (P2P) VPLS SD-WAN 專用 WAN 資料中心交叉連線 Equinix 結構連接 |
IVR系統
每個語音通話都會收到與入口點關聯的電話號碼,由Webex CC 接聽,且與入口點關聯的Webex CC Flow 會開始執行。
Webex CC Flow Builder 提供了編程構造/運算子和功能區塊(稱為活動),因此管理員或任何設計和實施IVR邏輯的任何人都可以組合這些構建塊並建立 Flow 定義。
Flow 支援的編程結構為:
-
聲明和設定變數 – 與流程執行關聯的狀態
-
用於設定變數值的 Pebble 表達式
-
-
條件檢查
-
循環 – 使用條件和轉至(將活動鏈結在一起的能力)
-
調用 REST API
-
解析資料 – JSON、TOML 和XML ,通常用於解析API回應。
-
撰寫活動
Flow 提供的一組具有代表性的活動包括:
-
播放訊息
-
收集使用者資料
-
將來電轉接至另一個目的地/電話號碼
-
將呼叫傳送至虛擬代理
-
將呼叫排隊,以便客服可以接聽。
對於每個處於活動狀態的通話,一個流程執行的實例也處於活動狀態,直到通話結束,從而導致流程的並行執行。
流程執行的每個實例都為與流程關聯的以及通過調用關聯的資料/狀態提供了隔離的環境。
在通話的整個生命週期中,流程還能夠對發生的某些事件做出回應並進行處理 – 譬如,當代理接聽通話時,事件處理程序可以在代理桌面介面中觸發螢幕彈出。
如需Webex CC Flow 的相關資訊,請參閱https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cust_contact/contact_center/webexcc/SetupandAdministrationGuide_2/b_mp-release-2/b_cc-release-2_chapter_0100.html#Cisco_Generic_Topic.dita_e338e055-64b0-4973-bd52-8a5581dcb0ee。
虛擬代理支援
Flow 提供了一項活動,以將互動轉接給虛擬代理,該代理是在Webex Control Hub 中預先設定的。
一旦通話連線至虛擬代理,即可向使用者提供對話式IVR體驗,而且活動會在通話終止或將通話上報給代理而結束。
在上報的情況下,流程可以配置為將通話排隊,然後由代理接聽。
接入數位互動
對於電子郵件和傳入互動的傳訊通道, Webex CC 使用Webex Connect 來佈建資產,流程來處理傳入的互動,然後在Webex Connect 流程明確將互動排入隊列以便可以通過以下方式處理時,將互動路由到Webex CC。代理。
下圖說明了Webex CC 中電子郵件的擷取、傳訊互動。
虛擬代理/BOT 整合
對於電子郵件和傳訊/社交通道互動,虛擬客服/ BOT 處理方式是在Webex Connect 流程中配置。
與語音虛擬代理一樣,如果 BOT 處理以因此而上報而結束,則互動會被排隊並路由給代理。
路由和隊列
Webex CC 會按照流程中的定義使用自動處理程序處理傳入的聯絡,並且流程可能會決定將聯絡加入佇列到隊列/直接到代理(代理特定的佇列 – 僅支援電話/語音互動)。
在排隊時,如果代理有空,則該代理會被保留,且互動會路由至該代理。如果沒有可用的代理,則互動將駐留在佇列上,且 Flow 將繼續處理具有附加至佇列活動的處理程序的客戶。
當代理可用時,處理常式會中斷,且互動會提供給代理。
下圖說明了隊列和路由架構。
代理選擇
Webex CC 中的佇列支援下列代理選擇算法:
-
線上時間最長的代理路由
-
技術型路由
-
線上時間最長的代理 (LAA)
-
最佳線上代理 (BAA)
-
客服透過團隊與隊列關聯。
一個佇列可以指派多個呼叫分配群組(每個群組具有一個或多個團隊),透過已設定的等待呼叫分配群組新增至佇列,因此相符代理的搜尋空間可擴展至其他隨著時間的推移,會撥話給分配群組。
對於基於技術的路由,在與佇列關聯的技術需求相符客服中,會根據 LAA 或 BAA 組態選擇客服。
語音/電話特定的其他功能
基於代理的路由 (僅適用於語音/電話通道)
Webex CC Flow 使用活動 佇列ToAgent,可以根據客服 ID 將互動直接路由至所選的客服。
如果代理無法處理互動,則互動可以停在代理特定的佇列中,等待代理變為可用
進階佇列資訊
Webex CC Flow 使用 GetQueueInfo 活動,可以擷取佇列的實時資訊,例如佇列中的位置 (PIQ)、預計的等待時間 (EWT)、佇列中可用的代理數,並可用於決定是否排隊與否。
禮貌回撥
Webex CC Flow 使用活動回撥,可讓客戶中斷通話,同時保持在佇列中的位置,並在佇列中的虛擬互動路由至代理時接收回撥。
溢位處理
Webex CC 支援使用基於容量的團隊 (CBT) 的溢位處理。
CBT 就像一個普通團隊,具有一定容量和為該容量提供服務的關聯外部DN 。它可以與「佇列呼叫分發週期」中的其他團隊一起配置。
通常,這會設定為最後一個週期,因此如果沒有可用的代理,即使所有已設定的呼叫分配群組無法找到可用的相符代理來處理互動,它也會充當溢位。
Agent Desktop操作
當代理登入Webex CC Agent Desktop時,代理會指定一個電話號碼,該號碼為代理的來電所可連線。如果代理是Cisco Webex Calling使用者,這可以是 PSTN 電話、行動電話或分機號。
請注意,此號碼必須是可將通話路由至的有效電話號碼。否則,客服將無法接聽來電。
根據客服正在處理的互動類型,客服桌面中的小工具提供執行某些媒體控制操作的能力。
譬如,接聽來電後,客服便可以執行下列與該通話相關的操作。
-
保留中通話
-
發起諮詢通話並
-
將來電轉接至另一個電話號碼(譬如代理電話號碼)/入口點
-
與另一代理開會加入通話
-
-
將呼叫轉接至另一個佇列
-
結束通話
客服桌面允許管理員透過擴展桌面功能並使其成為客服人員高效完成工作所需的統一的小工具集合來新增自訂小工具。
桌面架構
客服桌面是一個基於微型前端的單頁面應用程式,其中託管基於 Web 元件架構而建立的小工具。所有標準/庫存小工具都由 API 或伺服器端推送機制擷取的資料提供支援。
這些通常是異步 API,其中調用的回應透過 WebSocket 連線來到桌面。
Webex CC Agent Desktop使用Cisco公共身份識別 (CI) 驗證使用者,並且將權杖傳遞給所有API調用。對於自訂小工具,如果自訂小工具的驗證模型與 CI 整合,它將根據驗證模型向代理提供單一登入體驗。
一旦代理成為互動的一部分,該互動狀態或關聯資料的所有更新也將透過 WebSocket 連線推送到桌面。
桌面對連線和延遲的彈性
異步API和伺服器端推送可實現縮放,並且會偵測到 WebSocket 介面的任何連線中斷,以及桌面嘗試重新連線和重新登入。
下圖說明了Webex CC 中的客服桌面架構。
管理和設定
加入客戶
Webex Control Hub 是合作夥伴和客戶用於加入客戶以及啟用或設定功能的主要介面。
一旦在 Control Hub 中佈建組織和客服中心功能,將觸發Webex CC 中的工作流程,該工作流程根據客戶選擇的產品執行佈建所有客服中心功能的其餘步驟。
所有客服中心的佈建都是使用 BPM 工作流程引擎完成的,該引擎啟用了聲明性方式來定義所涉及的步驟,並使整個佈建步驟能夠復原失敗並確保資料完整性。
下圖說明了Webex CC 中的佈建工作流程。
組態實體
Webex CC 中的組織範圍內的關鍵組態實體是:
網站
網站代表一個或多個團隊、使用者(代理/主管)所在的位置。
每個使用者和團隊必須屬於一個網站。
團隊
一組使用者。團隊用於透過佇列將互動分發給客服。
每個團隊必須屬於一個網站。
代理
可以登入Agent Desktop並處理Webex CC 中設定的跨媒體類型的互動的使用者。
監督員
監督人員會指定給團隊,可以監控/指導客服,並且可以存取團隊層級狀態以及客服統計資料。
佇列
佇列是一個邏輯實體,可以在其中保留互動,同時等待代理可用,然後將其路由給代理。
佇列會映射至團隊(作為客服的搜尋空間),並能夠透過將其他團隊新增至搜尋空間來根據經過時間臨界值來擴展搜尋空間。
入口點
入口點是一個邏輯實體,代表進入Webex CC 的互動的入口點。對於電話,這主要對應通話到達的電話號碼;對於電子郵件/傳訊通道,入口點會指向Webex Connect 中的資產組態。
流動
與進入點關聯的流程(透過路由策略),它決定處理互動所涉及的步驟。
對於非電話通道(電子郵件、傳訊/社交),已選擇 Flow 作為Webex Connect 中資產設定的一部分。
多地點客服中心的存取控制
Webex CC 管理員可以設定使用者設定檔,使其具有對特定網站、團隊、佇列和入口點的存取權。此外,由於網站和團隊的層次結構,一旦提供對特定網站的存取權,使用者只能存取屬於那些網站或此類團隊的明確指定子集的團隊或日期。
佇列和進入點在組織層級是全局的,所以對於不同的地理位置(特定客服和團隊所在的網站),可以設定單獨的進入點和佇列,並且監督人員/使用者可以存取那些適用的實體用於特定網站。
下圖說明了關鍵組態實體和參考這些實體的使用者設定檔。
除了限制對這些實體的存取之外, Webex CC 管理員還可以控制使用者可在管理介面中存取的特定功能/模塊,從而使使用者俱有Webex CC 的特定實體以及區段/功能的管理/設定權利。管理介面。
報告和分析
Webex CC 使用一系列實時串流處理服務來處理互動生命週期中由各種服務產生的離散事件,並產生一組定義的實時資料集,並公佈給訂閱的用戶端。
此外,這些事件會被進一步處理、轉換和聚集,並保留產生的資料集,然後透過資料使用 API 以及報告及資料可視化介面 – 分析器來擷取。
下圖說明了Webex CC 中的資料處理和使用介面
整合
所有與 WxCC 的外部整合以充實和增強客戶可使用的功能,均使用標準已公佈的 API。
Webex CC 中可用的API介麵類型包括:
-
REST API
-
伺服器端推送使用
-
Webhook
-
WebSocket 訊息
-
CRM 整合
Webex CC 支援與客戶關係管理 (CRM) 系統的兩種整合模式。
-
桌面嵌入式連接器
-
在IVR中透過 HTTP(S) 連接器的 Flow 整合
桌面內嵌的連接器:將 CRM 應用程式作為主要介面
在此操作模式下,客服會以主要應用程式身份登入 CRM 主控台。
Webex CC 是內嵌應用程式(也稱為內嵌桌面應用程式或內嵌軟體電話),主要用於登入客服中心並接收Webex CC 路由的客服中心互動。
收到通話或對話請求時,CRM 整合會在 CRM 主控台上執行以下動作
-
螢幕會彈出與 ANI 或其他通話關聯資料關聯的客戶記錄。
-
在客戶記錄上將通話後中繼資料作為活動附註
-
透過按一下 CRM 內的聯絡人並向客戶起始輸出通話,允許客服「按一下一按撥入」
-
將通話記錄公佈到 CRM 報告表格中,以在 CRM 上進行主要報告。
-
提供Agent Desktop和通話控制項的完整功能(桌面應用程式的內嵌和精簡版)
與 CRM 整合的主要模式是將Webex CC Desktop 應用程式內嵌在單獨的 iFrame 中。
此外, Webex CC Desktop 應用程式執行一個自訂的無頭 widget(無使用者介面)在後台執行,與底層的 CRM 系統互動,以代表代理執行自動動作。
互動由無頭 widget 使用的兩個 SDK 提供支援。
-
Webex CC 桌面 JS SDK:這是Webex CC 提供的 JavaScript SDK,用於註冊代理和聯絡動作的事件偵聽器。
-
CRM JS SDK:這是適用於每個 CRM 的 CRM 用戶端 SDK,用於提取 CRM 的 REST API呼叫。例如,對於 Salesforce,由 Salesforce 提供的CTI JS 資料庫用於執行動作並偵聽 CRM 內部的事件。
下圖說明了 CRM 內嵌的Webex CC 桌面和連接器架構
Webex CC 支援下列 CRM 解決方案來實現上述整合:
有關設定Webex CC 桌面版面配置以啟用 CRM 連接器、功能集和變更日誌的更多資訊,請造訪https://github.com/Ciscodevnet/webex-contact-center-crm-integrations。
CRM 連接器的全球可用性
CRM 連接器在Webex CC 運作的所有地理和地區都可用。
彈性規模與效能
Webex CC 託管自訂小工具,可在 AWS CloudFront CDN 中實現 CRM 應用程式與Webex CC 桌面之間的雙向通訊,確保小工具 AWS 跨可用區和地區的高可用性。
所有 CRM 整合的特定計算都發生在客服使用 CRM 應用程式的瀏覽器上,且Webex CC 桌面版內嵌在 CRM 應用程式中。
安全功能
CRM 連接器透過Webex CC 代理桌面佈局調用,可選參數透過桌面佈局傳遞到小工具,以開啟和關閉功能。
例如,若要啟用 Salesforce 動作小工具,管理員可以將桌面版面配置參數設定 sfdcwidget 啟用為 true。
套件安裝
要讓整合雙向運作,CRM 主控台需要安裝內嵌的應用程式。這是為了支援在 iFrame 中載入桌面應用程式。
所有桌面內嵌式連接器都可在 CRM 市場上獲得。
譬如,
Zendesk: https://www.zendesk.com/marketplace/apps/support/202570/webex-contact-center/
Marketplace 應用程式安裝會啟動所需的外掛程式,並將所需的XML檔案匯入 CRM 主控台,以支援 CRM 上的通話記錄報告。
透過IVR中的 HTTP(S) 連接器進行流程整合
「 Webex CC Flow」建立器支援Webex CC 與 CRM 系統之間的雙向資料流,使用在Webex Control Hub 中設定並在Webex CC Flow 上使用的 HTTP(S) 連接器。
這些主要用於IVR中語音互動和自訂路由中的個人化。
依預設, Webex CC 支援 Control Hub 上的 Salesforce HTTP 連接器。其他 CRM 連接器可在Webex Control Hub 上新增為自訂連接器。
如需 HTTP 連接器的相關資訊,請造訪https://github.com/CiscoDevNet/webex-contact-center-crm-integrations。
IVR HTTP 連接器:
-
Salesforce IVR HTTP 連接器(內建): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Salesforce/salesforce-ivr-http-connector
-
Zendesk IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/Zendesk/zendesk-ivr-http-connector
-
ServiceNow IVR HTTP 連接器(自訂): https://github.com/CiscoDevNet/webex-contact-center-crm-integrations/tree/main/ServiceNow/servicenow-ivr-http-connector
外傳活動管理
Webex CC 支援使用 Acqueon 的活動管理解決方案的輸出預覽活動。
如需相關資訊,請參閱在Webex Contact Center 中配置語音外發活動模式。
員工最佳化
Webex CC 支援來自業界領先供應商的工作流程最佳化和品質管理解決方案。
擴展Agent Desktop
Webex CC 客服和主管桌面透過在桌面中開發和執行自訂小工具來啟用桌面功能的延伸。
有關更多詳細資訊,請造訪https://developer.webex-cx.com/documentation/guides/desktop。
其他 API
如需可在Webex CC 中執行的其他API整合的詳細資訊,請造訪https://developer.webex-cx.com/documentation/getting-started/。
部署和連線
Webex CC 部署在 AWS 中,目前在下列地區提供
-
US
-
美國-東弗吉尼亞州
-
美國-加利福尼亞州西部(僅限語音媒體輸入)
-
-
加拿大
-
中部
-
-
英國
-
倫敦
-
-
歐洲
-
法蘭克福
-
-
亞太地區
-
東京
-
雪梨
- 新加坡
-
可使用網際網路或使用 Amazon 網路 Services (AWS) Direct Connect 建立與 AWS 託管的Webex Contact Center 的連線。借助 AWS Direct Connect,可透過客戶內部部署網路與Webex Contact Center 之間的私人網路連線來傳遞資料,從而改進連線。有關更多詳細資訊,請參閱適用於Webex Contact Center 的 AWS Direct Connect 。
電話的多區域連線
對於在多個地理位置擁有代理和客戶的全球性組織, Webex CC 支援將媒體保留在本地區域內,對於那些執行語音媒體邊緣和輸入服務的區域。
下圖說明了使用區域媒體的多區域部署。
媒體邊緣及輸入服務部署在以下地區。
地理區域 |
Webex CC 服務(AWS 區域) |
Media Edge(語音 彈出) |
新一代媒體服務(AWS 區域)* |
---|---|---|---|
US |
弗吉尼亞北部 |
紐約 洛杉磯 |
弗吉尼亞北部 北加利福尼亞 |
加拿大 |
中部 |
溫哥華 多倫多 |
中部 |
巴西 |
聖保羅 里約熱內盧 |
||
歐洲 |
法蘭克福 |
法蘭克福 阿姆斯特丹 |
法蘭克福 |
英國 |
倫敦 |
倫敦 |
倫敦 |
印度 |
浦那 海德拉巴 |
孟拜 |
|
新加坡 |
新加坡 |
新加坡 |
|
日本 |
東京 |
東京 大阪 |
東京 |
澳洲 |
雪梨 |
墨爾本 雪梨 |
雪梨 |
安全性和隱私權
基礎設施安全
Edge 的語音基礎架構
Voice Edge 元件允許來自客戶網路/ PSTN 電訊廠商的SIP中繼線終止,這是根據已加入白名單且允許連線至 Edge 元件的 Ips 啟用的。
計算基礎架構安全性
Webex CC 計算實例在 AWS 中佈建,服務在具有多個命名空間的 Kubernetes 叢集中作為 Pod 執行,並且使用單獨的憑證限制對每個命名空間的存取權。
所有基礎架構佈建均使用代碼完成 — 無手動步驟 — 且無法手動存取任何憑證。
有一個中央憑證儲存區,其中為特定的服務/團隊集設定了特定的路徑,而且對憑證儲存區本身的存取受到限制,並在構建和部署系統中設定為密碼。
所有基礎設施元件/服務都不會直接暴露在 AWS VPC 之外,唯一公開的介面是使用 api 閘道控制和管理的 API 和 WebSocket 伺服器,
除此之外,開發人員會使用某些內部系統和介面,用於檢視記錄、指標、部署詳細資料、組建狀態和測試結果,這些系統和介面會使用角色和群組保護,並與Cisco內部驗證系統整合。
使用者介面的驗證和授權
各個客服中心使用者(客服、主管、管理員、分析師)使用的所有使用者介面都受到基於Cisco公共身份識別的持有人權杖驗證(OAuth 流程)的保護。
授權是使用取得權杖的使用者的角色和指定給權杖的範圍來完成的。
資料安全
傳輸中的資料
所部署的服務/基礎架構元件的所有介面都不會直接暴露給外部傳入流量。
選取服務,使用 http API 透過閘道公開這些介面,所有傳入的 https(包括 WebSocket 的那些)都在 ALB 中終止,並且透過 http 的內部流量路由至服務。
所有傳出互動均透過 https / TLS (適用於非 http 通訊協定)進行。
在 VPC 內部,服務之間的內部通訊(透過 http / 自訂TCP通訊協定)是透過純TCP通訊端進行的。
靜態資料
所有被儲存的資料都會在儲存層加密。此外,那些 VPC 外部的資料儲存區受到保護,存取控制及授權及憑證安全地儲存在密碼儲存區中,並進行管理。
下圖說明了中轉及靜態的資料流及安全性模型。
資料隱私權
最終使用者 PII 資料
Webex CC Flow 是用於處理互動的程式化控制器,可用於收集使用者資料,這些資料可指定給特別標記為「包含敏感資料」的流程變數。此類資料的值已加密,且資料中轉路徑中的任何服務都無法存取此資料。
此外,此類資料不會保留在Webex CC 報告資料存放區區中,且記錄/傳訊基礎架構將具有加密資料,而明文資料不會儲存在Webex CC 中的任何位置。
Contact Center 代理/主管 PII 資料
與客服中心使用者相關的資料會在記錄中編輯,但可用於Webex CC資料存放區區中的資料分析和可視化。
延展性
比例因素
對於Webex CC,影響比例的因素有:
-
並行登入的客服數
-
進行中的互動數
-
對這些互動執行的動作
-
-
監督人員/客服人員在處理互動之外執行的並行動作數量
-
產生和持續的資料量
實現擴展的架構方面
Webex CC 的架構和設計所基於的原則可讓解決方案在為各種服務和平台元件佈建的基礎架構強制執行的限制內,根據需要進行動態調整。
事件驅動的架構
Webex CC 中的服務使用訊息進行通訊,而且關鍵訊息處理流程不涉及任何封鎖 IO 操作,而且處理訊息所需的狀態已本地化為正在處理訊息的服務實例。
無狀態服務(或外部化狀態)
無狀態服務透過輕鬆新增/移除其他服務實例來啟用彈性。有某些服務本質上是有狀態的,這些服務具有外部化的狀態儲存區,而且基礎架構也支援這些服務的實例數量的動態變更,包括自動重新平衡/狀態轉移/將狀態本地化為需要狀態的實例。
彈性基礎架構
所有服務都在 Kubernetes 中執行,基礎架構 (即 Kubernetes 節點) 會根據使用情況自動擴展,這樣便能動態地新增更多計算節點,直至達到預先設定的最大高臨界值。
負載投影和定期驗證
所有服務都已針對效能特徵進行基準測試,並在服務層級驗證縮放模式。
進一步的持續驗證、尖峰負載和耐久性測試會使用已針對規模影響屬性的預計增長進行調整的測試參數,從而能夠識別瓶頸、計劃更新基礎設施資源使用的高臨界值,並為比賽日做好準備。
可靠性和可用性
事件驅動的架構和無狀態服務可實現彈性和彈性。但是,為了確保在功能受到影響之前能夠檢測到故障並採取行動, Webex CC 採用了以下策略。
-
基礎架構可用性和可靠性
-
所有Webex CC 服務和基礎設施元件始終部署在三個 AWS 可用性區域中。
-
這樣Webex CC 能夠彈性地因應可用區故障,而且在發生故障時,會自動將失敗的實例替換為較新的實例。
-
-
-
持續監控和警示
-
服務和基礎架構元件的內部和外部探測器,在失敗時會觸發警示。
-
從服務和基礎架構元件擷取並透過規則引擎處理的指標,可偵測相符規則並觸發警示。
-
-
持續驗證和警示
-
執行定期測試,任何失敗都會導致觸發警示
-
這些警示會造成主動突發事件,並作為影響客戶的真實突發事件處理。
-
這樣可預先預防對客戶的影響,並有助於提高系統的可用性和可靠性。
-
-
-
持續整合和交付
-
這是工程流程和交付管道,可在Webex CC 中快速可靠地建立、驗證和部署服務/服務變更。
-
如果需要部署變更以因應失敗,那麼能夠進行完全自動化的部署(從代碼到生產環境)以及所有必要的驗證,可以降低風險並最大限度縮短解決問題的時間。
-
-
-
斷路器和終止開關
-
可以有選擇地為所有客戶或選取客戶停用系統的各個部分/ Webex CC 的某些功能,以盡量減少故障的串聯影響。
-
這樣可最大限度減少故障面,並為客戶實現核心客服中心功能的可用性。
-
-
監控和故障偵測
下圖顯示了適用於Webex CC 的持續監控、驗證和警報機制。
業務持續與災害復原
災害復原和業務持續流程可確保偵測到某個地區內任何大規模的中斷,並會採取必要步驟來確保向該地區內的客戶恢復服務。
復原步驟會根據災害復原和管理流程進行記錄、驗證,並保持定期更新。
Webex CC 服務部署在一個 AWS 區域內的三個單獨的可用性區域中。每個可用區都是該地區中的不同實體位置,並具有獨立的公用程式。
如果 AWS 區域完全故障, Webex CC 依靠 AWS 來復原該區域,而且對於涉及整個區域的長時間中斷, Webex CC資料中心會在新的 AWS 區域中佈建並還原關鍵客戶設定和資料,以便客服中心能夠為新的 AWS 區域中的客戶提供服務。
這涉及自動化,但需要手動干預才能觸發流程,以及監控並確保還原所需的設定和資料,以使客服中心為客戶提供所需的運作。
合規性和憑證
Webex Contact 具有大量安全性認證清單。這些認證會定期更新。
-
PCI DSS QSA
-
CAIQ
-
HIPAA 與 HItech
-
CSA 星級 1 級
-
CSA 之星 2 級(協力廠商獨立評估)
-
SOC2
-
ISO27001(資訊安全的國際標準)
-
ISO27017(雲端服務提供者的安全性標準)
-
ISO27018(專注於保護雲端中個人資料的安全標準)
-
ISO27701(資料隱私權擴充)
-
C5 德國標準,展示針對網路攻擊的作業安全性
請參閱Webex Contact Center 服務隱私權資料表 獲取更多詳細資訊。