CN114726956B - 一种电话呼入处理方法及装置 - Google Patents

Abstract

本发明涉及网络技术领域，具体涉及一种电话呼入处理方法及装置，所述方法包括：根据第一用户的电话呼入请求获取所述第一用户的呼入号码；根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务；向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息。该方法及装置能够降低人工客服繁忙的程度，提高外呼服务的效率，增加用户满意度，解决了相关技术中外呼服务效率低、用户满意度下降的问题。

Description

一种电话呼入处理方法及装置

技术领域

本发明涉及网络技术领域，尤其涉及一种电话呼入处理方法及装置。

背景技术

当前，用户拨打外呼电话的服务模式，自助部分按照运营商内部业务分类进行，绝大部分并非难以解答的服务需求，由于没有提供相应的服务，都需要转到人工客服实现，这就容易导致人工客服异常繁忙，降低了外呼服务效率的同时，也因等待等问题，导致用户满意度下降。

发明内容

本发明所要解决的技术问题是针对现有技术的上述不足，提供一种电话呼入处理方法及装置，以至少解决相关技术中外呼服务效率低、用户满意度下降的问题。

第一方面，本发明提供一种电话呼入处理方法，包括：

根据第一用户的电话呼入请求获取所述第一用户的呼入号码；

根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务；

向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息。

优选地，所述根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务，包括：

在预设的缓存数据库中查找与所述呼入号码关联的所有用户的预设状态的业务；

其中，所述预设状态的业务包括以下至少之一：未完成有投诉状态的业务、已完成有投诉状态的业务、未完成无投诉状态的业务。

优选地，所述与所述呼入号码关联的所有用户包括所述第一用户以及与所述第一用户具有套餐关联关系和亲属关联关系的用户，所述在预设的缓存数据库中查找与所述呼入号码关联的所有用户的预设状态的业务之前，所述方法还包括：

根据第一用户的相关信息获取与所述第一用户具有套餐关联关系和亲属关联关系的用户，并建立关系图谱；

根据所述关系图谱建立用户组；

获取所述用户组内所有用户预设时间段内的所有业务；

基于所述用户组内所有用户预设时间段内的所有业务建立业务元组；

将所述业务元组中所有所述预设状态的业务缓存至预设的所述缓存数据库中。

优选地，所述根据第一用户的相关信息获取与所述第一用户具有套餐关联关系和亲属关联关系的用户，并建立关系图谱，具体包括：

采集所述第一用户的相关信息，其中，所述第一用户的相关信息包括第一身份信息、与所述第一身份信息对应的一个或多个第一电话号码、以及与每个所述第一电话号码对应的套餐信息和通信信息；

以所述第一身份信息为核心关联所述一个或多个电话号码；

针对每个所述第一电话号码，根据所述第一电话号码的套餐信息获取与所述第一电话号码具有套餐关联关系的第二电话号码，并进行关联；以及根据所述第一电话号码的通信信息获取与所述第一电话号码具有亲属关联关系的第三电话号码，并进行连接；

针对每个所述第二电话号码，获取对应的第二用户的第二身份信息，并进行关联；以及，

针对每个所述第三电话号码，获取对应的第三用户的第三身份信息，并进行关联，得到所述关系图谱。

优选地，若接收到所述第一用户的人工服务请求，所述方法还包括：

根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务；

若是，则向所述第一用户发送或播报延期服务询问信息，所述延期服务询问信息用于询问用户是否需要提供延期服务；

若接收到所述第一用户用于指示需要提供延期服务的指示信息，则将所述第一用户加入所述当前延期服务队列。

优选地，所述根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务，包括：

判断所述用户等级是否为预设等级；

若是，则进一步判断所述当前延期服务队列中的延期等待人数是否小于等于预设阀值；

若是，则判断需要向所述第一用户提供延期服务。

优选地，所述向所述第一用户发送或播报延期服务询问信息之前，所述方法还包括：

