映射客戶聯絡旅程

定義組織的目標後，請返回建置客戶旅程圖。此映射有助於識別典型的參與模式和解決客戶查詢所需的資料。它還有助於定義向客戶呈現的體驗、對意外事件和緊急事件的回應，以及部署所需的客戶聯絡的數量和規模。

此步驟對於規劃三個 AWS Well-Architected Framework 支柱至關重要：卓越營運、安全性和可靠性。

以下是您在建立客戶聯絡旅程圖時需要考慮的一些問題：

• 客戶聯絡的原因為何？

  此問題的答案有助於識別常見問題，例如餘額查詢、訂單狀態更新和密碼重設。

• 如何驗證客戶的身分？

  安全是首要任務，而驗證客戶身分是聯絡旅程中的關鍵步驟。驗證選項包括語音生物識別、一次性密碼和個人資訊，例如信用卡號碼和出生日期。此資訊也有助於識別合規要求，例如健康保險流通與責任法案 (HIPAA)、支付卡產業資料安全標準 (PCI DSS) 以及系統和組織控制 (SOC)。

• 您已經擁有此客戶的相關資訊？

  識別客戶之後，相關的客戶資料有助於個人化他們的體驗，並主動解決問題。此資料可能包括客戶名稱、開啟案例、聯絡歷史記錄和情緒，以及購買行為。

• 解決客戶的查詢需要哪些資訊？

  判斷解決客戶查詢所需的資訊，有助於定義應該在 IVR 系統內收集的客戶資料。例如，如果客戶想要檢查其餘額，則需要其帳戶號碼和安全 PIN，且 IVR 應用程式必須與包含銀行資料的後端資料存放區整合。檢查其訂單的狀態需要訂單編號。 

• 是否需要任何整合才能滿足客戶的請求？

  一般而言，IVR 上的自助服務請求需要後端整合，才能成功履行。視使用案例而定，這些整合可與組織中的資料庫、CRMs 或票證系統整合。例如，傳達訂單狀態可能需要從訂單管理系統查詢資訊。購買可能需要與付款閘道整合。儘早識別這些相依性至關重要，因此您可以規劃相關 APIs的可用性。

• 與客戶旅程或資料相關的合規要求是什麼？

  定義合規目標並將其納入 IVR 設計至關重要。合規計劃通常在組織層級強制執行。我們建議您讓資訊安全團隊參與這些討論和規劃工作階段。

  例如，IVR 上的付款資訊可能需要加密和 PCI DSS 合規。從任何客戶收集的個人識別資訊 (PII) 都需要加密。您的 IVR 系統可能涉及您必須保護的其他資訊。

• 如何回應高通話量或客服人員無法使用？

  識別高通話量可能導致更長等待時間的情況至關重要。在這些情況下，IVR 系統通常可做為有效重新導向客戶聯絡人的閘道。一些常見的偏轉策略包括在非常長的等待時間內提供回呼、設計溢位案例來擴展目標客服人員的集區、播放促銷訊息，以及將客戶重新導向至另一個管道 （簡訊或聊天）。如需這些策略的詳細資訊，請參閱部落格文章如何使用 Amazon Connect 處理非預期的聯絡峰值。

• 在假日或緊急情況下，客戶體驗應該是什麼？

  不可預見的緊急事件和意外事件可能會影響您的組織服務客戶的能力。在這些事件期間規劃客戶體驗是可靠性的最佳實務。此外，假日可能會限制人員配置，而 IVR 系統可以是讓客戶隨時掌握最新動態並設定期望的理想位置。

  例如，您可以在 IVR 系統中設計緊急預留位置和假日訊息、更新它們，並在需要時播放相關更新。 

• 當您遇到技術問題時，客戶體驗應該是什麼？

  當客戶遵循 IVR 流程時，即使應用程式或後端整合錯誤發生，客戶體驗仍應始終完整且有意義的。我們建議您在整合失敗時設計來電者體驗。一般而言，您可以實作重試和迴圈，或播放訊息來傳達技術問題，或將客戶轉接給客服人員。在任何一種情況下，來電者體驗都不應導致通訊突然且原因不明的結束，這通常會導致更多的呼叫。

概述客戶聯絡旅程之後，請尋找可重複的程序或常見模式。當您設計 IVR 架構的基礎時，這些將是重點重點。