[发明专利]呼叫交互方法、系统、计算机设备和存储介质

说明书

本公开涉及通信技术领域，提供一种呼叫交互方法、系统、计算机设备和存储介质。其中呼叫交互方法包括：接收一呼叫请求，提取所述呼叫请求携带的呼叫标识；从本地数据库获取与所述呼叫标识关联的用户信息，所述用户信息包括对应多个业务系统的多组用户历史数据；根据各组所述用户历史数据，基于单页面应用模式加载对应的业务系统的页面片段，并根据各所述页面片段和所述呼叫请求的实时呼叫数据，生成呼叫交互页面，以响应所述呼叫请求；以及根据所述呼叫标识将所述实时呼叫数据与所述用户信息对应存储至所述本地数据库。本公开能实现呼叫数据与业务信息的交互整合，在呼叫交互页面加载呼叫数据和业务信息，便于查看和操作，提高呼叫处理效率。

技术领域

本公开涉及通信技术领域，具体地说，涉及一种呼叫交互方法、系统、计算机设备和存储介质。

背景技术

客服接待系统用于电话接入和呼出。从系统架构层面，目前的客服接待系统采用iframe框架或spa模式进行系统架构的搭建。从交互模式来看，目前的客服接待系统的电话接入呼出通过tab切换实现。

目前的客服接待系统在系统架构、信息整合和交互模式上都存在一些不足。具体来说，系统架构上，iframe框架下各个业务系统完全独立，发布独立，可以避免因一个错误而引发全站崩溃的情况；但正由于绝对独立，系统架构存在资源严重浪费的现象，比如重复的ui，重复的代码，且由于是嵌入页面，路由切换产生的是页面的直接loading，导致用户体验感差。Spa模式下各个业务线之间可以复用ui，保持页面的ui统一，节省开发成本，用户体验上在路由切换时消除了loading的感觉，使加载速度得到了提升；但在大平台下，业务线之间无法拆分，全量发布时的一个小问题就会导致全站崩溃，风险较大。从信息整合和交互模式来看，目前的客服接待系统的外呼系统是独立的一套系统，并没有与其他业务系统产生关联，操作记录要另外进行录入，导致效率低下，同时tab的交互模式可提供的显示信息很少，无法直观地展示用户信息，操作上极度不便利。

需要说明的是，在上述背景技术部分申请的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

有鉴于此，本公开提供一种呼叫交互方法、系统、计算机设备和存储介质，实现呼叫数据与业务信息的交互整合，在呼叫交互页面加载呼叫数据和业务信息，以便于查看和操作，提高呼叫处理效率。

本公开的第一方面提供一种呼叫交互方法，所述呼叫交互方法包括：接收一呼叫请求，提取所述呼叫请求携带的呼叫标识；从本地数据库获取与所述呼叫标识关联的用户信息，所述用户信息包括对应多个业务系统的多组用户历史数据；根据各组所述用户历史数据，基于单页面应用模式加载对应的业务系统的页面片段，并根据各所述页面片段和所述呼叫请求的实时呼叫数据，生成呼叫交互页面，以响应所述呼叫请求；以及根据所述呼叫标识将所述实时呼叫数据与所述用户信息对应存储至所述本地数据库。

在一个实施例中，每个所述业务系统对应一由单页面应用模式构建的业务系统页面，每个所述业务系统页面包括多个页面片段，各所述业务系统对应的页面片段由公共组件加载。

在一个实施例中，每个所述业务系统页面具有一根路由和链接至其各页面片段的子路由，一所述业务系统页面的根路由与该所述业务系统页面对应的业务系统的名称相对应。

在一个实施例中，所述公共组件加载页面片段的步骤包括：根据所述用户历史数据对应的业务系统，获得所述业务系统对应的根路由；以及根据所述根路由链接至对应的业务系统页面，并通过所述业务系统页面的子路由跳转加载对应的页面片段。

在一个实施例中，所述公共组件封装为独立于各所述业务系统页面的公共组件模块，且每个所述业务系统页面封装为独立的业务系统模块。

在一个实施例中，所述生成呼叫交互页面的步骤中，各所述页面片段及所述实时呼叫数据分栏显示于所述呼叫交互页面中。