自訂虛擬客服整合的資源

本頁提供幫助規劃和實施自訂虛擬客服專員整合的參考資訊和資源。

架構

當設計您的自訂虛擬客服專員整合時，需要注意一些與延遲相關之重要考慮因素。最佳做法是讓自訂終點僅與架構中的一個元件互動。在單個請求期間，與終點互動的元件越多，發生延遲的可能性就越大。元件就是一個過程，例如語音轉文字或自然語言理解引擎。

以下範例顯示容易出現延遲的架構。這是因為要產生單一請求的回應需要多個 API 互動。

該圖顯示了一種整合，其中代理隧道將對 SST、TTS 和 NLU 服務進行三次單獨的 API 調用。

更有效的架構對每個請求僅進行一次互動。這最大限度地減少了與聯絡人談話期間發生延遲的機會。

該圖顯示了一種整合，其中代理隧道僅將對虛擬客服專員進行一次 API 調用。

代理隧道和 Webhook 設計

代理隧道是 CXone 與您的虛擬客服專員服務的終點之間的中介軟體。所有請求和回應都要透過其傳輸。此外，它可以將請求和回應轉換為目標系統所需的格式。下圖顯示了此過程：

該圖顯示了每個系統都有各自的格式，CXone 和代理隧道之間為實線箭頭，代理和虛擬客服專員之間為虛線箭頭。

該圖顯示代理隧道收到來自 CXone（用實線顯示）的請求，並將其翻譯成虛擬客服專員可以理解的格式（用虛線顯示）。然後，它接收來自虛擬客服專員的回應（虛線），並將其轉換為 CXone 能夠理解的格式（實線）。

重要的是要了解 CXone 和虛擬客服專員的模式，以及您的具體整合計劃的要求。必須要正確配對和轉換模式和參數。這可以確保預期的資訊可以在 CXone 和虛擬客服專員之間傳遞。此外，您的整合可能不需要模式中包含的所有參數。對整合的透徹理解可以確保僅翻譯所需的參數。

代理隧道要求

代理隧道還是 Webhook。它必須是一個公共的 URL。它接收來自 Studio 指令碼的對話請求。Webhook 終點必須：

  • 支援 POST 請求，且序列化請求正文必須為 ExternalIntegrationBotExchangeRequest 格式。
  • 將 ExternalIntegrationBotExchangeRequest 轉換為虛擬客服專員所需的格式。
  • 將回應轉換為 CXone 所需的 CustomExchangeResponseV1 格式。

代理隧道終點可以部署於內部，還可以託管在雲端服務中，如 Google Cloud、Microsoft Azure 或 Amazon Web Services。在您的終點中使用 HTTPS。

如果您想要在 CXone 和 Webhook 之間使用 mTLS 驗證，則必須在 Webhook 中將其啟用。

對請求和回應模式的更新

請求和回應模式可能會隨著 NICE CXone 版本的更新而變更。這可能會影響自訂虛擬客服專員整合的功能。虛擬客服專員中心 允許您選擇何時遷移到整合的新版本。這樣您可以更新代理隧道、指令碼和虛擬客服專員服務以處理模式變更。

當您準備好轉移到新版本時，您可以在 虛擬客服專員中心 中的 Custom Exchange Endpoint 應用程式的整合版本欄位中將其選中。

用例

下面的序列圖顯示了顯示語音通道上訂單狀態查詢的用例。此範例顯示了整個互動過程中的請求和回應。它包括文字轉語音和語音轉文字，因為聯絡人的口頭請求被轉換為文字，而虛擬客服專員的回應被轉換為合成式語音。此範例還顯示使用 DTMFClosed 使用者點擊或輕點電話鍵盤上的某個鍵而產生的訊號音。 輸入訂單號的聯絡。

要查看更多詳細資料，請在新標籤中開啟此圖像。

序列圖顯示了檢查訂單狀態用例的對話流程。

當您設計代理隧道時，必須要記錄請求和回應模式。技術設計文件 (TDD) 中提供了一個範例。還提供了自訂虛擬客服專員整合的其他範例。這些設計展示了代理隧道在不同網路架構中的其他可能性。

序列圖

