用于自定义虚拟坐席集成的资源

此页面提供参考信息和资源，以在规划和实施自定义虚拟坐席集成期间提供帮助。

体系结构

在设计自定义虚拟坐席集成时，需要牢记一些有关延迟的重要注意事项。最佳实践是让自定义端点仅与架构中的一个组件交互。端点在单个请求期间交互的组件越多，发生延迟的可能性就越大。组件是一个过程，例如语音到文本或自然语言理解引擎。

以下示例显示了一个容易出现延迟的架构。这是因为需要多个 API 交互来生成单个请求的响应。

更高效的架构仅对每个请求进行一次交互。这可以最大限度地减少与联系人对话期间发生延迟的可能性。

坐席隧道和 Webhook 设计

坐席隧道是 CXone 和虚拟坐席服务端点之间的中间件。所有请求和响应都通过它传递。此外，它将请求和响应转换为目标系统所需的格式。下图说明了这个过程：

该图显示坐席隧道接收来自 CXone （以实线显示）的请求，并将其转换为虚拟坐席可以理解的格式（以虚线显示）。随后，接收来自虚拟坐席的响应（虚线）并将其转换为 CXone 理解的格式（实线）。

务必理解 CXone 架构和您的虚拟坐席以及特定集成计划的要求。必须正确映射和转换模式和参数。这可确保在 CXone 和虚拟坐席之间传递预期信息。此外，您的集成可能不需要架构中包含的所有参数。对集成的透彻了解可确保仅转换所需的参数。

坐席隧道要求

坐席隧道也是一个 webhook。它必须是公共 URL。它接收来自 Studio 脚本的会话请求。Webhook 端点必须：

支持具有 ExternalIntegrationBotExchangeRequest 格式的序列化请求正文的 POST 请求。
将 ExternalIntegrationBotExchangeRequest 转换为虚拟坐席所需的格式。
将响应转换为CXone所需的CustomExchangeResponseV1格式。

坐席隧道端点可以位于本地，也可以托管在云服务中，例如 Google Cloud、Microsoft Azure 或 Amazon Web Services。在端点中使用 HTTPS。

如果您想在 CXone 和 webhook 之间使用mTLS 身份验证，您必须在 webhook 中启用它。

请求和响应架构更新

请求和响应架构可能会随着 NICE CXone 发布更新而更改。这可能会影响自定义虚拟坐席集成的功能。虚拟坐席中心允许您选择何时迁移到新版本的集成。这允许您更新坐席隧道、脚本和虚拟坐席服务以处理架构更改。

当您准备好迁移到新版本时，可以在集成版本字段，该字段在虚拟坐席中心中的自定义 Exchange 端点应用程序。

用例

以下序列图显示了语音通道上的订单状态查询的用例。此示例显示整个交互过程中的请求和响应。它包括文本到语音和语音到文本，因为联系人的口头请求被转换为文本，而虚拟坐席的响应被转换为合成语音。该示例还显示联系人使用 DTMF 当用户在电话按键上按下或敲击某个键时产生的信号音。输入订单号。

在设计代理隧道时，必须记录请求和响应架构。示例技术设计文档 (TDD) 中提供了相关示例。提供了自定义虚拟坐席集成的其他示例。这些设计展示了代理隧道在不同网络架构中的其他可能性。

序列图

序列图显示了虚拟坐席的各个部分如何协助集成交互以及这些交互发生的顺序。它们显示了交互的时间线，从左上角开始，然后在页面上来回移动。

序列图是规划自定义虚拟坐席集成的重要组成部分。您可以用其绘制 CXone、虚拟坐席中心、代理隧道、和您的虚拟坐席之间的请求和响应流。它们还可能有助于确定您的 Studio 脚本必须遵循的流程。

您可以为集成可能具有的各种用例创建不同的图表。此页面上有关代理隧道设计的部分显示了详细的用例示例。

CXone配置要求

