

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 绘制客户接触旅程图
<a name="map-journey"></a>

确定组织目标后，反向构建客户旅程图。此旅程图有助于确定典型的参与模式和解决客户查询所需的数据。它还有助于定义向客户提供的体验、对计划外事件和紧急情况的响应，以及部署所需的客户联系数量和规模。

此步骤对于规划三个 Framewor [AWS Well-Architected k](https://aws.amazon.com/architecture/well-architected/) 支柱至关重要：[卓越运营](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)、[安全](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html)性和[可靠性](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html)。

以下是创建客户接触旅程图时需要考虑的一些问题：
+ **客户联系的原因是什么？**

  此问题的答案有助于识别常见问题，例如余额查询、订单状态更新及密码重置。
+ **如何验证客户的身份？**

  安全是重中之重，验证客户的身份是接触旅程中的关键一步。身份验证选项包括语音生物识别、一次性密码及个人信息，例如信用卡号和出生日期。此信息还有助于确定合规性要求，例如健康保险流通与责任法案（HIPAA）、支付卡行业数据安全标准（PCI DSS）及系统和组织控制（SOC）。
+ **您已经掌握有关此客户的哪些信息？**

  确定客户后，相关的客户数据可以帮助他们实现个性化体验并主动解决问题。此数据可能包括客户姓名、未决案例、联系人历史记录和情绪及购买行为。
+ **解决客户的查询需要哪些信息？**

  确定解决客户查询所需的信息有助于定义应在 IVR 系统内收集的客户数据。例如，如果客户想要查看余额，则需要账号和安全 PIN，且 IVR 应用程序必须与包含银行数据的后端数据存储集成。检查订单状态需要订单编号。 
+ **是否需要任何集成才能满足客户的要求？**

  通常，IVR 上的自助服务请求需要后端集成才能成功完成。根据使用案例，这些集成可以与组织中的数据库、CRM 或工单系统集成。例如，传达订单状态可能需要从订单管理系统查询信息。购买可能需要与支付网关集成。尽早识别这些依赖关系至关重要，以便规划相关 API 的可用性。
+ **与客户的旅程或数据相关的合规要求有哪些？**

  定义合规目标并将其纳入 IVR 设计至关重要。合规性计划通常在组织级别执行。我们建议您让信息安全团队参与这些讨论和规划会议。

  例如，IVR 上的付款信息可能需要加密和 PCI DSS 合规性。从任何客户处收集的个人身份信息（PII）都需要加密。您的 IVR 系统可能涉及您必须保护的其他信息。
+ **如何应对高呼叫量或座席无法接听呼叫的情况？**

  必须找出高呼叫量可能导致更长等待时间的情况。在这些情况下，IVR 系统通常充当有效重定向客户联系人的网关。一些常见的转移策略包括：在等待时间异常漫长时提供回拨服务、设计增加目标座席数量的溢出方案、播放促销信息以及将客户重定向到其他渠道（SMS 或聊天）。有关这些策略的更多信息，请参阅博客文章《[如何处理与 Connect Customer 的意外联系高峰》](https://aws.amazon.com/blogs/contact-center/how-to-handle-unexpected-contact-spikes-with-amazon-connect/)。
+ **在节假日或紧急情况下，客户体验应该是怎样的？**

  不可预见的紧急情况和计划外事件可能会影响您的组织为客户提供服务的能力。在这些活动期间规划客户体验是提高可靠性的最佳实践。此外，假期可能会限制人员配置，IVR 系统可以成为让客户了解情况和设定期望的理想场所。

  例如，您可以在 IVR 系统中设计紧急占位符和节假日消息，进行更新，并在需要时播放相关更新。 
+ **当您遇到技术问题时，客户体验应该是怎样的？**

  当客户遵循 IVR 流程时，即使发生应用程序或后端集成错误，他们也应始终获得完整且有意义的体验。我们建议，您应设计集成故障情况下的呼叫方体验。通常，您可以实现重试和循环，或者播放一条消息来传达技术难题或将客户转接给座席。无论哪种情况，呼叫方的体验都不应导致通信突然且无法解释的结束，这通常会导致更多的呼叫。

在概述了客户接触旅程之后，寻找可重复的流程或常见模式。这些将是您在设计 IVR 架构基础时需要重点关注的方面。