Dynamic task orchestration system and method for phone lead lifecycle management

Abstract

This invention discloses a dynamic task orchestration system and method for telephone lead lifecycle management, relating to the field of data processing technology. The system includes a task orchestration module, a concurrency control module, a lead management module, and a line management module: the task orchestration module dynamically obtains load weights based on load assessment parameters of each service node, and dynamically executes task migration processes based on the obtained load weights and service node loads; the concurrency control module uses an adaptive resource allocation algorithm combining proportional allocation and heap optimization to achieve distributed atomic concurrent control; the lead management module manages the entire lead lifecycle based on a lead status transition mechanism and a three-layer deduplication mechanism; the line management module performs availability checks on candidate lines before outbound calls, implements intelligent allocation of line resources based on a priority-based line scheduling algorithm, and uses a sliding window rate limiting mechanism to achieve periodic frequency control of lines.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a dynamic task orchestration system and method for telephone lead lifecycle management. Background Technology

[0002] Telephone lead lifecycle management refers to the systematic tracking and status management of potential customer leads from generation, import, allocation, follow-up to final conversion or abandonment; dynamic task orchestration refers to the system capability to intelligently schedule and execute tasks such as outbound calls and SMS based on real-time load, resource availability, and business rules. Existing task orchestration technologies are mainly divided into three categories: traditional call center systems typically use fixed agent allocation mechanisms and simple polling algorithms for line selection, lacking intelligent resource scheduling capabilities, and concurrency control relies on database locking mechanisms; cloud communication platforms, although providing API interfaces, mostly use static configuration to manage line resources, lacking tracking and management of the entire lead lifecycle, and concurrency control strategies are relatively simple; open-source outbound calling systems are mostly based on traditional PBX architectures, relying on queue mechanisms to process tasks, and have limitations in terms of intelligent task orchestration, system scalability, and stability.

[0003] In telemarketing scenarios, efficiently processing massive amounts of leads and intelligently scheduling outbound call resources are key to improving customer acquisition efficiency. Traditional system architectures have significant limitations when facing large-scale, high-concurrency business: First, in terms of lead management, there is a lack of a unified mechanism for tracking and managing the entire lifecycle of leads from importation and allocation to follow-up and conversion, leading to chaotic processes and low efficiency. Second, in terms of resource scheduling, it is difficult to dynamically and intelligently coordinate and orchestrate various heterogeneous resources such as digital employees, outbound call lines, and concurrent channels. Third, in terms of concurrency control, there is a lack of refined resource allocation algorithms, which easily leads to resource contention and waste. Fourth, in terms of line management, there is a lack of unified quality control and assurance strategies for multi-carrier lines. Existing technical solutions, such as traditional call centers, cloud communication platforms, or open-source systems, generally adopt static configuration, fixed queues, or simple polling mechanisms, which are insufficient in terms of the intelligence of dynamic task orchestration, system scalability, and stability.

[0004] For example, patent application CN117707762A discloses a task orchestration method and device, which includes: receiving task orchestration operation event streams submitted by each target client through their respective task orchestration interfaces; sorting each task orchestration operation event included in each task orchestration operation event stream according to the submission time of each task orchestration operation event stream; and distributing each task orchestration operation event to the corresponding target client in sequence according to the sorting result, so that each target client synchronously refreshes the task chain in the task orchestration interface according to each received task orchestration operation event.

[0005] For example, the task scheduling method and device disclosed in patent application CN114691344A include: displaying a task scheduling interface, wherein the task scheduling interface includes a task list area and a task canvas area, wherein the task list area displays one or more tasks; detecting a task scheduling operation input by a user in the task scheduling interface for scheduling a task flow using the task displayed in the task list area; responding to the task scheduling operation, displaying a scheduling result corresponding to the task scheduling operation in the task canvas area, thereby displaying a task flow diagram formed according to the task scheduling operation in the task canvas area; and creating a user-scheduled task flow based on the task flow diagram.

[0006] However, in the process of implementing the inventive technical solution in the embodiments of this application, it was found that the above-mentioned technology has at least the following technical problems: In existing technologies, traditional telemarketing task orchestration schemes mostly adopt static resource allocation and fixed task queues, which cannot be dynamically adjusted according to real-time load, resulting in low resource utilization and easy bottlenecks. Their concurrency control relies on simple mechanisms such as database locks, which are insufficient in performance and accuracy under high-concurrency scenarios. Lead management lacks a full lifecycle perspective and intelligent flow rules, and cannot adapt to complex and ever-changing business needs. The system architecture is usually a tightly coupled monolithic design, which is difficult to support elastic scaling and large-scale concurrent processing, thus restricting the efficiency and scalability of the overall business. Summary of the Invention

[0007] This application provides a dynamic task orchestration system and method for telephone lead lifecycle management. It addresses the shortcomings of existing technologies, such as traditional telephone marketing task orchestration schemes that rely on static resource allocation and fixed task queues, which cannot dynamically adjust based on real-time load, resulting in low resource utilization and bottlenecks; concurrency control that depends on simple mechanisms like database locks, leading to insufficient performance and accuracy in high-concurrency scenarios; lack of a full lifecycle perspective and intelligent flow rules in lead management, making it unsuitable for complex and ever-changing business needs; and system architectures that are typically tightly coupled monolithic designs, hindering elastic scaling and large-scale concurrent processing, thus restricting overall business efficiency and scalability. The application provides an intelligent, highly elastic, and high-concurrency dynamic task orchestration and management system for the entire telephone lead lifecycle.

[0008] This application provides a dynamic task orchestration system for telephone lead lifecycle management, including: This application provides a dynamic task orchestration method for telephone lead lifecycle management, including: One or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By deeply integrating dynamic load balancing task orchestration, atomic concurrency control based on adaptive algorithms, lead management that supports multi-source import and intelligent flow, and line management with priority scheduling and sliding window rate limiting, a highly elastic and highly available distributed architecture is constructed. This effectively solves industry pain points such as low resource utilization, insufficient high-concurrency performance, rigid lead management, and difficulty in system expansion, thereby achieving the business goal of efficient, stable, and large-scale intelligent operation and management of the entire lifecycle of telemarketing leads.

[0009] 2. By integrating multi-dimensional indicators such as the current load, predicted load, and load standard deviation of service nodes into a comprehensive evaluation index with preset weights, and quantifying its load weight according to a mapping table, a refined and quantifiable node status evaluation system is constructed. Furthermore, by dynamically calculating dual thresholds based on the cluster average load and the status of the lightest-loaded node, a task migration from overloaded nodes to the least busy nodes is intelligently triggered and executed, with the thresholds dynamically updated after migration to form a closed-loop feedback. This series of operations collectively achieves accurate perception of the cluster load status and real-time, stable dynamic rebalancing, thereby ensuring the overall resource utilization and operational stability of the system under high concurrency and task fluctuation scenarios.

[0010] 3. By combining a basic algorithm that allocates resources proportionally based on remaining capacity with a dynamic remainder allocation mechanism based on max-heap optimization, fine-grained and maximized utilization of global concurrent resources is achieved. Simultaneously, precise time-window concurrency checks and counting control are performed using Redis sorted sets and Lua script atomic operations. This collaborative approach enables precise and reliable atomic-level concurrency control in high-concurrency distributed environments, ensuring fair and efficient resource allocation while preventing concurrency limits from being exceeded.

[0011] 4. By introducing a clue status transition mechanism that includes branch paths, combined with a three-layer deduplication mechanism covering real-time memory, historical data, and combined fields, the process ensures clear and controllable clue processing at the workflow level and achieves end-to-end uniqueness verification from immediate batch processing to persistent storage at the data level. This enables efficient, accurate, and complete management of massive multi-source clue data throughout its entire lifecycle, fundamentally avoiding data duplication, status confusion, and resource waste.

[0012] 5. By combining an intelligent route selection algorithm based on priority, geographic matching, and dynamic combination with a sliding window rate limiting mechanism based on time window counting, the system achieves optimized allocation and efficient utilization of route resources in the spatial dimension and precise and smooth control of call frequency in the temporal dimension. This collaboratively enables global and intelligent scheduling and protection of outbound call route resources, ensuring high connection rates, compliance, and overall stable operation of outbound call tasks. Attached Figure Description

