Telephone Outbound Call Method, Device, Electronic Device and Storage Medium

Abstract

An embodiment of the present application discloses a method, device, electronic device, and storage medium for outbound calls. The method includes: when an outbound call task is obtained, allocating a target outbound call robot for the outbound call task from a set of outbound call robots; determining the status of the target outbound call robot, where the status of the outbound call robot includes an online status and an offline status, and the offline status is used to indicate that the outbound call robot goes offline from the server when the time interval between the time of the last outbound call operation and the current time is greater than a preset threshold; when the status of the target outbound call robot is the offline status, bringing the target outbound call robot online on the server; and making an outbound call to the outbound call corresponding to the outbound call task through the target outbound call robot. The present application can avoid the problem that the outbound call robot occupies the server for a long time, resulting in waste of server resources.

Description

Technical Field

[0001] This application relates to the field of communication technologies, and in particular, to a method, device, electronic device, and storage medium for outbound calls. Background Art

[0002] With the rise of the telephone network, more and more enterprises contact customers by phone through artificial customer service. With the development of the times, outbound call robots have gradually replaced artificial customer service and become the main way for enterprises to communicate with customers.

[0003] In some scenarios, the scheduling method of the outbound call platform for outbound call robots adopts a combination of a running queue and a waiting queue. Specifically, outbound call tasks are saved in a database. The outbound call tasks have a start call time attribute. The database is scanned every certain period of time, and the outbound call tasks that will start outbound calls within a future predetermined time in the database are queried and added to the waiting queue. Then, the outbound call tasks in the waiting queue are continuously polled to determine whether these tasks meet the call conditions. If they meet the conditions, the outbound call robots are scheduled to start these outbound call tasks. Once started, these outbound call tasks are removed from the waiting queue and added to the running queue. When the resources of the outbound call robots are insufficient, the outbound call tasks are removed from the running queue and added back to the waiting queue. Using this method, all outbound call robots need to be in a ready state. However, the number of outbound call robots is large and their usage has a periodic pattern. Therefore, the number of outbound call robots used within the same period is limited. However, all outbound call robots need to be deployed on the server to be in a ready state, which will occupy the resources of the server and cause waste of server resources. Summary of the Invention

[0004] This application provides a method, device, electronic device, and storage medium for outbound calls to solve the problem that outbound call robots occupy the resources of the server for a long time and cause waste of server resources.

[0005] In a first aspect, this application provides a method for outbound calls, including: when an outbound call task is obtained, allocating a target outbound call robot for the outbound call task from a set of outbound call robots; determining the state of the target outbound call robot, where the state of the outbound call robot includes an online state and an offline state, and the offline state is used to indicate that the outbound call robot goes offline from the server when the time interval between the time of the last outbound call operation and the current time is greater than a preset threshold; when the state of the target outbound call robot is the offline state, bringing the target outbound call robot online on the server; and making an outbound call to the outbound call corresponding to the outbound call task through the target outbound call robot.

[0006] In a second aspect, the present application provides a telephone outbound calling device, including: an allocation module, configured to allocate a target outbound calling robot for the outbound calling task from a set of outbound calling robots when obtaining the outbound calling task; a determination module, configured to determine the status of the target outbound calling robot, where the status of the outbound calling robot includes an online status and an offline status, and the offline status is used to indicate that the outbound calling robot goes offline from the server when the time interval between the time of the last outbound calling operation and the current time is greater than a preset threshold; an online module, configured to bring the target outbound calling robot online on the server when the status of the target outbound calling robot is the offline status; and an outbound calling module, configured to make an outbound call corresponding to the outbound calling task through the target outbound calling robot.

[0007] In a third aspect, the present application provides an electronic device, including: a processor; and a memory for storing instructions executable by the processor; wherein, the processor is configured to execute the instructions to implement the method as in the first aspect.

[0008] In a fourth aspect, the present application provides a computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, enabling the electronic device to execute the method as in the first aspect.

[0009] It can be seen that for an outbound calling robot, an outbound calling robot whose time interval between the time of the last outbound calling operation and the current time is greater than a preset threshold is taken offline from the server. That is to say, when the outbound calling robot does not need to perform an outbound calling operation and is not used for a long time, it is taken offline from the server, so as not to occupy the resources of the server invalidly and avoid waste of server resources. When the target outbound calling robot needs to perform an outbound calling operation, the target outbound calling robot taken offline from the server is brought back online on the server, so as to use the target outbound calling robot to make an outbound call corresponding to the outbound calling task. In this way, not only can the outbound call of the outbound calling task be made in a timely manner, but also the outbound calling robot can be prevented from occupying the resources of the server invalidly when not in use, saving the resources of the server and avoiding waste of the resources of the server. Description of the Drawings

[0010] The drawings described herein are used to provide a further understanding of the present specification, and constitute a part of the present specification. The illustrative embodiments of the present specification and their descriptions are used to explain the present specification and do not constitute an improper limitation to the present specification. In the drawings:

[0011] Figure 1 is a schematic flowchart of a telephone outbound calling method provided by an embodiment of the present application;

[0012] Figure 2A is a schematic flowchart of a process for configuring an offline policy for an outbound calling robot provided by an embodiment of the present application;

[0013] Figure 2B A schematic flowchart for task preheating when scheduling outbound calls provided by an embodiment of this application;

[0014] Figure 2C A schematic flowchart for the timed start of outbound calls in a preheating queue provided by an embodiment of this application;

[0015] Figure 2D A schematic flowchart for periodically preheating special robots provided by an embodiment of this application;

[0016] Figure 3 A schematic structural diagram of a telephone outbound call device provided by an embodiment of this application;

[0017] Figure 4 A schematic structural diagram of an electronic device provided by an embodiment of this specification. Specific embodiments

[0018] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, rather than all of them. Based on the embodiments in this specification, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the scope of protection of this application.

