View a markdown version of this page

Connect Customer 中的场景和部署方法 - Amazon Connect Customer
传统联系中心入站出站Hybrid传统联系中心迁移虚拟桌面基础架构 (VDI)

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

Connect Customer 中的场景和部署方法

Connect Customer 提供自助服务配置，并通过各种迁移和集成选项实现任何规模的动态、个性化和自然的客户互动。在本节中，我们将解释在为Connect客户设计工作负载时要考虑的以下场景和部署方法：

  • 传统联系中心

  • 入站

  • 出站

  • 混合联络中心

  • 传统联系中心迁移

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

传统联系中心

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

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

传统联络中心。

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

入站

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

由联系人向中心发起的入站请求。

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

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

队列中的入站联系人。

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

出站

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

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

要向客户拨打外呼并运行指定流程，请使用以下 AWS CLI 命令。目标电话号码必须采用 E.164 格式。必须指定源电话号码或队列。如果您未指定队列，则出站联系人将使用该流程中定义的队列。

在以下命令中，将instance-id、contact-flow-id、电话号码值和aws-region替换为你自己的值。如果您在流程中指定队列，则该--source-phone-number参数是可选的。

aws connect start-outbound-voice-contact \
    --instance-id "instance-id" \
    --contact-flow-id "contact-flow-id" \
    --destination-phone-number "+15551234567" \
    --source-phone-number "+15557654321" \
    --region "aws-region"

成功后，该命令将ContactId返回新联系人的：

{
    "ContactId": "00000000-0000-0000-0000-000000000000"
}

Hybrid

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

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

IVR-only

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

客户交互式语音应答体验。

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

Agent-only

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

仅限特工的经验。

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

混合

在这种情况下，您可能会让 IVR 和座席在 Connect Customer 和传统联络中心平台上并行运行，以允许站点、座席组或业务线迁移。

仅限混合代理和交互式语音应答体验。

传统联系中心迁移

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

新工作负载

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

优先采用 IVR

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

最后采用 IVR

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

业务线细分

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

站点或座席组细分

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

虚拟桌面基础架构 (VDI)

虽然您可以在虚拟桌面基础架构 (VDI) 环境中使用连接客户联系人控制面板 (CCP)，但这将为您的解决方案增加另一层复杂性，因此需要单独进行POC工作和性能测试以进行优化。 configuration/support/optimization 最好由您的 VDI 支持团队处理，以下部署模型是最常实现的。

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

您可以使用 Connect Customer Streams API 构建自定义 CCP，方法是创建不带媒体的呼叫信令的 CCP。这样，使用标准 CCP 在本地桌面上处理媒体。信令和呼叫控制在没有媒体的情况下通过与 CCP 的远程连接进行处理。下图描述了这种方法。

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

使用 Connect 客户音频优化功能的 Citrix VDI

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

连接 Citrix VDI 环境的客户媒体工作流程。
注意

此解决方案要求您允许 VDI 服务器和 Connect Customer 之间的 WebRTC 信号流量，以及代理的桌面与 Connect Customer 之间的媒体连接。有关更多信息，请参阅设置您的网络以使用 Connect 客户联系人控制面板 (CCP) 文档。

采用 Connect 客户音频优化的 Amazon WorkSpaces VDI

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

连接客户和工作空间环境。

带有 Connect 客户音频优化功能的 Omnissa VDI

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

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

连接客户和 Omnissa 环境。

带有 Connect 客户音频优化功能的 Azure 虚拟桌面和 Windows 365 VDI

如果您的代理使用 Azure Virtual Desktop (AVD) 或 Windows 365 Cloud PC，则可以使用 (MMR) 优化 Connect Custom Microsoft Multimedia Redirection er 音频。这种方法不需要在 CCP 中使用特定平台的 SDK。MMR 浏览器扩展程序透明地将标准 WebRTC 媒体从会话主机重定向到代理的本地设备，在那里它直接连接到 Connect Customer。代理的本地设备代替会话主机处理音频，这样可以减少网络跳跃并提高音频质量。下图阐释了这种方法。

该图显示了 Azure 会话主机上的 MMR 浏览器扩展程序将音频重定向到代理的本地设备，该设备直接连接到 Connect Customer。

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

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

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