[0013] Figure 1 A schematic diagram of the structure of a dynamic task orchestration system for telephone lead lifecycle management provided in an embodiment of this application; Figure 2 A complete timing diagram of outbound call tasks for a dynamic task orchestration system for telephone lead lifecycle management provided in an embodiment of this application; Figure 3 A flowchart illustrating a dynamic task orchestration method for telephone lead lifecycle management provided in this application embodiment. Detailed Implementation

[0014] This application provides a dynamic task orchestration system and method for telephone lead lifecycle management. It addresses the problems of existing traditional telephone marketing task orchestration schemes, which often employ static resource allocation and fixed task queues, failing to dynamically adjust based on real-time load, resulting in low resource utilization and bottlenecks; their concurrency control relies on simple mechanisms such as database locks, leading to insufficient performance and accuracy in high-concurrency scenarios; lead management lacks a full lifecycle perspective and intelligent flow rules, making it unable to adapt to complex and ever-changing business needs; and the system architecture is typically a tightly coupled monolithic design, making it difficult to support elastic scaling and large-scale concurrent processing, thus hindering the overall efficiency and scalability of the business. The overall approach is as follows: The task orchestration module employs a multi-layered worker architecture, dynamically assessing service node load and performing task migration to optimize load balancing. The concurrency control module implements distributed atomic concurrency control based on adaptive algorithms and Redis. The lead management module integrates multiple import methods, combining state transitions and deduplication mechanisms to ensure the accuracy and completeness of leads throughout their lifecycle. The line management module intelligently allocates line resources through availability checks, priority scheduling, and sliding window rate limiting. Overall, the system aims to improve the systematic nature, stability, and efficiency of telephone lead management through dynamic task orchestration, resource control, lead integration, and line optimization.

[0015] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0016] like Figure 1The diagram shows the structure of a dynamic task orchestration system for telephone lead lifecycle management provided in this application embodiment. The system includes a task orchestration module, a concurrency control module, a lead management module, and a line management module. The task orchestration module adopts a multi-layer worker architecture, which includes a scheduler manager, digital employee workers, and a processor structure. The scheduler manager is responsible for unified global task scheduling. Each digital employee worker is assigned an independent instance. The processor includes an outbound call processor, an SMS processor, and a microprocessor. The underlying layer uses a cluster manager to register service nodes, monitor load, and perform intelligent scheduling. The task orchestration module dynamically obtains load weights based on the load evaluation parameters of each service node within the cluster in the multi-layer worker architecture. Based on the obtained load weights and service node loads, it dynamically executes a task migration process to balance load balancing effects and system load. The system is stable; the concurrency control module adopts a multi-layer concurrency control architecture, using an adaptive resource allocation algorithm based on a combination of proportional allocation and heap optimization, and implements distributed atomic concurrency control through Redis Lua scripts; the lead management module supports multi-source lead import methods, using a lead status flow mechanism and a three-layer deduplication mechanism to achieve efficient, accurate and complete management of the entire lead lifecycle. Multi-source lead import methods include management platform import, open API import, inbound call creation, partner import, test import, creation based on existing leads and automatic import; the line management module is used to perform availability checks on candidate lines before outbound calls are executed, and implements intelligent allocation of line resources based on a priority-based line scheduling algorithm. It uses a sliding window rate limiting mechanism to implement periodic frequency control of lines. Availability checks include outbound call area restrictions, outbound call interval restrictions, called party daily restrictions, digital employee concurrency restrictions, total line concurrency restrictions, daily outbound call restrictions and periodic rate limiting.

[0017] Based on the aforementioned dynamic task orchestration system for telephone lead lifecycle management, this invention constructs a complete closed loop from lead injection and scheduling to resource management and post-event analysis. Its core comprises a lead pipeline processing flow, a multi-stage outbound call scheduling execution flow, a real-time inbound event response flow, a line resource management and scheduling flow, a global control flow for concurrent resources, and a resource release and policy execution flow after the call ends. The following is a comprehensive description of each core sub-flow.

[0018] The lead pipeline processing workflow employs a pipeline mechanism based on functional programming paradigms. Data flows asynchronously through channels, sequentially passing through four stages: first, filtering, performing checks such as phone number formatting, blacklisting / whitelisting, and multi-layer deduplication; second, mapping and transformation, converting raw data into structured lead objects; third, batching, dividing the data stream into fixed-size segments; and finally, parallel data insertion, with multiple coroutines executing batch insertion and retries. This pipeline ensures high throughput and decoupling of data processing. For batch imports to the management platform, the process follows the above pipeline, with additional error collection and retries. For open API imports, the focus is on parameter validation, business rule checks, and real-time deduplication followed by synchronous return. For inbound events, the system triggers real-time number identification, location query, deduplication checks, and digital employee matching, thereby completing lead creation and allocation. A three-layer deduplication mechanism (real-time in-memory deduplication, historical data deduplication, and combined field deduplication) runs through all creation processes, ensuring lead uniqueness through concurrent and secure data structures and accurate query algorithms.

[0019] In the multi-stage execution process of outbound call scheduling, during the preparation phase, the system sequentially checks the lead status, the daily quota for express mode, and the agent's online status. It can also execute pre-reach tasks such as sending SMS messages or adding WeChat contacts to create conditions for formal outbound calls. The lead status pre-check first checks the current processing status of the lead. If the lead is marked as completed, it means that the lead has been processed by other processes. The system updates the status of the pending reach record to terminated and ends the current processing flow to avoid duplicate processing. For digital employees configured for express mode, the system needs to perform a daily outbound call quota check. The system uses a Redis counter to record the number of outbound calls made that day, with the key name containing the date and the digital employee identifier. The system first increments the counter to obtain the current value, and then compares it with the configured daily quota. If the current value exceeds the quota, an overload flag is set, the counter is rolled back once, the system administrator is notified of the overload situation, and the current processing is terminated. If the limit is not exceeded, the subsequent process continues, using a delayed execution mechanism to ensure that the count is only retained for successful outbound calls and rolled back for failed calls. For digital employee projects involving adding WeChat, if the configuration requires agents to be online before making outbound calls, the system needs to check the online status of the corresponding agents. The system extracts agent mobile phone number information from the business attributes of the leads to be reached and queries the digital employee's agent account data. If the corresponding online agent account is not found, the system postpones the next attempt time for the lead to be reached by 1 minute, waiting for the agent to come online before reprocessing, instead of directly failing, thus improving the lead processing success rate. Pre-reach task processing supports pre-call outbound strategies. If the type of the lead to be reached is sending an SMS before outbound calls, the system calls the SMS processing module to send a marketing SMS. After successful sending, the lead is converted to a regular outbound call type for further processing. If the type is adding WeChat before outbound calls, the system calls the WeChat processing module to push a WeChat add message. After successful processing, the lead is also converted to a regular outbound call type. This pre-processing mechanism prepares better customer reach conditions for outbound calls and improves the conversion rate.

[0020] Entering the resource preemption phase, the orderly execution of outbound calling tasks is ensured through a multi-layered locking mechanism and resource allocation: 1. Layered acquisition through distributed locks: The system implements a dual distributed lock mechanism. The first layer is a number call lock, used to prevent multiple processes from simultaneously making outbound calls to the same mobile number, causing customer harassment. The system uses Redis's non-existent key operation, with the mobile number as the key and the pending lead identifier as the value, setting a 60-second expiration time. If lock acquisition fails, it means the number is currently in a call, and the system increments the retry count for the pending lead record by one, delaying the next attempt by 5 seconds before returning. The second layer is a lead processing lock, used to prevent multiple service nodes or multiple coroutines from simultaneously processing the same pending lead record. It also uses Redis's atomic operation, with the pending lead identifier as the key and the node identifier as the value, setting a 60-second expiration time. If lock acquisition fails, it means another process is processing, and the current process is terminated directly. These two layers of locks are guaranteed to be automatically released upon function exit through a delayed execution mechanism, ensuring correct release of lock resources even if exceptions occur during processing. 2. Atomic Preemption of Concurrent Resources: The system calls the concurrent attempt preemption interface of the concurrency service, passing in the digital employee identifier, the identifier of the lead to be reached, and the concurrency limit. The concurrency service uses the aforementioned Lua script to atomically check the current concurrency and attempt to allocate resources. If the preemption is successful, a success flag and a new concurrency number are returned, and the subsequent process continues; if the preemption fails, it means that the concurrent resources for that digital employee have reached the limit, a flag for jumping to the next round is set, and the current processing ends. The system also uses a delayed execution mechanism to ensure that if the function exits abnormally and the outbound call is not successfully initiated, the concurrent release interface is called to return the preempted concurrent resources, avoiding resource leakage. 3. Intelligent Allocation of Line Resources: The system calls the line usage interface of the line service, passing in parameters such as the digital employee identifier, the identifier of the lead to be reached, the called number, the target line identifier, and the time zone identifier. The line service executes the aforementioned seven-layer checking mechanism, returning the allocation result, availability status, and rollback function. If the system returns an identifier indicating no available lines for the day, it means that the daily quota for all lines has been used up. The system will mark the pending record as interrupted, recording the reason for the interruption as no available lines for the day. If the system returns an identifier indicating no currently available lines, it means that the lines are temporarily busy but still have quota. The system will increment the retry count for the pending record, postpone the next attempt by 3 seconds, and set a flag to jump to the next round. If the allocation is successful, the system will obtain available line information and a rollback function. The rollback function is registered in the delayed execution mechanism to ensure that the line occupancy status can be correctly rolled back in the event of subsequent process failures, ensuring the accuracy of the resource ledger.