[0019] The terms "first", "second", etc. in this specification and the claims are used to distinguish similar objects, rather than to describe a specific order or sequence. It should be understood that such used data can be interchanged under appropriate circumstances so that the embodiments of this application can be implemented in an order other than those illustrated or described herein. In addition, "and / or" in this specification and the claims means at least one of the connected objects, and the character " / " generally indicates an "or" relationship between the associated objects before and after.

[0020] The dispatching method of the outbound call platform for outbound call robots adopts a combination of a running queue and a waiting queue. Specifically, outbound call tasks are stored in a database. Each outbound call task has an attribute of the start call time. The database is scanned every certain period of time, and the outbound call tasks that are scheduled to start outbound calls within a future predetermined time in the database are retrieved and added to the waiting queue. Then, the outbound call tasks in the waiting queue are continuously polled to determine whether these tasks meet the call conditions. If they do, the outbound call robots are dispatched to start these outbound call tasks. Once started, these outbound call tasks are removed from the waiting queue and added to the running queue. When the resources of the outbound call robots are insufficient, the outbound call tasks are removed from the running queue and added back to the waiting queue. Using this method, all outbound call robots need to be in a ready state. However, the number of outbound call robots is large and their usage has a periodic pattern. Therefore, the number of outbound call robots used in the same period is limited. But all outbound call robots need to be deployed on the server to be in a ready state, which will occupy the resources of the server and cause waste of server resources.

[0021] Therefore, an embodiment of this application provides a telephone outbound call method, including: when an outbound call task is obtained, a target outbound call robot is allocated for the outbound call task from the set of outbound call robots, and the status of the target outbound call robot is determined. Among them, the status of the outbound call robot includes an online status and an offline status. The offline status is used to indicate that the outbound call robot goes offline from the server when the time interval between the time of the last outbound call operation and the current time is greater than a preset threshold. When the status of the target outbound call robot is the offline status, the target outbound call robot is brought online on the server, and the outbound call robot dials the outbound call corresponding to the outbound call task.

[0022] Through the technical solution disclosed in the embodiment of this application, for an outbound call robot, the outbound call robot whose time interval between the time of the last outbound call operation and the current time is greater than the preset threshold is taken offline from the server. That is to say, when the outbound call robot does not need to perform an outbound call operation and is not used for a long time, it is taken offline from the server, so as not to occupy the resources of the server invalidly and avoid the problem of waste of server resources. When the target outbound call robot needs to perform an outbound call operation, the target outbound call robot taken offline from the server is brought back online on the server, and then the target outbound call robot is used to dial the outbound call corresponding to the outbound call task. In this way, not only can the outbound call of the outbound call task be made in time, but also it can be avoided that the outbound call robot does not occupy the resources of the server invalidly when not in use, saving the resources of the server and avoiding waste of the resources of the server.

[0023] It should be understood that the outbound call methods provided in the embodiments of the present application can be executed by an electronic device or software installed in the electronic device, and specifically can be executed by a terminal device or a server device. Among them, the outbound call method can be executed by the same electronic device, or can also be executed by different electronic devices.

[0024] The following will describe in detail the technical solutions provided in each embodiment of this specification with reference to the accompanying drawings.

[0025] The following will Figure 1 further describe in detail a kind of outbound call method provided in the embodiments of the present application. Please refer to Figure 1 , which is a schematic flowchart of a kind of outbound call method provided in an embodiment of this specification, and is applied to an electronic device. The method may include:

[0026] Step S101, when an outbound call task is obtained, allocate a target outbound call robot for the outbound call task from the set of outbound call robots.

[0027] Specifically, the identity documents (IDs) of the outbound call robots are stored in the set of outbound call robots. Each outbound call robot corresponds to a unique ID. The target outbound call robot can be allocated for the outbound call task according to the ID of the outbound call robot. When allocating an outbound call robot for the outbound call task, an ID can be randomly selected from the IDs of the outbound call robots stored in the database and allocated to the outbound call task, and the ID of the outbound call robot allocated for the outbound call task is used as the ID of the target outbound call robot. The outbound call tasks are saved in the database. The outbound call tasks themselves have attributes such as the start call time. Now there is a scheduled task that scans the database every 20 seconds, queries out the outbound call tasks that will start outbound calls within a future predetermined time (such as 30 seconds) in the database and adds them to the waiting queue, and then continuously polls the outbound call tasks in the waiting queue to see if these outbound call tasks meet the outbound call conditions. If they meet the conditions, these outbound call tasks will be started for calling. When an outbound call task cannot be outbound due to insufficient resources of the outbound call robot or outbound call time limit and other reasons, it will be re-added to the waiting queue. The waiting queue scans these outbound call tasks until they can be executed again, and then the outbound call task is obtained and started for calling. Among them, the outbound call conditions include but are not limited to reaching the time of the outbound call operation, or, it can also be that the outbound call operation in the suspended state has not reached the start time, etc.

[0028] There are a large number of outbound call tasks, but the resources of the outbound call robot are limited. The outbound call tasks waiting in line and those that do not currently meet the outbound call conditions will temporarily exist in this waiting queue. When obtaining an outbound call task from the waiting queue, the outbound call tasks in the waiting queue can be scanned periodically. The scan period can take any value, such as 30 seconds. When there is an outbound call task in the waiting queue that meets the outbound call conditions, obtain this outbound call task from the waiting queue.

[0029] Step S103, determine the status of the target outbound call robot.

[0030] Among them, the status of the outbound call robot includes the online status and the offline status. The offline status is used to indicate that the outbound call robot is taken offline from the server when the time interval between the time of the last outbound call operation of the outbound call robot and the current time is greater than a preset threshold.

