场景和部署方法

Amazon Connect 提供了自助配置，可提供多种迁移和集成选项，支持任何规模的动态、个人和自然的客户互动。在本节中，我们解释了在为 Amazon Connect 设计工作负载时应考虑的以下场景和部署方法：

• 传统联络中心

• 入站

• 出站

• 混合联络中心

• 传统联络中心迁移

• 虚拟桌面基础设施 (VDI)

传统联络中心

传统的联络中心需要大量的电话、媒体、网络、数据库和计算基础设施占用空间，这些空间可以跨越多个供应商和数据中心地点，为服务联系人提供服务。每个解决方案和供应商都有独特的硬件、软件、网络和架构要求，在解决版本控制、兼容性和许可冲突时必须满足这些要求。

对于本地和远程代理硬件和 VPN 连接、文本转语音 (TTS)、自动呼叫分配 (ACD)、交互式语音响应 (IVR)、语音音频和数据、物理桌面电话、语音录制、语音转录、聊天、报告、数据库、计算机电话集成 (CTI)、自动语音识别 (ASR) 和自然语言理解 (NLP)，通常会有不同的供应商和基础设施要求。当您考虑多阶段开发、质量保证和测试环境时，您的联络中心架构和基础架构会变得更加复杂。

典型的 Amazon Connect 部署可以解决或减少与版本控制、兼容性、许可、联络中心电话基础设施和维护相关的许多挑战。它使您能够灵活地在几分钟内在新位置创建实例，并单独或parallel 迁移组件，以最好地实现您的个人业务目标。您可以将流程用于 IVR/ACD，通过支持的 Web 浏览器将语音和数据传送到代理的软件电话，移植现有电话号码，将软件电话音频重定向到现有的台式电话，在流程中本地调用 Amazon Lex 机器人进行 ASR 和 NLP，并将相同的流程用于聊天和语音。您可以使用 Amazon Contact Lens 自动生成语音转录、进行关键词识别和情感分析，以及对联系人进行分类。对于代理 CTI 数据和实时语音流，您可以使用 Amazon Connect Agent Event Streams 和 Kinesis 视频流。您还可以创建多阶段开发、质量保证和测试环境，无需额外费用，只需按实际使用量付费。

入站

入站是联络中心术语，用于描述联系人向中心发起的通信请求。联系人可以联系您的 Amazon Connect 实例进行入站自助服务，也可以通过多种方式（包括语音和聊天）与在线客服通话。语音联系人通过 PSTN，然后通过您的实例中声明的电话号码路由到 Amazon Connect 实例的电话入口点。您可以直接通过 Amazon Connect 预留电话号码、移植现有电话号码或将语音联系人转发到 Amazon Connect。Amazon Connect 可以在支持该服务的所有地区提供本地和免费电话号码。

当向您的 Amazon Connect 实例中声明的号码拨打电话或移植到您的 Amazon Connect 实例时，将调用与被叫号码相关的流程。您可以使用无需编码知识即可配置的流块来定义流程。该流程决定了应如何处理和路由联系人，可以选择提示联系人提供其他信息以帮助做出路由决策，将这些属性存储到联系人详细信息中，并在必要时将该联系人转接给代理，并在此过程中收集到的所有呼叫详细信息和笔录。在流程中，您可以调用AWS Lambda函数来查询客户信息，调用 Amazon Pinpoint 等其他AWS服务发送短信，并使用原生AWS服务集成，包括适用于 NLU/NLP 的 Amazon Lex 和 Kinesis Video Streams 进行语音通话的实时直播。

如果入站联系人需要联系客服，则根据您的路由配置，当联系人的状态更改为 “可用” 时，该联系人会进入队列并路由给客服。当手动或通过自动接受配置接受可用代理的联系人时，Amazon Connect 会将联系人与代理人联系起来。

当入站联系人来自浏览器或移动应用程序的聊天会话请求时，该请求将路由到调用 Amazon Connect 聊天 API 来调用请求中配置的流程的 Web 服务或 Amazon API Gateway 终端节点。您可以使用相同的流程进行聊天和语音，根据流程中定义的逻辑对体验进行动态管理和路由。

出站

Amazon Connect 使您能够以编程方式尝试与本地和国际终端节点进行出站联系，缩短联系人之间的代理设置时间，并提高代理工作效率。通过使用 Amazon Connect Streams API 和 StartOutboundVoiceContact，您可以开发自己的出站解决方案，或利用与您的 CRM 数据配合的现有合作伙伴集成，为您的联系人创建动态、个性化的体验，并为代理提供为这些联系人提供服务所需的工具和资源。

出站活动通常由从 CRM 导出并分成联系人列表的联系人数据驱动。对这些联系人进行优先级排序，要么在预览一段时间后发送给代理发起，要么使用 Amazon Connect Outbount API 以编程方式联系，由您的流程逻辑驱动，然后根据需要连接到代理。典型的呼出联络中心用例包括欺诈和服务警报、收款和预约确认。

混合

如果您需要在 Amazon Connect 和传统联络中心技术之间转移联系人，则可以使用混合模型架构在转移时传递联系人数据。例如，传统联络中心平台上的销售业务部门可能需要将呼叫转接到已迁移到 Amazon Connect 的服务业务部门。如果没有混合架构，通话详细信息将丢失，可能需要联系人重复信息。这可能会增加处理时间，并可能导致出于相同目的再次拨打联系电话。