[0021] The final status update, parameter construction, and message sending are completed during the outbound call execution phase: 1. Atomicity update of lead status: The system constructs a database update statement, using conditional updates to ensure atomicity. Update conditions include the lead identifier to be reached being equal to the current record, and the processing status being equal to the waiting status. Update content includes changing the processing status to processing, the line identifier used by the record, incrementing the retry count, and updating the modification timestamp. After executing the update operation, the number of affected rows is checked. If it is zero, it means that the record has been modified by another process, and the current process abandons processing and returns directly; if it is greater than zero, it means that the update is successful, and the subsequent process continues. The system also registers a delayed execution function. If the subsequent process fails and the outbound call is not successful, the processing status is rolled back to the waiting status to ensure that the record can be rescheduled for processing. 2. Complete construction of outbound call parameters: The system constructs an outbound call parameter structure containing all necessary information. Core parameters include: generating a globally unique call identifier, setting the enterprise identifier and digital employee identifier, associating the lead identifier and the lead identifier to be reached, and configuring the call trunk address and script service address. The line parameters section sets the calling number, called number, number prefix, gateway address, answer delay time, and maximum ringing time. The operator transfer parameters section sets a list of transfer lines based on the digital employee's operator transfer configuration, with each line containing priority, number, and name information. The WeChat addition parameters section sets a strategy based on the digital employee's WeChat addition type, extracting the agent's mobile phone number and name from the lead's business attributes. The SMS parameters section sets whether to send an SMS after connection and the sending delay time based on the digital employee's SMS strategy. The business attribute parameters contain all custom fields for the lead, used for personalized call scripts. The custom prompt word parameter is used to override the default opening message. The test flag parameter is used to distinguish between test calls and official calls. 3. Reliable message queue delivery: The system serializes the outbound call parameter structure into a JSON format byte array, calls the message broadcast function to send it to the specified message queue topic, and configures the synchronous sending mode and the number of retries (default 3). The message broadcast function internally implements a producer confirmation mechanism, ensuring that the message is successfully written to the queue before returning. If the transmission fails, the system logs an error and sends an alarm notification. Simultaneously, due to the delayed execution mechanism, all allocated resources (distributed locks, concurrent resources, and line resources) are automatically rolled back and released to ensure system consistency. Upon successful transmission, the system increments the total number of outbound calls for each employee, sets a successful outbound call flag, and terminates the process normally.

[0022] like Figure 2The diagram shows the complete outbound call sequence of the dynamic task orchestration system for telephone lead lifecycle management provided in this embodiment of the application. Inbound call processing adopts an event-driven model, responding to inbound events in real time and performing intelligent allocation. Upon receiving an inbound event, the system immediately performs number identification, location lookup, and blacklist / whitelist verification. After deduplication checks to avoid duplicate creation in the short term, the system intelligently matches the best digital employee based on strategies such as location, time, and load. Finally, inbound leads are created in real time and corresponding pending contact records are generated, ensuring that customer calls receive a rapid follow-up response.

[0023] Incoming call lead creation employs an event-driven real-time processing mechanism: Upon receiving an incoming call event, the system first queries the number's location information from the number's location identification database, obtaining attributes such as province, city, area code, and operator type for subsequent digital employee matching and data analysis. Next, a blacklist / whitelist check is performed. The system checks if the number is on the blacklist; if so, creation is rejected and logged. Similarly, if a whitelist is configured and the number is not on it, creation is also rejected. This mechanism effectively filters out harassing numbers and non-target customers. Then, a call deduplication check is performed. The system checks if the number has already created an incoming lead within the last 24 hours; if so, duplicate creation is avoided, and the existing lead identifier is returned directly. This time-window deduplication strategy avoids duplicate recording within a short period while allowing repeat calls from long-term customers. Finally, intelligent digital employee matching is performed. Based on the incoming number's location information, the call time period, the digital employee's business type, and workload, the system uses a matching algorithm to select the most suitable digital employee. Matching rules include strategies such as region priority (prioritizing employees from the same province), load balancing (selecting digital employees with lower current load), and business matching (matching based on location and business type). Finally, inbound lead records are created. The system constructs lead objects, setting fields such as digital employee identifier, mobile phone number, source type (inbound), location information, lead status (processing), and creation time, and writes this information to the database to complete creation. Simultaneously, the system generates corresponding outbound contact records, setting the contact type to immediate outbound call to ensure that inbound leads can be responded to and processed quickly.

[0024] The line resource management and scheduling process employs a multi-layered checking and intelligent scheduling mechanism to ensure optimal utilization of line resources. First, a priority-based candidate set of lines is constructed based on digital employee binding relationships. The system calls a line binding query function, passing the digital employee's unique identifier as a parameter. This function returns a mapping table structure containing all configured line binding relationships for that digital employee. The returned mapping table is organized by priority, with each priority corresponding to a line binding configuration object. This configuration object contains the following three key attributes: Priority value: A 64-bit integer; the smaller the value, the higher the priority. The system selects lines in ascending order of this value. Line information list: An array of line information, containing all available lines at this priority level. Each line record includes detailed information such as the line's unique identifier, line name, gateway address, and geographical location priority configuration. Concurrency limit: A 64-bit integer representing the maximum number of simultaneous calls allowed for that digital employee on the current priority line group. This prevents a single digital employee from excessively consuming specific line resources, ensuring fair resource allocation. This priority-based line binding mechanism implements an intelligent line scheduling strategy. The system first attempts to use high-priority lines (usually lines with better quality or lower cost). When a high-priority line cannot be used due to full concurrency, exhaustion of the daily quota, or other restrictions, it automatically downgrades to a lower-priority line to continue trying, ensuring the success rate of outbound call tasks while taking into account the needs of line quality and cost control.