[0031] Specifically, the status of the target outbound call robot refers to its being divided into an online status and an offline status according to whether it is online or offline on the server. According to the situation of whether the target outbound call robot is successfully deployed on the server, the status of the target outbound call robot includes the offline status (frozen status) and the online status (non-frozen status); among them, the offline status means that the target outbound call robot is not successfully deployed on the server, that is, the target outbound call robot is offline on the server and it does not occupy the resources of the server. The online status means that the target outbound call robot is successfully deployed on the server, that is, the target outbound call robot is online on the server and it can use the resources of the server for outbound calls. Further, the outbound call robot can be taken offline from the server when the time interval between the time of the last outbound call operation of the outbound call robot and the current time is greater than a preset threshold. Among them, the time of the last outbound call operation of the outbound call robot refers to the time when the outbound call robot made the last outbound call. The preset threshold refers to the pre-configured freezing time. The unit of this freezing time can be set to minutes. Correspondingly, the time interval can also be converted to minutes, so that the freezing time can be more accurate, thereby improving the accuracy of taking the outbound call robot offline from the server. The length of the freezing time can be determined according to the actual situation, and the embodiments of the present application do not make any limitations here.

[0032] In a possible implementation, the status of the outbound call robot can be determined by adding an identifier to the outbound call robot, thereby improving the efficiency of determining the status of the target outbound call robot. Determining the status of the target outbound call robot includes: determining the identity identifier of the target outbound call robot, and querying whether there is an online identifier in the cache according to the identity identifier. The online identifier indicates that the target outbound call robot is in the online status. In the case where the online identifier does not exist, determine that the status of the target outbound call robot is the offline status.

[0033] Specifically, the identity identifier of the target outbound robot can be a unique ID assigned to each outbound robot. The online identifier refers to the successful deployment of the target outbound robot on the server, that is, it is online on the server. Among them, the existence of the online identifier of the target outbound robot in the cache can include two cases. One is that the target outbound robot has never been offline from the server and has always been in an online state on the server, that is, the time interval between the time of the target outbound robot's last task and the current time is less than a preset threshold. The other is that the target outbound robot can be directly used after it is offline from the server and then goes online again. Among them, the online identifier can be set as an identifier in any form, such as "MODEL_robotId_version_modelId". If the online identifier exists in the cache, it means that the target outbound robot is in an online state and can be directly used. If the online identifier does not exist in the cache, it means that the target outbound robot has been frozen and the state of the target outbound robot is an offline state. Further, the cache can be cached using redis, and of course other caching methods can also be used. The embodiments of the present application do not make any limitations in this regard.

[0034] Step S105, when the state of the target outbound robot is in an offline state, bring the target outbound robot online on the server.

[0035] Specifically, for the target outbound robot, if it is in an online state, the target outbound robot can be directly used to make an outbound call corresponding to the outbound task. If it is in an offline state, it means that the target outbound robot is frozen and the target outbound robot needs to be brought online on the server again.

[0036] Step S107, use the target outbound robot to make an outbound call corresponding to the outbound task.

[0037] Specifically, after the target outbound robot in the offline state is brought online on the server again, use the resources on the server through the target outbound robot to make an outbound call corresponding to the outbound task. Among them, the outbound call includes but is not limited to the phone number, personal information of the person being called, etc.

[0038] In a possible implementation manner, using the target outbound robot to make an outbound call corresponding to the outbound task includes: scanning each outbound task in the waiting queue at a predefined period, adding the outbound tasks that meet the outbound conditions to the running queue, and the running queue is a queue for storing outbound tasks that meet the outbound conditions; if the outbound task is in the running queue, use the target outbound robot to make an outbound call corresponding to the outbound task.

[0039] Specifically, the outbound call tasks are added to the waiting queue. The outbound call tasks in the waiting queue include those in a queued state due to limited resources of the outbound call robot and those that do not currently meet the outbound call conditions. The waiting queue reactivates the outbound call tasks for execution, scans each outbound call task in the waiting queue at a predefined cycle, and adds the executable outbound call tasks to the running queue to start execution. The ongoing outbound call tasks or those in the process of starting will exist in the running queue. Among them, if an outbound call task is in the running queue, it means that the task can be started for execution, and then the target outbound call robot is used to make the outbound call to the corresponding outbound call phone for the outbound call task.

[0040] Through the technical solution disclosed in the embodiments of the present application, for an outbound call robot, the outbound call robot whose time interval between the last outbound call operation and the current time is greater than a preset threshold is taken offline from the server. That is to say, when the outbound call robot does not need to perform outbound call operations and has not been used for a long time, it is taken offline from the server, so as not to occupy the server resources invalidly and avoid wasting server resources. When the target outbound call robot needs to perform an outbound call operation, the target outbound call robot taken offline from the server is then put back online on the server, and then the target outbound call robot is used to make the outbound call to the corresponding outbound call phone for the outbound call task. In this way, not only can the outbound call phone for the outbound call task be made in a timely manner, but also it can be ensured that the outbound call robot does not occupy the server resources invalidly when not in use, saving server resources and avoiding wasting server resources.

[0041] For an outbound call robot, a certain offline strategy can be set to avoid the problem of reduced outbound call efficiency caused by a large number of outbound call robots being taken offline from the server. In addition, to ensure that outbound call robots with high timeliness and low latency response requirements can continuously provide outbound call services and thus improve the outbound call efficiency, that is, outbound call robots with high timeliness and low latency response requirements are not allowed to be frozen for a long time, so that they can be promptly put into outbound call use.

[0042] In a possible implementation, the method further includes: obtaining the time when each outbound robot in the outbound robot set last performed an outbound operation; taking offline from the server the first outbound robot in the outbound robot set, for which the time interval between the time when it last performed an outbound operation and the current time is greater than a preset threshold; determining, according to a preconfigured robot identifier, whether the first outbound robot taken offline from the server is a second outbound robot, where the robot identifier is used to indicate that the offline duration of the second outbound robot from the server does not exceed a preset duration, and the second outbound robot is an outbound robot whose working performance meets a preset condition; in the case where the first outbound robot is the second outbound robot, determining the offline duration of the first outbound robot; when the offline duration is greater than the preset duration, bringing the first outbound robot back online on the server and caching an online identifier indicating that the first outbound robot has been successfully brought online on the server.

[0043] Specifically, the time when the outbound robot last performed an outbound operation refers to the time when the outbound robot last made an outbound call. The preset threshold refers to a preconfigured freezing time, and the unit of this freezing time can be set to minutes. Correspondingly, the time interval can also be converted to minutes, so as to make the freezing time more accurate, thereby improving the accuracy of taking the outbound robot offline from the server. The length of the freezing time can be determined according to the actual situation, and the embodiments of the present application do not make any limitations in this regard. Further, when configuring this freezing time, the setting of the freezing time can be added to the data dictionary. The purpose of the data dictionary is to define and describe the freezing time. By configuring the freezing time in the data dictionary, the freezing time can be adjusted more flexibly. When determining the time interval between the time when the last outbound operation was performed and the current time, the current time can be subtracted from the time when the last outbound operation was performed to obtain the time interval. When the time interval is greater than this freezing time, it means that the outbound robot has not been used for a long time and will occupy the resources of the server invalidly. At this time, the outbound robot is taken offline from the server to release the server resources occupied by the outbound robot. If the time interval is not greater than this freezing time, no processing is performed on the outbound robot. In this way, for an outbound robot, whether it needs to be taken offline from the server is determined by the time interval from the time when the outbound robot last performed an outbound operation to the current time. If it exceeds the preset threshold, it means that the outbound robot has not been used for a long time, and then the outbound robot is taken offline from the server, avoiding a large number of outbound robots being taken offline from the server and resulting in a reduction in outbound efficiency, which can not only ensure that the outbound efficiency is not affected, but also ensure that the problem of the outbound robot occupying the server resources invalidly is solved.

[0044] Furthermore, the working performance of the second outbound calling robot includes latency and timeliness, etc. The preset conditions refer to that the latency response is lower than the threshold, and / or the timeliness is higher than the threshold, that is, the working performance of the second outbound calling robot is better. Such outbound calling robots are not allowed to be offline from the server for a long time, so as to be able to make outbound calls in a timely manner and improve the outbound call efficiency. Further, the ID of the second outbound calling robot can be configured in the dictionary configuration, and then a scheduled task can be set. This scheduled task can be to scan all outbound calling robots at a predetermined interval and update the time of the last outbound call operation of these outbound calling robots. Then, obtain the robot identifier (such as ID) of the second outbound calling robot from the dictionary configuration, and determine the ID of the first outbound calling robot that is offline from the server. If the ID of the first outbound calling robot is the same as the ID of the second outbound calling robot, it means that the first outbound calling robot is the second outbound calling robot, and when the offline duration of the first outbound calling robot is greater than the preset duration, the first outbound calling robot is redeployed on the server to go online again on the server, and the online identifier of the successful deployment of the first outbound calling robot on the server is stored for future use, such as it can be stored in the redis cache.

[0045] It should be noted that, in order to avoid the situation that the redeployed outbound calling robot goes offline from the server again in a short time and improve the usage efficiency of the outbound calling robot, the freeze time (preset threshold) of the outbound calling robot can be reset. Among them, resetting the freeze time of the outbound calling robot means resetting the preset threshold of the outbound calling robot. The reset freeze time of the outbound calling robot can be greater than the originally preset freeze time, avoiding the situation that the redeployed outbound calling robot goes offline from the server again in a short time and improving the usage efficiency of the outbound calling robot. Further, the freeze time can be custom-set according to the number of outbound call tasks. Among them, the number of outbound call tasks is proportional to the reset freeze time, that is, the more the number of outbound call tasks, the longer the freeze time can be reset. The embodiments of the present application do not make any limitations here. In this way, outbound calling robots with high timeliness and low latency response requirements are not allowed to be frozen for a long time, so as to be able to be put into outbound call use in a timely manner, and it can be ensured that outbound calling robots with excellent performance such as high timeliness and low latency response requirements can continuously provide outbound call services, thereby improving the outbound call efficiency.

[0046] Furthermore, a manual processing interface can also be set. If the scheduled task fails, an alarm email can be sent to the designated person, and after the designated person troubleshoots the problem, the scheduled task can be triggered through this manual processing interface, ensuring that abnormal situations can be processed in a timely manner, so that the outbound calling robots for keeping alive can be put into outbound call use in a timely manner, and it can be ensured that outbound calling robots with excellent performance such as high timeliness and low latency response requirements can continuously provide outbound call services, thereby further improving the outbound call efficiency.

[0047] In order to distinguish outbound call tasks corresponding to outbound call robots in the offline state, avoid such outbound call tasks occupying slots in the waiting queue, and improve the outbound call efficiency. In a possible implementation, the outbound call tasks are obtained from the waiting queue. When the status of the target outbound call robot is offline, bringing the target outbound call robot online on the server includes: removing the outbound call task from the waiting queue and adding it to the preheating queue. The waiting queue is a queue storing the first outbound call tasks, and the first outbound call tasks are outbound call tasks waiting to be made and not meeting the outbound call conditions. The preheating queue is a queue storing the second outbound call tasks, and the second outbound call tasks are outbound call tasks that have not entered the queuing waiting. The priority of the first outbound call tasks is higher than that of the second outbound call tasks; obtaining an outbound call task from the preheating queue; bringing the target outbound call robot online on the server through a preset processing method, and caching the online identifier after the target outbound call robot is successfully brought online. The outbound call conditions include but are not limited to reaching the time for the outbound call operation, or it can also be that the outbound call operation in the paused state has not reached the start time, etc.

[0048] Specifically, the preheating queue stores the outbound call tasks of the outbound call robots going offline from the server. For the outbound call tasks in the preheating queue, a timed task can be set to scan the preheating queue at each certain time interval, obtain all the outbound call tasks from the preheating queue, and process each task one by one. Among them, in order to distinguish the waiting queue and the preheating queue, different queue identifiers can be added to the waiting queue and the preheating queue respectively. When the outbound call robot corresponding to the outbound call task is in the offline state, first remove the outbound call task from the waiting queue and add it to the preheating queue to avoid occupying the slots in the waiting queue, then obtain the outbound call task from the preheating queue, determine the target outbound call robot corresponding to the outbound call task, bring the target outbound call robot online from the server through a preprocessing method, and cache the online identifier for next use. Further, the outbound call condition can be reaching the time for the outbound call operation, or it can also be that the outbound call operation in the paused state has not reached the start time. The priority of the first outbound call tasks is higher than that of the second outbound call tasks. When making an outbound call to the outbound call task, the outbound call corresponding to the first outbound call task is given priority.

