本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
Connect Customer 中的案例和部署方法
Connect Customer 提供自助式組態,並透過各種遷移和整合選項,在任何規模上啟用動態、個人和自然的客戶互動。在本節中,我們會說明為 Connect Customer 設計工作負載時應考慮的下列案例和部署方法:
-
傳統的聯絡中心
-
傳入
-
傳出
-
混合式聯絡中心
-
傳統聯絡中心遷移
-
虛擬桌面基礎架構 (VDI)
傳統的聯絡中心
傳統的聯絡中心需要大量的電話、媒體、網路、資料庫和運算基礎架構,這些基礎架構要能夠橫跨多個供應商和資料中心位置,以便為聯絡提供服務。每個單獨的解決方案和廠商都有獨特的硬體、軟體、網路和架構需求,在解決版本控制、相容性和授權衝突時,必須滿足這些需求。
對於本地和遠端客服人員硬體和 VPN 連線、文字轉語音 (TTS)、自動呼叫分配 (ACD)、互動式語音回應 (IVR)、語音音訊和資料、實體桌面電話、語音錄製、語音轉錄、聊天、報告、資料庫、電腦電話整合 (CTI)、自動語音辨識 (ASR) 和自然語言理解 (NR),通常會有不同的廠商和基礎架構需求。當您考慮多階段開發、品質保證和測試環境時,您的聯絡中心架構和基礎架構會變得更加複雜。
典型的 Connect Customer 部署可解決或減少許多與版本控制、相容性、授權、聯絡中心電話基礎設施和維護相關的挑戰。讓您能夠幾分鐘內在新位置靈活建立執行個體,以及單獨或平行遷移元件,以最符合您個別的業務目標。您可以使用 IVR/ACD 流程、透過支援的網頁瀏覽器將語音和資料傳送到客服人員的軟體電話、移植現有電話號碼、將軟體電話音訊重新導向至現有的桌面電話、在流程中以原生方式調用 Amazon Lex 機器人以進行 ASR 和 NLP 流程,以及使用相同的流程進行聊天和語音。您可以使用 Connect Customer Contact Lens 自動產生語音轉錄、執行關鍵字識別和情緒分析,以及對聯絡進行分類。對於客服人員 CTI 資料和即時語音串流,您可以使用 Connect Customer Agent Event Streams 和 Kinesis Video Streams。您也可以建立多階段開發、品質保證和測試環境,無需額外費用,而且只需按使用量付費。
傳入
傳入是一個聯絡中心術語,用來描述聯絡人向聯絡中心發起的請求。聯絡人可以聯絡 Connect Customer 執行個體以取得傳入自助服務,或以各種方式與即時客服人員交談,包括語音和聊天。語音聯絡人會通過 PSTN,並透過執行個體中宣告的電話號碼路由到 Connect Customer Instance 電話進入點。您可以直接向 Connect Customer 保留電話號碼、移植現有的電話號碼,或將語音聯絡人轉送給 Connect Customer。Connect Customer 可以在支援服務的所有區域中提供當地和免付費電話號碼。
將通話撥打至在 Connect Customer 執行個體中宣告或移植到您 Connect Customer 執行個體的號碼時,會叫用與呼叫號碼相關聯的流程。您無須具備編碼的知識,即可使用流程區塊來設定流程的定義。流程決定應如何處理和路由連絡人,選擇性地提示聯絡人提供其他資訊以協助路由決策、將這些屬性儲存到聯絡人詳細資訊中,並在必要時將該聯絡人路由至客服人員,並在過程中收集所有通話詳細資訊和文字記錄。透過流程,您可以叫用 AWS Lambda 函數來查詢客戶資訊、呼叫 Amazon Pinpoint AWS 等其他服務來傳送簡訊,以及使用原生 AWS 服務整合,包括 Amazon Lex for NLU/NLP 和 Kinesis Video Streams 來即時串流語音通話。
如果傳入聯絡需要聯繫客服人員,則該聯絡會放入佇列中,並根據您的路由組態,待客服人員將其狀態變更為有空時,將其路由傳送至客服人員。手動或透過自動接受組態接受可用客服人員的聯絡時,Connect Customer 會將聯絡案例與客服人員連線。
當傳入聯絡人來自聊天工作階段的瀏覽器或行動應用程式請求時,請求會路由到呼叫 Connect Customer 聊天 API 的 Web 服務或 Amazon API Gateway 端點,以調用請求中設定的流程。您可以使用相同的流程進行聊天和語音,其體驗是根據流程中定義的邏輯動態管理和路由。
傳出
Connect Customer 可讓您以程式設計方式對本機和國際端點進行對外聯絡嘗試、縮短聯絡之間的客服人員設定時間,以及改善客服人員生產力。透過使用 Connect Customer Streams
傳出廣告通常由 CRM 導出的聯絡資料驅動,並分成聯絡清單。這些聯絡案例會排定優先順序,並交付給客服人員,以便在預覽期間之後啟動,或使用 Connect Customer Outbound API 以程式設計方式聯絡,由您的流程邏輯驅動,並視需要連線至客服人員。典型的對外聯絡中心使用案例包括欺詐和服務警示、收集和約會確認。
混合
如果您有在 Connect Customer 與舊版聯絡中心技術之間傳輸聯絡人的需求,您可以使用混合模型架構,透過傳輸傳遞聯絡人資料。例如,舊版聯絡中心平台上的銷售業務單位可能需要將通話轉接至已遷移至 Connect Customer 的服務業務單位。如果沒有混合式架構,將會遺失通話詳細資訊,並可能需要聯絡人重複資訊。這可能會增加處理時間,並可能導致為相同目的再次聯絡通話。
混合架構會要求您申請與預期並行聯絡人上限相同的電話號碼,以及 Connect Customer 和舊版聯絡中心平台可存取的中介狀態資料庫。當另一個平台需要轉接時,您將使用這些電話號碼之一作為唯一標識符,在中介資料庫中將其標記為使用中,插入您的聯繫方式,並在轉接聯繫人時將該號碼用作您的 ANI 或 DNIS。當其他聯絡中心平台收到聯絡時,您將根據您使用的唯一 ANI 或 DNIS 查詢中介資料庫中的聯絡詳細資訊。由於相關的額外成本和複雜性,混合式架構通常用作臨時遷移步驟。
僅限 IVR
您可以選擇使用 Connect Customer 來驅動聯絡的 IVR 體驗,同時您的客服人員人員仍保留在您的舊版聯絡中心平台上。透過此方法,您可以使用 Connect Customer 流程來推動自助式和轉接邏輯,並視需要將聯絡人轉接至舊版聯絡中心平台上的目標客服人員或客服人員佇列。
在此圖表中,聯絡人會撥打 Connect Customer 執行個體中宣告的電話號碼進行服務。如果需要轉接到舊版聯絡中心平台上的客服人員,則會叫用 AWS Lambda 函數來查詢可用的唯一電話號碼,將其標記為使用中,並將相關的聯絡詳細資訊寫入中介資料庫。然後,聯絡會使用從 Lambda 函數傳回的電話號碼轉接到舊版聯絡中心平台。然後,舊版聯絡中心將對中介資料庫執行聯絡詳細資訊的查詢,對應路由,然後重設中介資料庫中的聯絡資料,以便再次使用電話號碼。
僅限客服人員
透過此方法,您的舊版聯絡中心 IVR 會驅動聯絡人的 IVR 自助服務和轉接邏輯,並視需要將聯絡人轉接至 Connect Customer,以轉接至您的客服人員人員。
在此圖表中,聯絡人會撥打您舊版聯絡中心平台取得的電話號碼。如果需要轉接給 Connect Customer 上的客服人員,舊版聯絡中心平台會查詢可用的唯一電話號碼、將其標記為使用中,並將相關的聯絡詳細資訊寫入中介資料庫。然後,聯絡人將使用舊版聯絡中心查詢傳回的電話號碼轉接給 Connect Customer。Connect Customer 接著會使用 查詢中介資料庫中的聯絡詳細資訊 AWS Lambda、相應路由,以及重設中介資料庫中的聯絡資料,以便再次使用電話號碼。
混合
在此案例中,您可能會讓 IVR 和客服人員在 Connect Customer 和舊版聯絡中心平台上平行操作,以允許網站、客服人員群組或line-of-business遷移。
傳統聯絡中心遷移
當您評估 Connect Customer 是否有新的或現有的工作負載時,您可以考慮幾個策略。對於在 Connect Customer 與舊版聯絡中心解決方案之間轉接聯絡人時,需要包含聯絡詳細資訊的情況,則需要混合模型架構,直到遷移完成為止。本節中描述的方法可讓您分階段移動特定業務範圍、管理訓練和支援,以及降低與變更相關的風險。
新的工作負載
您可以透過在 Connect Customer 上採用新工作負載,降低現有業務單位變更的相關風險,並提高靈活性和數位創新潛力。全新工作負載不需要混合模型架構,因此複雜性較低,不受業務程序或客服人員常式變更的影響,而且上市時間更快。採用全新的工作負載可讓您充分利用以使用量為基礎的依用量計費定價。您的客服中心資源可以為終端使用者創造全新體驗、測試和實作以評估平台、獲得信心,並建立技能和作業機制,以準備跨現有工作負載進行大規模移轉。
IVR 優先
您可以選擇使用 Connect Customer 來驅動聯絡的 IVR 體驗,同時您的客服人員人員仍保留在您的舊版聯絡中心平台上。透過此方法,您可以使用 Connect Customer Flows 來推動自助式和轉接邏輯,並視需要將聯絡人轉接至舊版聯絡中心平台上的目標客服人員或客服人員佇列。
IVR 最後
透過此方法,您的舊版聯絡中心 IVR 會驅動聯絡人的 IVR 自助服務和轉接邏輯,並視需要將聯絡人轉接至 Connect Customer,以轉接至您的客服人員人員。
業務線細分
如果您的企業營運單獨具有獨立的 IVR,或者不需要將聯絡人轉移到舊版客服中心平台,則可能會想要考慮採用企業營運部門遷移方法。例如,選擇您內部支援的服務台,作為業務遷移的第一線。將服務台 IVR 和客服人員人口遷移至 Connect Customer 之後,您可以選擇將現有的聯絡人轉送至 Connect Customer,並在測試和業務驗證完成後移植端點。
網站或客服人員群組細分
如果您的聯絡中心遍佈全球、來自多個國家/地區的服務聯絡人,或是由各自的地理位置或地點獨立管理,您可能需要根據客服人員的實際網站或地理位置來考慮遷移方法。每個客服人員和/或地理位置都有其獨特的需求和考量,可能不適用於全球。透過這種方式處理您的遷移作業,可讓每個位置或客服人員群組獲得所需的技能,以便繼續獨立運作,然後再移至下一個位置。
虛擬桌面基礎架構 (VDI)
雖然您可以在虛擬桌面基礎設施 (VDI) 環境中使用 Connect Customer Contact Control Panel (CCP),但它會為您的解決方案增加另一層複雜性,這需要單獨的 POC 工作和效能測試才能最佳化。設定/支援/最佳化最好是由您的 VDI 支援團隊處理,而下列是最常實作的部署模式。
具有本機瀏覽器存取權的 VDI 用戶端
您可以使用 Connect Customer Streams
Citrix VDI 搭配 Connect Customer 音訊最佳化
如果您使用 Citrix Virtual Desktop Infrastructure (VDI) 環境,您可以使用 Connect Customer RTC JavaScript 程式庫建置自訂 CCP,該程式庫與 Citrix United Communications SDK (ucsdk) 整合,並自動將媒體從本機桌面重新導向至 Connect Customer。讓您的客服人員可以使用 Citrix VDI 用戶端應用程式 (例如 Citrix Workspaces) 連線至其自訂客服人員應用程式或自訂 CCP。這樣就無需開發和管理獨立的客服人員應用程式 (例如雙 CCP),用於 Citrix 環境的音訊媒體重新定向。下圖說明該方法:
注意
此解決方案需要您允許 VDI 伺服器與 Connect Customer 之間的 WebRTC 訊號流量,以及客服人員桌面與 Connect Customer 之間的媒體連線。如需詳細資訊,請參閱設定您的網路以使用 Connect Customer Contact Control Panel (CCP)文件。
Amazon WorkSpaces VDI 搭配 Connect Customer 音訊最佳化
透過使用虛擬桌面基礎設施 (VDI) 環境 Amazon WorkSpaces,您可以使用 Connect Customer Real-Time Communications (RTC) JavaScript 程式庫建立自訂的聯絡控制面板 (CCP)。此程式庫與 Amazon WorkSpaces SDK 無縫整合,可自動將媒體從本機桌面重新導向至 Connect Customer。如此,就無須為了 WorkSpaces 環境內的音訊媒體重新導向,特地開發和管理獨立的客服人員應用程式 (例如雙 CCP)。下圖說明此方法。
Omnissa VDI 搭配 Connect Customer 音訊最佳化
Omnissa Virtual Desktop Infrastructure (VDI) 解決方案可透過實作自訂聯絡控制面板 (CCP),與 Connect Customer 進行簡化整合。
透過使用 Connect Customer RTC JavaScript 程式庫搭配 Omnissa 的 Horizon WebRTC SDK,音訊處理是透過將媒體串流直接從代理程式的本機端點重新導向至 Connect Customer 來進行最佳化。此架構消除了過往透過虛擬桌面進行音訊轉接的挑戰,讓客服人員在使用其 Omnissa VDI 環境時享有絕佳的語音體驗。此解決方案消除了管理個別音訊重新導向應用程式的複雜性,為客服人員互動提供了單一整合介面。下圖說明此架構方法。
不具有本機瀏覽器存取權的 VDI 用戶端
有時 VDI 用戶端不具有本機瀏覽器存取權。在此情境中,您可以建立具 VDI 伺服器執行媒體執行的單一 CCP 執行個體,以允許存取企業資源。對於此部署模型,UDP 音訊通常在 VDI 作業系統上啟用。此部署模型需要進行大量測試,才能校準不同的 VDI 伺服器參數,以最佳化體驗品質: