Hotline traffic resource scheduling method and device, electronic equipment and storage medium

Abstract

The application relates to a hotline traffic resource scheduling method and device, electronic equipment and a storage medium, and relates to the technical field of communication operation management. The method comprises the following steps: determining and dynamically updating a benchmark index for representing a regular traffic level based on historical traffic volume under the same time characteristics in a historical period; collecting a plurality of real-time indexes representing current traffic load and operating state in real time; calculating at least one core parameter for early warning judgment based on the plurality of real-time indexes and the benchmark index; performing threshold comparison and state persistence checking on the at least one core parameter, and triggering a corresponding traffic pressure warning level according to the checking result; and according to the traffic pressure warning level, progressively scheduling hotline traffic resources according to a preset scheduling strategy with gradient difference. The application can realize intelligent, accurate and efficient response to sudden traffic, and significantly improve system operation efficiency and user experience.

Description

Technical Field

[0001] This invention relates to the field of communication operation management technology, and in particular to a method, apparatus, electronic device and storage medium for hotline call resource scheduling. Background Technology

[0002] Call dispatch is a crucial tool for hotline call management, with the core objective of preventing call congestion and excessively long user wait times. By dynamically and rationally matching call volume with agent resources, it's possible to reduce negative user experiences such as queuing, busy lines, and repeated dialing, thereby effectively controlling negative user emotions and improving the timeliness of addressing user requests.

[0003] Traditional hotline call dispatching methods typically predict call volume for a future period (such as the next hour or day) based on historical data, and then combine this with the current available manpower to predict whether the connection rate can meet the target. If the prediction fails to meet the target, adjustments are made according to preset, relatively fixed dispatching rules, such as allocating manpower from other teams for support.

[0004] The aforementioned traditional solutions suffer from two main problems: First, their scheduling decisions rely on predictions based on historical data, while actual call volume may experience unpredictable and sudden fluctuations. When actual call volume significantly exceeds predictions, insufficient pre-allocated manpower may prevent the target connection rate from being achieved, leading to system overload. Second, traditional solutions typically employ fixed scheduling rules, which may result in excessive resource allocation and waste during mild overload, or insufficient resource allocation and slow response during severe overload, failing to quickly alleviate congestion and thus negatively impacting user experience for an extended period. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a method, apparatus, electronic device and storage medium for hotline call resource scheduling.

[0006] The technical solution of the present invention to solve the above-mentioned technical problems is as follows: In a first aspect, the present invention provides a hotline call resource scheduling method, which adopts the following technical solution: A method for scheduling hotline call resources, comprising: Based on historical call volume under the same time characteristics within a historical period, a benchmark indicator for characterizing the level of routine call volume is determined and dynamically updated. It collects multiple real-time indicators that characterize the current call load and operating status. Based on the multiple real-time indicators and the benchmark indicators, at least one core parameter for early warning determination is calculated. The threshold comparison and status persistence verification of at least one core parameter are performed, and the corresponding traffic pressure warning level is triggered based on the verification result; Based on the aforementioned call load warning level, hotline call resources are progressively scheduled according to a preset scheduling strategy with tiered differences.

[0007] The beneficial effects of this invention are as follows: By establishing and dynamically updating benchmark indicators, combined with the collection and calculation of multi-dimensional real-time indicators, the deviation of call load from the normal level can be accurately perceived, thereby overcoming the shortcomings of traditional methods that rely on historical predictions and ignore real-time fluctuations. Furthermore, by triggering tiered early warnings through parameter threshold comparison and state persistence verification, transient interference is effectively filtered, ensuring the accuracy and robustness of the early warnings. Based on this, according to the severity of the early warning level, a preset scheduling strategy with gradient differences is executed to progressively schedule hotline call resources, achieving precise matching and efficient utilization of resource scheduling. This avoids resource waste during low loads and prevents insufficient response during high loads, thereby significantly improving the operational efficiency, service resilience, and user experience of the hotline system.

[0008] Based on the above technical solution, the present invention can be further improved as follows.

[0009] Furthermore, the step of performing threshold comparison and status persistence verification on the at least one core parameter, and triggering the corresponding traffic pressure warning level based on the verification result, includes: For each of the aforementioned call load warning levels, a preset threshold and observation window duration are defined for the at least one core parameter that triggers a warning at that call load warning level. Monitor the value of at least one core parameter within its respective observation window duration; If at least one core parameter is detected and its value continuously meets the parameter threshold corresponding to the call pressure warning level within the corresponding observation window duration, then the corresponding call pressure warning level is triggered.

[0010] The beneficial effects of adopting the above-mentioned further solution are as follows: By presetting differentiated parameter thresholds and observation window durations for each warning level, refined and standardized identification of call pressure of different severity levels is achieved. By monitoring the continuous performance of core parameters throughout the entire observation window, rather than relying on snapshots at a single moment, the system can effectively filter false alarms caused by instantaneous fluctuations or occasional data anomalies, ensuring the accuracy and reliability of warning signals. Ultimately, a warning for the corresponding level will only be triggered when one or more core parameters stably and continuously cross the judgment boundary of a certain level. In this way, the intelligence, robustness, and anti-interference capability of the warning system can be improved, ensuring that the initiation of scheduling response is based on real and continuous call pressure, and avoiding the ineffective allocation of resources due to false alarms.

[0011] Furthermore, the step of progressively scheduling hotline call resources according to the call pressure warning level and a preset, tiered scheduling strategy includes: When any of the aforementioned call pressure warning levels is triggered, an initial scheduling action preset for the aforementioned call pressure warning level is executed to schedule the corresponding hotline call resources; The following steps will be executed repeatedly until the traffic pressure warning level is lifted, at which point the progressive scheduling will stop: After executing the current scheduling action, monitor the queuing status during a preset observation period; If the queuing status is still detected at the end of the observation period, the next scheduling action preset for the call pressure warning level will be executed to schedule the hotline call resources of the next level. If the queuing state is detected to have been lifted at the end of the observation period, then the first duration of the queuing state being lifted is recorded. If the first duration exceeds the preset duration, the call load warning level is lifted; The preset scheduling action sequence for each of the call pressure warning levels is arranged sequentially according to the gradient defined by the team scope of the scheduled hotline call resources.