[0049] Among them, the preset processing method can be a retry strategy, which indicates that the target outbound robot is deployed on the server at a predefined period until the target outbound robot is successfully deployed on the server. That is to say, the target outbound robot is deployed on the server. If the deployment of the target outbound robot on the server fails, the target outbound robot is repeatedly deployed on the server until the target outbound robot is successfully deployed on the server. The time interval between each deployment is a predefined period, such as 30 seconds, 1 minute, etc. In this way, the target outbound robot is deployed on the server at a predefined period until the target outbound robot is successfully launched on the server, which can improve the success rate of the deployment of the target outbound robot on the server, thereby improving the reliability of the target outbound robot to make outbound calls corresponding to outbound tasks. Further, by adding a warm-up queue, the outbound tasks frozen by the outbound robot are placed in the warm-up queue to avoid the outbound tasks frozen by the outbound robot occupying the places in the waiting queue and improve the outbound efficiency.

[0050] Furthermore, in order to avoid the problem that the excessive number of repeated deployments of the target outbound robot on the server affects the outbound efficiency, a retry count threshold can also be set in the preset processing method. If the number of repeated deployments of the target outbound robot on the server exceeds the retry count threshold and the deployment still fails, an alarm email is triggered to prompt the relevant personnel to handle it manually, thereby improving the deployment efficiency of the target outbound robot on the server and further improving the outbound efficiency.

[0051] In a possible implementation manner, in order to ensure that the outbound task can be executed by the target robot in a timely manner, after the target outbound robot is launched on the server through the preset processing method, the method further includes: determining whether there is an online flag of the target outbound robot corresponding to the outbound task in the cache; in the case of the existence of the online flag, removing the outbound task from the warm-up queue and re-adding it to the waiting queue.

[0052] Specifically, it is determined from the cache whether there is an online flag of the target outbound robot corresponding to the outbound task. If there is such an online flag, it means that the target outbound robot has been launched on the server and can be directly used, then the outbound task is put into the waiting queue. The waiting queue scans the tasks in the waiting queue at regular intervals and starts the outbound task to be called by the target outbound robot for its corresponding outbound call. After the frozen outbound robot is launched on the server again, the outbound task is moved from the warm-up queue to the waiting queue to ensure that the outbound task can be executed by the outbound robot in a timely manner and further improve the outbound efficiency of the outbound task being called.

[0053] In a possible implementation, after obtaining the outbound call task from the warm-up queue, the method further includes: determining the task status of the outbound call task in the warm-up queue; in the case where the task status is a non-warm-up status, deleting the outbound call task from the warm-up queue to stop executing the target outbound call task, and the non-warm-up status includes any one of a manual pause status, a terminated status, an automatic pause status, a warning pause status, and a deleted status; determining whether there is an online identifier of the target outbound call robot corresponding to the outbound call task in the cache includes: in the case where the task status is a warm-up status, determining whether there is an online identifier of the second outbound call robot corresponding to the outbound call task in the cache; in the case where there is an online identifier, removing the outbound call task from the warm-up queue and re-adding it to the waiting queue includes: in the case where there is an online identifier, removing the outbound call task from the warm-up queue, changing the task status of the outbound call task from the warm-up status to the not-started status, and then re-adding it to the waiting queue, and the not-started status is used to indicate that the outbound call task has not started making the outbound call corresponding to the outbound call task after being created.

[0054] Specifically, the task status refers to the status of each stage corresponding to the outbound call task. The warm-up status means that the outbound call task in the warm-up queue can be started at any time. The non-warm-up status means that the outbound call task in the warm-up queue will not proceed further and can be directly deleted from the warm-up queue.

[0055] Among them, the manual pause status means that the operation personnel manually pause the outbound call task and stop the outbound call. To resume the outbound call, the outbound call task needs to be manually started by the operation personnel; the terminated status means that the operation personnel manually terminate it, and the terminated outbound call task cannot be restarted; the automatic pause status means that the outbound call task that is automatically paused due to rule restrictions, for example, when it is not within the outbound call time period, the outbound call task will stop the outbound call and automatically restart within the executable time; the warning pause status means that the outbound call task that stops due to an exception during the outbound call process needs to be manually started; the deleted status means that the outbound call task has been deleted. The warm-up status refers to the warm-up pause status: it means that the outbound call robot used by the outbound call task has been frozen, and at this time the outbound call task will be warm-up paused and will restart execution after the outbound call robot is awakened. The not-started status means that the outbound call task has not started making calls after being created.

[0056] Further, when the outbound task is in a non-warm-up state, it means that the outbound task can be temporarily not executed, and it is deleted from the warm-up queue and will not be executed further downward, thus saving server resources and avoiding occupying the quota of the outbound robot. When the outbound task is in a warm-up state, then execute the step of determining whether there is an online identifier in the cache for the target outbound robot corresponding to the outbound task, so as to determine whether to make an outbound call through the target outbound robot, and improve the outbound efficiency. In the case where there is an online identifier, remove the outbound task from the warm-up queue, and change the task status of the outbound task from the warm-up state to the not-started state and then re-add it to the waiting queue, so as to ensure that the outbound task can be successfully executed by the target outbound robot.

[0057] Next, the technical solutions provided by the embodiments of the present application will be described in detail in combination with an application scenario. Among them, taking the intelligent outbound platform in the financial industry as an example, the intelligent outbound platform includes multiple outbound robots and a server.

[0058] As Figure 2A shown, first configure the offline strategy of the outbound robot, which specifically includes:

[0059] Step S201, obtain the usage time of the outbound robot's last outbound operation, and the freezing time pre-configured in the dictionary.

[0060] Step S202, calculate the time interval between the usage time of the outbound robot's last outbound operation and the current system time.