需要联络点呼入联系人用来发起交互的入口点，如电话号码或电子邮件地址。来链接在处理这些交互的 Studio 脚本中使用的渠道联系人与坐席或机器人交互的一种方式。通道可以是语音、电子邮件、聊天、社交媒体等。联系人。如果交互可以来自多个渠道，则每个渠道都需要一个联系人。只要媒体类型匹配，您就可以让多个通道调用同一脚本。

创建联系人时，您必须选择ACD 技能用于根据坐席的技能、能力和知识自动传递交互。通过虚拟坐席交互，分配给联络点的 ACD 技能不会用于路由联系人。但它们确实会影响报告。根据您的组织使用的报告，您可能需要创建新的 ACD 技能以与自定义集成一起使用。如果您的自定义集成有多个联系人，则出于报告目的，您可能需要为每个联系人提供单独的 ACD 技能。如果您创建单独的 ACD 技能，则还需要为每项 ACD 技能开展活动。

与在，CXone 在数字与Digital Experience相关的任何渠道、联系或技能。联络点、技能和脚本的方式存在很大差异。如果您的自定义虚拟坐席集成使用数字渠道，您可以在数字脚本帮助页面上了解有关这些差异的更多信息。

有关每项任务的信息，请参阅CXone联机帮助中的以下页面：

创建语音或 CXone 聊天渠道营销活动。
为语音或 CXone 聊天渠道创建 ACD 技能。您无需将用户添加到分配给联系人的 ACD 技能中。ACD 技能不用于将交互路由到虚拟坐席。但是，如果您的脚本允许联系人转接至实时坐席，则当请求坐席时，您需要在脚本中使用一项或多项 ACD 技能。
创建语音或 CXone 聊天渠道联络点。必须以使用该联络点的 ACD 技能的名称以及在联系人路由到指定的 ACD 技能时要运行的脚本来配置联络点。

除了联络点所需的 ACD 技能之外，您可能还需要其他 ACD 技能来完成自定义虚拟坐席集成所需的脚本。例如，如果虚拟坐席确定需要实时坐席，您可能需要 ACD 技能将联系人路由至实时坐席。您可以使用现有的 ACD 技能或创建新技能。

脚本要求和指南

自定义虚拟坐席集成至少需要一个包含虚拟坐席操作的 Studio 脚本。多数时候，集成需要多个脚本。虚拟坐席操作将 CXone 连接到您的虚拟坐席提供程序。

提供示例脚本供您参考。

下载示例文本虚拟坐席脚本（ZIP 文件）。
下载示例语音虚拟坐席脚本（ZIP文件）。

与在传统 ACD 频道上，CXone 在方面处理数字交互的方式存在很大差异。这会影响与数字频道一起使用的脚本。如果您的自定义虚拟坐席集成使用数字渠道，您可以在数字脚本帮助页面上了解有关这些差异的更多信息。

媒体类型

使用正确的媒体类型为您希望其支持的渠道联系人与坐席或机器人交互的一种方式。通道可以是语音、电子邮件、聊天、社交媒体等。创建脚本。要支持电话交互，脚本必须具有语音媒体类型。要支持基于文本的交互，脚本必须具有聊天媒体类型。

脚本类型

您可能需要多个脚本来集成您的虚拟坐席。以下每个场景都需要自己的脚本：

呼入交互：呼入交互在联系人发起交互时发生。例如，通过致电您的组织或从您的网站开始聊天。
呼出交互：呼出交互在您的组织发起交互时发生。例如，通过致电联系人提醒他们即将到来的约会，或者通过具有帐户更新的直接消息传递数字渠道。

虚拟坐席 Studio 操作

有三个 Studio 操作可与虚拟坐席脚本一起使用。有两种类型的操作：交换操作和对话操作。您使用的操作取决于虚拟坐席的复杂性：

