虚拟坐席规划指南

在规划、构建和实施与CXone的自定义虚拟坐席集成时，请使用此规划指南。该指南提供了该过程的总体概述。每个阶段的具体要求和所需时间取决于您独特的环境和情况。

该过程分为五个阶段：

规划阶段 1：在此阶段，您将探索组织环境的架构。您的目标是了解环境并确定您独特情况的要求和限制。
规划阶段 2：在此阶段，您将了解虚拟坐席提供程序的要求。您的目标是确定需求如何影响您的环境以及与CXone的集成。在此阶段，您还可以确定虚拟坐席的用例并规划所需的脚本。
开发：在此阶段，您将构建代理隧道、创建所需的脚本并完成任何其他操作规划阶段确定的发展。
测试：在测试阶段，您将彻底测试您的自定义集成。
部署：在部署阶段，您可以将集成移至生产环境中。

下面描述了每个阶段的资源和可交付成果。

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

规划第 1 阶段：体系结构

在此阶段，您的目标是了解将在其中构建代理隧道的环境。您必须：

了解您环境的独特架构，包括 API 网关、防火墙和服务层。
了解您正在使用的虚拟坐席的架构，包括：
- API 端点。
- 连接到虚拟坐席提供程序 API 的要求。例如，您可以使用 RESTful 解决方案进行连接，还是需要 gRPC Google 远程过程通话数据交换技术。解决方案？
- 认证要求。
了解您与虚拟坐席一起使用的CXone渠道联系人与坐席或机器人交互的一种方式。通道可以是语音、电子邮件、聊天、社交媒体等。要求。例如，如果您要设置聊天机器人，则需要了解要与其集成的特定聊天渠道的要求（CXone 聊天或数字与Digital Experience相关的任何渠道、联系或技能。聊天渠道）。
确定您的环境中代理托管的要求，例如使用虚拟机或容器。例如，某些提供程序可能需要 RESTful 两个计算机系统之间的一个接口，允许在互联网上安全交换数据。解决方案，而其他提供程序可能需要 gRPC。
确定代理隧道的故障转移要求。
定义集成的实时生产版本的监控需求。

在此阶段结束时，您应该开始编写技术设计文档 (TDD)，包括：

此阶段进行的规划以虚拟坐席为中心。此阶段所需的规划将根据您是开发新的虚拟坐席还是集成现有虚拟坐席而有所不同。例如，您可能需要：

定义您希望虚拟坐席执行的操作以及它将如何与您的实时坐席和任何其他机器人、虚拟坐席或与CXone一起使用的坐席助手应用程序一款软件应用程序，为坐席提供特定于上下文的帮助。结合使用。
确定在您的环境中实施虚拟坐席的任何高级限制，并确定如何使用CXone和自定义Studio脚本来解决这些限制。
确定您的集成需要为 CXone 和虚拟坐席使用哪些架构和参数。需要在两个系统之间映射参数。
讨论您需要的功能，例如富媒体内容、markdown，或事件传输。
确定您需要的对话流程和意图。
规划出将虚拟坐席与 CXone 集成所需的 Studio 脚本的流程。
确定联系人将用于发起与虚拟坐席交互的渠道联系人与坐席或机器人交互的一种方式。通道可以是语音、电子邮件、聊天、社交媒体等。。请注意是否需要任何设置以及要求是什么。例如，如果您使用 CXone 聊天，则必须创建聊天配置文件来定义聊天窗口的外观，并且需要确定聊天将位于网站上的位置。
确定必需的 CXone ACD 技能用于根据坐席的技能、能力和知识自动传递交互、营销活动用于运行报告的技能分组。，以及联系人呼入联系人用来发起交互的入口点，如电话号码或电子邮件地址。。
非功能性要求，例如：
- 处理时间。
- 用于基准坐席处理时间的延迟测量。
- 内存消耗。

在此阶段结束时，您的 TDD 应包括：

在开发阶段，您需要在测试环境中构建集成所需的元素。在构建时，请遵循 TDD 中记录的要求。特别是，您需要：

在此阶段结束时，您将拥有以下内容的工作版本：

在测试阶段，对集成的各个方面（包括所有用例）进行用户验收和端到端测试。测试先前确定的非功能性需求。您还应该执行故障转移测试。解决出现的错误。

一个有效的自定义虚拟坐席集成已解决所有问题。

当集成经过全面测试并且在测试环境中按预期运行时，您可以将其移至生产环境中。当一切都在生产中设置完毕后，对其进行测试以确保系统仍然按预期运行。

部署后，对实时集成进行持续监控。