将当前人工服务数据输入预先训练好的时序模型，得到人均服务时间预测值；

基于所述人均服务时间预测值以及当前延期服务队列中的延期等待人数计算所述第一用户的等待时间预测值；

基于所述等待时间预测值向所述第一用户发送或播报提示信息，所述提示信息用于提示所述第一用户等待时间为所述等待时间预测值。

优选地，当前人工服务数据包括当前时间段、当前客服人数、当前服务人数排名在前N位的客服标识、当前服务人数排名在后N位的客服标识、当前服务用户总数、当前最长服务时间以及当前最短服务时间，其中，N大于等于1。

第二方面，本发明提供一种电话呼入处理装置，包括：

号码获取模块，用于根据第一用户的电话呼入请求获取所述第一用户的呼入号码；

业务获取模块，与所述号码获取模块连接，用于根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务；

业务进度反馈模块，与所述业务获取模块连接，用于向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息。

第三方面，本发明提供一种电话呼入处理装置，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以实现上述第一方面所述的电话呼入处理方法。

本发明提供的电话呼入处理方法及装置，考虑到第一用户拨打外呼电话时很可能会咨询与呼入号码关联的自身或其他用户预设状态的业务，本发明首先根据第一用户的电话呼入请求获取所述第一用户的呼入号码，然后根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务，最后向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息，从而能够降低人工客服繁忙的程度，提高外呼服务的效率，增加用户满意度，解决了相关技术中外呼服务效率低、用户满意度下降的问题。

附图说明

图1为本发明实施例1的一种电话呼入处理方法的流程图；

图2为本发明实施例1的关系图谱的结构示意图；

图3为本发明实施例2的一种电话呼入处理装置的结构示意图；

图4为本发明实施例3的一种电话呼入处理装置的结构示意图。

具体实施方式

为使本领域技术人员更好地理解本发明的技术方案，下面将结合附图对本发明实施方式作进一步地详细描述。

可以理解的是，此处描述的具体实施例和附图仅仅用于解释本发明，而非对本发明的限定。

可以理解的是，在不冲突的情况下，本发明中的各实施例及实施例中的各特征可相互组合。

可以理解的是，为便于描述，本发明的附图中仅示出了与本发明相关的部分，而与本发明无关的部分未在附图中示出。

可以理解的是，本发明的实施例中所涉及的每个单元、模块可仅对应一个实体结构，也可由多个实体结构组成，或者，多个单元、模块也可集成为一个实体结构。

可以理解的是，在不冲突的情况下，本发明的流程图和框图中所标注的功能、步骤可按照不同于附图中所标注的顺序发生。

可以理解的是，本发明的流程图和框图中，示出了按照本发明各实施例的***、装置、设备、方法的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可代表一个单元、模块、程序段、代码，其包含用于实现规定的功能的可执行指令。而且，框图和流程图中的每个方框或方框的组合，可用实现规定的功能的基于硬件的***实现，也可用硬件与计算机指令的组合来实现。

可以理解的是，本发明实施例中所涉及的单元、模块可通过软件的方式实现，也可通过硬件的方式来实现，例如单元、模块可位于处理器中。

实施例1：

本实施例提供一种电话呼入处理方法，如图1所示，该方法包括：

步骤S101：根据第一用户的电话呼入请求获取所述第一用户的呼入号码。

步骤S102：根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务。