[0012] The beneficial effects of adopting the above-mentioned further scheme are as follows: Starting with triggering an early warning, a preset initial scheduling action is immediately executed. Subsequently, a progressive loop based on real-time feedback is entered: after each scheduling, an observation period is initiated to monitor the queuing status. If the queue still exists at the end of the observation period, it indicates that the current scheduling intensity is insufficient, and the next scheduling action under that warning level is automatically executed to mobilize a wider range of resources at the next lower tier. This process will continue to cycle until the queuing pressure is effectively resolved. When the queuing status is detected to be resolved, the warning will not be immediately terminated, but will instead enter a stability confirmation phase. Only after the queue-resolved status has remained stable for a preset duration will the warning be officially lifted. This ensures that the initiation, escalation, and termination of scheduling actions are strictly based on the objective and real-time operational indicator of the queuing status, achieving precise matching, orderly deployment, and robust control of resource scheduling, thereby significantly improving response efficiency and avoiding ineffective resource consumption.

[0013] Furthermore, the method also includes: Monitor the second duration of the call load warning level from the time it is triggered; If the second duration exceeds the preset maximum warning duration and the call load warning level is still not lifted, an outbound call notification will be sent to off-duty personnel who are not currently in the dispatch action sequence to encourage them to return to work within the preset recall time.

[0014] The beneficial effects of adopting the above-mentioned further solution are as follows: when the regular on-duty and backup resources are still unable to alleviate the call volume pressure after continuous scheduling, resulting in the warning remaining in place for an extended period, the system can automatically activate and extend the scheduling scope to off-duty personnel. By sending outbound call notifications to off-duty personnel and requiring them to report to work within a specified time, the mobilization and emergency deployment of potential human resources can be maximized. This ensures that even in the face of extreme and prolonged call volume peaks, the system still possesses ultimate elastic expansion capabilities, providing final manpower coverage for city user access channels. This greatly enhances the continuity and reliability of hotline services in the face of rare emergencies, avoiding the risk of service interruption due to the depletion of regular resources.

[0015] Furthermore, the determination and dynamic updating of benchmark indicators for characterizing routine call volume levels based on historical call volume under the same time characteristics within a historical period includes: Collect the historical call volume of the same time block of each day in each week within the historical period as the historical traffic volume; Based on the collected historical call volumes, the average historical call volume for each time block of each day in a week is calculated as the benchmark indicator to form a benchmark call volume database. The baseline metrics are periodically recalculated using newly added historical call volume data, and the baseline call volume database is updated using the recalculated baseline metrics.

[0016] The beneficial effects of adopting the above-mentioned further solution are as follows: By collecting and calculating the average historical call volume under the same time characteristics within a historical period, a quantifiable benchmark value is generated, which forms a benchmark call volume database. Periodically refreshing the benchmark value using the latest generated call volume data ensures that the established benchmark can closely track the actual patterns of business development and avoids misjudgments caused by outdated reference data.

[0017] Furthermore, the real-time collection of multiple real-time indicators characterizing the current call load and operating status includes: Real-time data collection includes current incoming call volume, current queue volume, current number of people answering calls, current number of times a live agent connects, current number of incoming calls to live agents, and current call loss.

[0018] The beneficial effects of adopting the above-mentioned further solution are: real-time collection of current inbound call volume, current queue volume, current number of people answering calls, current number of times a human agent connects, current number of times a human agent makes inbound calls, and current call loss volume. The combination of these six real-time indicators constitutes a complete observation chain from inbound traffic, internal status, service output to final loss, which can ensure that the early warning judgment is based on a comprehensive and real-time accurate perception of the hotline system's status.

[0019] Furthermore, the at least one core parameter includes at least one of the following: call volume ratio, queue volume ratio, manual connection rate, and call loss rate, wherein the benchmark indicator is the benchmark call volume; The calculation of at least one core parameter for early warning determination based on the multiple real-time indicators and the benchmark indicators includes at least one of the following steps: Calculate the ratio of the current inbound call volume to the corresponding baseline call volume in the baseline call volume database, and use this ratio as the call volume ratio value; Calculate the ratio of the current queue size to the current number of people answering calls, and use this ratio as the queue size percentage; The ratio of the current number of calls connected to the current number of incoming calls to a human agent is calculated as the human agent connection rate. The current call loss is determined as the call loss.

[0020] The beneficial effects of adopting the above-mentioned further solutions are as follows: by calculating the call volume ratio, the deviation of the current call volume from the historical normal level can be quantified; by calculating the queuing volume ratio, the real-time congestion pressure within the system can be standardized for assessment; by calculating the manual connection rate, the real-time efficiency and quality of the service can be accurately measured; and by directly using the call loss volume, the service failure results caused by system overload can be objectively reflected; providing clear, reliable and quantifiable direct input for subsequent intelligent early warning judgment.

[0021] Secondly, the present invention provides a hotline call resource scheduling device, which adopts the following technical solution: A hotline call resource scheduling device, comprising: The benchmark determination module is used to determine and dynamically update benchmark indicators that characterize the level of normal call volume based on historical call volume under the same time characteristics within a historical period. The real-time acquisition module is used to collect multiple real-time indicators that characterize the current call load and operating status. The parameter calculation module is used to calculate at least one core parameter for early warning determination based on the multiple real-time indicators and the benchmark indicators. The early warning triggering module is used to perform threshold comparison and status persistence verification on at least one core parameter, and trigger the corresponding call pressure early warning level based on the verification result; The resource scheduling module is used to progressively schedule hotline call resources according to the call pressure warning level and a preset scheduling strategy with gradient differences.

[0022] Thirdly, the present invention provides an electronic device that adopts the following technical solution: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements the hotline call resource scheduling method as described in any of the first aspects.

[0023] Fourthly, the present invention provides a computer-readable storage medium, which adopts the following technical solution: A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the hotline traffic resource scheduling method as described in any of the first aspects.

[0024] Additional aspects and advantages of the invention will be set forth in part in the description which follows, and will become apparent from the description or may be learned by practice of the invention. Attached Figure Description

[0025] Figure 1 A flowchart illustrating the hotline call resource scheduling method provided by the present invention; Figure 2 A schematic diagram illustrating the update process of the benchmark call volume database provided by this invention; Figure 3 This invention provides a schematic diagram of the call load warning level triggering process. Figure 4 This is a schematic diagram of the hierarchical scheduling process for hotline call resources provided by the present invention; Figure 5 This is a schematic diagram of the hotline call resource scheduling device provided by the present invention; Figure 6 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0026] The principles and features of the present invention are described below. The examples given are only for explaining the present invention and are not intended to limit the scope of the present invention.

[0027] Please refer to Figure 1 , Figure 1 This is a flowchart illustrating the hotline call resource scheduling method provided by the present invention. Figure 1 As shown, the method may include the following steps S101-S105.

[0028] S101. Based on historical call volume under the same time characteristics within a historical period, determine and dynamically update the benchmark indicators used to characterize the level of regular call volume.

[0029] Specifically, the historical period refers to a fixed-length data collection window pre-set for establishing a benchmark and used to retrospectively analyze historical call volume. For example, a historical period of 8 weeks means continuously taking the complete historical call volume of the most recent 8 weeks for calculation. On the one hand, this ensures that the data sample size used for calculation is large enough to effectively smooth out occasional short-term fluctuations through statistical analysis, thereby reflecting stable operational patterns. On the other hand, through rolling updates, it ensures that the benchmark model can dynamically follow the long-term trends and seasonal changes in business development, maintaining its accurate representation of normal call volume levels and providing a reliable reference for subsequent real-time early warning.

[0030] The same time feature refers to the specific time tag used when dividing and matching historical call data. This tag can be defined by the day of the week and a time block within a day. For example, the time period of 10:10-10:15 every Monday constitutes a time unit with the same time feature, and historical call data of the same "Monday 10:10-10:15" from different weeks can be compared and calculated together.

[0031] Historical call volume refers to the actual number of calls received by the hotline system within each time unit with the same time characteristics in a historical period (e.g., historical call volume).

[0032] The benchmark metric is a quantitative reference value calculated from historical call volume (such as historical call volume) with similar time characteristics within a statistical period. It is used to characterize the expected normal call volume level under the absence of sudden interference. This metric is dynamically updated; for example, it can be automatically recalculated and refreshed using new call volume data for the past 8 weeks generated weekly. In this way, the benchmark metric can continuously track long-term patterns such as business development, seasonal changes, and evolution of workday patterns, thereby avoiding delayed warnings or misjudgments caused by a fixed reference system. It ensures that the determination of whether there is an abnormal surge in real-time call volume is always based on a stable and reliable reference standard that reflects the latest normal state.

[0033] This step first establishes a historical data backtracking timeframe and, based on pre-defined time alignment rules, extracts all historical call volume data within that timeframe that exhibits the same time characteristics. Next, a quantified value is calculated based on these selected historical call volume data points with consistent time characteristics. This value represents the expected call volume level for that time characteristic under normal operating conditions. To ensure the timeliness and accuracy of this benchmark, a periodic automatic update mechanism can be established to periodically recalculate and calibrate the benchmark value. Ultimately, a dynamic reference system that continuously reflects regular operational patterns is constructed and maintained.

[0034] In one embodiment, such as Figure 2 As shown, step S101 may include the following sub-steps S201-S203.

[0035] S201. Collect the historical call volume of the same time block of each day in each week within the historical period as the historical call volume.

[0036] For example, the entire day can be divided into 288 equal-length time blocks of fixed duration (e.g., 5 minutes). Each time block can be marked with its start time, end time, or other unique identifier, such as 1015 corresponding to 10:10-10:15. In practice, a historical period (e.g., the past 8 weeks) can be set, and historical call volume data occurring in the same time block on the same day each week within this period can be collected as the historical call volume for constructing a baseline.

[0037] S202. Based on the collected historical call volume, calculate the average historical call volume for each time block of each day in a week, and use it as a benchmark indicator to form a benchmark call volume database.

[0038] For example, after data collection is completed, historical call volumes collected over the past 8 weeks for the same time block on Mondays (e.g., 10:10-10:15 each day) are aggregated and their average value is calculated. This average value serves as the baseline call volume for the 10:10-10:15 time block on Mondays, thus calculating the baseline call volume for all time blocks on Mondays. Similarly, the baseline call volume for each corresponding time block from Tuesday to Sunday can be calculated separately. In this way, a baseline value is established for each day of the week and each fine-grained time block, thereby constructing a baseline call volume database.

[0039] S203. Periodically recalculate the benchmark indicators using newly added historical call volume data, and update the benchmark call volume database using the recalculated benchmark indicators.

[0040] For example, at a fixed time each week (e.g., early Sunday morning), the historical call volume data generated in the latest week is added to the calculation, while the historical call volume data from the earliest week is simultaneously removed, thus always using the latest, continuous 8 weeks of historical call volume data as the basis for calculation. Subsequently, based on this new set of 8 weeks of historical call volume data, the baseline call volume for each time block in the coming week is recalculated. Finally, these recalculated baseline values, reflecting the latest operational patterns, are used to update the corresponding old records in the baseline call volume database. This allows the baseline call volume database to continuously and sensitively track changes in actual call volume patterns, achieving true dynamic updates and providing a consistently reliable reference benchmark for real-time early warning.

[0041] It should be noted that the baseline call volume database can also be used to guide call scheduling, specifically including: 1) Data Extraction: Export core data B for the target period (e.g., next week) from the dynamic benchmark database. ij (i takes values ​​from 1 to 7, representing Monday to Sunday; j takes values ​​from 1 to 288, representing 288 five-minute time blocks in a day), which is the regular baseline call volume for the same week and time period over the past 8 weeks; 2) Parameter presets: Three types of key parameters can be customized according to the hotline type: Single agent's 5-minute processing capacity C: Calculated from average call duration and average post-call processing time; Target connection rate R: ≥95% for normal use (≥98% for high call volume hotlines, ≥90% for low call volume hotlines); Natural fluctuation coefficient K: Set according to the fluctuation intensity of different time periods (1.2-1.3 for peak periods, 1.0-1.1 for flat periods, default global value is 1.15). 3) Data Verification: Remove outliers from the baseline call volume database (such as abnormal call volumes caused by sudden disasters) to ensure B ij It conforms to the daily call volume pattern; if data for a certain time block is missing, it is supplemented with the average of adjacent time periods in the same week. 4) Calculate the standard shift schedule S ij Based on the baseline call volume, calculate the minimum number of agents required to achieve the target connection rate. The calculation formula is: S ij= ceil(B ij / C*R), where ceil() is the rounding function to avoid decimal seats and ensure that the minimum call completion rate is met.

[0042] 5) Calculate the fluctuation buffer scheduling quantity S ’ ij To compensate for natural fluctuations in call volume, redundant manpower is added. The final shift scheduling formula is: S ’ ij= ceil(S ij *K).

[0043] Through the above steps, a refined scheduling plan that meets service quality objectives and includes reasonable redundancy can be scientifically calculated based on dynamic benchmarks and historical patterns, providing a data-driven decision-making basis for the daily human resource planning of hotline operations.

