干货 | 高效联动，携程机票IVR可视化的探索和实践

作者简介

Michael，携程全栈开发专家，追求以技术手段解决业务上的共性问题，构建灵活可配置且可视化的系统，提高生产力，降低沟通成本。

CunShun，携程后端开发工程师，专注系统架构、稳定性、低代码等领域。

一、引言

IVR（交互式语音应答，Interactive Voice Response）系统，是指用户通过拨打指定号码后可以根据语音提示，收听和点送所需语音信息，并且协助完成自助服务。通过不断完善IVR交互逻辑，可以实现客户来电自助操作，减轻客服座席压力，使之仅处理确实需要人工处理的呼叫。

本文将主要分享携程机票IVR可视化系统的探索与实践。

二、携程机票IVR系统的演进过程

携程呼叫中心系统结构如下图所示，客人进线后由公共网关处理后转到相应部门的IVR流程中，然后由各自部门完成IVR内部处理逻辑。

2.1 携程机票IVR系统V1.0

最开始的机票IVR系统，主要面向国内市场的用户，语种只有中文并且业务流程只有一套。系统采用的是“InTag-OutTag”+“策略模式”的设计方案，和公共平台约定客户来电后第一次请求IVR时传入固定InTag，然后后续都使用客户按键对应的OutTag作为下一次请求机票IVR自助服务的InTag，然后机票IVR采用策略模式根据InTag处理对应的业务场景。

公共平台无需关心机票内部处理逻辑以及Tag的含义，机票方如果有业务变更也只需要新增InTag或OutTag场景即可。并且代码采用策略模式，所以新增业务逻辑对原有系统代码侵入很少。虽然业务场景是树状发散的，但是实际上从代码设计的角度其实是将业务场景完全平铺的。

2.2 携程机票IVR系统V2.0

后来随着业务扩张，在全球化战略的背景下，也要面向国际市场的用户，机票IVR系统也从原本单一的国内中文流程，扩展到20多条语言线。使得如果沿用原有IVR系统架构会存在以下痛点：

开关配置个数爆炸

由于各条语言线功能点上线速度不同、逻辑不一致等问题，采用硬编码开发过程中会产生大量开关配置。并且随着业务发展，上述问题愈发严重，业务逻辑也是愈发难以梳理。

无直观的处理流程

语言线众多，需求变更频繁且各条语言线逻辑不一致，业务文档往往无法及时更新，产品、流程等人员会经常找开发人员确认业务逻辑，开发人员需要花费大量时间翻代码查逻辑。

话术配置效率低下

没有直观的配置页面供业务人员使用，只能通过邮件沟通等方式来确认话术配置，然后由开发人员手动配置所有语言线的话术。在多语言背景下，沟通成本极大并且容易配置错误。

针对原有系统中存在的痛点，产研团队沟通后提出了IVR可视化、可配置化的设想，为此设计并开发IVR可视化平台。该系统完全颠覆原有的IVR系统架构，引入可视化流程树、规则引擎、脚本引擎、话术模板动态配置、多版本管理等全新概念，业务和产品可随时查看业务流程，通过配置调整快速需求上线，通过严格的权限控制、版本管理确保系统稳定性，通过可视化来电轨迹协助快速排查问题。该系统使产品、业务、开发、测试及TS人员高效联动，减少不必要的沟通成本，提高工作效率。

2.3 系统对比

	机票IVR系统V1.0	机票IVR系统V2.0
语种	只有中文	20多条语言线
流程是否可视化	无可视化流程，只有流程图	完全可视化的业务流程
轨迹是否可视化	可视化页面，需要通过DB数据反推执行流程。需要对业务逻辑以及字段含义有较深理解才能看懂	有可视化页面，并记录经过节点以及中间数据&#