需要说明的是，在现有相关技术中，当第一用户拨打外呼电话，比如100XX，运营商通常按自助部分的语音菜单进行提示，比如“欢迎拨打xx服务热线，话费查询请按1，……”等等。通常，自助部分的语音菜单无法解决用户的服务需求，都需要转到人工客服实现，这就导致人工客服异常繁忙，大大降低了外呼服务的效率。本发明考虑到第一用户拨打外呼电话时很可能会咨询与呼入号码关联的自身或其他用户预设状态的业务，首先根据第一用户的电话呼入请求获取所述第一用户的呼入号码，然后根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务，比如，预设状态的业务可以包括以下至少之一：未完成有投诉状态的业务、已完成有投诉状态的业务、未完成无投诉状态的业务、已完成无投诉状态的业务，在实际应用中，具体业务的划分可以根据需要进行设定，考虑到用户通常会咨询未完成和有投诉状态的业务，本发明预设状态的业务优选包括：未完成有投诉状态的业务、已完成有投诉状态的业务和未完成无投诉状态的业务。

可选地，所述根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务，可以包括：

在预设的缓存数据库中查找与所述呼入号码关联的所有用户的预设状态的业务；

在本实施例中，为了保证业务的快速查询，可以将与所述呼入号码关联的所有用户的预设状态的业务预先存储在预设的缓存数据库中，以便能够在缓存数据库中快速查找到与所述呼入号码关联的所有用户的预设状态的业务。

可选地，所述与所述呼入号码关联的所有用户包括所述第一用户以及与所述第一用户具有套餐关联关系和亲属关联关系的用户，所述在预设的缓存数据库中查找与所述呼入号码关联的所有用户的预设状态的业务之前，所述方法还包括：

根据第一用户的相关信息获取与所述第一用户具有套餐关联关系和亲属关联关系的用户，并建立关系图谱；

根据所述关系图谱建立用户组；

获取所述用户组内所有用户预设时间段内的所有业务；

基于所述用户组内所有用户预设时间段内的所有业务建立业务元组；

将所述业务元组中所有所述预设状态的业务缓存至预设的所述缓存数据库中。

在本实施例中，考虑到第一用户拨打外呼电话时，通常会咨询自身号码对应的业务，或是帮助亲属咨询亲属号码对应的业务，比如为父母咨询相关业务，因此，与所述呼入号码关联的所有用户包括所述第一用户以及与所述第一用户具有套餐关联关系和亲属关联关系的用户。

可选地，所述根据第一用户的相关信息获取与所述第一用户具有套餐关联关系和亲属关联关系的用户，并建立关系图谱，具体包括：

采集所述第一用户的相关信息，其中，所述第一用户的相关信息包括第一身份信息、与所述第一身份信息对应的一个或多个第一电话号码、以及与每个所述第一电话号码对应的套餐信息和通信信息；

以所述第一身份信息为核心关联所述一个或多个电话号码；

针对每个所述第一电话号码，根据所述第一电话号码的套餐信息获取与所述第一电话号码具有套餐关联关系的第二电话号码，并进行关联；以及根据所述第一电话号码的通信信息获取与所述第一电话号码具有亲属关联关系的第三电话号码，并进行连接；

针对每个所述第二电话号码，获取对应的第二用户的第二身份信息，并进行关联；以及，

针对每个所述第三电话号码，获取对应的第三用户的第三身份信息，并进行关联，得到所述关系图谱。

在本实施例中，可以事先通过数据采集模块从生产***(比如BSS业务支撑***)中采集所有用户的相关信息，其中包括第一用户的相关信息，以第一用户是小明为例，采集小明的第一身份信息，比如身份证号、与所述第一身份信息对应的一个或多个第一电话号码，比如，小明有5个电话号码，则采集该5个电话号码以及与每个电话号码对应的套餐信息和通信信息(包括话单信息、网络浏览行为等等)。

在一个具体的实施例中，以第一用户是小明为例，如图2所示，该关系图谱建立的步骤可以包括：

(1)以小明的第一身份信息为核心(具体可以是小明的身份证号)，关联其名下所有电话号码(也即账户)，比如关联电话号码1至5；

(2)根据每个账户的套餐信息，比如套餐内为号码组，关联号码组内所有电话号码，并根据关联的电话号码，关联该电话号码所属的自然人的身份信息。假设小明的电话号码1的套餐里，是融合套餐，小明的电话号码1与小红的电话号码6共用一个套餐，即具有套餐关联关系，则将电话号码1与电话号码6进行关联，并将电话号码6与小红的身份信息进行关联；