[0044] S102. Real-time collection of multiple real-time indicators representing the current call load and operating status.

[0045] Specifically, collecting a set of real-time indicators that reflect the current call load and operating status of the hotline system in real time and in multiple dimensions can ensure that subsequent early warning and scheduling decisions are based on a comprehensive and timely understanding of the current situation, rather than entirely based on predictions or historical experience. This solves the core problem of traditional methods relying on historical predictions and ignoring real-time fluctuations.

[0046] In one embodiment, step S102 may include: real-time collection of current incoming call volume, current queue volume, current number of people answering calls, current number of times a human agent connects, current number of incoming calls by a human agent, and current call loss.

[0047] Specifically, six real-time indicators representing the current call load and operational status are collected in real time.

[0048] 1) Current Inbound Calls: The total number of user calls received by the hotline system within the most recent collection period (e.g., the past 5 minutes), used to monitor the instantaneous inflow rate of citizen requests. This is the most direct and core indicator for sensing call load, reflecting the magnitude of input pressure from the demand side.

[0049] 2) Current queue size: At the moment of data collection, the number of users waiting in the queue to be answered by a human agent, which is also the amount of pending requests currently backed up in the hotline system. This metric directly reflects the real-time congestion status of the hotline system.

[0050] 3) Current number of operators answering calls: The total number of human agents actually handling calls at the moment of data collection. This represents the current available human resources supply capacity of the hotline system and is a key indicator for assessing its load-bearing capacity.

[0051] 4) Current number of calls connected by human agents: The number of calls successfully connected and service initiated by human agents within the most recent data collection period. This is a positive indicator for measuring service output and efficiency.

[0052] 5) Current number of incoming calls to human agents: The total number of calls that rang and were assigned to the human agent queue within the most recent data collection period (including those answered, those abandoned after being queued, and those that rang but were not answered). This metric is a key indicator for calculating service success rate.

[0053] 6) Current Call Loss: The number of calls that users hung up before being able to connect to a live agent due to reasons such as queuing timeouts or giving up waiting in the most recent data collection period. This metric is a result-oriented indicator reflecting service failures and negative user experiences, directly reflecting the losses caused by overload.

[0054] These six real-time indicators together form a complete observation chain from inbound traffic, internal status, service output to final loss: 1) Inbound traffic: Directly reflected by the current inbound call volume, it characterizes the real-time influx of external demand and is the starting point of the entire chain; 2) Internal status: Characterized by the current queue volume and the current number of people answering calls, it reflects the immediate congestion level of the hotline system and the current supply level of available human resources, revealing the real-time processing and capacity status of the hotline system; 3) Service output: Evaluated by the current number of times agents connect and the current number of calls made by agents. The combination of these two can calculate core indicators of service efficiency and quality (such as connection rate), reflecting the actual service capacity and results of the hotline system under a given load; 4) Final loss: Quantified by the current call loss volume, it directly reflects service failures caused by insufficient processing capacity or untimely response of the hotline system, and is a key endpoint indicator for assessing the consequences of overload and the damage to user experience. In this way, it can be ensured that the early warning judgment is based on a comprehensive and accurate perception of the hotline system's real-time status.

[0055] S103. Based on multiple real-time indicators and benchmark indicators, at least one core parameter for early warning determination is calculated.

[0056] Specifically, multiple real-time indicators collected in real time are combined with dynamically updated benchmark indicators to transform them into at least one core parameter that can more directly and effectively measure the degree of call traffic anomalies.

[0057] In one embodiment, at least one core parameter includes at least one of call volume ratio, queue volume ratio, human agent connection rate, and call loss, with the benchmark indicator being the benchmark call volume; step S103 may include at least the following steps: calculating the ratio of the current incoming call volume to the benchmark call volume corresponding to the benchmark call volume database as the call volume ratio; calculating the ratio of the current queue volume to the current number of people answering calls as the queue volume ratio; calculating the ratio of the current number of times a human agent connects to the current number of times a human agent makes incoming calls as the human agent connection rate; and determining the current call loss as the call loss.

[0058] Specifically, the call volume ratio = current inbound call volume / baseline call volume. The call volume ratio is used to measure the degree of deviation of the current real-time call volume from the historical normal level. It can effectively identify sudden call volume peaks, distinguish them from normal fluctuations during daily peak periods, and achieve early identification of sudden increases in call volume.

[0059] Queueing volume percentage = current queueing volume / current number of callers. Queueing volume percentage is used to quantify the real-time congestion status and resource shortage of the hotline system. It can convert absolute values ​​into relative pressure values ​​and adapt to congestion assessment under different sizes of call centers.

[0060] The human connection rate = (Number of calls connected to human agents / Number of incoming calls to human agents). The human connection rate measures the immediate service capability of the hotline system. When the human connection rate declines, it means that existing resources are no longer sufficient to meet current call demands, and the hotline system's service capability begins to deteriorate. It is a key parameter reflecting a decline in service quality.

[0061] Call loss is used to monitor whether the hotline system has reached or exceeded its maximum capacity. In particular, call loss exceeding the queue limit means that calls that cannot enter the queue are lost due to channel congestion. This is an extreme signal of hotline system overload and must trigger the highest level of response.

[0062] In this way, multiple real-time indicators collected in real time and dynamically updated benchmark indicators can be transformed into standardized indicators that can sensitively and comprehensively characterize the system status and risks from four core dimensions: traffic anomalies, internal congestion, service efficiency, and final loss. This provides clear, reliable, and quantifiable direct input for subsequent intelligent early warning judgments.

[0063] It should be noted that this embodiment offers high flexibility and configurability in the selection and use of core parameters. The defined call volume ratio, queue share, human connection rate, and call loss rate can be used individually or in any combination. This allows the solution to flexibly adapt to the monitoring needs, resource conditions, and operational maturity of different hotline systems. For example, in the initial stage, the call volume ratio can be deployed first to quickly detect sudden increases in call volume; as the system improves, the queue share and human connection rate can be gradually increased to more finely assess the internal status and service efficiency; in the advanced stage, all four indicators can be integrated to achieve comprehensive and multi-dimensional monitoring of the system's health status.

[0064] S104. Perform threshold comparison and status continuity verification on at least one core parameter, and trigger the corresponding call pressure warning level based on the verification result.

