本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
概述
成功迁移的支柱
要成功执行联络中心迁移，您不应将迁移仅仅视为一个技术交付项目，而应从各种视角进行看待。否则，您可能会忽略重要的准备工作，例如员工培训和运营模式变革。这些非技术方面的注意事项对于确保整体成功至关重要。
下图所示的支柱是AWS 云采用框架
将用户（客户、座席和操作员）转移到新的平台和工具集是一项艰巨的工作。无论您是要将现有的本地联络中心历程迁移到云端，还是要重构整个客户和座席体验，联络中心迁移都需要全面周密的规划。
以下各节讨论规划、管理以及完成向 Amazon Connect 的迁移的方法和最佳实践。
主要愿景
成功的联络中心迁移先从业务需求开始，其次关注人员、流程和技术。
首先制定一份主要愿景宣言，开启您的 Amazon Connect 迁移规划。这应该是指导决策制定方向的一般原则。然后，您可以在此一般原则的范围内为特定决策领域定义更具体的指导原则。
例如，你的项目的主要愿景陈述可能会回答 “成功是什么样子？” 如下所示：“在快速迁移服务线路的同时，最大限度地减少对用户的干扰（按重要性顺序排列：客户、代理、系统运营商）。”
请注意重点强调以下短语：
-
最大限度减少用户中断 — 根据您的联络中心的开放时间和后端系统的实际情况，迁移期间可能无法完全避免停机。现实一点，考虑与在不停机的情况下完成迁移所需的时间和精力相比，预期的中断是否尚可容忍。与完全不中断相比，接受最低限度的中断可能会降低项目交付其他领域的风险或节省大量成本。例如，您可能决定将新的网址分发给用户以访问新的 Amazon Connect 桌面，而不是迁移现有网址。这有助于避免签署新域证书和管理网址割接所花费的精力和费用。
-
按重要性顺序排列的用户列表 — 在迁移过程中，客户、座席和系统操作员有不同的优先级。一般来说，当务之急是避免为客户带来中断，即使这意味着要为座席和后端系统操作员带来额外的中断。
-
快速 — 迁移期间运营多个联络中心平台在财务和资源方面费用都很高。您的目标应该是尽可能缩短双系统状态的时长。时间越长，成本越高，操作员的负担越大，造成人为错误（例如在错误的平台上进行更改）的风险就越大。在严谨性、深度与快速移动的需求之间取得平衡。制定切实可行的交付计划并尽量遵循计划。
目标业务成果
在规划联络中心迁移时，请谨记以下业务成果：
-
业务敏捷性提高 — 快速、安全地将新功能投入生产。例如，情绪分析和大数据通话记录爬取可帮助您收集对客户通信的近乎实时的见解，并使您能够根据他们的需求优化产品和服务。确定并实现这些功能后，您可以通过使用 DevOps 原则来交付这些功能，这些原则鼓励开发人员和运营商之间的协作，并使用基础设施即代码 (IaC) 工具以及持续集成和持续交付 (CI/CD) 管道来管理构建和自动化测试。尽可能避免手动重复步骤，以避免人为错误给实施过程造成错误。
-
总拥有成本（TCO）有所改善，尤其是在早期阶段 — 返工需要花费时间和精力。要在第一时间做出正确的关键决策，请为迁移的发现和设计阶段分配足够的时间。如果没有相当高的成本投入，基础设施决策难以改变，因此请咨询相应的利益相关者。例如，更改通话录音的加密策略可能需要额外的基础设施组件，因此在开始实施之前，请确保您的安全合规性团队批准加密策略。在进入构建阶段之前，请先获得设计的批准。
-
敏捷客户体验 — 使用敏捷方法快速迭代地开发呼叫方历程。与基础设施组件不同，联系流程和用户历程很容易更改，因此请尽早从基本流程开始，并经常与利益相关者进行迭代以达到所需的状态。在 Amazon Connect 中添加消息提示或更改菜单选项很简单，无需任何编程知识。您的目标应该是交付正确的用户历程，而不是严格遵循您最初设计的历程。经常迭代使利益相关者能够在历程成熟和收到反馈时对其进行调整。
-
顺畅及时地介绍服务 — 在项目接近完成之前，用户培训、流程变更和服务台变更经常被忽视。新的联络中心必须被贵组织接受并纳入常规业务（BAU）运营，同时必须符合发布日期。如果没有适当移交，项目团队将无法抽身，BAU 团队也无法准备好使用新平台。让您的项目与 BAU 运营的集成成为发布批准的大门。在发布之前就平台所有权达成共识是至关重要的。从项目一开始就让服务介绍和运营模式的利益相关者参与进来，并让他们保持参与整个过程。
-
引入新的差异化功能以提高客户满意度（CSAT）分数 — 扪心自问 Amazon Connect 能否简化或改善用户体验。不要局限于将当前的呼叫中心直接迁移云端。使用 Amazon Connect 功能改善用户（客户和座席）体验或简化平台的技术实施。只需相对较少的努力，您就可以将新的 Amazon Connect 功能纳入您的呼叫中心，并使 CSAT 分数得到显著提高。