混合架构要求您申报与预期的最大并发联系人数量一样多的电话号码，以及可由 Amazon Connect 和您的传统联络中心平台访问的中间状态数据库。当需要向其他平台转账时，您将使用其中一个电话号码作为唯一标识符，在中间数据库中将其标记为正在使用，插入您的联系方式，并在转移联系人时使用该号码作为您的 ANI 或 DNIS。当其他联络中心平台收到联系人时，您将根据您使用的唯一 ANI 或 DNIS 在中介数据库中查询联系人详细信息。混合架构通常用作临时迁移步骤，因为相关的成本和复杂性会增加。

仅限于 IVR

您可以选择使用 Amazon Connect 来提升联系人的 IVR 体验，同时您的代理人仍使用您的传统联络中心平台。通过这种方法，您可以使用 Amazon Connect 流程来推动自助服务和路由逻辑，并在必要时将联系人转移到传统联络中心平台上的目标代理或代理队列。

在此图中，联系人拨打您的 Amazon Connect 实例中声明的电话号码以获取服务。如果需要将它们转移到您的传统联络中心平台上的代理，则会调用一个AWS Lambda函数来查询可用的唯一电话号码，将其标记为正在使用，并将相关的联系人详细信息写入中介数据库。然后，使用 Lambda 函数返回的电话号码将联系人转移到传统联络中心平台。然后，传统联络中心将在中间数据库上查询联系人详细信息，相应地进行路由，并重置中间数据库中的联系人数据，从而允许再次使用电话号码。

仅限代理

通过这种方法，您的传统联络中心 IVR 可驱动联系人的 IVR 自助服务和路由逻辑，并在必要时将联系人转移到 Amazon Connect 以路由到您的代理群体。

在此图中，联系人拨打的是您的旧版联络中心平台声明的电话号码。如果需要将其转接给 Amazon Connect 上的代理，传统联络中心平台将查询可用的唯一电话号码，将其标记为正在使用，并将相关的联系方式写入中介数据库。然后，该联系人将使用传统联络中心查询返回的电话号码转移到 Amazon Connect。然后，Amazon Connect 将使用AWS Lambda中介数据库查询联系人详细信息，进行相应路由，并重置中间数据库中的联系人数据，允许再次使用电话号码。

混合

在这种情况下，您可以让 IVR 和代理在 Amazon Connect 和旧版联络中心平台上parallel 运行，以允许站点、代理组或 line-of-business 迁移。

传统联络中心迁移

在针对新的或现有的工作负载评估 Amazon Connect 时，可以考虑多种策略。对于在 Amazon Connect 和您的传统联络中心解决方案之间转移联系人时需要包含联系人详细信息的情况，在迁移完成之前，将需要使用混合模型架构。本节中描述的方法允许您分阶段转移特定的业务线，管理培训和支持，并降低与变更相关的风险。

新工作负载

通过在 Amazon Connect 上采用新的净工作负载，您可以降低与现有业务部门变更相关的风险，提高灵活性和数字创新潜力。不需要混合模型架构的新工作负载不那么复杂，不受业务流程或代理程序变化的影响，并且可以缩短上市时间。采用全新工作负载可以让您充分利用基于使用量的 pay-as-you-go 定价。您的联络中心资源可用于为其最终用户创造全新体验，测试和实施该体验以评估平台，获得信心，并培养技能和操作机制，为跨现有工作负载进行更大规模的迁移做好准备。

IVR First

您可以选择使用 Amazon Connect 来提升联系人的 IVR 体验，同时您的代理人仍使用您的传统联络中心平台。通过这种方法，您可以使用 Amazon Connect Flows 来推动自助服务和路由逻辑，并在必要时将联系人转移到传统联络中心平台上的目标代理或代理队列。

IVR Last

通过这种方法，您的传统联络中心 IVR 可驱动联系人的 IVR 自助服务和路由逻辑，并在必要时将联系人转移到 Amazon Connect 以路由到您的代理群体。

业务线细分

如果您的业务部门有单独的 IVR 或不需要将联系人转移到传统联络中心平台，则可能需要考虑采用业务线迁移方法。例如，选择您的服务台提供内部支持，作为迁移的第一条业务线。将服务台 IVR 和代理人群迁移到 Amazon Connect 后，您可以选择将现有联系人转发到 Amazon Connect，在测试和业务验证完成后移植终端节点。

站点或代理组细分

如果您的联络中心覆盖全球，服务联系人来自多个国家，或者由相应的地理位置或地点独立管理，则可能需要考虑基于代理的物理站点或地理位置进行迁移。每个代理群体和/或地理位置都有自己独特的要求和注意事项，这些要求和注意事项可能不适用于全球。以这种方式进行迁移将使每个站点或代理组在进入下一个站点或代理组之前获得继续独立运行所需的技能。

虚拟桌面基础设施 (VDI)

虽然您可以在虚拟桌面基础设施 (VDI) 环境中使用 Amazon Connect Connect 控制面板 (CCP)，但它会给您的解决方案增加另一层复杂性，因此需要单独进行 POC 工作和性能测试以进行优化。配置/支持/优化最好由您的 VDI 支持团队处理，以下部署模型是最常实现的模型。

具有本地浏览器访问权限的 VDI 客户端

您可以使用 Amazon Connect Streams API 构建自定义 CCP，方法是创建没有用于呼叫信号的媒体的 CCP。这样，会在本地桌面上使用标准 CCP 处理媒体，并使用没有媒体的 CCP 通过远程连接处理信号发送和呼叫控制。下图描述了这种方法：

没有本地浏览器访问权限的 VDI 客户端

有时 VDI 客户端无法访问本地浏览器。在此方案中，您可以创建单个 CCP 实例，其中包含从 VDI 服务器运行的媒体创建单个 CCP 实例，允许用户使用 CP 实例。对于这种部署模型，通常在 VDI 操作系统上启用 UDP 音频。此部署模型需要进行大量测试来校准不同的 VDI 服务器参数以优化体验质量：