(3)根据每个账户的通信信息建立家庭所属关联。具体地，如果双方通信设备在预设时间内所属的基站相同且每周的通信频率达到预设阀值，则可以判断双方具有亲属关联关系。比如，双方手机在工作日的工作时间内，所属基站不同，但是夜间所属基站相同，且语音通信频率保持每周至少1次，则可以定义为亲属关系，每个人的亲属关系(号码)可以设置至多5个。假设小明与小会的手机近三个月内在夜间所属基站相同，且每周的通信频率达到2次以上，则可以将小明对应的电话号码3与小会对应的电话号码7进行关联，并将电话号码7与小会的身份信息进行关联，从而得到关系图谱。

在本实施例中，得到关系图谱后，可以根据所述关系图谱建立用户组，其中，具有套餐关联关系和亲属关联关系的用户视为同一用户组，以图2为例，小明、小红和小会即为同一用户组用户。

在本实施例中，为了便于获取与呼入号码关联的所有用户的预设状态的业务，考虑到属于同一用户组内的一个用户可能会替组内的另外一个用户办理业务或者投诉，在获取用户组内所有用户预设时间段内的所有业务后，可以基于所述用户组内所有用户预设时间段内的所有业务建立业务元组，以便通过业务元组来记录这个关系。具体地，可以首先通过数据采集模块采集获取该用户组内所有用户近一段时间内在预设APP或网站上提交的业务，然后基于获取的业务建立业务元组，比如，采集获取小明、小红和小会近1个月内在官方APP、官方网站上提交的所有业务，或提取客服***内客户外呼反馈的所有业务，业务的状态可以分为未完成有投诉、已完成有投诉、未完成无投诉、已完成无投诉四个状态。其中，未完成无投诉表示这个业务没处理完，但是用户也没有投诉；未完成有投诉表示事情没处理完且被用户投诉了；已完成无投诉表示这个业务已处理完，且客户是满意的；已完成有投诉表示虽然这个业务处理完成了，但是这个业务里用户是有投诉的，相当于说，这个用户的潜在状态、后续其他业务的交互状态可能都会有情绪，有可能还会继续投诉，这个可以用来作为后续任务分派优先级的参考依据，可以优先处理这种会频繁投诉用户的任务。建立的业务元组可以如下所示：

用户A-号码1：业务1，状态；业务2：状态；业务3：状态||用户A-号码2：业务1：状态；业务2：状态，业务3：状态||用户B-号码1：业务1：状态；业务2：状态，业务3：状态……。

在本实施例中，考虑到用户通常会咨询未完成和有投诉状态的业务，具体可以根据业务元组将用户未完成有投诉、已完成有投诉和未完成无投诉状态的业务存入缓存数据库中。

可选地，为了便于快速查询数据，可以先对业务元组内的业务按未完成有投诉、已完成有投诉、未完成有投诉的状态顺序进行排序，然后自动提取任务具体进度，存储进入平台的缓存数据库中，缓存数据库如redis数据库。具体地，可以通过两个redis缓存数据库进行存储。

一个以键：值(Key：value)方式缓存用户与电话号码的关系：

电话号码：“号码归属用户，关联用户”

用户：“号码1，号码2，号码3，…”

一个以键：值(Key：value)方式缓存电话号码和业务的关系：

号码：“业务1：状态、进度；业务2：状态、进度；…”

以图2为例，可以设置一个缓存数据库用于存储小明的电话号码1与小明、小红和小会的关系，以及小明、小红和小会与自身所有电话号码的关系，然后再设置一个缓存数据库用于存储小明、小红和小会各自每个电话号码分别对应的未完成有投诉、已完成有投诉、未完成有投诉状态的业务，以便能够在海量的数据场景下实现快速查询。需要说明的是，在实际应用中，一个业务元组内未完成和/或有投诉状态的业务通常不会太多，即不会出现一个用户组内每个人的每个电话号码都有业务要处理的情形，因此，缓存的数据相对比较少。