Exchange 操作：对复杂的虚拟坐席或需要自定义虚拟坐席的行为依次进行使用 Exchange 操作。这些操作监控对话中的每个回合。将每个话语联系人所说或输入的内容。发送到虚拟坐席。虚拟坐席将分析话语的意图联系人所说/输入内容背后的含义或目的；联系人想要沟通或完成的内容和上下文，并且确定需要作出的响应。随后，Exchange 操作将虚拟坐席的响应返回给联系人。对话完成后，该操作将继续执行脚本。Exchange 操作为 Voicebot Exchange 和 Textbot Exchange。
对话操作：仅对最简单的虚拟坐席使用对话操作。这些操作不允许在回合之间进行自定义。对话操作将对话的控制权移交给虚拟坐席。当虚拟坐席发出对话结束或联系人需要现场坐席的信号时，操作会收回控制权。Conversation 操作是 Voicebot Conversation。目前，不支持 TEXTBOT CONVERSATION 操作。

在大多数情况下，自定义虚拟坐席集成使用 Exchange 操作。

脚本要求

如果您使用 Exchange 操作，则必须在您的脚本中定义联系人与虚拟坐席代替现场人工坐席处理客户交互的软件应用程序。之间的对话流。您可以在Snippet操作中使用自定义代码来执行此操作。示例脚本展示了如何执行此操作。请参阅下面的代码段操作代码部分了解更多信息。使用Conversation操作时无需定义会话流，因为虚拟坐席会处理该流。

要完成虚拟坐席脚本，您可能还需要：

配置虚拟坐席操作，其中包括将其添加到虚拟坐席中心将其分配给脚本中的操作。有关操作属性的信息，请参阅当前使用的操作的联机帮助。
根据需要，使用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 编写，这是一种由 NICE CXone 开发的内部编程语言。Snippet的参考资料可在CXone联机帮助中找到。

提供了自定义虚拟坐席集成的代码片段示例供您使用。以下片段可用：

额外的脚本需求

您还必须拥有以下脚本：

使用一项或多项 ACD 技能用于根据坐席的技能、能力和知识自动传递交互将联系人路由到虚拟坐席脚本。例如，当联系人选择特定的菜单选项，您可能有一个 IVR 自动电话菜单，允许呼叫者通过语音命令、按键输入或两者进行交互，以获得信息、路由呼入的语音呼叫或两者。脚本路由联系人至虚拟坐席脚本。
对话完成后或虚拟坐席确定联系人需要实时坐席后，处理所需的任何路由。
定义DTMF 当用户在电话按键上按下或敲击某个键时产生的信号音。路由选项，用于不通向虚拟的音调坐席人。这仅适用于基于语音的虚拟坐席。

这些要求可以通过一个或多个脚本来满足。脚本编写的最佳实践是使用几个较小的脚本。这使得单独管理每个部分变得更加容易。您可以使用 RunSub 操作或 Runscript 操作将脚本链接一起。

授权与身份验证

授权和身份验证对于CXone、坐席服务器和虚拟坐席提供程序之间的通信安全非常重要。服务在允许请求通过之前通常需要授权、身份验证或两者兼而有之。自定义虚拟坐席与 CXone 支持身份验证和授权选项集成：

使用标头授权：您可以使用任何集成版本的标头授权。
使用令牌进行动态身份验证：您可以将动态身份验证与集成版本 2.0 及更高版本结合使用。
使用 mTLS 在客户端和服务器之间进行身份验证：您可以使用 mTLS 身份验证集成版本 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 的支持。

标题

标头是与向虚拟坐席发出的每个请求一起发送的键值对。它们包含允许虚拟坐席服务验证请求的凭据。您必须在虚拟坐席服务中生成凭据。当您在自定义虚拟坐席集成中使用标头进行身份验证时，必须将脚本配置为随每个请求发送标头信息。

所有版本的自定义交换端点都支持标头：