[0025] A seven-layer progressive check is performed on each candidate line. If any layer fails the check, the line is skipped and the next line is tried. These checks include: outbound call area compliance, outbound call interval, daily limit for a single called number, concurrency of digital employees on the line, global concurrency of the line, daily total outbound call limit for the line, and periodic rate limiting. The outbound call area restriction check retrieves the province information of the called number from the number's location query database. If the line has a prohibited area list configured, it checks whether the called number's province is on the prohibited list; if so, it returns a prohibited area error and marks the line as unavailable for the day. If the line has an allowed area list configured, it checks whether the called number's province is on the allowed list; if not, it returns a non-allowed area error and marks the line as unavailable for the day. If both lists are empty, no restriction is applied. This check ensures that the line only calls customers in the designated area, complying with regional marketing strategies and regulatory requirements. The outbound call interval restriction check reads the minimum and maximum interval times from the line configuration. If a random interval is set, the system generates a random number between the minimum and maximum values ​​as the actual interval; otherwise, the minimum interval value is used. The system reads the last outbound call timestamp from Redis for this line, calculates the difference between the current time and the last outbound call time, and determines whether the interval requirement has been met. If not, an interval failure error is returned. If the check passes, a success callback function is registered, updating the last outbound call time of this line to the current time when the line is successfully allocated. This check prevents excessive outbound calls, protecting line quality and avoiding operator restrictions. The called party daily limit check constructs a Redis key name based on the line group identifier (line group used to share quotas) configured for the line, containing the date, line group identifier, and called number. The system reads the count value of this key from Redis and determines whether the daily limit has been reached. If the limit is reached, a daily limit error is returned and the line is marked as unavailable for the day. If the check passes, a success callback function is registered, incrementing the counter and setting it to expire the next day when the line is successfully allocated. This check prevents the same number from being excessively dialed by the same line group within a single day, avoiding customer harassment. The digital employee concurrency limit check constructs a concurrency key name for the digital employee on this line and uses a Redis ordered set to store the currently occupied records. The system queries the cardinality of the sorted set to obtain the current concurrency count and compares it with the configured concurrency limit for digital employees on the line. If the limit is reached, a digital employee concurrency exceedance error is returned. If the check passes, a success callback function is registered, and the pending lead identifier and timestamp are added to the sorted set when the line is successfully allocated. This check ensures that a single digital employee does not excessively consume resources on a particular line, achieving fair allocation. The line total concurrency limit check constructs a global concurrency key for the line, also using a Redis sorted set. The system queries the set cardinality to obtain the current total concurrency count for the line and compares it with the configured total concurrency limit for the line. If the limit is reached, a line concurrency exceedance error is returned. If the check passes, a success callback function is registered, and the record is added to the global concurrency set when the line is successfully allocated. This check prevents line overload and ensures call quality.The daily outbound call limit check reads the total number of outbound calls made by the line that day from Redis (this data is persistently backed up in the database). The system compares the number of outbound calls made that day with the daily limit configured for the line. If the limit is reached, a daily limit error is returned and the line is marked as unavailable for the day. If the check passes, a success callback function is registered, and the daily outbound call counter is incremented when the line is successfully allocated. This check controls the total number of outbound calls made by the line each day, complying with the operator's quota and cost control requirements. The periodic rate limiting check calculates the total limit based on the number of SIM cards configured for the line and the period limit per SIM card, and determines the time window size based on the configured period time (e.g., 5 minutes). The system uses a sliding window rate limiting algorithm, cleans up expired records from the Redis ordered set, counts the number of outbound calls within the time window, and compares it with the total limit. If the limit is reached, a periodic limit error is returned. If the check passes, the outbound call is recorded in the rate limiter. This check achieves fine-grained frequency control, smooths traffic peaks, and protects line stability.

[0026] After all checks pass, the system sequentially executes all registered success callback functions, updates resource usage status, and returns successfully allocated line information. If any check fails, the system skips that line and tries the next candidate line, achieving intelligent line selection and fault tolerance. After the call ends, the system performs a unified line resource release process: The system receives a hang-up notification message containing information such as the digital employee identifier, the pending lead identifier, the lead identifier, the called number, the line identifier used, and the time zone. The system first releases the concurrent usage of the digital employee on that line by deleting the corresponding pending lead record from the Redis ordered set. Then, it releases the global concurrent usage of the line by similarly deleting the corresponding record from the global concurrent ordered set. The system also updates line statistics, including the number of connected calls, the number of unconnected calls, and the total outbound call duration, for line quality assessment and cost analysis. The entire release process ensures timely resource return, freeing up resource space for subsequent outbound call tasks.

[0027] The global control process for concurrent resources employs layered management and atomic operations at the allocation level to achieve precise concurrency control and dynamic load balancing. It includes several key steps: 1. Concurrent resource allocation process: The resource allocation process for concurrent services includes several key steps: Active digital employee screening mechanism: The system maintains a Redis ordered set recording all active digital employees, using the active expiration time as a score and the digital employee identifier as a member value. The system uses a range query operation to retrieve all members with scores greater than the current time, which constitutes the current list of active digital employees. Then, it performs an intersection operation with the requested list of digital employee identifiers to filter out digital employees who are both in the requested list and in an active state, avoiding waste by allocating concurrent resources to inactive digital employees. Real-time acquisition of global concurrency status: The system reads the global maximum concurrency configuration value from Redis, which is set by the system administrator based on the overall capacity of the call center. Then, it calls the call center service interface to obtain the current global actual number of calls, which is the sum of all calls currently in progress by all digital employees. The global available concurrency is obtained by subtracting the current number of calls from the global maximum concurrency. If the available concurrency is less than or equal to zero, it indicates that the system resources are saturated, and an empty allocation result is returned directly. The concurrency allocation strategy for different modes: The system divides active digital employees into two groups based on their outbound call mode: serial mode and high-speed mode. Serial mode digital employees receive priority resource allocation because they typically handle core business. The system calls the aforementioned adaptive resource allocation algorithm on the serial mode digital employee set to obtain the allocation result and the remaining concurrency. Then, it uses the remaining concurrency to call the allocation algorithm again on the high-speed mode digital employee set to fully utilize resources. Finally, the two allocation results are merged to form a complete allocation scheme mapping table, with the key being the digital employee identifier and the value being the allocated concurrency. Intelligent triggering of load alarms: The system calculates the remaining proportion of global concurrent resources. When the remaining concurrency is less than 25% of the maximum concurrency, an alarm is triggered. The system first checks the alarm deduplication lock, using Redis's setting of a non-existent key operation, with the key name being the alarm identifier and an expiration time of 30 minutes. If the setup is successful, indicating no alarms have been sent within 30 minutes, the system constructs an alarm message containing information such as the current available concurrency, the global maximum concurrency, and the utilization percentage. It then calls the Lark notification interface to send a P1-level alarm to the system administrator. This mechanism avoids alarm storms while providing timely notification of abnormal load conditions. 2. Concurrency preemption process: Concurrency preemption uses Lua scripts to ensure atomicity and accuracy. The system constructs Redis key names in the format of a digital employee real-time call record prefixed with a digital employee identifier. The Lua script receives the key name, digital employee identifier, pending lead identifier, concurrency limit, and current timestamp as parameters. The script first calculates the starting time of the sliding window, which is equal to the current timestamp minus 1200 seconds (20 minutes). Then, it performs a range deletion operation, cleaning up expired records in the ordered set whose scores are less than the window's starting time, keeping the dataset concise.Next, an interval counting operation is performed to count the number of records from the start time of the window to positive infinity, which is the current actual concurrency. The script compares the current concurrency with the concurrency limit. If it is less than the limit, an add operation is performed, writing the pending lead identifier and the current timestamp into an ordered set, and setting the expiration time of the entire key to 1800 seconds (30 minutes). It returns an array containing success identifiers and the new concurrency. If the limit is reached or exceeded, it returns an array containing failure identifiers and the current concurrency. The system calls Redis to execute this Lua script, parses the return value to determine whether the preemption was successful. If successful, the subsequent outbound call process continues; if it fails, the current processing ends. 3. Concurrency release process: Concurrency release ensures the timely return of resources: The system receives the hang-up notification, which includes a digital employee identifier and a pending lead identifier. The system constructs a Redis key with the same name as during preemption, calls the delete member operation of the ordered set, and deletes the record with the pending lead identifier as the member value. After successful deletion, the record is removed from the real-time call set, and the corresponding concurrent resources are released. The system also asynchronously updates the call statistics of digital employees, including total number of calls, number of connected calls, and call duration, for data analysis and report display. The entire release process adopts an eventual consistency model; even if deletion fails occasionally, it will eventually be automatically cleaned up due to the expiration time set for the key, preventing permanent resource occupation.

[0028] The call termination process employs a state machine pattern, executing corresponding follow-up strategies based on different call outcomes. First, it enters the resource release phase. After a call ends, the system performs a unified resource release process: a delayed execution mechanism is used to register resource release functions, ensuring cleanup is performed regardless of whether the call terminates normally or exits abnormally. First, the number call lock is released by deleting the distributed lock record in Redis with the phone number as the key, allowing the number to be called again. Then, the lead processing lock is released by deleting the distributed lock record with the lead identifier as the key, allowing the lead to be rescheduled. Next, the line service is notified to perform hang-up processing, passing parameters such as the employee ID, lead identifier, lead identifier, called number, line identifier used, and time zone. The line service releases the corresponding concurrent resources and updates statistics. Finally, the release interface of the concurrent service is asynchronously called to return concurrent resources. Asynchronous execution avoids blocking the main process and improves system response speed. Then, it enters the follow-up strategy processing state, executing corresponding follow-up strategies based on the call outcome: first, it determines the call outcome type, including not connected, connected, busy, called party hung up, etc., and calls the corresponding strategy processing function. For calls that are not connected, the system executes a global call-not-connected policy, deciding whether to recreate the pending contact record and redial based on the configuration, setting the redial delay time and priority. If it's the first call that is not connected, a special policy for first-time call-not-connected calls will also be executed, which may include changing the line or adjusting the outbound call time. For calls that are connected, the system first checks the call duration. If it's less than 3 seconds, it's considered a "hang-up" and the hang-up policy is executed, possibly marking it as an invalid lead or assigning it to a human follow-up. If the call duration is normal and there are advanced analysis results based on GPT, the system parses the intention tags and sentiment information of the dialogue content, and executes personalized policies based on the analysis results, such as immediately transferring high-intent customers to a human operator and delaying follow-up for low-intent customers. For other call results, the default policy is executed. After all policy processing is completed, the system updates the lead status, records the processing log, and triggers relevant business events, completing the closed-loop management of the entire outbound call process.

