View a markdown version of this page

映射客戶聯絡旅程 - AWS 方案指引

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

映射客戶聯絡旅程

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

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

以下是您在建立客戶聯絡旅程地圖時應考慮的一些問題:

  • 客戶聯絡的原因是什麼?

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

  • 如何驗證客戶的身分?

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

  • 您對此客戶已有哪些資訊?

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

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

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

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

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

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

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

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

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

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

  • 在假日或緊急情況下,客戶體驗應該如何?

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

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

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

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

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