步骤S103：向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息。

在本实施例中，获取到与所述呼入号码关联的所有用户的预设状态的业务后，可以触发***，进行业务进度反馈，也可以根据业务进度信息提供语音播报，比如第一用户办了宽带业务，语音播报的内容可以是：您几月几号办理的宽带业务，当前已分配现场工程师，请等待工程师联系，预计几天内联系等等。本发明在第一用户外呼介入时，根据第一用户呼入号码***第一用户服务内容，即查询与该号码关联的所有用户对应的预设状态的业务，并根据查询结果进行短信发送或语音播报，相当于进行了一次分流，去除掉了一部分只是为了查询业务进度的用户，进而降低了当前人工客服繁忙的程度。

可选地，若接收到所述第一用户的人工服务请求，所述方法还包括：

根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务；

若是，则向所述第一用户发送或播报延期服务询问信息，所述延期服务询问信息用于询问用户是否需要提供延期服务；

若接收到所述第一用户用于指示需要提供延期服务的指示信息，则将所述第一用户加入所述当前延期服务队列。

在本实施例中，当发送和/或播报完所述预设状态的业务所对应的业务进度信息后，可以进一步询问第一用户是否已完成本次要求服务，是否还需进一步请求人工服务，若第一用户进一步请求人工服务，则接收第一用户的人工服务请求。

可选地，所述根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务，包括：

判断所述用户等级是否为预设等级；

若是，则进一步判断所述当前延期服务队列中的延期等待人数是否小于等于预设阀值；

若是，则判断需要向所述第一用户提供延期服务。

在本实施例中，预设等级可以是高端用户对应的等级，不同运营商有不同的划分分法，如预设等级可以是四星级和五星级。预设阀值可以设置为当前客服上岗人数的2倍，比如，若第一用户为四星级或五星级，且当前延期服务队列中的延期等待人数小于等于当前客服上岗人数的2倍，则判断需要向所述第一用户提供延期服务，否则，不向第一用户提供延期服务。

在本实施例中，当前延期服务队列可以采取“队列Queue”的数据结构，如果第一用户选择了延期服务，则将第一用户加入当前延期服务队列，并记录申请延期服务的时间，以便客服能够在服务标准期限内服务第一用户，比如在72小时内选择空余时间进行电话回复服务第一用户。具体地，为了更好地服务用户，可以根据配置的服务标准(比如72小时)，每隔预定时间(比如12小时)发送提醒消息至所有的客服人员，提醒消息比如有多少延期等待用户，具体的到期时间等等，以辅助合理安排延期服务。如某客服人员处理完成后，***内操作标记该任务已完成，并在当前延期服务队列中删除该条信息。具体地，当当前延期服务队列已满时，可以向语音***发送信息，语音***接收到该信息后不再提供延期服务，直至队列中有用户信息删除的情况发生。

本发明在接收到用户的人工服务请求后，通过为满足一定条件的用户提供延期服务，筛选出不急于服务的人群，并将用户加入当前延期服务队列，相当于进行了第二次分流，进一步降低了当前人工客服繁忙的程度。

可选地，所述向所述第一用户发送或播报延期服务询问信息之前，所述方法还包括：

将当前人工服务数据输入预先训练好的时序模型，得到人均服务时间预测值；

基于所述人均服务时间预测值以及当前延期服务队列中的延期等待人数计算所述第一用户的等待时间预测值；

基于所述等待时间预测值向所述第一用户发送或播报提示信息，所述提示信息用于提示所述第一用户等待时间为所述等待时间预测值。