[0029] In this embodiment, at the resource scheduling and load balancing level, the task orchestration module relies on a multi-layer worker architecture and dynamically calculates load weights based on the load assessment parameters of service nodes. This ensures the immediate dominance of the current load and the auxiliary decision-making role of historical load trends through differentiated weight allocation. Furthermore, it quantifies stability risks using the load standard deviation and applies reasonable penalties. Ultimately, tasks are prioritized for allocation to nodes with low real-time load, smooth trends, and stable states. This effectively solves the resource waste and scheduling bottlenecks caused by traditional static allocation, significantly improving resource utilization while reducing load differences between service nodes, minimizing task interruptions caused by load fluctuations, and ensuring the overall stability of the system. At the concurrency control level, a multi-layer concurrency control architecture, combined with an adaptive resource allocation algorithm and Redis Lua script atomic operations, constructs a three-layer management system that globally controls the upper limit, prioritizes based on patterns, and precisely adapts capacity to individual nodes. The adaptive algorithm achieves fair and efficient allocation of concurrent resources through candidate selection, proportional allocation, and heap-optimized remainder allocation. Lua scripts ensure the atomicity of concurrent checks and allocation in distributed scenarios, completely overcoming the performance limitations of traditional database locks in high-concurrency scenarios. This supports the stable execution of large-scale concurrent outbound call tasks and, through a load alarm mechanism, monitors resource availability in real time, triggering timely administrator intervention to prevent service degradation due to system resource saturation. At the lead management level, the lead management module supports multi-source lead import and utilizes a three-layer deduplication mechanism. Real-time in-memory deduplication relies on a concurrent and safe data structure to achieve millisecond-level fast deduplication. Historical data deduplication avoids duplicate creation through precise queries, while combined field deduplication ensures lead uniqueness in complex scenarios through flexible configuration, effectively solving the problems of redundant duplicate data and fixed state transitions in traditional lead management. Simultaneously, a lead pipeline processing mechanism based on a functional programming paradigm achieves high-throughput processing of large batches of leads through asynchronous processes of filtering, mapping, batching, and parallel database entry, balancing data processing efficiency and accuracy and significantly improving the refinement of lead lifecycle management. At the level of line resource management, the line management module constructs a candidate set of lines by prioritization, combined with a seven-layer progressive availability check (covering dimensions such as regional compliance, time interval, concurrency limits, and quota control) to ensure that line resource allocation not only meets business strategies and regulatory requirements, but also avoids line overload and customer harassment. The sliding window rate limiting mechanism enables precise control of the periodic frequency of lines, smoothing traffic peaks to protect line stability. The unified resource release process after a call ends promptly returns the concurrent line usage and updates statistical data, reserving resource space for subsequent outbound call tasks, significantly improving the utilization rate of line resources and call success rate, while taking into account the needs of line quality and cost control.At the level of end-to-end closed-loop and fault tolerance, a complete business closed loop is formed, from multi-source adaptation of lead injection and multi-stage control of scheduling and outreach (pre-processing and pre-checking in the preparation stage, layered locking and atomic allocation in the resource preemption stage, and atomic state updates and reliable message sending in the execution stage), to dynamic regulation of resource management, resource release after the call ends, and result-oriented strategy execution (adapting to different scenarios such as not connected and connected based on state machine adaptation). Each link incorporates fault-tolerant designs such as delayed execution, failure retry, and automatic rollback, ensuring that resources are not leaked and tasks can be retried even in the event of anomalies. Combined with an event-driven real-time inbound call response mechanism, it ensures rapid acceptance of customer needs and efficient lead conversion, ultimately achieving high system availability, millisecond-level response speed, and high concurrency capacity, completely solving the core pain points of traditional outbound telephone systems in terms of efficiency, stability, and scalability.

[0030] Furthermore, the load assessment parameters include the current load status, historical load trend, and load stability. The steps for dynamically obtaining load weights based on the load assessment parameters of each service node in the cluster within the multi-layer worker architecture include: using the current load value, the predicted load value obtained from historical data, and the load standard deviation of each service node as assessment indicators for the current load status, historical load trend, and load stability, respectively; obtaining the preset first weight ratio, second weight ratio, and third weight ratio, where the first weight ratio (0.6) and the second weight ratio (0.4) are designed with weights of 0.6 and 0.4 based on actual load characteristics: the current load reflects the immediate state and should dominate, so it has a larger weight; the predicted load reflects the trend direction and plays an auxiliary role, so its weight is secondary, which ensures timely response to the current state and considers future trends, avoiding frequent adjustments that may be caused by relying solely on the current state; the load standard deviation is used as a stability penalty term, and the third weight ratio (0.2) is used as a penalty factor, which increases the overall weight when the node load fluctuates greatly. The scheduling priority of the node is reduced by a coefficient of 0.2, which has been experimentally optimized to reflect the importance of stability without excessively affecting the main load assessment. The current load value, predicted load value, and load standard deviation of each service node are multiplied based on the first, second, and third weight ratios to obtain the first, second, and third influence indices for each service node. These indices are then superimposed to obtain the comprehensive load assessment index for each service node. The comprehensive load assessment index of each service node is matched with a preset comprehensive load weight mapping table to obtain the corresponding comprehensive load weight. The comprehensive load weight mapping table maps the comprehensive load assessment index to specific load weight values. When a new digital employee needs to be assigned, the service node with the lowest comprehensive load weight is selected for assignment, ensuring that nodes with low real-time load, slow load increase trends, and stable loads receive tasks first.

[0031] In this embodiment, the current load value (current) represents the number of digital employees being processed by the service node at the current moment. This value is obtained by querying the worker mapping table of the service node in real time, reflecting the node's real-time working status. The larger the current load value, the more tasks the node is carrying. The predicted load value (predicted) represents the future load trend predicted based on historical data. The calculation formula is: predicted(t) = α × current(t-1) + (1-α) × predicted(t-1), where α is a smoothing coefficient with a value of 0.3, and t is the current time point. This algorithm gives higher weight to recent data, enabling it to quickly respond to load change trends while smoothing random fluctuations through historical data. The predicted load value can reflect the load development direction of the node; a high predicted value indicates that the node load is on an upward trend. The load standard deviation (stdDev) represents the standard deviation of the load value within a certain time window, used to measure the stability of the load. The system maintains the most recent 10 load sampling values ​​and calculates their standard deviation. The larger the standard deviation, the more drastic the load fluctuation and the worse the system stability. The introduction of standard deviation can identify and penalize nodes with unstable loads, avoiding the allocation of new tasks to nodes with large fluctuations. This invention uses comprehensive load weight as the scheduling basis, prioritizing the allocation of new digital employee tasks to the node with the lowest weight. The node with the lowest weight naturally possesses the triple advantages of low real-time load, slow load increase trend, and stable load status. Low real-time load means that the node currently has sufficient resources to handle new tasks, avoiding resource overload; a slow load increase trend indicates that the node's future load growth is controllable, reducing the risk of subsequent resource shortages; and stable load ensures that task execution is not easily interrupted or delayed due to fluctuations. The three factors work together to ensure that task allocation not only conforms to the current resource supply and demand situation but also takes into account long-term load balance. Practical application verification shows that this scheduling method can reduce the load difference between service nodes, reduce resource idle rate, and improve task execution success rate and shorten the overall system response latency by reducing frequent scheduling and fluctuation interference. It completely solves the core problems of traditional scheduling, which only considers real-time load leading to short-term overload, ignores historical trends leading to repeated scheduling, and ignores stability leading to task interruption. It provides key technical support for the efficient and stable operation of large-scale digital employee tasks.