[0065] Specifically, different threshold levels are preset for each core parameter, and the performance of the core parameter is monitored over a continuous period of time, rather than simply judging its value at a single sampling point. Only when the value of a core parameter consistently meets the threshold condition for a certain traffic pressure warning level within the set duration will the corresponding warning be triggered. This dual judgment method of threshold comparison and status persistence verification effectively filters false alarms caused by instantaneous fluctuations, data spikes, or minor fluctuations, ensuring that the triggered warnings truly reflect the persistent traffic pressure, thereby significantly improving the accuracy, stability, and reliability of the warnings. Ultimately, a clear, tiered traffic pressure warning signal is output.

[0066] In one embodiment, such as Figure 3As shown, step S104 may include the following sub-steps S301-S303.

[0067] S301. For each call pressure warning level, preset at least one core parameter, which is the parameter threshold and observation window duration corresponding to triggering the warning under the call pressure warning level.

[0068] For example, for a yellow alert, the following thresholds can be preset: the call volume ratio threshold is 1 and 1.5 times, the queue volume ratio threshold is 5%, the manual connection rate threshold is 95%, and the corresponding observation window duration is at least 15 minutes.

[0069] For orange alerts, the following thresholds can be preset: the call volume ratio threshold is 1.5 times and 3 times, the queuing volume ratio threshold is 10%, the manual connection rate threshold is 90%, and the call loss threshold is 1. The corresponding observation window duration is at least 10 minutes.

[0070] For red alerts, the following thresholds can be preset: a call volume ratio threshold of 3 times, a queue volume ratio threshold of 15%, a manual connection rate threshold of 85%, and a call loss threshold of 1. The corresponding observation window duration is at least 5 minutes.

[0071] With this configuration, high-level early warnings not only have stricter thresholds (higher numerical requirements) but also shorter observation windows (reduced requirements for continuity). This allows high-level early warnings to focus on preventing missed reports and rapid response, while low-level early warnings focus on preventing false alarms and stable operation.

[0072] S302. Monitor the value of at least one core parameter within its corresponding observation window duration.

[0073] For example, for a yellow alert, the values ​​of the call volume ratio, the queue volume ratio, and the human connection rate are monitored within 15 minutes.

[0074] For orange alerts, monitor the call volume ratio, queue volume ratio, manual connection rate, and call loss rate within 10 minutes.

[0075] For red alerts, monitor the call volume ratio, queue volume ratio, manual connection rate, and call loss rate within 5 minutes.

[0076] S303. If at least one core parameter is detected and its value continuously meets the parameter threshold corresponding to the call pressure warning level within the corresponding observation window duration, then the corresponding call pressure warning level is triggered.

[0077] For example, for a yellow alert, if any of the following conditions are met within 15 consecutive minutes: call volume ratio ≥ 1.0 and < 1.5; queuing volume percentage ≥ 5%; manual connection rate ≤ 95%, and queuing status is sampled every 5 seconds during the 15-minute observation period (a total of 180 sampling points), and the proportion of sampling points in a queue during the 15-minute observation period is ≥ 80%, then a yellow alert is triggered. A yellow alert indicates a mild warning and has a relatively long observation window, which can filter out instantaneous, short-term spikes. The yellow alert is only activated when call volume pressure is confirmed to be persistent, thus achieving operational stability.

[0078] For an orange alert, if any of the following conditions are met within a continuous 10-minute period: call volume ratio ≥ 1.5 and < 3.0; queuing volume ≥ 10%; manual connection rate ≤ 90%; (out-of-queue) call loss ≥ 1, and queuing status is sampled every 5 seconds during the 10-minute observation period (a total of 120 sampling points), and the proportion of sampling points in a queue during the 10-minute observation period is ≥ 80%, then an orange alert is triggered. An orange alert indicates a moderate alert; the observation window is shortened, the indicator thresholds are stricter, and monitoring of call loss is increased, enabling the identification of significant and persistent call traffic peaks.

[0079] For a red alert, if any of the following conditions are met within 5 consecutive minutes: call volume ratio ≥ 3.0; queue volume ≥ 15%; human operator connection rate ≤ 85%; (out-of-queue) call loss ≥ 1, and the queue status is sampled every 5 seconds during the 5-minute observation period (a total of 60 sampling points), and the proportion of sampling points in the queue status during the 5-minute observation period is ≥ 80%, then a red alert is triggered. A red alert indicates a severe warning, with the shortest observation window. Once it is reached, it is triggered immediately, ensuring the fastest possible response when the system faces the risk of collapse.

[0080] By employing both observation window duration and parameter threshold constraints, dynamic adjustment of early warning sensitivity can be achieved: low-level early warnings focus on preventing false alarms, while high-level early warnings focus on preventing missed alarms. This allows for precise matching of scheduling resources, avoiding resource waste or response delays, and significantly improving the intelligence level of the call dispatch system.

[0081] S105. Based on the call load warning level, dispatch hotline call resources progressively according to a preset, tiered scheduling strategy.

[0082] Specifically, the tiered differences in the scheduling strategy are reflected in the fact that the scope of hotline call resources scheduled, the intensity and urgency of the scheduling instructions are all proportional to the severity of the triggered call pressure warning level, thereby achieving level-based matching and differentiated response. By following this pre-set, tiered scheduling strategy to progressively schedule hotline call resources, it is possible to ensure accurate, orderly, and efficient responses to different levels of call pressure. This effectively avoids the waste caused by over-allocation of resources under low pressure conditions or the slow response caused by insufficient resource allocation under high pressure conditions, thus achieving refined and scientific management of operational risks and ultimately ensuring the stability of hotline services and user experience.

[0083] In one embodiment, such as Figure 4 As shown, step S105 may include the following sub-steps S401-S407.

[0084] S401. When any call pressure warning level is triggered, execute the initial scheduling action preset for the call pressure warning level to schedule the corresponding hotline call resources. S402. After executing the current scheduling action, monitor the queuing status during a preset observation period; S403. Determine whether a queuing state is still detected at the end of the observation period; if yes, proceed to step S404; if no, proceed to step S405. S404. Execute the next scheduling action preset for the call pressure warning level to schedule the hotline call resources of the next level, and proceed to step S402. S405, Count the first duration after the queue status has been cleared; S406. Determine whether the first duration exceeds the preset duration; if yes, proceed to step S407; if no, proceed to step S404. S407. Call volume pressure warning level lifted, progressive dispatching stopped.

[0085] The preset scheduling action sequence for each call pressure warning level is arranged sequentially according to the gradient defined by the team scope of the dispatched hotline call resources.

