一种基于智能设备的呼叫处理方法、装置及服务器与流程

本申请涉及通信技术领域，特别涉及一种基于智能设备的呼叫处理方法、装置及服务器。

背景技术：

随着通信技术的飞速发展，越来越多的用户使用智能设备。智能设备，是指像个人电脑一样，具有独立的操作系统和独立的运行空间，可以由用户自行安装软件、游戏或导航等第三方服务商提供的app应用程序，并可以通过移动通讯网络来实现无线网络接入的这样一类设备的总称。例如，智能手机，或者可通讯的平板电脑等。

在现有技术中，用户在下载并安装第三方服务器商提供的app之后，如果在使用app过程中出现问题，需要给第三方服务商联系的时候，经常会拨打客服电话进行咨询。但是在热线高峰期，往往由于拨打线路繁忙而导致用户需要排队等候电话的接通，更有甚者，可能会出现，大量用户根本无法拨通客服电话的情况。

发明人在研究过程中发现，现有技术存在以下问题：由于在热线高峰期，用户经常无法拨通客服电话，这就使得app的客服系统无法取得与用户的直接联系，也无法获取到用户使用app的相关操作信息；进一步的，海量用户拨打电话不通也会使得通信资源由于重复拨打而导致过多的浪费；再进一步的，用户使用app中出现的问题由于没有办法得到客服反馈而无法解决，给用户的使用带来很多不便。

技术实现要素：

本申请所要解决的技术问题是提供一种基于智能设备的呼叫处理方法，用以解决现有技术中app的客服系统无法获取到用户使用app的相关操作信息的问题，进一步的，由于过多用户的重复拨打或者拨打不通而导致通信资源过多的浪费问题，再进一步的，还能提升用户使用智能设备中安装的app的使用体验。

本申请还提供了一种基于智能设备的呼叫处理装置及设备，用以保证上述方法在实际中的实现及应用。

为了解决上述问题，本申请公开了一种基于智能设备的呼叫处理方法，包括：

响应于用户触发的呼叫当前应用程序app对应的客服电话的请求，监听所述app所集成的智能设备的通话状态；

判断所述通话状态是否表示当前呼叫所述客服电话失败，如果是，则依据所述用户操作所述当前app的行为日志确定当前呼叫涉及的app问题；

将所述app问题发送至所述app的服务器端。

可选的，所述判断所述通话状态是否表示当前呼叫所述客服电话失败，包括：

在通话状态发生了从空闲到繁忙再到空闲的变化的情况下，判断记录的用户与客服电话的通话时间是否为零。

可选的，所述监听所述app所集成的智能设备的通话状态，包括：

启动一个用于监听所述当前app所集成的智能设备的通话状态的、独立的监听线程。

可选的，所述将所述app问题发送至所述当前app的服务器端，包括：

从预置的数据库中获取与所述app问题对应的当前编码，所述数据库中保存有不同的app问题与编码的对应关系；

将所述对应的当前编码发送至当前app的服务器端。

可选的，所述依据所述用户操作所述当前app的行为日志确定当前呼叫涉及的app问题，包括：

通过分析所述当前app的行为日志确定当前用户行为异常；

确定当前用户行为异常对应的app问题。

可选的，还包括：

在有多个app问题的情况下，依据所述多个app问题对应的问题等级对所述多个app问题进行排序；

则相应的所述将所述app问题发送至所述app的服务器端，为：按照顺序依次将所述多个app问题发送至app的服务器端。

本申请公开了一种基于智能设备的呼叫处理装置，包括：

监听模块，用于响应于用户触发的呼叫当前应用程序app对应的客服电话的请求，监听所述app所集成的智能设备的通话状态；

判断模块，用于判断所述通话状态是否表示当前呼叫所述客服电话失败；

确定模块，用于在所述判断模块的结果为是的情况下，依据所述用户操作所述当前app的行为日志确定当前呼叫涉及的app问题；

发送模块，用于将所述app问题发送至所述app的服务器端。

可选的，所述判断模块包括：

确定子模块，用于确定通话状态发生了从空闲到繁忙再到空闲的变化；

判断子模块，用于判断记录的当前呼叫客服电话的通话时间是否为零。

可选的，所述监听模块，具体包括：

启动子模块，用于启动一个独立的监听线程；

监听线程，用于监听所述app所集成的智能设备的通话状态。

可选的，所述发送模块包括：

获取子模块，用于从预置的数据库中获取与所述当前app问题对应的当前编码，所述数据库中保存有app问题与编码的对应关系；

发送子模块，用于将所述对应的当前编码发送至app的服务器端。

可选的，所述确定模块包括：

确定异常子模块，用于通过分析所述当前app的行为日志确定当前用户行为异常；

确定问题子模块，用于确定当前用户行为异常对应的app问题。

可选的，还包括：

