本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
使用者旅程工作流
使用者旅程工作流也涉及可以在很少的努力或影響下進行變更或逆轉的決策。重點是從使用者旅程的基本構建開始，並頻繁且快速地迭代以獲得最終產品。最終使用者旅程很少與第一次提出的完全相同，因此敏捷和迭代的方法對於此工作流是有意義的。
使用者旅程工作流包含五個階段：探索、設計、建置、測試、部署和上線支援。
探索
在此階段中，您會收集現有的使用者旅程流程和設計，並將其傳遞給聯絡流程建置團隊。如果這些內容不存在，或者您想要設計新的使用者旅程，請在研討會中聚集利益相關者，並在可視化擷取工具中協同開發使用者旅程架構，例如：
-
可視化畫布工具 – 使用 Microsoft PowerPoint、Microsoft Visio 或 draw.io 等工具。在研討會中將畫布畫面共用給所有利益相關者。新增區塊和決策點以建立端對端使用者旅程，並為稍後應確認的步驟新增預留位置 (例如，佇列訊息音訊檔案的確切措辭或匯入)。新增應確認預留位置的擁有者名稱。
-
聯絡流程設計器 – 不使用繪圖工具 (例如 draw.io 或 Visio)，而考慮使用 Amazon Connect 中包含的聯絡流程設計器，以開發和記錄畫面共用中的使用者旅程。對於稍後應確認的步驟，使用提示區塊預留位置 (例如，佇列訊息音訊檔案的確切措辭或匯入)。使用簡單的text-to-speech(TTS) 提示區塊來記錄確認步驟的擁有者 （例如，「佇列 A 訊息 .wav 檔案由 John Smith 提供」)。這使您能夠並行執行使用者旅程和路由邏輯的端到端測試。
研討會與會者：
-
專案經理
-
業務和解決方案架構
-
業務分析師
-
服務專線擁有者和操作員
設計
設計文件是可選的。它取決於聯絡流程的大小和複雜性。如果您使用聯絡流程設計器 (它具有直觀、易於遵循的流程圖介面)，則旅程將自行記錄，並代表聯絡流程的實際建置。這確保了使用者旅程的快速且敏捷開發過程中的單一事實來源。否則，聯絡流程的獨立設計文件必須遵守變更控制，以避免隨著時間的推移與實際建置產生差異。
組建
透過使用基礎設施即程式碼 (IaC) 工具中的 AWS CloudFormation 範本和 API，可使用 Amazon Connect 組態。使用 DevOps 工具來建立和管理 Amazon Connect 元件，例如安全設定檔和聯絡流程。如果使用聯絡流程設計器來設計流程，則可以在 IaC DevOps 工具中包含流程，並將其手動匯出為 JSON 檔案。
注意
您也可以在建立其他 AWS 帳戶時開始在開發環境中建立聯絡流程，並在 Amazon Connect 執行個體準備就緒時將流程匯出到測試和生產環境中。
測試
測試階段由兩個順序子階段組成：
-
功能測試 – 在 Amazon Connect 中建立聯絡流程時，透過敏捷衝刺迭代執行。執行者：功能測試團隊
-
使用者接受度測試 (UAT) – 僅在聯絡流程通過功能測試之後執行。執行者：用戶端業務使用者 (來自服務線路業務單位的專業團隊或使用者)
部署
在此階段中，客服人員和使用者憑證會上傳到 Amazon Connect 生產執行個體中，以便使用者可以登入。只有聯絡流程在上一階段成功通過 UAT 測試之後，才應該將其上傳。在 Amazon Connect 儀表板中申請臨時電話號碼，並將其指派給聯絡流程。只有專案團隊才能看見這些電話號碼，他們會使用這些電話號碼來進行測試呼叫。在此過程中，專案團隊經常執行選擇的 UAT 指令碼。在系統上線及真正的客服人員可以存取工作流程之前，此方法提供使用者旅程的準備 (管道清理) 測試。在排定的上線時間，此臨時號碼會被客戶使用的公開路由號碼取代，這是您切換到新系統的時間點。如有必要，您可以將號碼掉換回舊服務線路，以復原變更。
上線後支援 (PGLS)
在新聯絡中心上線後的頭幾週內，專案團隊仍然與服務線路利益相關者、照常營業 (BAU) 團隊和最終使用者保持合作關係。專案團隊可協助使用者開始使用新系統、與 BAU 支援團隊一起進行問題疑難排解，並根據客戶和客服人員意見回饋改善聯絡流程。