[0061] Step S203, determine whether this time interval is greater than the freezing time configured in the dictionary.

[0062] Step S204, if it is greater than the freezing time, then take the outbound robot offline from the server.

[0063] Step S205, if it is not greater than the freezing time, then do nothing.

[0064] As Figure 2B shown, task warm-up is performed when scheduling outbound tasks, which specifically includes:

[0065] Step S211, the timed task scans the outbound tasks in the waiting queue and determines the ID of the outbound robot used by the outbound task.

[0066] Step S212, according to the ID of the outbound robot used by the outbound task, query whether there is an online identifier (MODEL_robotId_version_modelId) corresponding to this ID in the redis cache.

[0067] Step S213, if this online identifier exists, normally start the outbound task to make an outbound call.

[0068] Among them, if this online identifier exists, it proves that the outbound robot has gone online from the server and can be directly used.

[0069] In step S214, if the identifier does not exist, it proves that the outbound robot has gone offline from the server or the cache has expired. Remove the outbound task from the waiting queue and add it to the warm-up queue.

[0070] In step S215, bring the outbound robot online from the server.

[0071] In step S216, after the outbound robot successfully goes online from the server, the online identifier MODEL_robotId_version_modelId will be added to the cache again. If the outbound robot itself has not gone offline and it is only due to cache expiration, this process can be completed in milliseconds.

[0072] In step S217, when it fails to bring the outbound robot online from the server, add a retry policy. If the retry fails, trigger an alarm email to prompt the relevant management personnel to perform manual online processing.

[0073] Among them, retry three times in total, with a 30-second interval each time.

[0074] As Figure 2C shown, the outbound tasks in the warm-up queue are started regularly, specifically including:

[0075] In step S220, determine the warm-up queue. Among them, if the warm-up queue is not found, search the database again.

[0076] In step S221, add a timed task to execute once every 30 seconds to obtain all outbound tasks from the warm-up queue (queue identifier: PREHEAT_TASK_QUEUE), and perform subsequent steps for each outbound task. Among them, when the status of the outbound task changes to: manual pause, terminated, automatic pause, warning pause, deleted, remove the task from the warm-up task queue and do not proceed further. (Note: Manual pause and warning pause do not need to be added to the waiting queue because they need to be manually operated to start; automatic pause does not need to be added to the waiting queue because the outbound task that has triggered automatic pause is already in the waiting queue; deleted and terminated are non-runable tasks and are directly removed).

[0077] In step S222, determine whether the online identifier: MODEL_robotId_version_modelId of the corresponding outbound robot exists in the cache.

[0078] Step S223, when there is no online flag in the cache, it indicates that the outbound robot has not successfully gone online to the server. The outbound task is put back into the warm-up queue and waits for the execution of the next scheduled task to trigger the outbound robot to go online to the server.

[0079] Step S224, when the online flag exists in the cache, change the status of the outbound task from the warm-up state to the not-started state and re-add it to the waiting queue. The waiting queue will re-awaken the outbound task for execution. The waiting queue scans the existing outbound tasks every 30 seconds, and the executable ones will be started for execution.

[0080] Such as Figure 2D shown, for special robots with high timeliness requirements and low delay response requirements, long-term freezing is not allowed. Periodic warm-up is required to keep the outbound robot in an active state and achieve uninterrupted operation. Specifically, it includes:

[0081] Step S230, add a scheduled task to be executed once at 3:00 am every day, and obtain the ID of the special robot that needs to be kept alive from the dictionary (the special robot that needs to be kept alive refers to the second outbound robot whose offline duration from the server does not exceed the preset duration).

[0082] Step S231, update the last usage time of the outbound robot for the outbound operation, and trigger the outbound robot to go online to the server.

[0083] Step S232, determine whether the outbound robot has successfully gone online.

[0084] Step S233, if so, reset the remaining freezing time of the outbound robot and save the online flag MODEL_robotId_version_modelId to the cache.

[0085] Step S234, if not, add a manual processing interface. When the number of failed executions of the scheduled task exceeds 3 times, send an alarm email to the designated person. After the designated person troubleshoots the problem, manually trigger this operation once to ensure the handling of abnormal situations.

[0086] In addition, corresponding to the telephone outbound method shown above Figure 3 This application embodiment also provides a telephone outbound device. Figure 3 is a schematic structural diagram of a telephone outbound device 300 provided by this application embodiment, including:

[0087] An allocation module 301, configured to allocate a target outbound robot for the outbound task from the outbound robot set when obtaining the outbound task;

[0088] A determination module 302, configured to determine the status of a target outbound calling robot, where the status of the outbound calling robot includes an online status and an offline status, and the offline status is used to indicate that the outbound calling robot goes offline from the server when the time interval between the time of the last outbound call operation and the current time is greater than a preset threshold;

[0089] An online module 303, configured to bring the target outbound calling robot online on the server when the status of the target outbound calling robot is the offline status;

[0090] An outbound calling module 304, configured to make an outbound call to the outbound call corresponding to the outbound call task through the target outbound calling robot.

[0091] It can be seen that for an outbound calling robot, the outbound calling robot whose time interval between the time of the last outbound call operation and the current time is greater than a preset threshold is taken offline from the server. That is to say, when the outbound calling robot does not need to perform an outbound call operation and is not used for a long time, it is taken offline from the server, so as not to occupy the resources of the server invalidly and avoid waste of server resources. When the target outbound calling robot needs to perform an outbound call operation, the target outbound calling robot taken offline from the server is brought back online on the server, so as to use the target outbound calling robot to make an outbound call to the outbound call corresponding to the outbound call task. In this way, it can not only make the outbound call of the outbound call task in time, but also avoid the outbound calling robot from occupying the resources of the server invalidly when not in use, saving the resources of the server and avoiding waste of the resources of the server.