序列圖顯示了自訂虛擬客服專員整合的各個部分如何進行互動以及這些互動發生的順序。序列圖顯示了互動的時間線，從左上角開始，然後在頁面上來回移動。

序列圖是規劃自訂虛擬客服專員整合的一個重要部分。您可以使用序列圖繪製 CXone、虛擬客服專員中心、代理隧道和虛擬客服專員之間的請求和回應流程。序列圖還有助於確定 Studio 指令碼必須遵循的流程。

您可以為整合可能具有的各種用例建立不同的圖。此用例的詳細範例顯示了本頁代理隧道設計 中 部分。

該圖展示了聯絡人和虛擬客服專員透過 CXone 進行的對話流程。
該圖展示了聯絡人和虛擬客服專員透過 CXone 進行的對話流程。

CXone 設定要求

需要一個聯絡點Closed 呼入聯絡人用來發起互動的入口點，如電話號碼或電郵地址。來連結帶有處理這些Studio互動的指令碼的通道Closed 聯絡人與客服專員或機器人互動的方式。通道可以是語音、電郵、聊天、社交媒體等等。聯絡。如果互動可以來自多個通道，則需要為每個通道設定一個聯絡點。只要媒體類型相符，就可以讓多個通道調用同一個指令碼。

在建立聯絡點時，您必須選擇 ACD 技能Closed 用於基於客服專員技能、能力和知識的互動的自動化傳遞。在虛擬客服專員互動中，指派給聯絡點的 ACD 技能不用於路由聯絡人。但是，它們確實會影響報告。根據您組織使用的報告，您可能需要建立新的 ACD 技能，以便與您的自訂整合一起使用。如果您的自訂整合有多個聯絡點，則每個聯絡點都需要建立單獨的 ACD 技能，以便於報告。如果您建立了單獨的 ACD 技能，則每個 ACD 技能還需要一個活動。

與傳統 ACD 通道相比，的方式在數位Closed 任何與Digital First Omnichannel相關的通道、聯絡或技能。接觸點、技能和指令碼方面存在顯著差異。如果您的自訂虛擬客服專員整合使用數位通道，您可以在數位指令碼説明頁面了解更多有關這些差異的資訊。

有關每項任務的資訊，請參閱 CXone 線上說明中的這些頁面：

  • 為 語音或 CXone 聊天通道建立活動。
  • 為 語音 或 CXone 聊天通道建立 ACD 技能。您不需要將使用者新增至指派給聯絡點的 ACD 技能中。ACD 技能不用於將互動路由到虛擬客服專員。但是，如果您的指令碼允許將聯絡轉移到實時客服專員，則需要在請求客服專員時在指令碼中使用一個或多個 ACD 技能。
  • 為 語音或 CXone聊天通道建立聯絡點。聯絡點必須設定為使用該聯絡點的 ACD 技能的名稱，並且指令碼必須是當聯絡被路由到指定的 ACD 技能時，您想要運行的指令碼。

除了聯絡點所需的 ACD 技能外，您可能還需要其他 ACD 技能來完成您的自訂虛擬客服專員整合所需的指令碼。例如，您可能需要 ACD 技能，以便在虛擬客服專員確定需要實時客服專員的情況下，將聯絡轉給實時客服專員。您可以使用現有的 ACD 技能或建立新的技能。

指令碼要求和 指南

自訂虛擬客服整合至少需要一個包含虛擬客服動作的 Studio 指令碼。很多時候，整合需要多個指令碼。虛擬客服操作將CXone 連接到您的虛擬客服提供者。

提供有供您參考的指令碼範例。

與傳統 ACD 通道相比，CXone 處理數位互動的方式在方面存在顯著差異。這會影響用於數位通道的指令碼。如果您的自訂虛擬客服專員整合使用數位通道，您可以在數位指令碼説明頁面了解更多有關這些差異的資訊。

媒體類型

為您希望通道支援的通道Closed 聯絡人與客服專員或機器人互動的方式。通道可以是語音、電郵、聊天、社交媒體等等。建立具有正確媒體類型的指令碼。要支援電話互動，指令碼必須是語音媒體類型。要支援基於文字的互動，指令碼必須是聊天媒體類型）。

指令碼的類型

