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

# Decision-making 进程
<a name="decision-making-processes"></a>

使用以下步骤来定义从本地Avaya联络中心迁移到 Amazon Lex 和 Amazon Connect 客户的策略：
+ [步骤 1：定义业务目标和时间表](#step-1)
+ [步骤 2：选择分阶段迁移或全面迁移](#step-2)
+ [步骤 3：选择迁移策略](#step-3)
+ [步骤 4：选择架构](#step-4)

## 步骤 1：定义业务目标和时间表
<a name="step-1"></a>

这是迁移决策过程中的第一步。如果该项目的目标是增加自助服务，并仅使用 Amazon Lex 进行 IVR，您必须制定策略来决定如何在 Avaya 与 Amazon Lex 之间转移呼叫。了解现有本地系统的限制有助于您设计高效的架构。以下是高级业务目标以及您可能期望实现这些目标的时间范围的示例：
+ 在三个月内，将每个业务部门的 Avaya IVR 分阶段迁移到 Amazon Lex。
+ 在一年内，从Avaya本地系统完全迁移到 Amazon Connect 客户和 Amazon Lex。

## 步骤 2：选择分阶段迁移或全面迁移
<a name="step-2"></a>

在考虑迁移联络中心系统时，有两种可能的方法：
+ **分阶段方法**：在这种方法中，您不需要一次性完成所有过渡。相反，您可以策略性地逐步移动特定的组件或功能。这可能意味着一次迁移一项 IVR 业务功能，这样可以提供更多的控制并可以帮助您最大限度地减少中断。此方法提供了在前进过程中进行测试、学习和调整的机会。对于系统复杂或希望将风险降至最低的组织来说，这通常是首选。
+ **完全迁移**：****在此方法中，您无需将迁移分为多个部分，而是进行一次完整的切换，同时过渡所有联络中心系统。此方法可能更快，但也有自己的一些挑战。这需要精心的计划和准备。如果您对自己的迁移计划充满信心并希望更快地过渡，那么这可能是适合您的方法。

在这些方法之间进行选择时，必须评测业务运营的规模、复杂性和具体需求。关键是在最大限度地减少中断和确保顺利过渡到新系统之间取得平衡。

## 步骤 3：选择迁移策略
<a name="step-3"></a>

传统的本地联络中心通常采用双音多频（DTMF）方法或语音转文本方法构建。不建议使用 Amazon Lex 复制您的本地体验，尤其是在您的调用流极其复杂的情况下。相反，您可以专注于使用 Amazon Lex 的人工智能功能来提供卓越的体验。但是，如果您的项目的目标是迁移到云，并且您现有的调用流非常基础，您可以选择重新托管，然后在将来对体验进行现代化改造。

## 步骤 4：选择架构
<a name="step-4"></a>

根据您的迁移项目的目标，从本指南的[本地迁移的架构选项 Avaya 联系中心到 AWS](architecture-options.md)部分讨论的可能方法列表中进行选择。