在 1.0.0 版本中，只能发送一个标头，并且密钥名称硬编码为 Authentication。
版本 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 中，虚拟坐席中心中的自定义 Exchange 端点应用程序使用您在应用程序中提供的信息来管理令牌。

以下示例显示使用令牌的授权标头。授权请求标头和响应中的键值对可能会根据授权服务的配置方式而有所不同。以下示例中的访问令牌已被缩短以节省空间。

{
	"access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1Ni",

	"expires_in": 3600,

	"token_type": "Bearer"

}

有关在版本 1.0.0、2.0.0 和 3.0.0 中使用基于令牌的身份验证在以下部分中提供。

1.0.0 版本授权

在自定义交换端点版本 1.0.0 中，您可以为每个请求发送一个标头。在授权标头字段中添加标头详细信息，其中字段在虚拟坐席中心中的自定义 Exchange 端点应用程序。发送到虚拟坐席端点的请求包含一个键值对，其中键名为Authorization，值是您在Authorization 标头中输入的标头。您必须在虚拟坐席服务中生成标头值。您的脚本必须设置为在每个请求中包含标头。

如果您想要对自定义交换端点版本 1.0.0 使用动态身份验证，则需要配置脚本来处理它。这在默认情况下不受支持。使用 REST API Studio 操作与身份验证服务器通信。该脚本必须处理令牌的过期，并能够在需要时请求新令牌。您可以使用自定义有效负载或机器人会话状态代码片段来发送访问令牌。您可以向任一代码片段添加其他参数，以便在给定的对话回合包含访问令牌。机器人会话状态代码片段是首选方法。以下示例显示了脚本请求身份验证令牌的架构：

版本 2.0.0 和 3.0.0 中的标头授权

在自定义交换端点版本 2.0.0 和 3.0.0 中，您可以为每个请求发送多个标头。在自定义标头字段中添加标头详细信息，字段处于虚拟坐席中心中的自定义 Exchange 端点应用程序。

标头可以是任何键值对，但键名称必须与虚拟坐席期望的名称匹配。这与版本 1.0.0 不同，版本 1.0.0 中密钥名为授权并且不能更改。

您的脚本必须设置为在每个请求中包含标头。

如果您在自定义标头中配置授权标头，并且您还使用 OAuth，则来自 OAuth 的授权标头覆盖自定义标头中的设置。

版本 2.0.0 和 3.0.0 中使用令牌的动态身份验证

在自定义交换端点版本 2.0.0 和 3.0.0 中，虚拟坐席中心管理动态身份验证令牌。这意味着您不需要像使用版本 1.0.0 那样配置脚本来处理它们。

使用下列信息在虚拟坐席中心中配置自定义 Exchange 端点应用程序：

授权服务器 URL。
身份验证请求正文的键值对。这可以是 API 机密或客户端凭据等内容。
身份验证请求中标头的键值对。

令牌的过期时间可以存在于三个位置：OAuth 服务器上、虚拟坐席中心中的自定义 Exchange 端点应用程序中以及默认设置。系统按以下顺序使用它们：

如果 OAuth 服务器的 OAuth 响应中发送了过期时间，则该时间用于确定授权令牌何时过期。
如果 OAuth 响应不包含过期时间，则使用您在虚拟坐席中心中的自定义 Exchange 端点应用程序中配置的时间。
如果应用程序没有设置过期时间，则使用默认值。默认值为 3600 秒（一小时）。

此外，如果您使用动态身份验证，则可以自定义与授权标头一起发送到虚拟坐席提供程序的键值对。默认情况下，授权标头名称为授权。您还可以更改添加到标头值的前缀。默认值为承载。

使用客户端证书和 mTLS 进行身份验证

虚拟坐席中心中的自定义虚拟坐席集成支持 mTLS（相互传输层安全）。mTLS 是一种传输层协议，用于对客户端和服务器进行身份验证。它为客户端-服务器通信提供了更高的安全性。通过 TLS 身份验证，可以在两个服务器之间验证证书。mTLS 验证客户端和服务器之间的证书。客户端可以是 Web 浏览器，也可以是 API 调用。