您可能需要一個以上的指令碼來整合您的虛擬客服專員。以下每種場景都需要各自的指令碼：

  • 傳入互動：當聯絡發起互動時，就會發生傳入互動。例如，透過呼叫您的組織或從您的網站開始聊天。
  • 傳出互動：當組織發起互動時，就會發生傳出互動。例如，透過呼叫聯絡人，提醒他們即將到來的預約，或透過帳戶已更新的直接訊息數位通道給他們傳送簡訊。

虛擬客服Studio 動作

提供三種可用於虛擬客服指令碼的 Studio 動作。有兩種類型的動作：Exchange 動作和 Conversation 動作。您使用的動作取決於您的虛擬客服專員的複雜性：

  • Exchange 動作：複雜的虛擬客服專員或當您需要按輪次自訂虛擬客服專員的行為，使用 Exchange 動作。這些動作監控對話中的每個輪次。他們將每一段話語Closed 聯絡人所說或所輸入的內容。傳送給虛擬客服專員。虛擬客服專員分析話語中的意圖Closed 聯絡人所說/所輸入內容背後的含義或目的；聯絡要傳達或實現什麼和上下文，然後決定使用哪種回應。然後，Exchange 動作將虛擬客服專員的回應傳回給聯絡人。對話完成後，此動作將繼續執行指令碼。Exchange 動作是 Voicebot Exchange 和 Textbot Exchange。
  • Conversation 動作：僅對最簡單的虛擬客服使用 Conversation 動作。這些動作不允許在輪次之間進行自訂。Conversation 動作將對話的控制權交給虛擬客服專員。當虛擬客服專員發出對話結束的訊號時或聯絡需要實時客服專員時，動作將收回控制權。Conversation 動作為 Voicebot Conversation。目前不支援 TEXTBOT CONVERSATION 動作。

在大多數情況下，自訂虛擬客服專員整合使用 Exchange 動作。

指令碼要求

如果您使用 Exchange 動作，則必須在指令碼中定義聯絡人和虛擬客服專員Closed 代替真人客服專員處理客戶互動的軟體應用程式。之間的對話流程。使用 Snippet 動作中的自訂代碼執行此操作。範例指令碼展示了如何執行此操作。若要了解更多資訊，請參閱下面的Snippet 動作程式碼部分。在使用 Conversation 動作時，您不需要定義對話流程，因為虛擬客服專員會處理該流程。

要完成虛擬客服專員指令碼，您可能還需要：

  • 配置虛擬客服動作，包括將其新增至虛擬客服專員中心並將其指派給指令碼中的動作。請參考您正在使用的動作的線上說明，以了解該動作屬性方面的資訊。
  • 使用Snippet動作根據需要將初始化 snippet 新增到指令碼中。您可以藉此來自訂您的虛擬客服，或將客戶身份資訊傳送給虛擬客服。
  • 重新配置動作連接器，確保適當的聯絡流程並糾正任何潛在的錯誤。
  • 正確連接所有分支。

  • 新增代碼來處理授權。指令碼必須在每個對話輪次中傳遞授權標頭。如果您使用整合版本 1.0.0，並且要使用動態驗證，必須配置您的指令碼來處理它。如果您使用整合版本 2.0.0 或 3.0.0，虛擬客服專員中心在您設定後自動處理動態驗證。

    整合版本 1.0.0 和 2.0.0 將在未來的版本中被棄用。3.0.0 版本是與自訂虛擬客服整合使用的首選版本。如果您目前使用 1.0.0 或 2.0.0 版本，請計劃升級到 3.0.0。3.0.0 版本與 2.0.0 版本幾乎相同。主要區別是 3.0.0 增加了對 StandardBot 的支援。

  • 使用 OnReturnControlToScript 分支來處理掛斷或結束互動。如果您使用Default分支，您的指令碼可能無法按預期工作。
  • 完成任何額外的指令碼編寫並測試指令碼。

確保指令碼的 虛擬客服專員中心 動作中的所有參數都配置為傳遞正確的資料。有關如何配置每個參數的資訊，請參閱線上說明主題，了解您正在使用的動作。