[0032] Furthermore, the steps for dynamically executing the task migration process based on the acquired load weight and service node load include: acquiring a preset first coefficient and a second coefficient, where the first coefficient (0.4) and the second coefficient (1.5) are preset multipliers used for dynamically executing the task migration process. The first coefficient is set based on empirical values, allowing for a certain degree of load unevenness while promptly correcting severe load skew. The second coefficient is optimized to reduce system jitter while ensuring load balancing. Calculate the arithmetic mean of the comprehensive load weights of each service node in the cluster. Multiply the arithmetic mean based on the first coefficient to obtain a basic threshold, which represents the allowable load deviation. When the comprehensive load weight of a node exceeds this threshold, task migration is considered. Identify the service node with the smallest comprehensive load weight in the cluster and obtain its comprehensive load weight value, which represents the lightest-loaded node in the cluster and is a potential target for task migration. Multiply the obtained minimum comprehensive load weight value based on the second coefficient to obtain a minimum movement threshold. Only when the minimum comprehensive load weight value exceeds this threshold is the task migration considered. Task migration is only initiated when the load on a node is significantly higher than that of the lightest-loaded node (at least 1.5 times). This avoids unnecessary adjustments when the load is basically balanced. The larger value between the base threshold and the minimum move threshold is selected as the task migration decision threshold to ensure the reasonableness of the threshold. When the overall cluster load is high, the base threshold is larger to avoid over-migration. When the overall cluster load is low but there are individual high-loaded nodes, the minimum move threshold is larger to ensure the necessity of migration. Service nodes whose comprehensive load weight exceeds the task migration decision threshold are marked as overloaded nodes, triggering the task migration process. During the migration, the lowest-priority digital employees are selected from the overloaded nodes and migrated to the service node with the lowest current comprehensive load weight. After the migration is completed, the comprehensive load weight of each service node in the cluster is recalculated, and the task migration decision threshold is dynamically adjusted based on the updated weight value, forming a closed-loop control process of continuous monitoring and dynamic adjustment, achieving a good balance between load balancing effect and system stability.

[0033] In this embodiment, the present invention calculates a base threshold and a minimum migration threshold from two dimensions—average cluster load and lightest node load—using two optimized preset coefficients, and takes the larger of the two as the final task migration decision threshold. When the overall cluster load is high, the system uses a more lenient base threshold to avoid exacerbating system pressure due to frequent migrations; while when the overall cluster load is light but there are individual hotspots, the system uses a stricter minimum migration threshold to ensure that migration is only initiated when the load difference is significant enough, effectively suppressing unnecessary system jitter. Once a node is marked as overloaded, the system carefully selects the lowest priority task (i.e., the one with the relatively low migration cost) to migrate to the currently lightest node, thereby achieving smooth load distribution. Crucially, after each migration, the system re-evaluates the state of the entire cluster and dynamically updates the decision threshold for the next round, thus forming a closed-loop control system of continuous monitoring, intelligent decision-making, precise execution, and re-evaluation. Overall, this mechanism not only proactively and promptly corrects load skew and prevents single-point performance bottlenecks, but more importantly, through adaptive threshold strategies and cautious migration strategies, it effectively improves the overall resource utilization of the cluster while maximizing the continuity and stability of service operation, achieving the best balance between load balancing and system robustness.

[0034] Furthermore, the multi-layered concurrency control architecture of the concurrency control module includes a global layer, a mode layer, and an individual layer. The global layer controls the overall concurrency limit of the system; the mode layer distinguishes between serial mode and high-speed mode for the concurrency allocation of digital employees; and the individual layer performs fine-grained allocation based on the capacity of each digital employee. The adaptive resource allocation algorithm includes the following steps: traversing all digital employees, calculating the remaining allocable capacity of each digital employee (i.e., the maximum concurrency minus the currently used concurrency), filtering digital employees with remaining capacity greater than zero to form a candidate set, and calculating the sum of the remaining capacities of all digital employees in the candidate set as the total remaining capacity; for each digital employee in the candidate set, allocating the globally available concurrency based on the proportion of its remaining capacity to the total remaining capacity. Specifically, first calculating the capacity proportion of the digital employee, then multiplying the globally available concurrency by this proportion and rounding down to obtain the basic allocation amount. The basic allocation amount cannot exceed the remaining capacity of the digital employee. After completing the basic allocation, the allocated quantity is deducted from the global available concurrency, and the remaining allocable quantity for each digital employee is updated. The theoretical value of the basic concurrency is rounded down to obtain the integer part of the basic concurrency actually allocated to each digital employee. The allocation remainder is calculated based on the total concurrent resources and the sum of all allocated integer parts of the basic concurrency, which is the remaining value of the total concurrent resources minus the sum of all allocated integer parts of the basic concurrency. Using the remaining capacity of the digital employee as the key, a max-heap data structure is constructed, and the dynamic allocation remainder process is executed: the digital employee with the largest remaining capacity is extracted from the max-heap, the allocation of concurrency is increased for that digital employee, the remaining capacity of that digital employee is updated, and the remaining capacity of that digital employee is decremented by one; it is determined whether the remaining capacity of the digital employee is greater than 0. If so, it is reinserted into the max-heap, and the allocation remainder is decremented by one. Otherwise, the digital employee is removed from the max-heap. The dynamic allocation remainder process is executed repeatedly until the allocation remainder is 0 or the capacity of all digital employees is saturated, ensuring that all pending concurrency is fully allocated.

[0035] In this embodiment, the multi-level architecture first refines the concurrency strategy level by level, from the system-wide level and business model level down to the individual digital employee level, ensuring the integrity and flexibility of control granularity. Based on this, the adaptive allocation algorithm achieves optimal resource allocation through a two-step strategy: First, the algorithm iterates through all digital employees and fairly allocates the basic concurrency (rounded down) according to the proportion of each employee's remaining capacity to the total remaining capacity, ensuring the rationality and fairness of the allocation at a macro level. Second, for any remaining resources that may arise after the first step, the algorithm innovatively introduces a max-heap data structure with remaining capacity as the key, dynamically and iteratively allocating these scattered resources to the digital employee with the largest current remaining capacity. This strategy cleverly solves the resource fragmentation problem that may be caused by simple proportional allocation, driving the system to continuously converge towards a load-balanced state, thereby achieving full utilization of resources and maximizing global efficiency at the micro level. This invention not only strictly protects the overall concurrency limit of the system to prevent overload, but also ensures, through dynamic and adaptive allocation logic, that resources can be accurately, efficiently and fairly delivered to the processing units that need them most under high concurrency pressure. Thus, while ensuring system stability, it significantly improves the overall outbound call throughput and resource utilization efficiency.

[0036] Furthermore, the steps for implementing distributed atomic concurrency control using Redis Lua scripts include: storing real-time call records of digital employees in a Redis sorted set, using the call start timestamp as the score and the pending lead identifier as the member value; the concurrency check and allocation process is executed atomically in the Lua script to ensure data consistency in a distributed environment; calculating the start time of the time window, using the interval counting function of the Redis sorted set to count the number of call records within the time window as the current actual concurrency; determining whether the current concurrency is less than the preset concurrency limit; if so, writing the current lead identifier and timestamp into the sorted set, setting an expiration time, and returning an allocation success identifier and the new concurrency; otherwise, returning an allocation failure identifier and the current concurrency.

[0037] In this embodiment, the present invention maintains a dynamic time window precisely in a Redis ordered set, using timestamps as the order. Each record within the window represents an ongoing call. When a new concurrency quota needs to be allocated, the entire process—including calculating the window start point, counting the current concurrency, comparing it with a preset threshold, deciding whether to write a new record, and returning the result—is fully written in a Lua script and executed atomically by a single thread on the Redis server. This fundamentally eliminates race conditions and data inconsistencies (such as over-allocation) caused by network latency or interleaved operations in a distributed multi-node environment. Simultaneously, by utilizing the native interval statistics and expiration cleanup capabilities of ordered sets, the concurrency count is real-time, accurate, and efficiently stored. With extremely low performance overhead, this invention achieves strong consistency control and millisecond-level response for distributed concurrency states, ensuring that the system strictly and accurately adheres to preset concurrency limit rules under any high concurrency pressure, providing a solid technical foundation for the stable and compliant operation of outbound call services.

