智能外呼方法、装置、外呼系统及存储介质与流程

1.本技术属于大数据技术领域，尤其涉及一种智能外呼方法、装置、外呼系统及存储介质。


背景技术：

2.目前，随着呼叫中心的发展，第三方系统为了向用户推销业务产品，或对已购买业务产品的用户进行回访，通常需要将包含用户终端号码的名单发送至外呼系统，以使外呼系统可以根据用户终端号码与用户建立通话连接。
3.传统的外呼系统中，通常是通过智能外呼平台向用户终端发起外呼，并且为了提高接通率，需要先对用户终端号码进行黑名单过滤、频次过滤等处理。然而，因用户终端上具有的电话拦截功能，即使外呼系统向经过黑名单过滤、频次过滤等处理后的用户终端号码发起外呼，其外呼被拒接的概率也通常较大。


技术实现要素：

4.本技术实施例提供了一种智能外呼方法、装置、外呼系统及存储介质，可以解决外呼系统发起外呼时接通率低的问题。
5.第一方面，本技术实施例提供了一种智能外呼方法，应用于外呼系统，该方法包括：
6.分别为外呼系统中的每个智能外呼平台分配至少一个待外呼名单，每个待外呼名单中包括待外呼号码；
7.获取待外呼号码的历史外呼记录；
8.针对任一智能外呼平台对应的待外呼名单，根据待外呼号码的历史外呼记录，从待外呼名单中确定第一待外呼号码；第一待外呼号码为智能外呼平台连续预设次数发起外呼时未被接通的号码；
9.将第一待外呼号码更新至其他智能外呼平台对应的待外呼名单中；
10.控制多个智能外呼平台分别根据对应更新后的待外呼名单发起外呼。
11.第二方面，本技术实施例提供了一种智能外呼装置，应用于外呼系统，该装置包括：
12.分配模块，用于分别为外呼系统中的每个智能外呼平台分配至少一个待外呼名单，每个待外呼名单中包括待外呼号码；
13.获取模块，用于获取待外呼号码的历史外呼记录；
14.第一待外呼号码确定模块，用于针对任一智能外呼平台对应的待外呼名单，根据待外呼号码的历史外呼记录，从待外呼名单中确定第一待外呼号码；第一待外呼号码为智能外呼平台连续预设次数发起外呼时未被接通的号码；
15.更新模块，用于将第一待外呼号码更新至其他智能外呼平台对应的待外呼名单中；
16.外呼模块，用于控制多个智能外呼平台分别根据对应更新后的待外呼名单发起外呼。
17.第三方面，本技术实施例提供了一种外呼系统，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述第一方面的方法。
18.第四方面，本技术实施例提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机程序，其特征在于，计算机程序被处理器执行时实现如上述第一方面的方法。
19.第五方面，本技术实施例提供了一种计算机程序产品，当计算机程序产品在外呼系统上运行时，使得外呼系统执行上述第一方面的方法。
20.本技术实施例与现有技术相比存在的有益效果是：针对任一分配有待外呼名单的智能外呼平台，根据待外呼名单中每个待外呼号码的历史外呼记录，确定智能外呼平台连续预设次数发起外呼时，未被接通的第一待外呼号码。之后，将第一待外呼号码从原本的待外呼名单中撤销；同时，将第一待外呼号码更新至其余智能外呼平台对应的待外呼名单中。以此，对于任一智能外呼平台对应的待外呼名单，其待外呼名单中所包含的待外呼号码，均不属于智能外呼平台连续预设次数发起外呼时未被接通的号码。也即该智能外呼平台拨打待外呼名单中任一待外呼号码时，均不存在被待外呼号码对应的用户终端拦截的情况。以此，可以提高外呼系统整体的接通成功率。
附图说明
21.为了更清楚地说明本技术实施例中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本技术的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
22.图1是本技术一实施例提供的一种智能外呼方法的实现流程图；
23.图2是本技术一实施例提供外呼系统分别与用户终端、第三方系统以及业务系统的应用场景示意图；
24.图3是本技术另一实施例提供的一种智能外呼方法的实现流程图；
25.图4是本技术一实施例提供的一种智能外呼方法的s104的一种实现方式示意图；
26.图5是本技术又一实施例提供的一种智能外呼方法的实现流程图；
27.图6是本技术再一实施例提供的一种智能外呼方法的实现流程图；
28.图7是本技术一实施例提供的一种智能外呼方法的s105的一种实现方式示意图；
29.图8是本技术一实施例提供的一种智能外呼装置的结构示意图；
30.图9是本技术一实施例提供的一种外呼系统的结构示意图。
具体实施方式
31.以下描述中，为了说明而不是为了限定，提出了诸如特定系统结构、技术之类的具体细节，以便透彻理解本技术实施例。然而，本领域的技术人员应当清楚，在没有这些具体细节的其它实施例中也可以实现本技术。在其它情况中，省略对众所周知的系统、装置、电路以及方法的详细说明，以免不必要的细节妨碍本技术的描述。
32.应当理解，当在本技术说明书和所附权利要求书中使用时，术语“包括”指示所描述特征、整体、步骤、操作、元素和/或组件的存在，但并不排除一个或多个其它特征、整体、步骤、操作、元素、组件和/或其集合的存在或添加。
33.另外，在本技术说明书和所附权利要求书的描述中，术语“第一”、“第二”、“第三”等仅用于区分描述，而不能理解为指示或暗示相对重要性。
34.请参阅图1，图1示出了本技术实施例提供的一种智能外呼方法的实现流程图，该方法包括如下步骤：
35.s101、外呼系统分别为外呼系统中的每个智能外呼平台分配至少一个待外呼名单，每个待外呼名单中包括待外呼号码。
36.在应用中，执行上述智能外呼方法的主体可以为外呼系统。其中，外呼系统具体包括名单中间件平台以及智能外呼平台。其中，名单中间件平台用于接收业务系统或第三方系统发送的待外呼名单。之后，名单中间件平台可以具体对分配的待外呼名单中的各个待外呼号码，执行s101-s104步骤中的方法，得到更新后的待外呼名单。之后，由智能外呼平台向各更新后的待外呼名单中的待外呼号码发起外呼。具体的，参照图2，图2为外呼系统分别与用户终端、第三方系统以及业务系统的应用场景示意图。
37.在应用中，上述智能外呼平台为用于接通或拨打待外呼号码的智能语音机器人，该智能外呼平台中可以预先存储有多种外呼业务场景的对话流程，用于与用户进行智能对话。其中，智能外呼平台可以基于外呼系统发送的待外呼名单，依次向每个待外呼号码发起外呼。
38.在应用中，上述业务系统和第三方系统可以通过超文本传输hyper text transfer protocol，http)、企业服务粽贤(enterprise service bus，esb)或消息队列协议(message queue)，mq)等协议，向名单中间件平台发送待外呼名单。而后，由名单中间件平台通过http协议，将待外呼名单分配至每个智能外呼平台进行外呼。
39.然而，因智能外呼平台通常只接收http协议的待外呼名单，因此，将造成外呼系统接收待外呼名单等数据的渠道类型具有一定局限性。基于此，在本实施例中，将名单中间件平台作为接入中间件设置在外呼系统中，可以使外呼系统分别与第三方系统或业务系统进行更加灵活的对接，以增加接收待外呼名单等数据的渠道类型。
40.另外，需要补充的是，虽然名单中间件平台分配待外呼名单至每个智能外呼平台，但对每个待外呼名单进行处理的过程均由名单中间件平台进行。智能外呼平台只需根据处理后的待外呼名单进行外呼即可。以此，提高智能外呼平台发起外呼的效率。即智能外呼平台在外呼时，不需同时对待外呼名单进行并发处理(黑名单过滤，待外呼号码合法性校验等处理)，减少被占用的智能外呼平台的外呼并发，进而提高外呼效率。
41.需要说明的是，在已有的现有技术中，外呼系统中通常不包括名单中间件平台，均由第三方系统或业务系统直接发送待外呼名单至外呼系统中的智能外呼平台。因此，将造成智能外呼平台在发起外呼的同时，还需执行对待外呼号码进行处理的过程。
42.在应用中，上述智能外呼平台的数量通常具有多个，外呼系统通常为每个智能外呼平台分配第一待外呼名单。其中，分配的待外呼名单中的待外呼号码也通常包括多个。
43.在一实施例中，参照图3，在执行s101分别为外呼系统中的每个智能外呼平台分配至少一个待外呼名单后，外呼系统还可以通过如下步骤s11-s12，对待外呼名单中的各个待
外呼号码进行校验，以撤销其不符合要求的待外呼号码：
44.s11、外呼系统对待外呼号码进行规则校验，得到规则校验未通过的待外呼号码；规则校验至少包括黑名单校验、格式校验或合法性校验中的一种。
45.在应用中，上述黑名单校验用于校验每个待外呼号码是否处于黑名单上，若处于，则将该待外呼号码从待外呼名单中进行撤销。
46.示例性的，外呼系统中还可以预先存储有黑名单，其中，黑名单中记录有多个不需进行外呼的外呼号码。外呼系统可以将待外呼名单中每个待外呼号码，分别与黑名单中的外呼号码进行比对。在任一待外呼号码命中黑名单中的外呼号码时，则直接将该待外呼号码从待外呼名单中进行撤销。
47.在应用中，上述格式校验用于对每个待外呼号码的数据格式进行校验，其包括但不限于：校验待外呼号码的字段长度是否超过长度限制、待外呼名单中是否具有待外呼号码，以及待外呼名单中待外呼号码的数量是否超过最大限制数量(例如，10个)。之后，对于上述不符合格式校验的异常号码直接进行撤销。需要说明的是，在分配的待外呼名单中包含的待外呼号码数量超过10个时，可以只取前10个待外呼号码，作为该批次需被智能外呼平台发起外呼的号码。
48.在应用中，对待外呼号码的合法性进行校验可以为：通过正则表达式对其进行校验。例如，可以校验各个待外呼号码中是否包含字母、其他非法字符、是否为特殊服务号码(例如，110、120、10086、12395xxx、96xxx等)等校验条件。同样的，若待外呼号码命中任一上述校验条件，则判断待外呼号码的合法性校验不通过。
49.s12、外呼系统从待外呼名单中，撤销任一规则校验未通过的待外呼号码。
50.在应用中，外呼系统对待外呼号码执行上述撤销功能具体可以为：待外呼名单中还具有idsubtask字段，其用于为每个待外呼号码进行唯一属性标记。同时，待外呼名单中还具有batchid字段，用于标记待外呼名单当前的外呼批次。并且，外呼系统中包括可以根据idsubtask字段进行单个待外呼号码进行处理的撤销接口，以及根据batchid字段对待外呼号码进行批量处理的撤销接口。即外呼系统可以根据上述字段以及对应的撤销接口对待外呼号码执行撤销功能。
51.在另一实施例中，上述撤销还包括业务系统或第三方系统主动发送的撤销指令，以对待外呼名单中的待外呼号码进行撤销。可以理解的是，若突发重大社会事件，该事件可能影响到业务系统或第三方系统中的业务，则存在业务系统或第三方系统主动要求停止对待外呼号码发起外呼的情况。基于此，外呼系统还需根据撤销指令中包含的信息(需要撤销外呼的待外呼号码)，对待外呼名单中的待外呼号码执行撤销处理。
52.s102、外呼系统获取待外呼号码的历史外呼记录。
53.在应用中，上述历史外呼记录可以为：当前时刻之前的预设时间段内的外呼记录。其中，预设时间段的时长可以由工作人员根据实际情况进行设置，对此不作限定。需要说明的是，在智能外呼平台向待外呼号码发起外呼时，无论是未接通外呼、接通外呼、接通时长以及未接通时间等信息，智能外呼平台均可以对其进行记录，进而生成外呼记录。因此，外呼系统可以获取该待外呼号码在之前的预设时间段内的历史外呼记录。
54.需要说明的是，对于待外呼号码的历史外呼记录，其包括但不限于被分配到的智能外呼平台在当前时刻之前向待外呼号码发起的外呼，以及其他智能外呼平台向待外呼号
码发起的外呼。可以理解的是，对于多个智能外呼平台，且对于大量的待外呼号码，外呼系统在为每个智能外呼平台分配待外呼名单时通常是随机分配的。因此，每个待外呼号码对应的历史外呼记录可能包括：当前的智能外呼平台向其发起的外呼，和/或其他智能外呼平台向其发起的外呼。
55.s103、针对任一智能外呼平台对应的待外呼名单，外呼系统根据待外呼号码的历史外呼记录，从待外呼名单中确定第一待外呼号码；第一待外呼号码为智能外呼平台连续预设次数发起外呼时未被接通的号码。
56.s104、外呼系统将第一待外呼号码更新至其他智能外呼平台对应的待外呼名单中。
57.在应用中，上述s102以对历史外呼记录进行解释，对此不再进行说明。其中，预设次数可以由工作人员根据实际情况进行设置，对此不作限定。
58.需要特别说明的是，该预设次数为未被第一待外呼号码对应的用户终端接通的次数。也即该预设次数不是现有技术中智能外呼平台向第一待外呼号码发起外呼的次数。在发起外呼的次数中，其包括第一待外呼号码对应的用户终端接通外呼的次数，与第一待外呼号码对应的用户终端未接通外呼的次数之和。
59.在本实施例中，限定该预设次数为第一待外呼号码对应的用户终端未接通外呼的次数。基于此，在判定第一待外呼号码为智能外呼平台连续预设次数发起外呼时未被接通的号码时，即可以确定该第一待外呼号码对应的用户终端已将该智能外呼平台的外呼号码进行拉黑。
60.可以理解的是，针对智能外呼平台对应的待外呼名单，若待外呼名单中存在第一待外呼号码，由对应的智能外呼平台发起外呼，且被连续预设次数均被第一待外呼号码对应的用户终端拒接，则表明对应的智能外呼平台的外呼号码已被第一待外呼号码的用户终端的用户拉入黑名单中。该智能外呼平台即便多次向第一待外呼号码发起外呼，均将被第一待外呼号码对应的用户终端拦截。
61.基于此，为了提高外呼系统整体的呼叫成功率，外呼系统可以将该第一待外呼号码，从对应的智能外呼平台所分配到的待外呼名单中进行撤销，并同时将该第一待外呼号码更新至其他智能外呼平台对应的待外呼名单中。
62.具体的，参照图4，外呼系统可以通过如下步骤s1041-s1042，将该第一待外呼号码更新至其他智能外呼平台对应的待外呼名单：
63.s1041、外呼系统根据第一待外呼号码的历史外呼记录中，从其他智能外呼平台中查询目标智能外呼平台，目标智能外呼平台为其他智能外呼平台中未被第一待外呼号码的用户终端拒接的智能外呼平台；或者，为其他智能外呼平台中未向第一待外呼号码发起外呼的智能外呼平台。
64.s1042、外呼系统将第一待外呼号码更新至目标智能外呼平台对应的待外呼名单中。
65.在应用中，上述s102已说明每个待外呼号码对应的历史外呼记录可能包括当前的智能外呼平台向其发起的外呼，和/或其他智能外呼平台向其发起的外呼。基于此，在当前的智能外呼平台的外呼号码，可能已经被第一待外呼号码对应的用户终端拉黑的情况下，为了提高外呼系统整体的呼叫成功率，外呼系统可以从第一待外呼号码的历史外呼记录
中，查询未被第一待外呼号码的用户终端拒接的其余智能外呼平台；或者，查询从未向第一待外呼号码发起过外呼的其余智能外呼平台。之后，外呼系统可以将该第一待外呼号码重新分配至写入其余智能外呼平台对应的待外呼名单中。
66.s105、外呼系统控制多个智能外呼平台分别根据对应更新后的待外呼名单发起外呼。
67.在应用中，在对每个智能外呼平台对应的待外呼名单进行更新后，其待外呼名单中所包含的待外呼号码均符合规则校验，且均不属于智能外呼平台连续预设次数发起外呼时未被接通的号码。以此，可以降低外呼系统向待外呼名单发起外呼时，被拦截的概率
68.在本实施例中，针对任一分配有待外呼名单的智能外呼平台，根据待外呼名单中每个待外呼号码的历史外呼记录，确定智能外呼平台连续预设次数发起外呼时，未被接通的第一待外呼号码。之后，将第一待外呼号码从原本的待外呼名单中撤销；同时，将第一待外呼号码更新至其余智能外呼平台对应的待外呼名单中。以此，对于任一智能外呼平台对应的待外呼名单，其待外呼名单中所包含的待外呼号码，均不属于智能外呼平台连续预设次数发起外呼时未被接通的号码。也即该智能外呼平台拨打待外呼名单中任一待外呼号码时，均不存在被待外呼号码对应的用户终端拦截的情况。以此，可以提高外呼系统整体的接通成功率。
69.在一实施例中，待外呼名单中还包括待外呼号码被外呼过的外呼业务场景，以及在外呼业务场景下待外呼号码的外呼次数；参照图5，在s104将第一待外呼号码更新至其他智能外呼平台对应的待外呼名单中之后，还包括如下步骤s141-143：
70.s141、外呼系统确定智能外呼平台对应的当前外呼业务场景。
71.在应用中，上述外呼业务场景具体为业务系统中每个业务对应的外呼业务场景。可以理解的是，业务系统提供的待外呼名单中，每个待外呼号码对应的用户可能只办理过一个业务，或未办理过业务。
72.示例性的，业务系统中包含有多种业务，每种业务通常对应着不同的对话流程，其面向的用户也通常各不相同。例如，对于办理医疗保险领域的业务，通常分配的待外呼名单中包含的待外呼号码对应的用户，为未办理医疗保险业务的用户。对于医疗保险业务的反馈调查，通常分配的待外呼名单中包含的待外呼号码对应的用户，为已经办理的医疗保险业务的用户，对此不作限定。
73.基于此，在向待外呼名单发起外呼以使用户办理业务，或对用户进行反馈调查时，外呼系统可以生成对待外呼号码的外呼记录，同时还可标记该外呼记录对应的外呼业务场景，以及在该外呼业务场景下的外呼次数。
74.具体的，外呼系统可以为每个外呼业务场景设置一个场景号(或者，设置一个业务线，或平台编码等标识)，并在对待外呼号码发起外呼后，对该待外呼号码生成场景号+待外呼号码+数值的外呼记录，并将该外呼记录存储在待外呼名单中。示例性的，以外呼业务场景的场景号(业务线号或平台编码)和待外呼号码为key为例进行进行记录。
75.s142、外呼系统从更新后的待外呼名单中确定第二待外呼号码；第二待外呼号码为已被外呼过的外呼业务场景中，包含有与当前外呼业务场景相同的号码。
76.s143、若第二待外呼号码对应的外呼次数大于当前外呼业务场景对应的预设次数，则外呼系统从更新后的待外呼名单中撤销第二待外呼号码，得到最终的待外呼名单；否
则，维持更新后的待外呼名单不变。
77.在应用中，若待外呼名单中未有一个待外呼号码为第二待外呼号码，则表明任意一个待外呼号码均未在当前业务场景下被外呼过。若待外呼名单中具有第二待外呼号码，则表明在当前业务场景下，该第二待外呼号码被外呼过。此时，外呼系统可以根据待外呼名单中的历史外呼记录，从更新后的待外呼名单中获取到：当前业务场景对应的场景号+待外呼号码为key，value值为n的历史外呼记录。其中，value值用于表示该待外呼号码在当前业务场景下被外呼的外呼次数。
78.之后，外呼系统可以比较value值n与预设次数的大小，若n大于预设次数，则从更新后的待外呼名单中撤销第二待外呼号码，得到最终更新后的待外呼名单。否则，维持更新后的待外呼名单不变。
79.需要说明的是，将外呼次数大于预设次数的第二待外呼号码进行撤销的目的在于：减少对第二待外呼号码对应的用户造成骚扰，降低投诉风险。
80.最后，外呼系统可以根据最终更新后的待外呼名单，执行s105控制多个智能外呼平台分别根据对应更新后的待外呼名单发起外呼的步骤。并且，参照图6，在s105之后，还可以执行如下步骤s151-s152，以对待外呼名单中每个待外呼号码的历史外呼记录进行更新，具体的：
81.s151、针对任一待外呼号码，外呼系统将对应的当前外呼业务场景更新至待外呼号码的外呼记录中。以及，
82.s152、外呼系统更新外呼记录中当前外呼业务场景的外呼次数。
83.在应用中，上述s143中已说明外呼系统可以从历史外呼记录中获取到：当前业务场景对应的场景号+待外呼号码为key，value值为n的历史外呼记录。
84.基于此，在外呼系统向待外呼号码发起外呼后，若智能外呼平台在此之前已经对该待外呼号码发起至少一次外呼，则可以在该待外呼号码的历史外呼记录中，将当前业务场景对应的value值在原有的数值上+1。
85.同样的，若智能外呼平台在此之前未对该待外呼号码发起过外呼，则表明该待外呼号码的历史外呼记录中，未记录有当前业务场景的场景号，以及相应的外呼次数。基于此，在外呼系统对该待外呼号码发起外呼后，可以新建当前业务场景对应的场景号+待外呼号码为key，value值为1的外呼记录。
86.需要特别说明的是，在外呼系统向待外呼号码发起外呼后，其外呼记录中value值需要在原有的数值上+1。然而，在此基础上，对于下一次统计待外呼号码在当前时刻之前的预设时间段内的历史外呼记录时，由于下一次的时刻将被认定为是新的当前时刻，也即在当前时刻之前的预设时间段是变更的。因此，外呼系统中确定历史外呼记录也应当是改变的。即外呼系统需重新基于历史外呼记录确定外呼次数value值。
87.之后，参照图6，在s152之后，外呼系统可以通过如下步骤s153-s154，对更新后的外呼记录进行处理，具体的：
88.s153、外呼系统从待外呼名单中，确定被撤销的待外呼号码。
89.s154、外呼系统将更新后的外呼记录，以及被撤销的待外呼号码更新至第三方系统；第三方系统为向外呼系统发送待外呼名单的系统。
90.在应用中，上述s12已说明如何从待外呼名单中确定被撤销的待外呼号码，对此不
再进行说明的。其中，在对待外呼号码进行撤销后，外呼系统可以将其写入数据库中进行保存，同时标记为非法号码加入异常外呼号码名单中，并回传至业务系统或第三方系统。
91.具体的，在外呼系统中对待外呼号码执行撤销后，会在待外呼名单中将该待外呼号码的状态更改为撤销状态。同时，生成撤销状态的外呼结果发送至名单中间件平台。之后，由名单中间件平台通过回调接口将撤销状态的外呼结果回传至业务系统或第三方系统，以统一业务系统或第三方系统与外呼系统发起外呼的数据结果。即做到业务系统或第三方系统中实际被外呼的待外呼号码，与外呼系统实际向待外呼号码发起外呼的数据结果一致性。同时，外呼系统还可以将更新后的外呼记录，同时发送至业务系统或第三方系统。
92.在一实施例中，参照图7，在s105控制多个智能外呼平台分别根据对应更新后的待外呼名单发起外呼中，具体可通过如下子步骤s1051-s1053实现，详述如下：
93.s1051、针对任一待外呼号码，外呼系统从待外呼号码的历史外呼记录中，确定通话时间超过预设时长的第一外呼记录，以及未接通外呼的第二外呼记录。
94.在应用中，上述预设时长可以由工作人员根据实际情况进行设置。需要说明的是，历史外呼记录中通常还包括对每个待外呼号码发起外呼时，每个待外呼号码对应的用户终端接通外呼的通话时长，或未接通外呼的情况。
95.s1052、外呼系统根据第一外呼记录的接通时间段，以及第二外呼记录的未接通时间段，预测待外呼号码被接通的目标时间段。
96.s1053、外呼系统若当前时刻处于目标时间段内，则向待外呼号码发起外呼；否则，将目标时间段标记为待外呼号码的待外呼时间。
97.在应用中，对于接通外呼的情况，且通话时间超过预设时长的第一外呼记录中，其通常还记录有待外呼号码对应的用户终端接通外呼时的接通时间段。
98.可以理解的是，在该时间段内向该待外呼号码发起外呼时，其被接通的概率可能更大。同样的，对于未接通外呼的第二外呼记录，其包含有该待外呼号码对应的用户终端拒接外呼的未接通时间段。
99.基于此，若当前时刻处于接通时间段内，或者与接通时间段相近，则表明智能外呼平台向待外呼号码发起外呼时被接通的概率更大。其中，目标时间段可以为处于接通时间段内、或处于接通时间段之前和/或之后的半个小时内，对此不作限定。
100.需要补充的是，因待外呼号码对应的用户终端接通外呼，且通话时间超过预设时长。因此，可以认为用户终端接通外呼的时间点为接通时间段的起始时间点，同时将用户挂断外呼的时间点确定接通时间段为终止时间点。
101.然而，对于未接通时间段，因用户终端拒接外呼时，其拒接的时刻应当仅为一个单独的时间点。基于此，外呼系统具体可以将距离该时间点之前的预设时长下的时间点作为起始时间点，以及将距离该时间点之后的预设时长下的时间点确定为终止时间点，进而得到未接通时间段。其中，预设时长可以由工作人员根据实际情况进行设置，例如，半个小时。
102.在一种可能存在的情况下，上述未接通时间段，与接通时间段为具有交集的时间段。基于此，外呼系统可以将接通时间段中，不具有交集的时间段确定为目标时间段。以此，进一步的预测出用户终端可能接通外呼的时间段，降低外呼未接通的概率。
103.请参阅图8，图8是本技术实施例提供的一种智能外呼装置的结构框图。本实施例中智能外呼装置包括的各模块用于执行图1、图3至图7对应的实施例中的各步骤。具体请参
阅图1、图3至图7以及图1、图3至图7所对应的实施例中的相关描述。为了便于说明，仅示出了与本实施例相关的部分。参见图8，智能外呼装置800可以包括：分配模块810、获取模块820、第一待外呼号码确定模块830、更新模块840以及外呼模块850，其中：
104.分配模块810，用于分别为外呼系统中的每个智能外呼平台分配至少一个待外呼名单，每个待外呼名单中包括待外呼号码。
105.获取模块820，用于获取待外呼号码的历史外呼记录。
106.第一待外呼号码确定模块830，用于针对任一智能外呼平台对应的待外呼名单，根据待外呼号码的历史外呼记录，从待外呼名单中确定第一待外呼号码；第一待外呼号码为智能外呼平台连续预设次数发起外呼时未被接通的号码。
107.更新模块840，用于将第一待外呼号码更新至其他智能外呼平台对应的待外呼名单中。
108.外呼模块850，用于控制多个智能外呼平台分别根据对应更新后的待外呼名单发起外呼。
109.在一实施例中，智能外呼装置800还包括：
110.规则校验模块，用于对待外呼号码进行规则校验，得到规则校验未通过的待外呼号码；规则校验至少包括黑名单校验、格式校验或合法性校验中的一种。
111.待外呼号码撤销模块，用于从待外呼名单中，撤销任一规则校验未通过的待外呼号码。
112.在一实施例中，更新模块840还用于：
113.根据第一待外呼号码的历史外呼记录，从其他智能外呼平台中查询目标智能外呼平台；目标智能外呼平台为其他智能外呼平台中未被第一待外呼号码的用户终端拒接的智能外呼平台；或者，为其他智能外呼平台中未向第一待外呼号码发起外呼的智能外呼平台；将第一待外呼号码更新至目标智能外呼平台对应的待外呼名单中。
114.在一实施例中，待外呼名单中还包括待外呼号码被外呼过的外呼业务场景，以及在外呼业务场景下待外呼号码的外呼次数；智能外呼装置800还包括：
115.外呼业务场景确定模块，用于确定智能外呼平台对应的当前外呼业务场景。
116.第二待外呼号码确定模块，用于从更新后的待外呼名单中确定第二待外呼号码；第二待外呼号码为已被外呼过的外呼业务场景中，包含有与当前外呼业务场景相同的号码。
117.处理模块，用于若第二待外呼号码对应的外呼次数大于当前外呼业务场景对应的预设次数，则从更新后的待外呼名单中撤销第二待外呼号码，得到最终的待外呼名单；否则，维持更新后的待外呼名单不变。
118.在一实施例中，智能外呼装置800还包括：
119.外呼业务场景更新模块，用于针对任一待外呼号码，将对应的当前外呼业务场景更新至待外呼号码的外呼记录中。以及，
120.外呼次数更新模块，用于更新外呼记录中当前外呼业务场景的外呼次数。
121.在一实施例中，智能外呼装置800还包括：
122.撤销的待外呼号码确定模块，用于从待外呼名单中，确定被撤销的待外呼号码。
123.外呼记录更新模块，用于将更新后的外呼记录，以及被撤销的待外呼号码更新至
第三方系统；第三方系统为向外呼系统发送待外呼名单的系统。
124.在一实施例中，外呼模块850还包括：
125.针对任一待外呼号码，从待外呼号码的历史外呼记录中，确定通话时间超过预设时长的第一外呼记录，以及未接通外呼的第二外呼记录；根据第一外呼记录的接通时间段，以及第二外呼记录的未接通时间段，预测待外呼号码被接通的目标时间段；若当前时刻处于目标时间段内，则向待外呼号码发起外呼；否则，将目标时间段标记为待外呼号码的待外呼时间。
126.当理解的是，图8示出的智能外呼装置的结构框图中，各模块用于执行图1、图3至图7对应的实施例中的各步骤，而对于图1、图3至图7对应的实施例中的各步骤已在上述实施例中进行详细解释，具体请参阅图图1、图3至图7以及图1、图3至图7所对应的实施例中的相关描述，此处不再赘述。
127.图9是本技术一实施例提供的一种外呼系统的结构框图。如图9所示，该实施例的外呼系统900包括：处理器910、存储器920以及存储在存储器920中并可在处理器910运行的计算机程序930，例如智能外呼方法的程序。处理器910执行计算机程序930时实现上述各个智能外呼方法各实施例中的步骤，例如图1所示的s101至s105。或者，处理器910执行计算机程序930时实现上述图8对应的实施例中各模块的功能，例如，图8所示的模块810至850的功能，具体请参阅图8对应的实施例中的相关描述。
128.示例性的，计算机程序930可以被分割成一个或多个模块，一个或者多个模块被存储在存储器920中，并由处理器910执行，以实现本技术实施例提供的智能外呼方法。一个或多个模块可以是能够完成特定功能的一系列计算机程序指令段，该指令段用于描述计算机程序930在外呼系统900中的执行过程。例如，计算机程序930可以实现本技术实施例提供的智能外呼方法。
129.外呼系统900可包括，但不仅限于，处理器910、存储器920。本领域技术人员可以理解，图9仅仅是外呼系统900的示例，并不构成对外呼系统900的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件，例如外呼系统还可以包括输入输出设备、网络接入设备、总线等。
130.所称处理器910可以是中央处理单元，还可以是其他通用处理器、数字信号处理器、专用集成电路、现成可编程门阵列或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件等。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。
131.存储器920可以是外呼系统900的内部存储单元，例如外呼系统900的硬盘或内存。存储器920也可以是外呼系统900的外部存储设备，例如外呼系统900上配备的插接式硬盘，智能存储卡，闪存卡等。进一步地，存储器920还可以既包括外呼系统900的内部存储单元也包括外部存储设备。
132.本技术实施例提供了一种外呼系统，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述各个实施例中的智能外呼方法。
133.本技术实施例提供了一种计算机可读存储介质，包括存储器、处理器以及存储在存储器中并可在处理器上运行的计算机程序，处理器执行计算机程序时实现如上述各个实
施例中的智能外呼方法。
134.本技术实施例提供了一种计算机程序产品，当计算机程序产品在外呼系统上运行时，使得外呼系统执行上述各个实施例中的智能外呼方法。
135.以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的精神和范围，均应包含在本技术的保护范围之内。