[0086] Specifically, when any traffic pressure warning level is triggered, the first preset scheduling action corresponding to that level is immediately executed to mobilize initial resources to cope. After each subsequent scheduling, a preset observation period is initiated, continuously monitoring the system's queuing status. If queuing persists at the end of the observation period, the current scheduling intensity is determined to be insufficient, and the next preset scheduling action is automatically triggered to utilize a wider range of resources at the next lower tier, then the system re-enters the observation period. This cycle continues until the queuing pressure is alleviated.

[0087] The disappearance of the queue does not immediately signify the end of the warning. The system will then initiate a stability verification phase, tracking the duration of the queue being cleared and determining if it exceeds a preset stability threshold (e.g., 5 minutes without queues). Only when this stability condition is met will the system finally lift the current warning and stop scheduling. If the stability condition is not met (queues may reappear), the system will return to the progressive loop to execute the next scheduling action to solidify the control effect.

[0088] The entire process involves a series of pre-defined scheduling actions, arranged in a sequence based on the responsibilities and scope of the teams being scheduled (e.g., from the frontline power connection team to the second-line support team, and then to the back-end support team). This progressive scheduling is not a series of rigid instructions, but rather an intelligent, closed-loop process that dynamically adjusts between increasing pressure and maintaining stability based on feedback from the core state of queuing.

[0089] The following detailed description of this embodiment will be provided through specific examples.

[0090] To facilitate tiered and graded dispatching, the hotline operation system is divided into multiple dispatching teams based on personnel responsibilities, including a front-line call-in team, several batches of second-line support teams (four batches are used as an example in this embodiment), a back-end support team, and an after-sales follow-up team. Each team has one or more management positions (team leaders).

[0091] For a yellow alert: 1) A yellow alert is activated, and the dispatch and distribution platform sends a notification to all frontline call-receiving personnel, reminding them to "shorten post-call processing time, stop taking short breaks, and suspend going off-duty." 2) After observing for 5 minutes, if the queuing status still exists, the dispatch and distribution platform will send a notification to prompt all management personnel of the front-line power connection team to join the power connection. 3) After observing for 10 minutes, if there is still a queue, the dispatch and distribution platform will send a notification to remind all members of the first batch of second-line support team to answer the phone, and at the same time make an outbound call to the configured management personnel number to inform them of the dispatch requirements; 4) After observing for 15 minutes, if there is still a queue, the dispatch and distribution platform will send a notification to remind the second batch of second-line support team to reserve a small number of core duty personnel, and the rest of the personnel will answer the phone and make an outbound call to the configured management personnel number to inform them of the dispatch requirements. 5) After observing for 20 minutes, if there is still a queue, the dispatch and distribution platform will send a notification to remind all members of the third batch of second-line support team to answer the phone, and at the same time make an outbound call to the configured management personnel number to inform them of the dispatch requirements; 6) After observing for 25 minutes, if there is still a queue, the dispatch and distribution platform will send a notification to remind half of the second-line support team members in the fourth batch to answer the phone (all members can be notified, and the management personnel will dispatch according to the pre-arranged plan). At the same time, the platform will make an outbound call to the configured management personnel number to inform them of the dispatch requirements. 7) After observing for 30 minutes, if there is still a queue, the dispatch and distribution platform will send a notification to remind the back-end support team to reserve a small number of core personnel, and the rest of the personnel will answer the phone. At the same time, the platform will make an outbound call to the configured management personnel number to inform them of the dispatch requirements.

[0092] While conducting the aforementioned progressive scheduling of on-duty and seated personnel, the dispatch and distribution platform simultaneously makes outbound calls to the mobile phones of on-duty but not seated (away) personnel in each dispatch team, urging them to be in position to answer the call within 10 minutes.

[0093] Warning cancellation condition: If the system does not experience a queuing state for 5 consecutive minutes after the scheduling is executed, the yellow warning will be lifted.

[0094] For orange alert: 1) Activate the orange alert and immediately execute the dispatch according to the highest level of the yellow alert. The dispatch and distribution platform sends a notification to remind all call-receiving personnel to "shorten the post-call processing time, stop taking short breaks, and suspend going off duty"; at the same time, notify the front-line call-receiving management post, each batch of second-line support teams, and the back-end support team to enter the call-receiving state, and simultaneously make outbound calls to the configured management personnel numbers to inform them of the dispatch requirements. 2) If there is still a queue after 5 minutes of observation, the dispatch and distribution platform will send a notification to remind all members of the after-sales follow-up team to answer the phone, and at the same time make an outbound call to the configured management personnel number to inform them of the dispatch requirements; 3) After observing for 10 minutes, if there is still a queue, the dispatch and distribution platform will send a notification to remind all participating teams to reserve a small number of core emergency duty personnel, and all remaining personnel to answer the phone and simultaneously make an outbound call to the configured management personnel number to inform them of the dispatch requirements.

[0095] While scheduling the aforementioned on-duty and seated personnel, the dispatch and distribution platform simultaneously makes outbound calls to the mobile phones of on-duty but not seated (away) personnel in each dispatch team, urging them to be on duty and answer the call within 10 minutes; at the same time, management personnel operate the dispatch system to make outbound calls to the mobile phones of personnel about to take over the shift, requiring them to be on duty and answer the call as quickly as possible.

[0096] Warning cancellation condition: If the system does not experience a queuing state for 5 consecutive minutes after the scheduling is executed, the orange warning will be lifted.

[0097] For red alerts: 1) Activate the red alert and immediately complete the highest level of dispatch for the orange alert. The dispatch and distribution platform sends a notification to remind all personnel receiving calls to "shorten the post-call processing time, stop taking short breaks, and suspend going off duty." At the same time, notify all dispatch teams to reserve only core emergency duty personnel and for all other personnel to receive calls. Simultaneously, make outbound calls to the mobile phones of their respective department heads and shift leaders to inform them of the dispatch requirements. 2) After observing for 5 minutes, if there is still a queue, the dispatch and distribution platform will send a notification to prompt all on-duty non-callers in the hotline operation system to join the call-taking process. At the same time, the platform will make an outbound call to the configured management personnel number to inform them of the dispatch requirements.

[0098] While scheduling the aforementioned on-duty and seated personnel, the dispatch and distribution platform simultaneously makes outbound calls to the mobile phones of on-duty but not seated (away) personnel in each dispatch team, urging them to be on duty and answer the call within 10 minutes; at the same time, management personnel operate the dispatch system to make outbound calls to the mobile phones of personnel about to take over the shift, requiring them to be on duty and answer the call as quickly as possible.