若您需要Studio中指令碼方面的協助，請聯絡您的CXone 客戶代表、查看線上說明的 指令碼參考材料部分，或造訪NICE CXone社群網站。

Snippet 動作代碼

虛擬客服專員整合的指令碼需要 Snippet 動作以將變數、物件和自訂代碼新增至指令碼中。Snippet 動作中的代碼必須用 Snippet 編寫，該語言是由 NICE CXone 開發的內部程式設計語言。CXone 線上說明中提供了 Snippet 的參考材料。

提供了用於自訂虛擬客服專員整合的 snippet 代碼範例供您使用。以下是可用的 snippet：

額外的指令碼需求

您還必須擁有以下指令碼：

可以在一個或幾個指令碼中滿足這些要求。指令碼的最佳做法是使用幾個小的指令碼。這樣可以更方便地分別管理每一片段。您可以使用 RunSub 動作 或 Runscript 動作 已將指令碼連結起來。

授權和驗證

授權和認證對於CXone、代理服器和虛擬客服專員提供者之間的通訊安全非常重要。服務在允許請求通過之前通常需要授權、驗證或兩者均需要。自訂虛擬客服專員整合帶有支援驗證和授權的 CXone 支援選項：

  • 使用標頭的授權：您可以在任何整合版本中使用具有 標頭的授權。
  • 使用權杖的動態驗證：您可以在整合版本 2.0 及更高版本中使用 動態驗證。
  • 使用 mTLS 在用戶端和伺服器之間進行驗證：您可以在整合版本 3.0.0 及更高版本中使用 mTLS 驗證。目前僅支援自訂虛擬客服專員整合。

整合版本 1.0.0 和 2.0.0 將在未來的版本中被棄用。3.0.0 版本是與自訂虛擬客服整合使用的首選版本。如果您目前使用 1.0.0 或 2.0.0 版本，請計劃升級到 3.0.0。3.0.0 版本與 2.0.0 版本幾乎相同。主要區別是 3.0.0 增加了對 StandardBot 的支援。

標頭

標頭資訊是每次向虛擬客服專員發出請求時傳送的鍵值對。其中包含允許虛擬客服專員服務對請求進行驗證的憑證。您必須在虛擬客服專員服務中產生憑證。當在您的自訂虛擬客服專員整合中使用標頭資訊進行驗證時，您的指令碼必須被設定為與每個請求一起傳送標頭資訊。

所有版本的自訂交換終點都支援標頭：

  • 在版本 1.0.0 中，您僅能傳送一個標頭，並且金鑰名稱將被硬編碼為 驗證。
  • 版本 2.0.0 和 3.0.0 支援多個標頭。您可以使用任何鍵值對。所有的鍵名都不是硬編碼。您需要使用您的虛擬客服專員所需要的鍵值對。從您的虛擬客服專員提供者獲取所需的標頭資訊。

此範例顯示了僅使用標頭的授權標頭請求：

{
	"accessKeyId": "12998c017066eb0d2a70b94e6ed3192985855ce390f321bbdb832022888bd251===", 
	"accessKeySecret": "e97deac957f87d18ef0058a07dfa52501b312382691f5a1de5a712871fef69ee==="
}

有關在整合版本 1.0.0、2.0.0 和 3.0.0 中使用標頭資訊的更多資訊，請參見以下部分。

動態驗證

動態驗證使用權杖而不是標頭。您必須擁有單獨的授權伺服器。權杖可從授權伺服器獲取並儲存在快取中。權杖在過期前會持續一定的時間，然後必須獲得另一個權杖。

您可以在兩個版本的自訂交換終點中使用動態驗證。然而，這兩個版本之間存在差異：

  • 在版本 1.0.0 中，您必須設定您的指令碼以管理權杖管理的所有方面。
  • 在版本 2.0.0 和 3.0.0 中，虛擬客服專員中心 中的 Custom Exchange Endpoint 應用程式使用您在應用程式中提供的資訊管理權杖。

下面的範例顯示了使用權杖的授權標頭。授權請求標頭和回應中的鍵值對可能根據授權服務的設定方式而有差異。下面範例中的存取權杖已縮短以節省空間。

{
	"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1Ni",

	"expires_in": 3600,

	"token_type": "Bearer"

}

