本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
概觀
成功移轉的基礎
若要成功進行聯絡中心遷移，不應該只將遷移視為技術交付專案，應從多個角度進行處理。否則，您可能會忽略重要的準備工作，例如員工培訓和操作模式變更。這些非技術考量事項對於確保整體成功至關重要。
下圖中說明的支柱是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 分數的顯著改善。