排序模块，用于在有多个app问题的情况下，依据所述多个app问题对应的问题等级对所述多个app问题进行排序；

则相应的所述发送模块，具体用于：按照顺序依次将所述多个app问题发送至app的服务器端。

本申请公开了一种基于智能设备的呼叫处理设备，包括：

前述的任一项呼叫处理装置。

与现有技术相比，本申请包括以下优点：

在本申请实施例中，通过监听智能设备的通话状态可以使app的客服系统在用户拨打不同客服电话的情况下，仍然能够获取到用户使用app的相关操作信息，进一步的，也可以避免由于过多用户的重复拨打或者拨打不通而导致通信资源过多的浪费问题，再进一步的，还能提升用户使用智能设备中安装的app的使用体验。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本说明书实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本说明书中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请的一种基于智能设备的呼叫处理方法实施例的流程图；

图2是本申请的一种基于智能设备的呼叫处理方法实施例的信令图；

图3为本申请的一种基于智能设备的呼叫处理装置实施例的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请可用于众多通用或专用的计算装置环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境等等。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

参考图1，示出了本申请一种基于智能设备的呼叫处理方法实施例的流程图，本实施例可以应用于云计算系统中的各台主机上，本实施例可以包括以下步骤：

步骤101：响应于用户触发的呼叫当前app对应的客服电话的请求，监听所述app所集成的智能设备的通话状态。

在本申请实施例中，用户在使用智能设备上安装的应用程序app的时候，可能会遇到一些问题，例如在使用手机软件付款时，密码多次校验错误，或者在玩游戏过程中，多次调用器材失败等，则用户可以通过触发当前app在手机上的显示界面中提供的客服电话的快捷链接，来拨打当前app的客服电话进行咨询。如果用户触发了客服电话的快捷链接，本申请实施例需要启动对该app集成的智能设备的通话状态(例如，接通，或者未接通)的监听。

具体的，在监听所述app所集成的智能设备的通话状态时，可以通过启动一个用于监听所述app所集成的智能设备的通话状态的独立的监听线程的方式实现。智能设备的操作系统一般都开放有电话监听状态类接口，那么在app中新建一个独立的监听线程调用该电话监听状态类接口，形成一个可读的新对象，然后该监听线程读取该对象的状态即可获得智能设备的通话状态。

步骤102：判断所述通话状态是否表示当前呼叫所述客服电话失败，如果是，则进入步骤103。

在监听通话状态的过程中，监听线程可以实时判断当前监听到的通话状态是否表示当前呼叫客服电话失败。具体在实现时，可以通过在通话状态发生了从空闲到繁忙再到空闲的变化的情况下，判断记录的当前呼叫客服电话的通话时间是否为零。例如，该线程监听到的通话状态从空闲(call_state_idle)变化到正拨打(call_state_offhook)，又变化到空闲，如果是的话，则读取上一次的通话时间记录，如果通话时间大于零说明接通了，而如果通话时间等于零则说明没有接通，即当前呼叫客服电话失败。

需要说明的是，在本步骤中，如果没有判断得到当前呼叫客服电话失败，则不执行后续流程。

步骤103：依据所述用户操作所述当前app的行为日志确定当前呼叫对应的app问题。

如果监听线程判断得到用户打不通客服电话，则会将该用户拨打不通客服电话通知给app，则app可以依据用户近一段时间内操作app的行为日志，来确定用户当前呼叫客服电话对应的app问题。app可以保存一段时间内用户的行为日志，具体可以根据app的实际应用场景需求来设置不同的时间段，例如支付宝钱包可以保存1～3天内的行为日志。

可以理解的是，app直接将用户行为日志存在本地即可实现本步骤。当然，app也可以将用户行为日志同步到服务器端，那么，服务器端也可以根据app同步的行为日志进行问题的定位。但是用户行为日志由于数据量较大，并且将用户行为日志同步到服务器端会耗费较多的流量和通信资源，因此，一般情况下由app依据本地存储的用户行为日志进行判断即可。

本步骤具体实现时，可以采用以下方式：先通过分析所述当前app的行为日志确定当前用户行为异常，再确定当前用户行为异常对应的app问题。例如，对于支付宝钱包app来讲，用户可能2天内在收银台页面上多次输入正确的支付密码都无法校验成功，那么就可以确定用户行为异常，并且该用户行为异常所对应的app问题是支付密码校验失败的问题。

在实际应用中，可以预先将用户可能出现的异常行为与该异常行为确定出的app问题，对应保存至一个特定的数据库中，等待后续执行步骤103的时候再去数据库中匹配即可。

步骤104：将所述app问题发送至所述app的服务器端。