[0092] In a possible implementation manner, it further includes an acquisition module, configured to acquire the time of the last outbound call operation of each outbound calling robot in the outbound calling robot set; take the first outbound calling robot in the outbound calling robot set whose time interval between the time of the last outbound call operation and the current time is greater than a preset threshold offline from the server; determine whether the first outbound calling robot taken offline from the server is a second outbound calling robot according to a pre-configured robot identifier, where the robot identifier is used to indicate that the offline duration of the second outbound calling robot from the server does not exceed a preset duration, and the second outbound calling robot is an outbound calling robot whose working performance meets a preset condition; in the case that the first outbound calling robot is the second outbound calling robot, determine the offline duration of the first outbound calling robot; when the offline duration is greater than the preset duration, bring the first outbound calling robot online on the server and cache an online identifier used to indicate that the first outbound calling robot is successfully online on the server.

[0093] In a possible implementation manner, the determination module 302 is further configured to determine the identity identifier of the target outbound calling robot; query whether there is an online identifier in the cache for the target outbound calling robot, where the online identifier indicates that the target outbound calling robot is in an online state; in the case that the online identifier does not exist, determine the status of the target outbound calling robot as the offline status.

[0094] In a possible implementation, the online module 303 is further configured to remove the outbound call task from the waiting queue and add it to the warm-up queue. The waiting queue is a queue storing the first outbound call tasks, where the first outbound call tasks are outbound call tasks that are queuing up waiting for outbound call operations and do not meet the outbound call conditions. The warm-up queue is a queue storing the second outbound call tasks, where the second outbound call tasks are outbound call tasks that have not entered the queuing waiting state. The priority of the first outbound call tasks is higher than that of the second outbound call tasks. Obtain the outbound call task from the warm-up queue; online the target outbound call robot to the server through a preset processing method, and cache the online identifier after the target outbound call robot is successfully online.

[0095] In a possible implementation, the determination module 302 is further configured to determine whether there is an online identifier of the target outbound call robot corresponding to the outbound call task in the cache; in the case where there is an online identifier, remove the outbound call task from the warm-up queue and re-add it to the waiting queue.

[0096] In a possible implementation, the determination module 302 is further configured to determine the task status of the outbound call task in the warm-up queue; in the case where the task status is a non-warm-up state, delete the outbound call task from the warm-up queue to stop executing the target outbound call task. The non-warm-up state includes any one of the manual pause state, the terminated state, the automatic pause state, the warning pause state, and the deleted state. The determination module 302 is further configured to, in the case where the task status is a warm-up state, determine whether there is an online identifier of the second outbound call robot corresponding to the outbound call task in the cache; in the case where there is an online identifier, removing the outbound call task from the warm-up queue and re-adding it to the waiting queue includes: in the case where there is an online identifier, removing the outbound call task from the warm-up queue, changing the task status of the outbound call task from the warm-up state to the not-started state, and then re-adding it to the waiting queue. The not-started state is used to indicate that the outbound call task has not started making the outbound call corresponding to the outbound call task after being created.

[0097] In a possible implementation, the outbound call module 304 is further configured to scan each outbound call task in the waiting queue at a predefined period, add the outbound call tasks that meet the outbound call conditions to the running queue. The running queue is a queue storing the outbound call tasks that meet the outbound call conditions; if the outbound call task is in the running queue, use the target outbound call robot to make the outbound call corresponding to the outbound call task.

[0098] Obviously, the telephone outbound call device disclosed in the embodiments of the present application can be used as the execution subject of the telephone outbound call method shown in the above embodiments, and thus can implement the functions achieved by the telephone outbound call method in the above embodiments. Since the principles are the same, they will not be elaborated here.

[0099] Figure 4It is a schematic structural diagram of an electronic device according to an embodiment of this specification. Please refer to Figure 4 , at the hardware level, the electronic device includes a processor, and optionally also includes an internal bus, a network interface, and a memory. Among them, the memory may include a memory, such as a high-speed random access memory (Random-Access Memory, RAM), and may also include a non-volatile memory, such as at least one disk memory, etc. Of course, the electronic device may also include other hardware required for other services.

[0100] The processor, network interface, and memory can be interconnected through an internal bus, and the internal bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of simplicity of representation, Figure 4 only a bidirectional arrow is used in

[0101] but it does not mean that there is only one bus or one type of bus.

[0102] The memory is used to store programs. Specifically, the program may include program code, and the program code includes computer operation instructions. The memory may include a memory and a non-volatile memory, and provide instructions and data to the processor.

[0103] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a telephone outbound calling device at the logical level. The processor executes the program stored in the memory and is specifically used to execute the telephone outbound calling method mentioned in any of the above method embodiments.

[0103] As described above in this specification Figure 1The method executed by the outbound call device disclosed in the illustrated embodiment can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, the steps of the above method can be completed by the integrated logic circuit of the hardware in the processor or the instructions in the form of software. The above processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. It can implement or execute the various methods, steps, and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the embodiments of the present application can be directly embodied as being executed and completed by the hardware decoding processor, or executed and completed by the combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method.

[0104] It should be understood that the electronic device in the embodiments of the present application can implement the functions of the outbound call device in Figure 1 the illustrated embodiment. Since the principle is the same, it will not be repeated in the embodiments of the present application.

[0105] Of course, in addition to the software implementation, the electronic device in this specification does not exclude other implementation manners, such as a logic device or a combination of software and hardware, etc. That is to say, the execution subject of the following processing flow is not limited to each logic unit, and may also be hardware or a logic device.

[0106] The embodiments of the present application also propose a computer-readable storage medium that stores one or more programs. The one or more programs include instructions that, when executed by a portable electronic device including a plurality of application programs, can enable the portable electronic device to execute the outbound call method of any of the above embodiments.

[0107] The above describes specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired results. Additionally, the processes depicted in the figures do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain implementations, multitasking and parallel processing are also possible or may be advantageous.

[0108] In summary, the above are only the preferred embodiments of this specification and are not intended to limit the scope of protection of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of this specification shall be included within the scope of protection of this specification.

[0109] The systems, devices, modules, or units illustrated in the above embodiments may be specifically implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0110] Computer-readable media includes both permanent and non-permanent, removable and non-removable media and can be implemented by any method or technology for information storage. The information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transitory media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory computer-readable media such as modulated data signals and carrier waves.