有關在 1.0.0、2.0.0 和 3.0.0 版本中使用基於權杖驗證的更多資訊，請參見以下部分。

1.0.0 版本中的授權

在自訂交換終點 1.0.0 版本中，您可以為每個請求傳送一個標頭。您可以在 虛擬客服專員中心 中的 Custom Exchange Endpoint 應用程式的 授權標頭 欄位中新增標頭詳細資料。傳送到虛擬客服專員終點的請求包含一個鍵值對，其中鍵名為 授權，該值是您在 授權標頭 中輸入的標頭。您必須在您的虛擬客服專員服務中產生該標頭值。您的指令碼必須被設定為在每個請求中包括該標頭。

如果您想要使用版本 1.0.0 的自訂交換終點進行動態驗證，則需要自訂您的指令碼進行處理。預設情況下不支援該功能。使用 REST API Studio 動作以與驗證伺服器通訊。指令碼必須處理過期的權杖，並能夠在需要時請求新的權杖。您可以使用自訂工作負載或機器人會話狀態 Snippet 來傳送存取權杖。您可以在任一 Snippet 中新增額外參數，以便在特定對話回合中包含存取權杖。機器人會話狀態 Snippet 是首選方法。下面的範例顯示了指令碼請求驗證權杖的架構：

使用授權權杖的整合示意圖。該指令碼包括 REST API 動作，其從授權伺服器請求權杖。

版本 2.0.0 和 3.0.0 中帶有標頭的授權

在自訂交換終點版本 2.0.0 和 3.0.0 中，您可以為每個請求傳送多個標頭。您可以在 虛擬客服專員中心 中的 Custom Exchange Endpoint 應用程式的 自訂標頭 欄位中新增標頭詳細資料。

標頭可以是任何鍵值對，但鍵名稱必須要與您的虛擬客服專員所預期的名稱相符。這與 1.0.0 版本有所不同，其中將鍵命名為 授權，並且無法變更。

您的 指令碼必須被設定為在每個請求中包括標頭。

如果您在自訂標頭中設定了授權標頭，並且您還使用了 Oauth，則來自 Oauth 的授權標頭將覆寫自訂標頭中的設定。

在版本 2.0.0 和 3.0.0 中使用權杖進行動態驗證

在自訂交換終點版本 2.0.0 和 3.0.0中，虛擬客服專員中心 管理動態驗證權杖。這表示您不需要像版本 1.0.0 那樣設定您的指令碼來對其進行處理。

使用以下資訊設定 虛擬客服專員中心 中的 Custom Exchange Endpoint 應用程式：

  • 授權伺服器 URL。
  • 認證請求正文的鍵值對。這可以是 API 密碼或用戶端憑證。
  • 驗證請求中標頭的鍵值對。

權杖的過期時間可能會出現在三個位置：OAuth 伺服器上、虛擬客服專員中心 的 Custom Exchange Endpoints 應用程式中以及預設設定中。系統使用它們時的順序如下：

  1. 如果在 OAuth 回應中傳送了來自 OAuth 伺服器的過期時間，則該時間用於確定授權權杖何時過期。
  2. 如果 OAuth 回應不包含過期時間，那麼就會使用在 虛擬客服專員中心 的 Custom Exchange Endpoints 應用程式中設定的時間。
  3. 如果應用程式未設定過期時間，則使用預設值。預設為 3600 秒（1 小時）。

此外，如果您使用動態驗證，您可以自訂與授權標頭一起傳送給虛擬客服專員提供者的鍵值對。預設情況下，授權標頭的名稱為授權。您還可以變更新增至標頭值的前綴。預設為 Bearer。

使用用戶端憑證和 mTLS 進行驗證

虛擬客服專員中心 中的自訂虛擬客服專員整合支援 mTLS (Mutual Transport Layer Security)。mTLS 是一種用於驗證用戶端和伺服器的傳輸層協議。它為用戶端與伺服器之間的通訊提供了額外安全性。使用 TLS 驗證在兩個伺服器之間對憑證進行驗證。mTLS 驗證用戶端和伺服器之間的憑證。用戶端可以是 Web 瀏覽器，還可以是 API 調用。