要将 mTLS 身份验证与自定义虚拟坐席集成结合使用，您的 Webhook 必须启用 mTLS。您可以将客户端证书和密钥添加到虚拟坐席中心中的自定义交换端点应用程序。CXone 在与 webhook 协商握手时使用此信息。

虚拟坐席意图

您的虚拟坐席必须能够识别联系人的需求。它使用您配置其识别的意图来执行此操作。您需要的意图取决于虚拟坐席的用例。一旦您知道所需的意图，您必须在提供程序的管理控制台中配置虚拟坐席。一些提供程序用于意图概念的术语可能有所不同。

CXone 要求您的虚拟坐席对某些意图有响应。所有其他意图取决于您的组织的虚拟坐席计划。您至少必须定义：

问候/欢迎意图：这是联系人发起对话时虚拟坐席开始的默认消息。
后备意图：这是虚拟坐席在没有其他答复适用时所说的内容。
超时/沉默意图：这是联系人长时间沉默时虚拟坐席所说的内容。
结束/完成意图：这是虚拟坐席结束对话的方式。

虚拟坐席用例

规划虚拟坐席时，您需要考虑它将处理的场景类型。为这些场景构建用例，包括每个场景必须遵循的对话流程。对于每个用例，创建一个序列图来映射整个交互过程中的请求和响应。

例如，用例可能正在回答有关订单状态的问题。对话流程可能如下所示：

虚拟坐席：我能为您做点什么？

联系人：“我想核查我的订单状态。”

虚拟坐席：“请现在说出或输入您的十三位订单号。”

联系人：“我看看，订单号是 2390294837290。”

虚拟坐席：“抱歉，您的订单延迟了三天。”

联系人：“哦，那不太好。”我需要早点到货。我有什么办法可以和其他人谈谈这件事吗？

虚拟坐席：“是的，我会将您转接给可以帮助您的坐席。”

此用例的序列图可能类似于以下示例中的序列图：

对话记录文本

CXone 可以从语音和聊天虚拟坐席对话中收集文字记录和意图联系人所说/输入内容背后的含义或目的；联系人想要沟通或完成的内容数据。您可以按照满足组织需求的任何方式使用这些信息。例如，您可以将它们保存到外部数据库中。您还可以将它们发送到坐席应用程序进行交互，然后升级为实时人工坐席。该功能必须在虚拟坐席中心中的虚拟坐席的配置应用程序中启用。默认情况下，不收集记录文本和意图。

收集的确切数据取决于功能的配置方式。您可以仅收集记录文本、仅收集意图，或同时收集记录文本和意图。如果有多个虚拟坐席，您可以为每个虚拟坐席单独配置。

您如何处理收集到的数据取决于您。如果您想保存它以进行记录，则必须配置虚拟坐席的 Studio 脚本来执行此操作。默认情况下，启用对话记录文本收集后，收集的数据在交互完成前均将保存。

使用此功能需要在虚拟坐席 Studio 脚本中的自定义脚本编写。此外，必须在虚拟坐席中心虚拟坐席配置应用程序的“记录文本”页面上启用。

CXone API 端点和架构

CXone 使用的 API 端点和架构在 Swagger 文档一个带有从中心向外指向的箭头的正方形。中定义。作为创建代理隧道 webhook 的一部分，您可以在映射 CXone 与虚拟坐席提供程序之间的请求和响应时使用此信息。

ExternalIntegrationBotExchangeRequest：这是通过代理隧道从 CXone 到虚拟坐席的请求端点。
CustomExchangeResponse：这是从虚拟坐席到 CXone 的响应端点。

架构在架构页面上定义。但是，请务必检查 Swagger 页面，以确保您使用的是最新版本的架构。