本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# Amazon Connect 中的场景和部署方法
<a name="scenario-deployment-approaches"></a>

Amazon Connect 提供自助配置，支持任何规模的动态、个人和自然的客户互动，并提供各种迁移和集成选项。在此部分，我们将介绍在为 Amazon Connect 设计工作负载时需要考虑的以下场景和部署方法：
+ 传统联系中心
+ 入站
+ 出站
+ 混合联络中心
+ 传统联系中心迁移
+ 虚拟桌面基础架构 (VDI)

## 传统联系中心
<a name="traditional-contact-center"></a>

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

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

![传统联络中心。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/traditionalcontactcenter.png)


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

## 入站
<a name="inbound"></a>

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

![此图显示了联系人向中心发起的入站请求。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/inbound.png)


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

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

![此图显示了队列中入站联系人。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/inbound2.png)


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

## 出站
<a name="outbound"></a>

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

出站活动通常由从联系人列表导出 CRMs 并分离到联系人列表中的联系人数据驱动。这些联系人将进行优先级排序，并交付给座席以在一段时间的预览后启动，或者使用 Amazon Connect 出站 API 以编程方式联系，由您的流逻辑驱动，并根据需要连接到座席。典型的出站联络中心使用案例包括欺诈和服务提醒、收集和预约确认。

## Hybrid
<a name="hybrid"></a>

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

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

### 仅限 IVR
<a name="ivr-only"></a>

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

![此图显示了客户互动语音应答体验。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/hybridivr.png)


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

### 仅座席
<a name="agent-only"></a>

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

![此图显示了仅限座席体验。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/hybridagentonly.png)


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

### 混合
<a name="mixed"></a>

在这种情况下，您的 IVR 和代理可能会在 Amazon Connect 和旧的联络中心平台上并行运行，以便进行站点、座席组或 line-of-business迁移。

![此图显示了仅限混合座席和客户互动语音应答体验。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/hybridmixed.png)


## 传统联系中心迁移
<a name="legacy-contact-center-migration"></a>

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

### 新工作负载
<a name="new-workload"></a>

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

### 优先采用 IVR
<a name="ivr-first"></a>

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

### 最后采用 IVR
<a name="ivr-last"></a>

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

### 业务线细分
<a name="lob-segmentation"></a>

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

### 站点或座席组细分
<a name="agent-segmentation"></a>

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

## 虚拟桌面基础架构 (VDI)
<a name="vdi"></a>

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

### 具有本地浏览器访问权限的 VDI 客户端
<a name="vdi-with-browser"></a>

您可以使用 [Amazon Connect Streams](https://github.com/aws/amazon-connect-streams) API 创建一个不含呼叫信令的媒体的 CCP，从而构建自定义 CCP。这样，会在本地桌面上使用标准 CCP 处理媒体，并使用不含媒体的 CCP 通过远程连接处理信号发送和呼叫控制。下图描述了这种方法。

![具有本地浏览器访问权限的 VDI 客户端。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/vdi.png)


### Citrix VDI 与 Amazon Connect 音频优化
<a name="vdi-citrix"></a>

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

![适用于 Citrix VDI 环境的 Amazon Connect 媒体工作流。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/vdi-citrix.png)


**注意**  
此解决方案要求您允许 WebRTC 在您的 VDI 服务器和 Amazon Connect 之间传输信令流量，以及允许在座席的桌面和 Amazon Connect 之间建立媒体连接。有关更多信息，请参阅[设置网络以使用 Amazon Connect 联系人控制面板 (CCP)](ccp-networking.md) 文档。

### 带有 Amazon WorkSpaces Connect 音频优化的亚马逊 VDI
<a name="vdi-amazon-workspaces"></a>

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

![Amazon Connect 和 Workspaces 环境。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/vdi-connect.png)


### Omnissa VDI 与 Amazon Connect 音频优化
<a name="vdi-omnissa"></a>

Omnissa 虚拟桌面基础架构（VDI）解决方案通过实施自定义联系人控制面板（CCP），实现了与 Amazon Connect 的简化集成。

 通过将Amazon Connect RTC JavaScript 库与Omnissa的Horizon WebRTC软件开发工具包结合使用，通过将媒体流直接从代理的本地终端节点重定向到Amazon Connect来优化音频处理。这种架构消除了通过虚拟桌面进行音频路由的传统挑战，为座席在使用其 Omnissa VDI 环境时提供了卓越的语音体验。该解决方案消除了管理单独音频重定向应用程序的复杂性，为座席互动提供了一个统一的界面。下图阐释了此架构方法。

![Amazon Connect 和 Omnissa 环境。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/omnissa-6.png)


### 不具有本地浏览器访问权限的 VDI 客户端
<a name="vdi-without-browser"></a>

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

![不具有本地浏览器访问权限的 VDI 客户端。](http://docs.aws.amazon.com/zh_cn/connect/latest/adminguide/images/architecture/vdinobrowser.png)