要在自訂虛擬客服專員整合中使用 mTLS 驗證，則必須啟用 Webhook 中的 mTLS。您可以在 虛擬客服專員中心 的 自訂交換端點 應用程式中新增用戶端憑證和金鑰。當與 webhook 協商握手時，CXone 將使用此資訊。

虛擬客服專員意圖

您的虛擬客服專員必須能夠識別聯絡想要執行什麼。要做到這一點，使用您設定的意圖進行識別。您需要的意圖取決於虛擬客服專員的用例。若您知道了所需的意圖，就必須在提供者的管理主控台中設定虛擬客服專員。某些提供者對意圖概念使用的術語可能有所不同。

CXone 要求您的虛擬客服專員要對某些意圖進行回應。所有其他意圖取決於您的組織對虛擬客服專員的計劃。您必須至少定義：

  • 問候/歡迎意圖：這是虛擬客服專員開始時（當聯絡人發起對話時）的預設資訊。
  • 遞補意圖：這是虛擬客服專員在其他回應都不適用時所說的話。
  • 逾時/沉默意圖：這是虛擬客服專員在聯絡長時間處於沉默時所說的話。
  • 結束/完成意圖：這是虛擬客服專員結束對話的方式。

虛擬客服專員用例

當規劃您的虛擬客服專員時，您需要考慮用於處理的場景類型，為這些場景建立用例，包括其在每種場景中必須遵循的對話流程。對於每個用例，建立可以配對整個互動過程中的請求和回應的序列圖。

例如，用例可能是回應關於訂單狀態的問題。對話流程可能如下：

虛擬客服專員：「請問有什麼可以幫到您？」

聯絡人：「我想要檢查我的訂單狀態。」

虛擬客服專員：「請說出或輸入您的 13 位數的訂單號。」

聯絡人：「我查一下，訂單號為 2390294837290。」

虛擬客服專員：「很遺憾，您的訂單延遲了三天。」

聯絡人：「哦，這可不好。我真的需要訂單更快。有什麼辦法可以讓我和別人談談此問題嗎？」

虛擬客服專員：「可以，我會把您轉接給可以幫助您的客服專員。」

此用例的序列圖可能與如下範例類似：

要查看更多詳細資料，請在新標籤中開啟此圖像。

對話轉錄

CXone 可以收集語音和聊天虛擬客服專員對話中的轉錄和意圖Closed 聯絡人所說/所輸入內容背後的含義或目的；聯絡要傳達或實現什麼資料。您可以以任何符合組織需要的方式使用資訊。例如，您可以將其儲存在外部資料庫中。您也可以讓其傳送至 客服專員應用程式，以用於升級到真人客服專員的互動。必須在 虛擬客服專員中心 中的虛擬客服專員配置應用程式中啟用此功能。預設情況下，不會收集轉錄和意圖。

收集的確切資料取決於該功能的設定方式。您可以僅收集轉錄，僅收集意圖，或同時收集轉錄和意圖。如果您有多個虛擬客服專員，則可以單獨配置每個客服專員。

您如何處理收集到的資料，取決於您自己。如果您想進行儲存以作為記錄，則必須將虛擬客服專員的 Studio 指令碼配置為如此操作。預設情況下，當啟用對話轉錄收集時，所收集的資料會被儲存起來，直到互動完成。

使用此功能需要在虛擬客服專員 Studio 指令碼中自訂指令碼。還必須在 虛擬客服專員中心 中的虛擬客服專員配置應用程式中的「轉錄」頁面上啟用。

CXoneAPI 終點和模式

在 Swagger 文件一個正方形，箭頭從中心指向外。中定義了 CXone 使用的 API 終點和模式。當在 CXone 和您的虛擬客服專員提供者之間映射請求和回應時使用此資訊，並將其作為建立代理隧道 Webhook 的一部分。

  • ExternalIntegrationBotExchangeRequest：這是透過代理隧道從 CXone 到您的虛擬客服專員傳遞請求的終點。
  • CustomExchangeResponse：這是從虛擬客服專員到 CXone 的回應的終點。

模式頁面中定義了模式。然而，應始終檢查 Swagger 頁面以確保您使用的是最新版本的模式。