本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。
选项 1:入口到 Avaya 然后使用呼叫转接导出到 Amazon Lex
-
客户呼叫本地 Avaya 联络中心。Avaya 使用欢迎菜单向呼叫方打招呼,并为呼叫方提供自助菜单选项。
-
Avaya 使用本地 API 向 Concentrix IVR 发送客户信息和唯一客户标识符(UCID)。
-
ConcentrixIVR 开始将呼叫转接给 Connect Customer 的过程,如下所示:
-
Concentrix IVR 向 Amazon API Gateway 发出 API 调用。这将启动一个 AWS Lambda 函数。
-
Lambda 函数查询 Amazon DynamoDB 数据库实例,并获取可用的拨号号码识别服务 (DNIS) 出站拨号号码,用于将呼叫转接给 Connect 客户。选择此号码后,Lambda 函数会在 DynamoDB 中屏蔽该号码,这样该号码就不能用于其他呼叫。
-
-
Avaya使用上一步中检索到的号码致电 Connect Customer,然后将 DNIS 号码和 UCID 传递给 Connect 客户。
-
当呼叫与 Connect Customer 连接时,Connect 客户联系流程会启动 Lambda 函数,该函数使用当前互动的 DNIS 编号从 DynamoDB 表中获取客户数据。
-
Connect 客户将客户属性传递给 Amazon Lex。Amazon Lex 开始自助处理呼叫。
-
Amazon Lex 调用对话框代码挂钩,并使用 Lambda 函数实现意图。
-
Lambda 函数在呼叫期间插入所有客户属性,并按如下方式启动返回 Avaya 的路由过程:
-
Connect 客户调用 Lambda 函数。
-
Lambda 函数选择 Avaya 可用的出站拨号号码,阻止 DNIS 号码,并将拨号号码传递回 Amazon Lex。
-
Amazon Lex 在会话属性中将该号码传回给 Connect 客户。
-
-
Connect 客户使用此号码回电Avaya。
-
Avaya 向 Amazon API Gateway 发出 API 调用。
-
Amazon API Gateway 启动一个 Lambda 函数,该函数获取与 DNIS 号码关联的客户属性,并释放该号码以备将来使用。
-
Avaya 将呼叫和客户属性路由给座席。
此架构的优点
此架构的优点
-
更好的客户体验
-
无需额外的硬件或许可
-
无需额外的电话线路,因为呼叫会转接给 Connect 客户
-
快速实施周转时间
此架构的缺点
-
数据无法通过公用交换电话网(PSTN)线路传输。这种架构依赖于本地和 AWS 联络中心系统之间的客户数据交换,而这无法通过 PSTN 线路完成。
-
在 Connect Customer 中处于活动状态的呼叫会话期间以及将呼叫转移到其他电话系统的过程中会产生额外费用。
-
要在 Connect Customer 中构建流程,还需要付出额外的努力。