将定位出的app问题由app应用系统与app的客户服务系统建立的连接通道(通常有https协议连接、tcp协议连接，本方案不限各种协议连接方式，以建立通信连接为准)发送至app的服务器端，例如，可以发送给app的客服系统(第三方企业为客服人员服务用户提供的客户服务工作台)，在服务器端保存有各种app问题所对应的答案，那么在其中就可以检索到当前app的问题对应的答案。后续客服人员可以在看到答案之后，再将该答案通过短信、电话或者邮件等其他方式主动告知用户。

具体的，app在将app问题发送至app的客服系统的时候，可以通过以下方式实现：

步骤a1：从预置的数据库中获取与所述当前app问题对应的当前编码，所述数据库中保存有app问题与编码的对应关系；

因为用汉字描述app问题的时候，可能会使得数据量因为汉字过多而较大，所以app可以预先为各种app问题设置编码，例如，p0表示安全类的支付密码错误的问题，p1表示查询类的信息查询失败的问题，等等。那么首先，app可以从保存有app问题与编码的对应关系的数据库中获取到与当前app问题对应的当前编码。

步骤a2：将所述对应的当前编码发送至app的服务器端。

再将当前编码发送至app的客服系统，因为该过程传输的是编码了，因此就比传输汉字更为节省流量。

可以理解的是，在不同的实施例中，在步骤104之前还可以包括：

步骤100：在有多个app问题的情况下，依据所述多个app问题对应的问题等级对所述多个app问题进行排序。

如果最终确定出的当前app问题有多个，例如用户支付密码的输入有误，并且查询界面显示不正常，那么可以按照预先为app问题划分的问题等级来对这多个app问题进行排序。例如，安全类问题定义为最高级，包括支付密码的相关问题等，而查询类问题则可以定义为最低级，例如，查询界面显示不正常等。那么，如果当前多个app问题有安全类问题也有查询类问题，则相应的将安全类问题排在查询类问题之前进行发送。

相应的步骤104就需要按照步骤100的排序顺序依次将所述多个app问题发送至app的客服系统。

按照顺序发送app问题可以保证重要的问题可以优先发送给客服系统，这样就可以在节省传输资源及流量的前提下，为用户优先提供更重要的问题答案，从而使用户获得更好地使用体验。

参考图2所示，为本申请方法实施例在实际应用中的一个具体实例的信令图。其中的各个步骤在图1中均有对应的描述，在此不再赘述。

可见，在本申请实施例中，通过监听智能设备的通话状态可以使app的客服系统在用户拨打不同客服电话的情况下，仍然能够获取到用户使用app的相关操作信息，进一步的，也可以避免由于过多用户的重复拨打或者拨打不通而导致通信资源过多的浪费问题，再进一步的，还能提升用户使用智能设备中安装的app的使用体验。

对于前述的方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

与上述本申请一种基于智能设备的呼叫处理方法实施例所提供的方法相对应，参见图3，本申请还提供了一种基于智能设备的呼叫处理装置实施例，在本实施例中，该装置可以包括：

监听模块301，用于响应于用户触发的呼叫当前应用程序app对应的客服电话的请求，监听所述app所集成的智能设备的通话状态。

其中，在不同的实施例中，所述监听模块301，具体可以包括：

启动子模块，用于启动一个独立的监听线程；和，监听线程，用于监听所述app所集成的智能设备的通话状态。

判断模块302，用于判断所述通话状态是否表示当前呼叫所述客服电话失败。

其中，在不同的实施例中，所述判断模块302具体可以包括：

确定子模块，用于确定通话状态发生了从空闲到繁忙再到空闲的变化；和，判断子模块，用于判断记录的当前呼叫客服电话的通话时间是否为零。

确定模块303，用于在所述判断模块的结果为是的情况下，依据所述用户操作所述当前app的行为日志确定当前呼叫涉及的app问题。

其中，所述确定模块在不同的实施例中，具体可以包括：

确定异常子模块，用于通过分析所述当前app的行为日志确定当前用户行为异常；和，确定问题子模块，用于确定当前用户行为异常对应的app问题。

发送模块304，用于将所述app问题发送至所述app的服务器端。

其中，在不同的实施例中，所述发送模块304具体可以包括：

获取子模块，用于从预置的数据库中获取与所述当前app问题对应的当前编码，所述数据库中保存有app问题与编码的对应关系；和，发送子模块，用于将所述对应的当前编码发送至app的服务器端。

其中，在不同的实施例中，所述装置还可以包括：

排序模块，用于在有多个app问题的情况下，依据所述多个app问题对应的问题等级对所述多个app问题进行排序；则相应的所述发送模块304，具体可以用于：按照顺序依次将所述多个app问题发送至app的服务器端。

本申请还提供了一种基于智能设备的呼叫处理设备，该设备可以例如是智能设备，该设备的cpu上集成前述的基于智能设备的呼叫处理装置。

需要说明的是，本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。对于装置类实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

以上对本申请所提供的基于智能设备的呼叫处理方法、装置及服务器进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。