在本实施例中，为了准确预测第一用户的等待时间，可以提取近几年或近几个月的历史人工服务数据对预先建立的时序模型进行训练，历史人工服务数据比如可以是近三个月以及去年、前年同月份和前后月份每天上午和下午上岗的客服人数，服务人数最多的N名上岗人，服务人数最少的N名上岗人，服务用户总数，最长服务时间，最短服务时间等等，其中，N大于等于1，优选为10，比如模型训练的输入数据可以如表1所示，包括25个字段(如上岗人数不满20，则值为空)，时间段字段1表示上午，0表示下午：

表1：

假设当前是2021年10月3日，训练数据提取的日期范围可以是2021年7月3日-10月2日的历史人工服务数据以及2020年和2019年9、10、11月的数据，通过不同年份和月份的数据，可以达到跨时间的稳定性，同时也能够避免节假日的特殊影响，通过历史人工服务数据，拟合出25个字段与1个字段(人均服务时间)的数学关系，来预测后续的人均服务时间。

在本实施例中，当接收到第一用户的人工服务请求时，将当前人工服务数据输入预先训练好的时序模型，即可得到人均服务时间预测值，再将人均服务时间预测值与当前延期服务队列中的延期等待人数相乘即可得到第一用户的等待时间预测值。其中，当前人工服务数据包括当前时间段、当前客服人数、当前服务人数排名在前N位的客服标识、当前服务人数排名在后N位的客服标识、当前服务用户总数、当前最长服务时间以及当前最短服务时间。

在本实施例中，通过向用户提示对应的等待时间预测值可以劝退一部分当前不急于服务的用户，或者让满足一定条件的用户能够选择延期服务，因此能够进一步降低人工客服繁忙的程度。

本实施例提供的电话呼入处理方法，考虑到第一用户拨打外呼电话时很可能会咨询与呼入号码关联的自身或其他用户预设状态的业务，本发明首先根据第一用户的电话呼入请求获取所述第一用户的呼入号码，然后根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务，最后向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息，从而能够降低人工客服繁忙的程度，提高外呼服务的效率，增加用户满意度，解决了相关技术中外呼服务效率低、用户满意度下降的问题。

实施例2：

如图3所示，本实施例提供一种电话呼入处理装置，用于执行上述电话呼入处理方法，包括：

号码获取模块11，用于根据第一用户的电话呼入请求获取所述第一用户的呼入号码；

业务获取模块12，与所述号码获取模块11连接，用于根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务；

业务进度反馈模块13，与所述业务获取模块12连接，用于向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息。

可选地，业务获取模块12具体用于在预设的缓存数据库中查找与所述呼入号码关联的所有用户的预设状态的业务；

其中，所述预设状态的业务包括以下至少之一：未完成有投诉状态的业务、已完成有投诉状态的业务、未完成无投诉状态的业务。

可选地，所述与所述呼入号码关联的所有用户包括所述第一用户以及与所述第一用户具有套餐关联关系和亲属关联关系的用户，所述装置还包括：

图谱建立模块，用于根据第一用户的相关信息获取与所述第一用户具有套餐关联关系和亲属关联关系的用户，并建立关系图谱；

用户组建立模块，用于根据所述关系图谱建立用户组；

第一获取模块，用于获取所述用户组内所有用户预设时间段内的所有业务；

元组建立模块，用于基于所述用户组内所有用户预设时间段内的所有业务建立业务元组；

缓存模块，用于将所述业务元组中所有所述预设状态的业务缓存至预设的所述缓存数据库中。

可选地，所述图谱建立模块具体包括：

采集单元，用于采集所述第一用户的相关信息，其中，所述第一用户的相关信息包括第一身份信息、与所述第一身份信息对应的一个或多个第一电话号码、以及与每个所述第一电话号码对应的套餐信息和通信信息；

第一关联单元，用于以所述第一身份信息为核心关联所述一个或多个电话号码；

