本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
使用案例示例
现在,让我们来看一个用例,说明如何应用这些原则并推导出模块化基础架构。Example Corp 是一家虚构的全球公司,是我们例子的焦点。
Example Corp 希望迁移到基于云的联络中心,以减少数据中心维护,专注于创新并削减成本。他们的关键优先事项是自助服务,目的是在迁移过程中增强客户体验。Example Corp 是一家全球性组织,根据国家(美国、加拿大、意大利、荷兰等 TFNsDIDs)和业务领域(销售、支持、新产品等)管理多个免费电话号码 () 和直接拨入号码 ()。这意味着他们需要支持多种语言(例如美国英语、加拿大法语和意大利语)。Example Corp 还希望根据拨打的号码或始发国家/地区为来电者提供个性化、定制的体验,这可能会导致在 IVR 系统中更改菜单选项或提供不同的提示消息。此外,每个国家/地区都有一套专门的技能(基于语言、业务领域等),必须将这些技能分配给客服人员进行呼叫路由。该公司总共支持 25 个国家/地区和 12 种语言。他们还计划提供付款处理以及无需与代理商交谈即可购买产品和附加组件的功能。作为最佳实践,Example Corp 将维护其联络中心的开发、暂存和生产环境。
本节演示了如何将我们在本指南前面讨论的 IVR 设计原则应用于 Example Corp 用例。我们通过使用 AWS 服务来完成确定组织目标、建立客户联系旅程以及创建架构框架以满足公司要求的过程。
确定组织的目标
对于 Example Corp 来说,主要的组织目标包括以下内容:
-
节省成本:迁移到基于云的联络中心,以降低维护成本并增强创新。
-
个性化自助服务:根据客户的原始号码或国家(包括语言选项)为其提供个性化的定制体验。
-
提高IVR控制率:简化IVR系统内的付款处理,使客户无需代理干预即可购买产品和附加组件。
-
改进的变更管理/创新中心:为 IVR 系统维护单独的环境(开发、暂存和生产),以实现有效的变更管理和实验。
-
改善首次通话解决方案:根据语言、国家和客户意图实施有效的路由策略。
绘制客户联系旅程
要为 Example Corp 创建客户联系之旅,我们需要考虑以下方面:
-
来@@ 电发起:确定与来电相关的国家/地区和业务线,以提供量身定制的体验。
-
语言选择:根据来电者的来源国家、个人资料以及 Example Corp. 支持的语言提供适当的语言菜单
-
客户身份验证:使用来电者的账户信息、语音生物识别或其他安全方法对来电者进行身份验证。
-
个性化:收集和使用客户数据来个性化 IVR 体验,例如用姓名向来电者打招呼,或者根据他们的账户历史记录提供自定义菜单选项。
-
自助服务选项:提供自助服务选项以解决常见的客户查询,例如余额查询、订单状态更新或密码重置。
-
付款处理:集成安全的支付网关,以便客户可以在IVR系统内进行购物。
-
后端集成:考虑使用后端 API 集成来实现自助服务流程,例如个性化问候、订单更新和付款。检查这些的可用性和准备情况 APIs。
-
安全性与合规性:确定需要进一步加密、屏蔽或禁用日志的信息(例如,信用卡信息和客户 PII)。
-
可重复的流程:确定将在大多数国家和业务领域重复的支付和来电者身份验证等流程。
创建基础架构
要为 Example Corp IVR 系统创建模块化和动态架构框架,请考虑删除静态内容并模块化可重复的流程。
消除静态内容
-
考虑使用变量根据分配给每个国家的免费电话号码 (TFNs) 动态调用提示。例如,如果 TFN1 属于加拿大,则可以从外部数据库调用相应的提示为客户提供英语和加拿大法语作为语言选项。根据客户的选择,您可以从外部数据库调用英语(或加拿大法语)提示,并在整个 IVR 呼叫流程中播放这些提示。这种方法使用单个 IVR 流程,消除了所有流程的冗余。 TFNs
-
考虑将呼叫者需要路由到的代理队列和技能、呼叫需要遍历的下一个 IVR 树以及 API 终端节点的值(例如和 URLs Amazon 资源名称 (ARNs))存储在外部数据库中。您也可以根据分配给某个国家/地区或业务领域的 TFN 来调用它们。
-
为了进一步简化体验,您还可以将部署环境的详细信息存储在外部数据库中。例如,如果 TFN2 映射到开发环境,则可以调用仅与该环境相关的相关语言提示、API 端点、代理队列和技能。如果 TFN3 映射到暂存环境,则可以调用分配给暂存环境的呼叫详细信息,依此类推。这种方法大大简化了呼叫流程的维护和开发。开发人员可以维护单个呼叫流程,他们可以根据分配给国家/地区的TFN、业务线或环境等关键参数轻松更改体验。
确定可重复的流程
以Example Corp为例,在不同国家和业务领域中确定的一些可重复流程是来电者语言选择和付款处理。您可以将这些流程构建为模块,这样它们便于在所有呼叫流中集中管理、维护和调用。
下图显示了基于本指南中讨论的 IVR 设计方法的示例架构。此架构使用 Amazon Connect 流程和模块以及以下附加 AWS 服务:
-
Amazon DynamoDB 表 ARNs存储、动态属性和提示。
-
AWS Lambda 函数从 DynamoDB 表中检索信息。
-
Amazon Polly 将文本提示转换为语音。
-
亚马逊简单存储服务 (Amazon S3) Service 存储 A mazon Connect 的联系记录。

IVR 系统执行以下步骤:
-
客户致电公司特定国家/地区的 DID 或 TFN。
-
该呼叫进入了 Amazon Connect 初始化流程 (
initFlow
)。 -
初始化流程调用三个 Lambda 函数,这些函数从三个 DynamoDB 表中检索数据:
-
第一个函数 ARNs根据调用的环境(例如生产、暂存或开发)检索 Amazon Connec t 实例。
-
第二个函数根据拨打的号码检索动态属性,例如国家、语言和支持队列。
-
第三个功能根据客户的语言选择获取 IVR 提示消息。
-
-
Amazon Connect 语言模块 (
langModule
) 根据所选语言设置 Amazon Polly 语音。 -
然后,呼叫将遍历到下一个联系流 (
mainFlow
),该联络流会播放动态提示,例如欢迎消息或呼叫中心选项,这些提示是从第三个 DynamoDB 表中检索的。 -
Lambda 函数调用 DynamoDB API 来调用子联系人流程、模块和队列。
-
根据客户在 IVR 系统中的选择,呼叫可能会被转接到支持中心代理。座席的屏幕上会动态填充所捕获的数据,例如客户的国家/地区、身份和来电原因。
-
客户联系数据也作为 Amazon Connect 联系人记录的一部分存储在 S3 存储桶中,并可使用生成自定义报告 QuickSight。
有关如何在现实场景中使用这种设计的信息,请参阅 re: Invent 2020 演示文稿贝斯特韦斯特如何使用 Amazon Connect 构建模块化和动态的联络中心