[0111] It should also be noted that the terms "comprise", "include" or any other variant thereof are intended to cover non-exclusive inclusion, such that a process, method, commodity or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, commodity or device. Without further limitation, an element defined by the statement "comprising an..." does not exclude the presence of additional identical elements in the process, method, commodity or device comprising the element.

[0112] Each embodiment in this specification is described in a progressive manner. For the identical or similar parts among the embodiments, reference can be made to each other, and the differences between each embodiment and other embodiments are emphasized. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and reference can be made to the relevant part of the method embodiment for the relevant content.

Claims

1. A telephone outbound calling method, characterized in that, it includes: When obtaining an outbound calling task, allocate a target outbound calling robot for the outbound calling task from a set of outbound calling robots; Determine the status of the target outbound calling robot, where the status of the outbound calling robot includes an online status and an offline status, and the offline status is used to indicate that the outbound calling robot goes offline from the server when the time interval between the last outbound calling operation time and the current time is greater than a preset threshold; When the status of the target outbound calling robot is the offline status, bring the target outbound calling robot online on the server; Make an outbound call to the outbound call corresponding to the outbound calling task through the target outbound calling robot.

2. The telephone outbound calling method according to claim 1, characterized in that, the method further includes: Obtain the time of the last outbound calling operation of each outbound calling robot in the set of outbound calling robots; Take offline from the server the first outbound calling robot in the set of outbound calling robots whose time interval between the last outbound calling operation time and the current time is greater than the preset threshold; Determine whether the first outbound calling robot taken offline from the server is a second outbound calling robot according to a pre-configured robot identifier, where the robot identifier is used to indicate that the offline duration of the second outbound calling robot from the server does not exceed a preset duration, and the second outbound calling robot is an outbound calling robot whose working performance meets preset conditions; When the first outbound calling robot is the second outbound calling robot, determine the offline duration of the first outbound calling robot; When the offline duration is greater than the preset duration, bring the first outbound calling robot online on the server and cache an online identifier indicating that the first outbound calling robot has been successfully brought online on the server.

3. The telephone outbound calling method according to claim 1, characterized in that, the determination of the status of the target outbound calling robot includes: Determine the identity identifier of the target outbound calling robot; Query whether there is an online identifier in the cache for the target outbound calling robot according to the identity identifier, where the online identifier indicates that the target outbound calling robot is in an online status; When the online identifier does not exist, determine that the status of the target outbound calling robot is the offline status.

4. The telephone outbound calling method according to claim 3, characterized in that, the outbound calling task is an outbound calling task obtained from a waiting queue, and when the status of the target outbound calling robot is the offline status, bringing the target outbound calling robot online on the server includes: Remove the outbound calling task from the waiting queue and add it to a preheating queue, where the waiting queue is a queue storing first outbound calling tasks, the first outbound calling tasks are outbound calling tasks that are queuing up waiting for an outbound calling operation and do not meet the outbound calling conditions, the preheating queue is a queue storing second outbound calling tasks, the second outbound calling tasks are outbound calling tasks that have not entered the queuing waiting, and the priority of the first outbound calling tasks is higher than that of the second outbound calling tasks; Obtain the outbound calling task from the preheating queue; The target outbound robot is launched onto the server through a preset processing method, and an online identifier is cached after the target outbound robot is successfully launched.

5. The telephone outbound method according to claim 4, wherein, after the target outbound robot is launched onto the server through the preset processing method, the method further includes: determining whether an online identifier exists in the cache for the target outbound robot corresponding to the outbound task; when the online identifier exists, removing the outbound task from the warm-up queue and readding it to the waiting queue.

6. The telephone outbound method according to claim 5, wherein, after obtaining the outbound task from the warm-up queue, the method further includes: determining the task status of the outbound task in the warm-up queue; when the task status is a non-warm-up status, deleting the outbound task from the warm-up queue to stop executing the outbound task, and the non-warm-up status includes any one of a manual pause status, a terminated status, an automatic pause status, a warning pause status, and a deleted status; the determining whether an online identifier exists in the cache for the target outbound robot corresponding to the outbound task includes: when the task status is a warm-up status, determining whether an online identifier exists in the cache for a second outbound robot corresponding to the outbound task; when the online identifier exists, the removing the outbound task from the warm-up queue and readding it to the waiting queue includes: removing the outbound task from the warm-up queue, changing the task status of the outbound task from the warm-up status to an unstarted status, and then readding it to the waiting queue, and the unstarted status is used to indicate that the outbound call corresponding to the outbound task has not been made after the outbound task is created.

7. The telephone outbound method according to claim 6, wherein, the making an outbound call to the outbound call corresponding to the outbound task through the target outbound robot includes: scanning each outbound task in the waiting queue at a predefined period, and adding the outbound tasks that meet the outbound conditions to a running queue, and the running queue is a queue for storing outbound tasks that meet the outbound conditions; if the outbound task is in the running queue, using the target outbound robot to make an outbound call to the outbound call corresponding to the outbound task.

8. A telephone outbound device, wherein, it includes: an allocation module, configured to allocate a target outbound robot for the outbound task from a set of outbound robots when obtaining the outbound task; a determination module, configured to determine the status of the target outbound robot, wherein the status of the outbound robot includes an online status and an offline status, and the offline status is used to indicate that the outbound robot goes offline from the server when the time interval between the time of the last outbound operation and the current time is greater than a preset threshold; an online module, configured to launch the target outbound robot onto the server when the status of the target outbound robot is the offline status; an outbound module, configured to make an outbound call to the outbound call corresponding to the outbound task through the target outbound robot.

9. An electronic device, characterized in that, comprising: a processor; a memory for storing executable instructions of the processor; wherein the processor is configured to execute the instructions to implement the outbound call method according to any one of claims 1 to 7.

10. A computer-readable storage medium, when the instructions in the storage medium are executed by a processor of an electronic device, to implement the outbound call method according to any one of claims 1 to 7.

Images