第二关联单元，用于针对每个所述第一电话号码，根据所述第一电话号码的套餐信息获取与所述第一电话号码具有套餐关联关系的第二电话号码，并进行关联；以及根据所述第一电话号码的通信信息获取与所述第一电话号码具有亲属关联关系的第三电话号码，并进行连接；

第三关联单元，用于针对每个所述第二电话号码，获取对应的第二用户的第二身份信息，并进行关联；以及，

第四关联单元，用于针对每个所述第三电话号码，获取对应的第三用户的第三身份信息，并进行关联，得到所述关系图谱。

可选地，若接收到所述第一用户的人工服务请求，所述装置还包括：

延期判断模块，用于根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务；

发送播报模块，用于若是，则向所述第一用户发送或播报延期服务询问信息，所述延期服务询问信息用于询问用户是否需要提供延期服务；

队列加入模块，用于若接收到所述第一用户用于指示需要提供延期服务的指示信息，则将所述第一用户加入所述当前延期服务队列。

可选地，所述延期判断模块可以包括：

第一判断单元：用于判断所述用户等级是否为预设等级；

第二判断单元：用于若是，则进一步判断所述当前延期服务队列中的延期等待人数是否小于等于预设阀值；

第三判断单元：用于若是，则判断需要向所述第一用户提供延期服务。

可选地，所述装置还包括：

模型输入模块，用于将当前人工服务数据输入预先训练好的时序模型，得到人均服务时间预测值；

计算模块，用于基于所述人均服务时间预测值以及当前延期服务队列中的延期等待人数计算所述第一用户的等待时间预测值；

信息提示模块，用于基于所述等待时间预测值向所述第一用户发送或播报提示信息，所述提示信息用于提示所述第一用户等待时间为所述等待时间预测值。

可选地，当前人工服务数据包括当前时间段、当前客服人数、当前服务人数排名在前N位的客服标识、当前服务人数排名在后N位的客服标识、当前服务用户总数、当前最长服务时间以及当前最短服务时间，其中，N大于等于1。

实施例3：

参考图4，本实施例提供一种电话呼入处理装置，包括存储器21和处理器22，存储器21中存储有计算机程序，处理器22被设置为运行所述计算机程序以执行实施例1中的电话呼入处理方法。

其中，存储器21与处理器22连接，存储器21可采用闪存或只读存储器或其他存储器，处理器22可采用中央处理器或单片机。

实施例2至实施例3提供的电话呼入处理装置，考虑到第一用户拨打外呼电话时很可能会咨询与呼入号码关联的自身或其他用户预设状态的业务，本发明首先根据第一用户的电话呼入请求获取所述第一用户的呼入号码，然后根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务，最后向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息，从而能够降低人工客服繁忙的程度，提高外呼服务的效率，增加用户满意度，解决了相关技术中外呼服务效率低、用户满意度下降的问题。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。

Claims (9)

1.一种电话呼入处理方法，其特征在于，包括：

根据第一用户的电话呼入请求获取所述第一用户的呼入号码；

根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务；

向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息；

若接收到所述第一用户的人工服务请求，所述方法还包括：

根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务；

若是，则向所述第一用户发送或播报延期服务询问信息，所述延期服务询问信息用于询问用户是否需要提供延期服务；

若接收到所述第一用户用于指示需要提供延期服务的指示信息，则将所述第一用户加入所述当前延期服务队列。

2.根据权利要求1所述的电话呼入处理方法，其特征在于，所述根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务，包括：

在预设的缓存数据库中查找与所述呼入号码关联的所有用户的预设状态的业务；

其中，所述预设状态的业务包括以下至少之一：未完成有投诉状态的业务、已完成有投诉状态的业务、未完成无投诉状态的业务。

3.根据权利要求2所述的电话呼入处理方法，其特征在于，所述与所述呼入号码关联的所有用户包括所述第一用户以及与所述第一用户具有套餐关联关系和亲属关联关系的用户，所述在预设的缓存数据库中查找与所述呼入号码关联的所有用户的预设状态的业务之前，所述方法还包括：

