

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

# 技术注意事项
<a name="tech-considerations"></a>

有关以下最佳技术实践和其他建议的更多信息，请参阅 *Amazon Connect 管理员指南*中的 [Amazon Connect 最佳实践](https://docs.aws.amazon.com/connect/latest/adminguide/best-practices.html)。

**语音流量路径** — 音频流会通过公司的互联网链接传输，还是应该使用 Direct Connect 连接作为专用链接？ Direct Connect 避免对延迟敏感的语音流量与数据中心互联网管道（例如网页浏览和电子邮件）上的普通流量竞争。

**设置您的网络**-健康的 end-to-end网络连接对于获得一致和稳定的用户体验至关重要。您应该考虑每个组件，从座席的设备到其本地网络连接和虚拟专用网络（VPN），再到 Amazon Connect（如果适用）。网络连接的运行状况取决于其最薄弱的一环。要针对 Amazon Connect 优化您的网络，请查看 *Amazon Connect 管理员指南*中的[设置您的网络](https://docs.aws.amazon.com/connect/latest/adminguide/ccp-networking.html)。

**远程座席** — 您的座席在家办公时是否使用 VPN？ 如果是，请考虑为语音流量启用 VPN 隧道分离。该举措会通过本地互联网路由延迟敏感型语音流量，而不是将其发送回数据中心，然后通过互联网将其路由到 Amazon Connect。如果您不使用隧道分离，则会增加不必要的延迟（导致音频延迟或软电话操作缓慢），VPN 集中器设备会增加额外的流量负载，并且您的数据中心互联网入口和出口费用也会增加。

**数据迁移** — 对于诸如通话录音和报告统计数据之类的数据，请考虑两种方法：
+ 将数据迁移到新平台。这需要进行规划和可行性评估（例如，检查音频格式的兼容性），但这意味着您可以从新平台上的单个门户访问您原有的数据。
+ 将您的数据存档到位，并在最短保留期到期后将其停用。这可能更具成本效益，特别是数据存储在付费的平台上并且不经常访问的情况，因此拥有两个门户分别用来浏览新旧数据是一种切实可行的选择。

**号码移植**
+ 考虑是否需要非地理号码（NGN）提供商或免费电话号码服务（TFNS）提供商。将免费电话、本地费率或 direct-dial-in (DDI) 号码移植到 Amazon Connect，可以集中管理和计费通话。 end-to-end请考虑当前NGN/TFNS service and compare it with Amazon Connect charges. Be mindful of charges for calls that are made outside operating hours. Some NGN/TFNS providers do not charge for these calls if they handle the out-of-hours check and messaging. NGN/TFNS合同的收费模式，条款各不相同，因此请仔细收集信息以进行准确的比较。
+ 号码移植的时间表可能需要几周的时间，因此请尽早通过票证提交移植请求。使用票证最终确定割接日期和时间。如果时间表处理有问题，请设置临时性的号码转发，从现有电话队列转移到新的 Amazon Connect 电话号码，详见下面的割接选项。 

**移植号码的割接方法**

您可以使用 NGN 后端重新指向或号码移植来移植电话号码。

*NGN 后端重新指向* — 将前端 NGN 号码后端重新指向到托管在 Amazon Connect 上的入站号码（DDI），如下图所示。这不需要更改任何公开的号码，其通常作为 NGN 运营商提供商的服务请求票证进行管理。可以将重新指向安排在特定的日期和时间。

![\[NGN 后端重新指向\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-migration-connect/images/ngn-repoint.png)


*号码移植* — 此过程包括两个阶段：
+ 号码转发 — 此为可选步骤。如下图所示，将流量从旧平台引导到新平台，而无需更改公开的号码。您可以在预定的号码移植日期之前完成此步骤。这加快了座席向新平台的迁移速度，同时加快了号码移植过程。还可以在不依赖运营商的情况下快速回滚（取决于对呼叫转发规则的相对简单的更改）。但是，我们建议您不要长时间保持号码转发状态，因为这会增加呼叫费用（您需要为 DDI-1 的入站流量付费，为新的 DDI-2 的出站转发和入站流量付费）并消耗基础设施容量（每个入站呼叫还会消耗转发路径的出站电路）。  
![\[号码转发是移植呼叫中心号码的第一步\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-migration-connect/images/ngn-xfer-1.png)
+ 完成号码移植 — 在约定的日期和时间，DDI-1 的承运人将号码移植到 AWS，这样 Amazon Connect 就可以使用，如下图所示。然后，您可以将该号码分配给用户历程或功能，并将其当作本地来源的 DDI 在 AWS中进行管理。这简化了计费并提供了灵活性，因为您可以在 Amazon Connect 控制台中管理电话号码，而不必依赖第三方运营商来处理服务请求。  
![\[完成呼叫中心迁移的号码移植\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/strategy-migration-connect/images/ngn-xfer-2.png)

在**其他平台和 Amazon Connect 之间转移呼叫** — 组织通常根据业务范围、工作类型或其他标准将代理分组迁移到 Amazon Connect。在一段时间内，其他平台上的代理组会逐步迁移到 Amazon Connect。根据群组的数量和规模，迁移阶段可能需要几个月的时间，分散在不同平台上的团队可能需要在此期间相互转接呼叫。

要在平台之间转接呼叫，请使用 PSTN DDI 号码。 DDIs 仅针对跨平台转接使用情况进行分配，因此您可以独立衡量和报告转接情况，并在需要时以不同的方式确定呼叫的优先级。

考虑在传输期间是否必须在平台之间交换呼叫附加数据。例如，如果来电者在一个平台上通过了安全检查，则应在呼叫转接期间交换其安全状态，以防止他们不得不再次通过 Amazon Connect 上的代理通过安检。有两种方法需要考虑：
+ **不带呼叫附加数据的传输** — 结构迁移组阶段划分，以减少在需要呼叫附加数据的情况下对传输的操作需求。例如，在来电者交换了大量数据之后，将经常相互转接呼叫的团队迁移在一起，否则这些数据需要重新捕获。如果呼叫者在跨平台转接之前仅与 IVRs 或代理进行最少的交互，则可能没有必要交换呼叫附加数据。您还应该考虑加快迁移时间，以最大限度地缩短跨平台传输的时间。这意味着接受暂时的不便，以换取不必建立技术债务，也不必管理迁移完成后不再需要的跨平台数据交换解决方案。
+ **带有呼叫附加数据的转移** — 这种方法适用于需要在相当长一段时间内跨平台分散并且需要在转移期间交换呼叫附加数据以保持运营绩效的团队。使用一种称为*滚动拨号号码识别服务 (DNIS) 的*技术。有关如何开始滚动 DNIS 的示例，请参阅 GitHub存储库[从旧平台传输到 Amazon Connect](https://github.com/aws-samples/Transfers_from_Legacy_Platform_into_Amazon_Connect)。

**单独 AWS 账户**-为您的 Amazon Connect 开发、测试和生产实例设置不同的 AWS 账户。这种方法将这些活动分离开来，并将变革的影响限制在单个账户上。它还提供了计费界限，以便相应的业务部门支付开发、测试和生产工作的费用。 

您可以根据预定义的模板创建具有特定政策、规则和原则的新账户。这意味着该账户中的任何构建或配置都必须符合组织定义的规范。您可以用 [AWS Organizations](https://aws.amazon.com/organizations/) 集中管理和治理账户。

**记录和提醒-启**用 Amazon CloudWatch Logs 以跟踪使用量阈值和联系流中的错误。您可以使用 CloudWatch 仪表板查看使用情况和错误。您还可以通过电子邮件或 SMS 短信主动发送警报。通过深入了解低级系统行为，您可以在问题变得严重前快速识别和解决问题。博客文章《[使用亚马逊版 Amazon For Amazon Connect 监控和触发警报》中描述了 Amazon CloudWatch Connect 的主动警报](https://aws.amazon.com/blogs/contact-center/monitor-and-trigger-alerts-using-amazon-cloudwatch-for-amazon-connect/)解决方案示例。

**单点登录（SSO）**— 使用 SSO 使用户能够使用其公司凭证（例如，通过 Active Directory）登录 Amazon Connect，而不需要使用单独的用户名和密码。这提供了最佳的用户体验，因为它不需要额外的登录步骤或是另一组凭证。它还无需集中管理用于密码重置和其他操作的单独登录凭证。Amazon Connect 支持多种身份管理集成模式。有关更多信息，请参阅 *Amazon Connect 管理员指南*中的 [在 Amazon Connect 中计划身份管理](https://docs.aws.amazon.com/connect/latest/adminguide/connect-identity-management.html)。

**工作站设备** — 验证最终用户（例如座席和主管）计算机是否满足 *Amazon Connect 管理员指南*中 [CCP 座席耳机和工作站要求](https://docs.aws.amazon.com/connect/latest/adminguide/ccp-agent-hardware.html)部分规定的最低 CPU 和内存要求。如果您计划将这些工作站用于联络中心工作以外的任务，则它们应该满足更高的要求。使用 Amazon Connect [端点测试实用程序](https://docs.aws.amazon.com/connect/latest/adminguide/check-connectivity-tool.html)检查设备和网络的兼容性。我们建议您在不同地点的各种座席工作站上运行此实用程序，包括在家办公或在不同网络岛上工作的座席，以确保整个组织的兼容性。

**虚拟桌面基础架构（VDI）环境** — 考虑针对虚拟桌面用户的[网络](https://docs.aws.amazon.com/connect/latest/adminguide/using-ccp-vdi.html)和[部署](https://docs.aws.amazon.com/connect/latest/adminguide/scenario-deployment-approaches.html)优化。

**耳机** — 使用由 USB 供电的有线耳机以确保一致的音频体验。不鼓励使用蓝牙或无线耳机，因为这会增加延迟并降低音频质量。

**有线网络连接** — 设备应使用有线（以太网）连接，以确保稳定、高质量的音频体验。验证设备是否有有线端口。如果需要保护锁，则必须在迁移之前进行预算和采购。

**麦克风和扬声器****设置** — 如果您的组织使用多功能设备，请确认允许共享麦克风和扬声器（关闭独占模式）。有关指南请参阅 *Amazon Connect 管理员指南*中的[来自客户的单向音频？](https://docs.aws.amazon.com/connect/latest/adminguide/one-way-audio-from-customers.html)。本指南适用于扬声器和麦克风。

**专属设备**（理想）— 如果可能，应为用户提供专供联络中心使用的设备。然后，为了提升联络中心体验，您可以优化这些设备，并使用不同的设备执行其他任务。

**原有的习惯**— 注意可能影响新流程的用户原有的习惯行为。例如：
+ 座席设备现在主要通过 Wi-Fi 连接吗？ 如果是这样，则要求有线连接对于座席而言是一种文化变革，并可能导致合规性问题和不良的通话体验。可能需要开展终端用户培训活动来推动这种文化变革。
+ 座席是否在其设备上使用其他协作应用程序（例如 Microsoft Teams 或 Zoom）？ 这可能会导致对设备上的扬声器和麦克风设备的需求相互冲突，例如 Amazon Connect 在座席正在接听一个呼叫时尝试转入另一个呼入。这还可能导致座席因为忙于拨打内部电话而错过客户来电。我们建议如果可行，请删除其他协作应用程序，以避免通话冲突。