本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 決策程序
<a name="decision-making-processes"></a>

使用下列步驟來定義從內部部署Avaya聯絡中心遷移至 Amazon Lex 和 Amazon Connect Customer 的策略：
+ [步驟 1：定義業務目標和排程](#step-1)
+ [步驟 2：選擇分階段方法或完整遷移](#step-2)
+ [步驟 3：選擇遷移策略](#step-3)
+ [步驟 4：選取您的架構](#step-4)

## 步驟 1：定義業務目標和排程
<a name="step-1"></a>

這是遷移決策程序的第一步。如果專案的目標是提高自助式服務，並僅針對 IVR 使用 Amazon Lex，您必須規劃如何在 Avaya和 Amazon Lex 之間傳輸通話。了解現有現場部署系統的限制可協助您設計高效的架構。以下是高階業務目標的範例，以及您可能預期實現這些目標的時間範圍：
+ 在三個月內，將 Avaya IVRs 分階段遷移至每個業務單位的 Amazon Lex。
+ 在一年內，從Avaya內部部署系統完全遷移到 Amazon Connect Customer 和 Amazon Lex。

## 步驟 2：選擇分階段方法或完整遷移
<a name="step-2"></a>

考慮遷移聯絡中心系統時，有兩種可能的方法：
+ **分階段方法 – **在此方法中，您不會一次全部轉換。相反地，您可以逐步策略性地移動特定元件或函數。這可能意味著一次遷移一個 IVR 業務函數，這提供更多控制，並可協助您將中斷降至最低。此方法可讓您在繼續時測試、學習和調整。對於具有複雜系統或想要將風險降至最低的組織，這通常是首選選項。
+ **完全遷移** –** **在此方法中，您可以進行完整的切換並同時轉換所有聯絡中心系統，而不是將遷移分成幾個部分。這種方法可能更快，但會帶來自己的一組挑戰。它需要精細的規劃和準備。如果您對遷移計劃有信心，並希望更快速地轉換，這可能是您的方法。

在選擇這些方法時，評估業務營運的大小、複雜性和特定需求至關重要。關鍵是在將中斷降至最低和確保順利轉換到新系統之間取得平衡。

## 步驟 3：選擇遷移策略
<a name="step-3"></a>

傳統的內部部署聯絡中心通常以雙音多頻率 (DTMF) 方法或speech-to-text型方法為基礎。不建議使用 Amazon Lex 複寫您的內部部署體驗，特別是當您的呼叫流程非常複雜時。反之，您可以專注於使用 Amazon Lex 的 AI 功能來推動卓越的體驗。不過，如果您專案的目標是遷移至雲端，而您現有的呼叫流程非常基本，您可以選擇重新託管，然後在未來現代化體驗。

## 步驟 4：選取您的架構
<a name="step-4"></a>

根據遷移專案的目標，從本指南 [將內部部署Avaya聯絡中心遷移至 的架構選項 AWS](architecture-options.md)一節中討論的可能方法清單中選擇。