场景和部署方法

Amazon Connect 提供自助配置，支持任何规模的动态、个人和自然的客户互动，并提供各种迁移和集成选项。在此部分中，我们将介绍在为 Amazon Connect 设计工作负载时需要考虑的以下场景和部署方法：

• 传统联系中心

• 入站

• 出站

• 混合联系中心

• 传统联系中心迁移

• 虚拟桌面基础架构 (VDI)

传统联系中心

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

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

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

入站

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

当向 Amazon Connect 实例中申请或转网到的号码拨打电话时，将调用与被叫号码关联的流。您可以使用无需编码知识即可配置的流数据块来定义流。流可确定应如何处理和路由联系人，可以选择提示联系人提供其他信息以协助路由决策，将这些属性存储到联系详细信息中，并在必要时将该联系人路由到座席，并附上在整个过程中收集的所有叫详细信息和转录。通过该流程，您可以调用 AWS Lambda 函数来查询客户信息，调用 Amazon Pinpoint 等其他 AWS 服务发送短SMS信，以及使用原生 AWS 服务集成，包括适用于NLU/NLP的 Amazon Lex 和 Kinesis Video Streams 来实时直播语音通话。

如果入站联系人需要联系座席，则根据您的路由配置，当该联系人将其状态更改为“可用”时，该联系人将被放入队列中并路由到座席。当手动或通过自动接受配置接受可用座席的联系人时，Amazon Connect 会将联系人与座席连接。

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

出站

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

出站活动通常由从联系人列表导出CRMs并分离到联系人列表中的联系人数据驱动。这些联系按优先顺序排列，要么在预览一段时间后发送给客服人员发起，要么使用 Amazon Connect Outbound 以编程方式联系API，由您的流程逻辑驱动，并根据需要连接到代理。典型的出站联系中心使用案例包括欺诈和服务提醒、收集和预约确认。

混合

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

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

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 和您的传统联络中心平台上并行运行，以便进行站点、座席组或 line-of-business 迁移。

传统联系中心迁移

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

新工作负载

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

IVR首先

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

IVR最后一次

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

业务线细分

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

站点或座席组细分

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

虚拟桌面基础架构 (VDI)

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

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

您可以通过 Amazon Connect Stream API s 创建不CCP包含呼叫信令媒体的自定义CCP内容。这样，就可以在本地桌面上使用标准处理媒体CCP，而信令和呼叫控制则在没有媒体的情况下通过远程连接CCP进行处理。下图描述了这种方法：

VDI具有 Amazon Connect 音频优化功能的 Citrix

如果您使用 Citrix 虚拟桌面基础设施 (VDI) 环境，则可以使用 Amazon Connect RTC JavaScript 库构建自定义CCP库，该库与 Citrix 联合通信 SDK (ucsdk) 集成，并自动将媒体从本地桌面重定向到 Amazon Connect。这使您的代理能够使用 Citrix VDI 客户端应用程序（例如 Citrix Workspaces）连接到其自定义代理应用程序或自定义代理应用程序。CCPs这样就无需为其 Citrix 环境的音频媒体重定向开发和管理单独的代理应用程序（例如 dual-CCPs）。下图描述了这种方法：

注意

此解决方案要求您允许VDI服务器和 Amazon Connect 之间的网络RTC信令流量，以及代理的桌面和 Amazon Connect 之间的媒体连接。有关更多信息，请参阅设置网络 文档。

亚马逊采 WorkSpaces VDI用 Amazon Connect 音频优化

通过使用虚拟桌面基础设施 (VDI) 环境 Amazon WorkSpaces，您可以利用 Amazon Connect 实时通信 (CCP) JavaScript 库创建自定义的联系人控制面板 (RTC)。该库与亚马逊无缝集成 WorkSpaces SDK，可自动将媒体从本地桌面重定向到 Amazon Connect。这样就无需开发和管理专门用于其 WorkSpaces 环境中的音频媒体重定向的单独代理应用程序（例如 dual-CCPs）。下图说明了这种方法：

VDI无法访问本地浏览器的客户端

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