根据第一用户的相关信息获取与所述第一用户具有套餐关联关系和亲属关联关系的用户，并建立关系图谱；

根据所述关系图谱建立用户组；

获取所述用户组内所有用户预设时间段内的所有业务；

基于所述用户组内所有用户预设时间段内的所有业务建立业务元组；

将所述业务元组中所有所述预设状态的业务缓存至预设的所述缓存数据库中。

4.根据权利要求3所述的电话呼入处理方法，其特征在于，所述根据第一用户的相关信息获取与所述第一用户具有套餐关联关系和亲属关联关系的用户，并建立关系图谱，具体包括：

采集所述第一用户的相关信息，其中，所述第一用户的相关信息包括第一身份信息、与所述第一身份信息对应的一个或多个第一电话号码、以及与每个所述第一电话号码对应的套餐信息和通信信息；

以所述第一身份信息为核心关联所述一个或多个电话号码；

针对每个所述第一电话号码，根据所述第一电话号码的套餐信息获取与所述第一电话号码具有套餐关联关系的第二电话号码，并进行关联；以及根据所述第一电话号码的通信信息获取与所述第一电话号码具有亲属关联关系的第三电话号码，并进行连接；

针对每个所述第二电话号码，获取对应的第二用户的第二身份信息，并进行关联；以及，

针对每个所述第三电话号码，获取对应的第三用户的第三身份信息，并进行关联，得到所述关系图谱。

5.根据权利要求1所述的电话呼入处理方法，其特征在于，所述根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务，包括：

判断所述用户等级是否为预设等级；

若是，则进一步判断所述当前延期服务队列中的延期等待人数是否小于等于预设阀值；

若是，则判断需要向所述第一用户提供延期服务。

6.根据权利要求1所述的电话呼入处理方法，其特征在于，所述向所述第一用户发送或播报延期服务询问信息之前，所述方法还包括：

将当前人工服务数据输入预先训练好的时序模型，得到人均服务时间预测值；

基于所述人均服务时间预测值以及当前延期服务队列中的延期等待人数计算所述第一用户的等待时间预测值；

基于所述等待时间预测值向所述第一用户发送或播报提示信息，所述提示信息用于提示所述第一用户等待时间为所述等待时间预测值。

7.根据权利要求6所述的电话呼入处理方法，其特征在于，当前人工服务数据包括当前时间段、当前客服人数、当前服务人数排名在前N位的客服标识、当前服务人数排名在后N位的客服标识、当前服务用户总数、当前最长服务时间以及当前最短服务时间，其中，N大于等于1。

8.一种电话呼入处理装置，其特征在于，包括：

号码获取模块，用于根据第一用户的电话呼入请求获取所述第一用户的呼入号码；

业务获取模块，与所述号码获取模块连接，用于根据所述呼入号码获取与所述呼入号码关联的所有用户的预设状态的业务；

业务进度反馈模块，与所述业务获取模块连接，用于向所述第一用户发送和/或播报所述预设状态的业务所对应的业务进度信息；

若接收到所述第一用户的人工服务请求，所述装置还包括：

延期判断模块，用于根据所述第一用户的用户等级以及当前延期服务队列中的延期等待人数判断是否需要向所述第一用户提供延期服务；

发送播报模块，用于若需要向所述第一用户提供延期服务，则向所述第一用户发送或播报延期服务询问信息，所述延期服务询问信息用于询问用户是否需要提供延期服务；

队列加入模块，用于若接收到所述第一用户用于指示需要提供延期服务的指示信息，则将所述第一用户加入所述当前延期服务队列。

9.一种电话呼入处理装置，其特征在于，包括存储器和处理器，所述存储器中存储有计算机程序，所述处理器被设置为运行所述计算机程序以实现如权利要求1-7中任一项所述的电话呼入处理方法。