[0038] Furthermore, the clue status flow mechanism in the clue management module includes three states: pending processing, processing, and completed. The processing state can branch to the terminated or interrupted state. The three-layer deduplication mechanism includes real-time memory deduplication, historical data deduplication, and combined field deduplication. These three mechanisms work together to ensure the accuracy and completeness of deduplication while also considering performance and flexibility. Real-time memory deduplication imports batch clue data using a synchronous mapping table structure. For each new clue, it checks whether the phone number already exists in the phone number deduplication table. If it does, it is marked as duplicate and an error message is recorded. A unique key is generated based on the configured deduplication field combination. It checks whether this unique key already exists in the combined deduplication table. If it does, it is determined to be a duplicate clue. If it does not exist, the unique key is inserted into the combined deduplication table, and the clue is allowed to enter the subsequent processing flow. Through fast memory-level lookup, millisecond-level deduplication response is achieved, effectively avoiding duplicate data within the same batch. Historical data deduplication follows the in-memory deduplication check of leads. It then queries the database for historical lead data within a specified time range, using criteria including employee ID numbers, phone numbers, and configured deduplication fields. Precise matching is performed based on the data type of the business attributes (string, integer, date, etc.). If the query results show that historical data already exists, the creation of this lead is rejected; otherwise, the historical deduplication check is passed. Combined field deduplication supports deduplication based on multiple business fields, which are flexibly configured by the user. The configured deduplication field list is traversed, the actual value of each field is extracted, and key-value pair string fragments are constructed. All fragments are sorted lexicographically to ensure that identical data generates the same unique key. The sorted fragments are then connected with a delimiter to form the final unique key used for deduplication, ensuring field order independence and efficient searching.

[0039] In this embodiment, the present invention constructs a complete management closed loop from process to data, achieving refined, efficient, and highly reliable control over the entire lifecycle of leads. At the process level, a clear state transition mechanism provides each lead with a clear and controllable lifecycle path, making business processing visible and traceable, and flexibly responding to complex business scenarios such as call interruptions and customer rejections, ensuring the rigor and adaptability of the process. At the data level, an original three-layer deduplication mechanism constitutes a progressive, three-dimensional defense system: real-time memory deduplication first performs millisecond-level filtering during data import, using a synchronous mapping table to quickly eliminate duplicate leads within the same batch, greatly improving initial processing efficiency; historical data deduplication then prevents the repeated creation of leads across batches and time periods through precise matching with database historical records, ensuring the long-term uniqueness of data; and combined field deduplication provides high business flexibility, supporting users to customize deduplication rules according to various business attributes, and ensuring the stability and efficiency of generating unique keys through sorting and concatenation technology. These three layers of mechanisms are interconnected, achieving comprehensive coverage from instantaneous memory to persistent storage, and from simple phone number comparison to complex business logic matching. Ultimately, the close integration of processes and data enables the system to automatically filter out unique, effective, and high-quality leads from a massive influx of leads from multiple sources, and guide them through each processing stage in an orderly manner. This fundamentally eliminates data redundancy, resource waste, and status chaos, maximizing the utilization of lead resources and achieving intelligent operation and management.

[0040] Furthermore, the specific steps of the priority-based line scheduling algorithm in the line management module include: obtaining the line configuration information bound to digital employees; storing the configuration using an ordered mapping structure, where the key is the priority value (the smaller the value, the higher the priority), and the value is a list of lines under that priority. Each line configuration includes parameters such as line identifier, concurrency limit, and geographic location priority; traversing the line set sequentially from high to low priority; for each priority level's line list, grouping them according to the matching of the called number's location and the line's geographic attributes: lines with geographic location priority and matching location, lines with geographic location priority but matching location... For lines with mismatched locations and lines without geographical location restrictions, a dynamic combination operation is performed based on the priority of each group of lines. Each group of lines is randomly shuffled to avoid uneven load caused by a fixed order. Then, these three groups of lines are combined according to priority, with lines with matching locations being tried first. The availability of the line list after the current priority dynamic combination operation is checked. If a line passes all checks, it is assigned. If all lines of the current priority fail the checks but are not unavailable for the current day, they are waited for retry. If they are confirmed to be unavailable for the current day, they are downgraded to the next priority line list to continue the allocation attempt.

[0041] In this embodiment, the invention first traverses available lines from high to low according to a preset priority order (the smaller the value, the higher the priority), ensuring that high-value lines are used first. Within each priority level, the system further intelligently groups lines based on the geographical attributes of the called number's location and the lines, and randomly shuffles each group of lines to avoid load imbalance caused by a fixed order. Finally, the system dynamically reassembles the attempt sequence for this level according to the principle of geographical matching priority. This process closely integrates business priority strategy with call effectiveness optimization. Subsequently, the system performs strict availability checks (such as concurrency and frequency limits) on each line in the sequence to quickly locate the best available line at the current moment. If there are no available lines for the current priority, the system can intelligently distinguish between temporary unavailability and unavailability for the day, and make reasonable decisions based on this, such as waiting for retry or downgrading to the next priority level. This not only maximizes the utilization rate of line resources and the overall connection rate of outbound calls, but also significantly enhances the system's ability to cope with single-point failures and traffic fluctuations through dynamic load balancing and graceful degradation mechanisms, ensuring the efficient and stable operation of outbound call services.

[0042] Furthermore, the sliding window rate limiting mechanism includes the following steps: calculating the start time of the current time window based on the current time and the window size (current time minus window size); using the interval deletion operation of the ordered set to clean up historical records before the start time of the window, keeping the dataset minimal; using the set cardinality operation to obtain the number of records in the current window, determining whether the number is less than a preset threshold, if so, allowing the outbound call and adding the new record to the ordered set with an appropriate expiration time; otherwise, rejecting the request. This achieves precise time window control, ensures concurrency safety through Redis's atomic operations, avoids data accumulation through an automatic cleanup mechanism, and achieves smooth flow control through the sliding window algorithm, making it more accurate and fairer than the fixed window algorithm.

[0043] In this embodiment, the invention calculates the starting boundary of the sliding window in real time and automatically cleans up expired data using the interval deletion function of ordered sets, thereby ensuring the minimization of storage space and the real-time accuracy of the calculation results. When each outbound call request arrives, the mechanism compares the number of existing records within the window with a preset threshold in real time, and atomically decides whether to allow the request and update the set based on the comparison result. This series of operations is encapsulated in Redis atomic commands, fundamentally eliminating counting race conditions in high-concurrency scenarios and ensuring strong consistency and concurrency safety in traffic judgment. Compared to traditional fixed-window algorithms, this sliding window design allows the time window to move smoothly in real time with requests, not only eliminating potential traffic surges at fixed window boundaries but also making traffic limiting more uniform and fair across any continuous time period, achieving true smooth rate limiting. Overall, the invention achieves precise frequency control, reliable data consistency maintenance, and system self-protection with minimal computational and storage overhead, effectively preventing the line from triggering operator risk control due to overloaded calls and ensuring the continuous compliance and stable operation of outbound call services.

[0044] like Figure 3 The diagram shows a flowchart of a dynamic task orchestration method for telephone lead lifecycle management provided in this application embodiment. The method dynamically obtains load weights based on load evaluation parameters of each service node within a multi-layer worker architecture cluster. Based on the obtained load weights and service node loads, a task migration process is dynamically executed to balance load balancing effects and system stability. An adaptive resource allocation algorithm combining proportional allocation and heap optimization is used, with distributed atomic concurrent control implemented through Redis Lua scripts. A lead status transition mechanism and a three-layer deduplication mechanism are used to achieve efficient, accurate, and complete management of the entire lead lifecycle. Before outbound calls are executed, availability checks are performed on candidate lines, a priority-based line scheduling algorithm is used for intelligent allocation of line resources, and a sliding window rate limiting mechanism is used for periodic frequency control of the lines.

[0045] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0046] This invention is described with reference to flowchart illustrations and / or block diagrams of systems, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0047] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0048] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0049] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.

[0050] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A dynamic task orchestration system for telephone lead lifecycle management, characterized in that, It includes a task orchestration module, a concurrency control module, a thread management module, and a route management module: The task orchestration module adopts a multi-layer worker architecture, which is used to dynamically obtain load weights based on the load evaluation parameters of each service node in the cluster in the multi-layer worker architecture, and dynamically execute the task migration process based on the obtained load weights and service node loads to balance the load balancing effect and system stability. The concurrency control module adopts a multi-layer concurrency control architecture, which is used to implement distributed atomic concurrency control through Redis's Lua scripts based on an adaptive resource allocation algorithm that combines proportional allocation and heap optimization. The clue management module supports multi-source clue import methods and is used to achieve efficient, accurate and complete management of the entire life cycle of clues based on the clue status flow mechanism and the three-layer deduplication mechanism. The line management module is used to check the availability of candidate lines before outbound calls are executed, implement intelligent allocation of line resources based on priority-based line scheduling algorithm, and implement periodic frequency control of lines using sliding window rate limiting mechanism.

2. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 1, characterized in that, The multi-layer worker architecture of the task orchestration module includes a scheduler manager, digital employee workers, and a processor structure. The scheduler manager is responsible for the unified scheduling of global tasks. The digital employee workers allocate an independent instance to each digital employee. The processor includes an outbound call processor, an SMS processor, and a microprocessor. The underlying layer implements service node registration, load monitoring, and intelligent scheduling through a cluster manager.

3. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 1, characterized in that, The load assessment parameters include the current load status, historical load trends, and load stability. The steps for dynamically obtaining load weights based on load evaluation parameters of each service node in a cluster within a multi-layer worker architecture include: The current load value, the predicted load value obtained from historical data, and the load standard deviation of each service node are used as evaluation indicators for the current load status, historical load trend, and load stability, respectively. Obtain the preset first weight ratio, second weight ratio, and third weight ratio; The current load value, predicted load value, and load standard deviation of each service node are processed based on the first weight ratio, the second weight ratio, and the third weight ratio respectively to obtain the first influence index, the second influence index, and the third influence index of each service node. The comprehensive load assessment index of each service node is obtained by superimposing the first impact index, the first impact index, and the first impact index of each service node. The comprehensive load assessment index of each service node is matched with the preset comprehensive load weight mapping table to obtain the corresponding comprehensive load weight. The comprehensive load weight mapping table is a correspondence table that maps the comprehensive load assessment index to specific load weight values. When new digital employees need to be assigned, the service node with the lowest overall load weight is selected for assignment.

4. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 3, characterized in that, The steps of the dynamic task migration process based on the acquired load weight and service node load include: Obtain the preset first and second coefficients; Calculate the arithmetic mean of the overall load weights of each service node in the cluster; The arithmetic mean is processed based on the first coefficient to obtain the basic threshold. Identify the service node with the lowest overall load weight in the cluster and obtain its overall load weight value; The minimum comprehensive load weight value is processed based on the second coefficient to obtain the minimum movement threshold; The larger value between the base threshold and the minimum movement threshold is selected as the task migration determination threshold; Service nodes whose overall load weight exceeds the task migration judgment threshold are marked as overloaded nodes, triggering the task migration process. During the migration process, the lowest priority digital employees are selected from the overloaded nodes and migrated to the service node with the lowest current overall load weight. After the migration is completed, the overall load weight of each service node in the cluster is recalculated, and the task migration judgment threshold is dynamically adjusted based on the updated weight value.

5. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 1, characterized in that, The multi-layer concurrency control architecture of the concurrency control module includes a global layer, a pattern layer, and an individual layer. The adaptive resource allocation algorithm includes the following steps: Iterate through all digital employees, calculate the remaining allocable capacity for each digital employee, filter digital employees with remaining capacity greater than zero to form a candidate set, and calculate the sum of the remaining capacity of all digital employees in the candidate set as the total remaining capacity. For each digital employee in the candidate set, allocate the number of globally available concurrent connections based on the proportion of its remaining capacity to the total remaining capacity. The theoretical value of the base concurrency is rounded down to obtain the integer part of the base concurrency for each digital employee; The allocation remainder is calculated based on the total concurrent resources and the integer parts of all allocated basic concurrent resources; Using the remaining capacity of digital employees as the key, construct a max-heap data structure and execute a dynamic allocation process for the remainder: Extract the digital employee with the largest remaining capacity from the max-heap, increase the concurrency allocation for that digital employee, and update the remaining capacity of that digital employee. Determine if the remaining capacity of the digital employee is greater than 0. If so, reinsert the digital employee into the max-heap and decrement the allocation remainder by one. Otherwise, remove the digital employee from the max-heap. The dynamic allocation remainder process is executed repeatedly until the allocation remainder is 0 or all digital employee capacity is saturated.

6. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 1, characterized in that, The steps for implementing distributed atomic concurrency control using Redis's Lua scripts include: The real-time call records of digital employees are stored in a Redis sorted set, with the call start timestamp as the score and the pending lead identifier as the member value. The concurrency check and allocation process is executed atomically in Lua scripts to ensure data consistency in a distributed environment. Calculate the start time of the time window, count the number of call records within the time window, and use this as the current actual concurrent number. Determine if the current concurrency is less than the preset concurrency limit. If so, write the current thread identifier and timestamp into an ordered set, set the expiration time, and return a success message and the new concurrency. Otherwise, return the allocation failure flag and the current concurrency level.

7. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 1, characterized in that, The clue status flow mechanism in the clue management module includes a waiting state, a processing state, and a completed state. The processing state can branch and flow to the terminated state or the interrupted state. The three-layer deduplication mechanism includes real-time memory deduplication, historical data deduplication, and combined field deduplication. The real-time memory deduplication process imports batches of clue data using a synchronous mapping table structure. For each new clue, it checks whether the phone number already exists in the phone number deduplication table. If it does, it is marked as duplicate and an error message is recorded. Generate a unique key based on the configured deduplication field combination. Check if the unique key already exists in the combined deduplication table. If it exists, it is determined to be a duplicate clue. If it does not exist, insert the unique key into the combined deduplication table and allow the clue to enter the subsequent processing flow. The historical data deduplication process involves querying historical clue data within a specified time range in the database after the clues have passed the memory deduplication check. The query conditions include digital employee identifiers, mobile phone numbers, and a configured combination of deduplication fields. The system performs exact matching based on the data type of the business attributes. If the query results show that the historical data already exists, the creation of this lead is rejected; otherwise, a deduplication check is performed based on the historical data. The combined field deduplication supports deduplication based on multiple business fields. It iterates through the configured deduplication field list, extracts the actual value of each field, and constructs a string fragment in the form of key-value pairs. All fragments are sorted lexicographically, and the sorted fragments are connected with a delimiter to form the final unique key for deduplication, ensuring that the field order is irrelevant and the search is efficient.

8. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 1, characterized in that, The specific steps of the priority-based line scheduling algorithm in the line management module include: Obtain the line configuration information bound to the digital employee. The configuration is stored in an ordered mapping structure, where the key is the priority value and the value is a list of lines under that priority. The line set is traversed sequentially from high to low priority. For each priority level of the line list, the lines are grouped according to the matching of the called number's location and the line's geographical attributes, and a dynamic combination operation is performed based on the priority of each group of lines. Perform an availability check on the list of lines after the current priority dynamic combination operation. If a line passes all checks, then allocate that line. If all lines of the current priority fail the check but are not unavailable for the current day, wait for a subsequent retry; If it is confirmed that the line is unavailable for the day, it will be downgraded to the next priority line list to continue the allocation attempt.

9. The dynamic task orchestration system for telephone lead lifecycle management as described in claim 1, characterized in that, The specific steps of the sliding window rate limiting mechanism include: Calculate the start time of the current time window based on the current time point and the window size; Clear the history prior to the window's start time; Get the number of records in the current window, and determine whether the number is less than a preset limit threshold. If so, allow the outbound call and add the new record to the ordered set; otherwise, reject the request.

10. A dynamic task orchestration method for telephone lead lifecycle management, applied to the dynamic task orchestration system for telephone lead lifecycle management as described in any one of claims 1-9, characterized in that, Specifically, it includes; The load weight is dynamically obtained based on the load evaluation parameters of each service node in the cluster in the multi-layer worker architecture. The task migration process is dynamically executed based on the obtained load weight and service node load to balance the load balancing effect and system stability. An adaptive resource allocation algorithm based on a combination of proportional allocation and heap optimization is used to implement distributed atomic concurrency control through Redis's Lua scripts; Based on the clue status transition mechanism and the three-layer deduplication mechanism, efficient, accurate and complete management of the entire life cycle of clues can be achieved; Before making outbound calls, the availability of candidate lines is checked, a priority-based line scheduling algorithm is used to achieve intelligent allocation of line resources, and a sliding window rate limiting mechanism is used to achieve periodic frequency control of the lines.

Images