[0099] Warning cancellation condition: If the system does not experience a queuing state for 5 consecutive minutes after the scheduling is executed, the red warning will be lifted.

[0100] Optionally, if situations such as personnel response timeouts or abnormal fluctuations in indicators occur, a secondary reminder will be sent to the management personnel.

[0101] The above example demonstrates in detail a set of preset, progressive scheduling sequences corresponding to the yellow, orange, and red alert levels. After each alert level is activated, the system monitors the queuing status for a preset observation period. If the queuing status persists, resources from teams with a wider scope and stronger intensity are scheduled in sequence until the queuing status is cleared for 5 minutes, at which point the alert can be cancelled. This achieves the goal of matching gradient strategies according to alert level and progressively scheduling based on queuing feedback until the problem is stably resolved.

[0102] In one embodiment, the method further includes: monitoring a second duration of the call load warning level from the date of triggering; if the second duration exceeds a preset maximum warning duration and the call load warning level is still not lifted, then sending an outbound call notification to off-duty personnel who are not currently in the dispatch action sequence to encourage off-duty personnel to return to work within a preset recall time.

[0103] For example, when a call load warning level (such as a red warning) is triggered, if its duration exceeds a preset maximum threshold (e.g., 75 minutes) and the warning remains in effect, it indicates that regular on-duty and backup resources are insufficient to alleviate the current call load. In this case, the system will activate the highest-level emergency response mechanism. The dispatch and distribution platform will send outbound call notifications to the mobile phones of off-duty personnel in their respective shifts who are not currently in the regular dispatch sequence, clearly informing them of the current emergency situation and dispatch requirements. This aims to encourage off-duty personnel to return to their posts and resume call answering within a preset recall timeframe (e.g., 2 hours). This allows for the efficient and orderly mobilization and recall of off-duty human resources, serving as the ultimate guarantee against extreme and prolonged call load peaks. Ultimately, it ensures maximum manpower coverage of the city's user access channels, guaranteeing the continuity and availability of hotline services.

[0104] Optionally, key information throughout the entire early warning and dispatch process can be structured and recorded to form a complete dispatch archive. The structured records include: specific conditions and data for triggering an early warning (such as the call volume ratio, queuing percentage, connection rate, call loss rate, and other core parameter values ​​at the time of triggering); details of the dispatch execution process (including the dispatched teams, outbound call recipients, and the triggering and execution times of various dispatch instructions); the response status and efficiency of relevant personnel (such as the arrival time of notified personnel and their call-handling status after arrival); and the complete trend of various indicators within the early warning period. The resulting dispatch archive supports combined queries, statistical analysis, and data export based on multiple dimensions such as time range, early warning level, and responsible teams, providing detailed data support for subsequent operational reviews, performance evaluations, and strategy optimization.

[0105] This invention provides a hotline call resource scheduling method. By establishing and dynamically updating benchmark indicators, combined with the collection and calculation of multi-dimensional real-time indicators, it accurately perceives the deviation of call load from the normal level, thus overcoming the shortcomings of traditional methods that rely on historical predictions and ignore real-time fluctuations. Furthermore, by triggering tiered early warnings through parameter threshold comparison and state persistence verification, it effectively filters out instantaneous interference, ensuring the accuracy and robustness of early warnings. Based on this, according to the severity of the early warning level, a preset scheduling strategy with gradient differences is executed to progressively schedule hotline call resources, achieving precise matching and efficient utilization of resources. This avoids resource waste during low loads and prevents insufficient response during high loads, thereby significantly improving the operational efficiency, service resilience, and user experience of the hotline system.

[0106] Please refer to Figure 5 , Figure 5 This is a schematic diagram of the hotline call resource scheduling device provided by the present invention. Figure 5 As shown, the device may include: The benchmark determination module 501 is used to determine and dynamically update benchmark indicators that characterize the level of normal call volume based on historical call volume under the same time characteristics within a historical period. The real-time acquisition module 502 is used to collect multiple real-time indicators that characterize the current call load and operating status. The parameter calculation module 503 is used to calculate at least one core parameter for early warning determination based on multiple real-time indicators and benchmark indicators. The early warning triggering module 504 is used to perform threshold comparison and status persistence verification on at least one core parameter, and trigger the corresponding traffic pressure early warning level based on the verification result. The resource scheduling module 505 is used to progressively schedule hotline call resources according to a preset scheduling strategy with gradient differences, based on the call pressure warning level.

[0107] In some embodiments, the hotline call resource scheduling device of the present invention can be implemented in a combination of hardware and software. As an example, the hotline call resource scheduling device of the present invention can be a processor in the form of a hardware decoding processor, which is programmed to execute the hotline call resource scheduling method of the present invention. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0108] The modules described in the embodiments of this invention can be implemented in software or hardware. The names of the modules are not, in some cases, limiting the scope of the module itself.

[0109] An electronic device according to an embodiment of the present invention includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements any of the above-mentioned hotline call resource scheduling methods. That is, an electronic device according to an embodiment of the present invention may include, but is not limited to: a processor and a memory; the memory is used to store the computer program; the processor is used to execute the hotline call resource scheduling method shown in any embodiment of the present invention by calling the computer program.

[0110] In one alternative embodiment, an electronic device is provided, such as Figure 6 As shown, Figure 6 The illustrated electronic device 4000 includes a processor 4001 and a memory 4003. The processor 4001 and the memory 4003 are connected, for example, via a bus 4002. Optionally, the electronic device 4000 may further include a transceiver 4004, which can be used for data interaction between the electronic device and other electronic devices, such as sending and / or receiving data. It should be noted that in practical applications, the transceiver 4004 is not limited to one type, and the structure of the electronic device 4000 does not constitute a limitation on the embodiments of the present invention.

[0111] Processor 4001 may be a CPU (Central Processing Unit), a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this invention. Processor 4001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0112] Bus 4002 may include a path for transmitting information between the aforementioned components. Bus 4002 may be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. Bus 4002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus 4002 is represented by only one thick line, but this does not mean that there is only one bus or one type of bus.

[0113] The memory 4003 may be ROM (Read Only Memory) or other types of static storage devices capable of storing static information and instructions, RAM (Random Access Memory) or other types of dynamic storage devices capable of storing information and instructions, or EEPROM (Electrically Erasable Programmable Read Only Memory), CD-ROM (Compact Disc Read Only Memory) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0114] The memory 4003 stores application code (computer program) for executing the present invention, and its execution is controlled by the processor 4001. The processor 4001 executes the application code stored in the memory 4003 to implement the content shown in the foregoing method embodiments.

[0115] Among them, electronic devices can also be terminal devices, which can be any device that can install applications, including at least one of smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, smart TVs, and smart in-vehicle devices.

[0116] It should be noted that, Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments of the present invention.

[0117] An embodiment of the present invention provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements any of the above-described hotline call resource scheduling methods.

[0118] Alternatively, the computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a compact disc read-only memory (CD-ROM), magnetic tape, a floppy disk, and an optical data storage device, etc.

[0119] In an exemplary embodiment, a computer program product or computer program is also provided, which includes computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the aforementioned hotline traffic resource scheduling method.

[0120] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0121] It should be understood that the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0122] The computer-readable storage medium provided in this invention can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EEPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0123] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the method shown in the above embodiments.

[0124] The above description is merely a preferred embodiment of the present invention and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this invention is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this invention.

[0125] It should be noted that the terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and represent a limitation on a specific order or sequence. Where appropriate, the order of use for similar objects can be interchanged so that the embodiments of this application described herein can be implemented in an order other than that shown or described.

[0126] Those skilled in the art will recognize that this invention can be implemented as a system, method, or computer program product. Therefore, this invention can be specifically implemented in the following forms: it can be entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software, generally referred to herein as a "circuit," "module," or "system." Furthermore, in some embodiments, this invention can also be implemented as a computer program product contained in one or more computer-readable media, which includes computer-readable program code.

[0127] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A method for scheduling hotline call resources, characterized in that, include: Based on historical call volume under the same time characteristics within a historical period, a benchmark indicator for characterizing the level of routine call volume is determined and dynamically updated. It collects multiple real-time indicators that characterize the current call load and operating status. Based on the multiple real-time indicators and the benchmark indicators, at least one core parameter for early warning determination is calculated. The threshold comparison and status persistence verification of at least one core parameter are performed, and the corresponding traffic pressure warning level is triggered based on the verification result; Based on the aforementioned call load warning level, hotline call resources are progressively scheduled according to a preset scheduling strategy with tiered differences.

2. The hotline call resource scheduling method according to claim 1, characterized in that, The step of performing threshold comparison and status persistence verification on at least one core parameter, and triggering the corresponding traffic pressure warning level based on the verification result, includes: For each of the aforementioned call load warning levels, a preset threshold and observation window duration are defined for the at least one core parameter that triggers a warning at that call load warning level. Monitor the value of at least one core parameter within its respective observation window duration; If at least one core parameter is detected and its value continuously meets the parameter threshold corresponding to the call pressure warning level within the corresponding observation window duration, then the corresponding call pressure warning level is triggered.

3. The hotline call resource scheduling method according to claim 1, characterized in that, The step of progressively scheduling hotline call resources according to the call load warning level and a preset, tiered scheduling strategy includes: When any of the aforementioned call pressure warning levels is triggered, an initial scheduling action preset for the aforementioned call pressure warning level is executed to schedule the corresponding hotline call resources; The following steps will be executed repeatedly until the traffic pressure warning level is lifted, at which point the progressive scheduling will stop: After executing the current scheduling action, monitor the queuing status during a preset observation period; If the queuing status is still detected at the end of the observation period, the next scheduling action preset for the call pressure warning level will be executed to schedule the hotline call resources of the next level. If the queuing state is detected to have been lifted at the end of the observation period, then the first duration of the queuing state being lifted is recorded. If the first duration exceeds the preset duration, the call load warning level is lifted; The preset scheduling action sequence for each of the call pressure warning levels is arranged sequentially according to the gradient defined by the team scope of the scheduled hotline call resources.

4. The hotline call resource scheduling method according to claim 3, characterized in that, The method further includes: Monitor the second duration of the call load warning level from the time it is triggered; If the second duration exceeds the preset maximum warning duration and the call load warning level is still not lifted, an outbound call notification will be sent to off-duty personnel who are not currently in the dispatch action sequence to encourage them to return to work within the preset recall time.

5. The hotline call resource scheduling method according to claim 1, characterized in that, The method of determining and dynamically updating benchmark indicators for characterizing routine call volume levels based on historical call volume under the same time characteristics within a historical period includes: Collect the historical call volume of the same time block of each day in each week within the historical period as the historical traffic volume; Based on the collected historical call volumes, the average historical call volume for each time block of each day in a week is calculated as the benchmark indicator to form a benchmark call volume database. The baseline metrics are periodically recalculated using newly added historical call volume data, and the baseline call volume database is updated using the recalculated baseline metrics.

6. The hotline call resource scheduling method according to claim 5, characterized in that, The real-time collection of multiple indicators characterizing the current call load and operational status includes: Real-time data collection includes current incoming call volume, current queue volume, current number of people answering calls, current number of times a live agent connects, current number of incoming calls to live agents, and current call loss.

7. The hotline call resource scheduling method according to claim 6, characterized in that, The at least one core parameter includes at least one of call volume ratio, queue volume ratio, manual connection rate and call loss, and the benchmark indicator is the benchmark call volume; The calculation of at least one core parameter for early warning determination based on the multiple real-time indicators and the benchmark indicators includes at least one of the following steps: Calculate the ratio of the current inbound call volume to the corresponding baseline call volume in the baseline call volume database, and use this ratio as the call volume ratio value; Calculate the ratio of the current queue size to the current number of people answering calls, and use this ratio as the queue size percentage; The ratio of the current number of calls connected to the current number of incoming calls to a human agent is calculated as the human agent connection rate. The current call loss is determined as the call loss.

8. A hotline call resource scheduling device, characterized in that, include: The benchmark determination module is used to determine and dynamically update benchmark indicators that characterize the level of normal call volume based on historical call volume under the same time characteristics within a historical period. The real-time acquisition module is used to collect multiple real-time indicators that characterize the current call load and operating status. The parameter calculation module is used to calculate at least one core parameter for early warning determination based on the multiple real-time indicators and the benchmark indicators. The early warning triggering module is used to perform threshold comparison and status persistence verification on at least one core parameter, and trigger the corresponding call pressure early warning level based on the verification result; The resource scheduling module is used to progressively schedule hotline call resources according to the call pressure warning level and a preset scheduling strategy with gradient differences.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the hotline call resource scheduling method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the hotline call resource scheduling method as described in any one of claims 1 to 7.

Images