A method and system for collaborative response to customer demand

Abstract

This invention relates to the technical field of customer demand response management, and provides a method and system for collaborative response to customer demands. The method includes: receiving and storing resource reservation declarations submitted by processing units to obtain resource pre-occupancy information of the processing units; monitoring and recording the dwell time of customer demands in the processing stage; when the dwell time exceeds a preset threshold, querying the resource reservation declarations to determine whether corresponding resource pre-occupancy information exists in the processing stage, and obtaining a resource pre-occupancy judgment result; if the resource pre-occupancy judgment result indicates existence, updating the status of the customer demand to a specific status indicating the reason for resource pre-occupancy; when the customer demand is in the specific status indicating the reason for resource pre-occupancy, suppressing the triggering of preset downstream processes, thereby realizing the identification and handling of process anomalies in collaborative response to customer demands. This invention has the advantage of improving the accuracy and efficiency of process anomaly handling.

Description

Technical Field

[0001] This invention relates to the technical field of customer demand response management, and specifically to a collaborative response method and system for customer demands. Background Technology

[0002] In the realm of collaborative customer demand response, enterprises typically employ multi-stage, cross-departmental collaborative processes to handle customer needs, ensuring efficient response and problem resolution. To effectively manage these complex processes, existing systems generally incorporate status monitoring mechanisms, evaluating process efficiency by setting standard durations for each processing stage. When the actual dwell time of a customer demand at a certain processing stage exceeds a preset threshold, the system usually marks it as an anomaly to alert managers and prompt intervention.

[0003] However, when the processing capacity of a certain stage in the process continuously declines due to resources being occupied by high-priority tasks or unexpected reasons, a large number of customer requests become stuck at that stage for an extended period. The system will mark these requests as process anomalies based on fixed time threshold rules. This anomaly marking often triggers standardized response processes in downstream or related stages. For example, it may prompt frontline customer service personnel to reconfirm the original request information. Although these response processes generate new data records (such as "reconfirmation communication completed"), these records do not stem from substantial progress of the request at the bottleneck stage, nor do they address the root cause of the request delay (i.e., resource saturation or capacity decline at the processing stage). This repeated state reset and ineffective loop not only causes the system to exhibit high-frequency state oscillations on the end-to-end status monitoring interface, making it difficult for managers to accurately grasp the true processing status of requests and process bottlenecks, but also generates a large amount of state change data with no business value, seriously affecting the system's data consistency and reliability. Consequently, the system cannot accurately reveal the true collaborative bottlenecks and may even mask the truth of the problem.

[0004] To address the aforementioned issues, existing technologies urgently need improvement. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this application provides a customer demand collaborative response method and system, which has the advantages of accurately identifying process anomalies caused by resource pre-occupancy, effectively suppressing unnecessary downstream process triggering, avoiding repeated oscillations in system state and data redundancy, and improving the accuracy and efficiency of process anomaly handling.

[0006] This application provides a collaborative response method for customer needs, the key technical points of which are: A collaborative response method for customer needs includes: Receive and store the resource reservation declaration submitted by the processing unit to obtain the resource pre-occupancy information of the processing unit; Monitor and record the time customer requests spend in the processing stage; When the dwell time exceeds the preset threshold, query the resource reservation declaration, determine whether there is corresponding resource pre-occupancy information in the processing stage, and obtain the resource pre-occupancy judgment result. If the resource pre-occupancy determination result indicates that it exists, then the status of the customer's demand will be updated to a specific status indicating the reason for the resource pre-occupancy. When a customer's demand is in a specific state indicating the reason for resource pre-occupancy, the triggering of a preset downstream process is suppressed, so as to identify and handle process anomalies in the collaborative response to customer demands.

[0007] The above solution can accurately identify process anomalies caused by resource pre-occupancy, effectively suppress unnecessary downstream process triggering, avoid repeated oscillations in system state and data redundancy, and improve the accuracy and efficiency of process anomaly handling.

[0008] To further address the issue, this application also proposes a step whereby, if the resource pre-occupancy determination result indicates existence, updating the status of the customer's demand to a specific status indicating the reason for resource pre-occupancy includes: If the resource pre-occupancy determination result indicates that it exists, the status of the customer's request will be updated to a specific status indicating the reason for the resource pre-occupancy, and a status lock identifier will be attached to the data record of the customer's request; the status lock identifier contains the service identifier that generated the status lock; When a modification attempt occurs corresponding to the status of a customer's request, check whether the data record of the customer's request has a status lock identifier, and obtain the identifier check result. If the identifier check result indicates that it exists, then the service identifier in the state lock identifier is compared with the identifier of the system module corresponding to the attempted modification behavior to obtain the identifier comparison result; If the identifier comparison result indicates that the identifiers are inconsistent, the system module's attempt to modify the identifier will be prevented. When the resource pre-occupancy information corresponding to a customer's request is detected to be invalid or the customer's request has been transferred to the next processing stage, the status lock flag is released.

[0009] The above solution, by introducing state lock identification and comparison mechanisms, further enhances the protection of customer demand states, effectively preventing other system modules from mistakenly or invalidally modifying the demand states while resources are pre-occupied, thus ensuring the accuracy and consistency of the states.

[0010] To improve the solution, this application also proposes that when the resource pre-occupancy information corresponding to a customer's request is detected to be invalid or the customer's request has been transferred to the next processing stage, the steps to release the state lock flag include: When the pre-occupancy information of the resources corresponding to the customer's demand is detected to be invalid, the actual resource status information of the processing unit is obtained. During the preset observation window, continuously receive actual resource status information; Based on the actual resource status information, determine whether the resources of the processing unit have been actually released, and obtain the release judgment result; If the release judgment result indicates that it has been actually released, then the state lock flag is removed; If the release determination result indicates that the lock has not actually been released, then the state lock identifier is maintained. Alternatively, the status lock can be released when the customer's request has moved to the next processing stage.

[0011] The above solution provides a more refined state lock release mechanism. In particular, by monitoring the actual resource status and judging the observation window, it ensures that the state lock is only released after the resource is actually released or the demand is actually transferred, thus avoiding repeated problems caused by premature release.

[0012] To further address the problem, this application also proposes that the steps for obtaining the actual resource status information of the processing unit include: Establish data channels with the internal workflow system or personnel management system of the processing unit; The current task load data or current personnel availability data of the processing unit are obtained through the data channel as actual resource status information.

[0013] The above solution clarifies the specific ways to obtain actual resource status information. By establishing a data channel with the internal system, more accurate and real-time task load or personnel availability data can be obtained, thereby improving the reliability of resource status judgment.

[0014] To improve the solution, this application also proposes a setting procedure for the preset observation window period, including: Obtain the reserved task types contained in the resource pre-occupancy information; Based on the reserved task type, select the observation window parameters from the preset observation window configuration set; Based on the observation window parameters, set the preset observation window period.

[0015] The above solution enables dynamic and intelligent setting of the observation window period, and adjusts the observation duration according to the reserved task type, making the judgment on resource release more flexible and in line with actual business scenarios.

[0016] To further address this issue, this application also proposes a step for determining whether the resources of the processing unit have been actually released based on actual resource status information, and obtaining the release determination result, including: Obtain the resource types of the processing unit and the corresponding resource release standards for each resource type; Obtain specific resource status information corresponding to the resource type from the actual resource status information received within the preset observation window period; Based on the resource release criteria corresponding to the resource type and specific resource status information, it is determined whether the resource has been actually released, and the resource release judgment result of the processing unit is obtained.

[0017] The above scheme provides a judgment method based on resource type and release criteria, which makes the judgment of resource release more accurate and standardized, and avoids the limitations of single threshold judgment.

[0018] To improve the solution, this application also proposes a step for determining whether the resources of the processing unit have been actually released, and obtaining the release determination result of the resources: Based on resource type, identify the key resource types of the processing unit; Determine whether key resource types have been actually released, and obtain the key release determination result; If the key release judgment result indicates that the resource has been actually released, then the release judgment result of the processing unit is determined to be that the resource has been actually released. If the key release judgment result indicates that the resource was not actually released, then the resource release judgment result of the processing unit is determined to be not actually released.

[0019] The above solution introduces the concept of key resource types, enabling resource release decisions to focus on core resources that have the greatest impact on business, thus improving the efficiency and accuracy of the decisions and avoiding interference from the status of non-key resources.

[0020] To further address the problem, this application also proposes that the steps for identifying the key resource types of the processing unit include: Obtain the current business scenario information or current customer demand type information of the processing unit; Based on business scenario information or customer demand type information, obtain the matching resource importance configuration; Based on resource importance allocation, the key resource types of the processing unit are identified.

[0021] The above solution enables dynamic identification of key resource types and flexibly configures the importance of resources according to the current business scenario or customer needs, allowing the system to better adapt to different business requirements and priorities.

[0022] To improve the solution, this application also proposes steps for obtaining the current business scenario information or current customer demand type information of the processing unit, including: Establish data interfaces with the business systems of the processing unit; Through the data interface, the type label or business priority identifier of the task being processed by the processing unit can be obtained in real time, which can be used as information about the current business scenario or the current customer demand type.

[0023] The above solution clarifies the specific technical approaches to obtaining information on business scenarios and customer needs. By connecting with the data interface of the business system, it ensures the real-time nature and accuracy of the information, providing a reliable data foundation for the identification of key resources.

[0024] A customer demand collaborative response system for performing customer demand collaborative response includes: The resource occupancy acquisition module is used to receive and store the resource reservation declaration submitted by the processing unit in order to obtain the resource pre-occupancy information of the processing unit; The dwell time monitoring module is used to monitor and record the dwell time of customer needs during the processing stage; The resource occupancy judgment module is used to query the resource reservation declaration when the dwell time exceeds the preset threshold, determine whether there is corresponding resource pre-occupancy information in the processing stage, and obtain the resource pre-occupancy judgment result. The demand status update module is used to update the status of customer demand to a specific status indicating the reason for resource pre-occupancy if the resource pre-occupancy judgment result indicates that it exists. The suppression trigger response module is used to suppress the triggering of preset downstream processes when customer requests are in a specific state indicating the reason for resource pre-occupancy, so as to realize the identification and handling of process anomalies in the collaborative response to customer requests.

[0025] The above solution provides a system architecture for implementing the above method. Through modular design, the functions of identifying and handling process anomalies in customer demand collaborative response can be effectively implemented, improving the maintainability and scalability of the system.

[0026] In summary, the customer demand collaborative response method and system provided in this application, by introducing resource pre-occupancy information identification, specific state updates, and downstream process suppression mechanisms, can distinguish between process stagnation caused by resource bottlenecks and general anomalies, thereby avoiding invalid process triggering and state oscillations. This ensures the accuracy and efficiency of the system's collaborative response to customer demands. It has the advantages of accurately identifying process anomalies caused by resource pre-occupancy, effectively suppressing unnecessary downstream process triggering, avoiding repeated oscillations of system state and data redundancy, and improving the accuracy and efficiency of process anomaly handling. Attached Figure Description

[0027] Figure 1 This is a flowchart of a customer demand collaborative response method in one embodiment of the present invention; Figure 2This is one of the flowcharts of a collaborative response method for customer needs in another embodiment of the present invention; Figure 3 This is a second flowchart of a customer demand collaborative response method according to another embodiment of the present invention; Figure 4 This is the third flowchart of a customer demand collaborative response method in another embodiment of the present invention; Figure 5 This is the fourth flowchart of a customer demand collaborative response method in another embodiment of the present invention; Figure 6 This is the fifth flowchart of a customer demand collaborative response method in another embodiment of the present invention; Figure 7 This is a system block diagram of a customer demand collaborative response system according to another embodiment of the present invention; Explanation of reference numerals in the attached figures: 1. Customer demand collaborative response system; 11. Resource usage acquisition module; 12. Dwell time monitoring module; 13. Resource usage judgment module; 14. Demand status update module; 15. Suppression trigger response module. Detailed Implementation

[0028] The technical solutions of this application will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments. The components of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0029] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this application, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] Traditional customer demand collaborative response systems face a challenge in monitoring the status and data consistency of multi-stage processes. When the processing capacity of a certain stage in the process declines unexpectedly, causing the customer's demand to remain at that stage for longer than a preset standard, the system marks it as an anomaly. However, this anomaly marking may trigger standardized response processes in other stages. While these processes generate new data records, they do not substantially advance the demand. The upper-level status aggregation module may incorrectly interpret this non-substantial data as a signal of process recovery, leading to repeated resets of the demand status, thus masking the true process bottleneck and creating data consistency issues. Specifically, the current technical challenge is how to effectively distinguish between misleading status change data generated by system-human interactions and valid status change data that truly reflects the progress of demand processing, thereby avoiding the system from getting stuck in an ineffective loop of repeated state jumps and accurately identifying the real bottlenecks in the process caused by declining processing capacity.

[0031] In response, this application proposes a collaborative response method for customer needs, combining... Figure 1 As shown, it includes: S1, Receive and store the resource reservation declaration submitted by the processing unit to obtain the resource pre-occupancy information of the processing unit; S2, monitors and records the time customer requests spend in the processing stage; S3, when the dwell time exceeds the preset threshold, query the resource reservation declaration, determine whether there is corresponding resource pre-occupancy information in the processing step, and obtain the resource pre-occupancy judgment result; S4, If the resource pre-occupancy judgment result indicates that it exists, then update the status of the customer's demand to a specific status indicating the reason for the resource pre-occupancy; S5, when a customer's demand is in a specific state indicating the reason for resource pre-occupancy, suppresses the triggering of preset downstream processes, so as to identify and handle process anomalies in the collaborative response to customer demands.

[0032] Resource reservation declarations are formal notifications submitted by processing units to the system before executing high-priority or specific tasks, declaring their intention to occupy or the status of occupied resources. These declarations can take various forms, such as structured data packets submitted via API interfaces, pre-allocation records in resource management systems, or pre-occupancy information manually entered into a specific management interface. The purpose is to enable the system to obtain resource pre-occupancy information in advance, providing a basis for subsequently determining the reasons for customer demand stagnation. Furthermore, resource pre-occupancy information refers to specific data extracted from resource reservation declarations regarding the pre-allocation or occupation of processing unit resources. This can include the type of occupied resource, occupation duration, priority of the occupied task, and expected release time. Its purpose is to clearly identify that processing unit resources have been planned for other tasks within a specific time period, thus helping the system distinguish between normal resource scheduling waits and genuine process anomalies. Additionally, preset thresholds are upper limits set by the system for the dwell time of customer demands at a specific processing stage. When the actual dwell time exceeds this standard, the system considers the demand potentially abnormal. It can be configured in various ways, such as average processing time based on historical data statistics, time limits dynamically adjusted according to business priorities, or fixed time values ​​manually configured by the system administrator. Its purpose is to serve as a trigger condition for initially determining whether customer needs are stalled or abnormal. Furthermore, a specific state refers to a unique status identifier updated by the system when a customer need is identified as stalled due to resource pre-occupancy. This state differs from a general "process abnormality" state; it explicitly indicates that the stall is due to resource pre-occupancy. It can be represented as a specific enumerated value in a status field in the database, an additional label, or an independent Boolean flag. Its purpose is to accurately distinguish different types of process stalls, avoid misjudging normal waiting caused by resource pre-occupancy, and prevent triggering unnecessary downstream processes. Finally, suppressing the triggering of preset downstream processes means that when a customer need is in a specific state indicating the reason for resource pre-occupancy, the system actively blocks or suspends subsequent processing steps or notification mechanisms that would normally start automatically when the need status is abnormal. This can include blocking automatically sent reminder notifications, suspending automatic transfer to the next stage, or preventing the triggering of standardized troubleshooting processes by other teams. The purpose is to avoid invalid data interactions and state changes during resource pre-occupancy, prevent the system from getting stuck in repeated state reset loops, thereby maintaining data consistency and accurately identifying the real process bottlenecks.

[0033] This application's solution employs a collaborative mechanism designed to accurately identify genuine bottlenecks in customer request processing flows, avoiding misjudgments and ineffective operations caused by resource pre-occupancy. First, the system receives and stores resource reservation declarations from various processing units, containing information on resource pre-occupancy within each unit. This allows the system to anticipate resource allocation within each unit, such as which teams or equipment have been pre-occupied by high-priority tasks. Simultaneously, the system continuously monitors and records the actual dwell time of each customer request at each processing stage. This monitoring is dynamic, ensuring the system can promptly detect any potential request stalls. When a customer request's dwell time at a processing stage exceeds a preset threshold, the system does not immediately flag it as a general anomaly and trigger downstream processes. Instead, it first queries previously stored resource reservation declarations to determine if corresponding resource pre-occupancy information exists at the current processing stage. This determination is crucial, as it distinguishes between two different types of stalls: normal waiting due to processing unit resources being pre-occupied by other high-priority tasks, and genuine process efficiency issues or anomalies. If the assessment indicates resource pre-occupancy, the system updates the customer's request status to a specific state indicating the reason for the resource pre-occupancy. This specific state clearly informs the system and relevant personnel that the current stagnation of the request is due to resource pre-occupancy, not insufficient processing capacity or process failure. It is precisely because of this precise status identification that the system can avoid misjudging normal resource scheduling waits as process anomalies. Based on this, when a customer's request is in this specific state indicating the reason for resource pre-occupancy, the system intelligently suppresses the triggering of preset downstream processes. This means that standardized response processes that would normally be automatically initiated upon detecting general process anomalies, such as automatic reminders, sending progress update requests to the customer, or triggering other teams to investigate, will not be executed. This suppression mechanism is the core of this solution; it prevents invalid data interaction and status changes caused by misjudgment, and avoids the system falling into the repeated state reset loop described in the background technology. In this way, this solution achieves accurate identification and handling of process anomalies in collaborative response to customer requests, ensuring the authenticity of the system status and the consistency of data, thereby accurately revealing the real bottleneck caused by a decline in processing capacity.

[0034] In some preferred embodiments, this method is implemented as follows. In an enterprise-level customer service management system, when a customer submits a technical support request, the request enters a multi-stage processing flow, such as from "acceptance" to "technical analysis" and then to "spare parts scheduling." The system maintains a "resource pre-occupancy registration form," which records information on the core resources reserved by each technical team as a processing unit for undertaking urgent projects. For example, when the "technical analysis team" is assigned to execute a large-scale equipment upgrade and renovation project, the team leader submits a resource reservation declaration through the system interface, declaring that a large portion of the team's technical backbone will be occupied by the project in the future, along with the project priority and expected occupancy duration. The system receives and stores this resource pre-occupancy information. Simultaneously, a monitoring service in the system continuously tracks the dwell time of each customer request in the "technical analysis" stage. For example, the service records the timestamp of the request entering the "technical analysis" queue and calculates its dwell time in real time. When a regular customer request lingers in the "Technical Analysis" stage for longer than a preset threshold—for example, exceeding 1.5 times the standard processing time for that stage—the system will not immediately mark it as a "process anomaly." Instead, it will first query the "Resource Pre-occupancy Registration Form" to determine if the "Technical Analysis Team" currently has resource pre-occupancy information. If the query results show that the "Technical Analysis Team" does indeed have resource pre-occupancy due to an urgent project, the system will update the customer request's status to the specific "Resource Pre-occupancy Awaiting" status. This status differs from the regular "Process Anomaly" status, as it clearly indicates the reason for the stagnation. When a customer request is in the "Resource Pre-occupancy Awaiting" status, the system will activate a process inhibition logic. For example, the system will prevent the automatic sending of "Request Anomaly Investigation" notifications to the frontline customer service team, will not automatically trigger "Customer Progress Update" emails, and will not reset the request's status back to "Pending Analysis" to start a new loop. Instead, the request will remain in the "Resource Pre-occupancy Awaiting" status until the resource pre-occupancy is resolved or the request is actually processed. In this way, the system avoids invalid communication and data recording caused by resource pre-occupancy, ensures the accuracy of system status, and provides a real basis for subsequent resource scheduling and process optimization.

[0035] Optional, combined Figure 2 As shown, if the resource pre-occupancy determination result indicates that it exists, the step of updating the status of the customer's demand to a specific status indicating the reason for resource pre-occupancy includes: S41, if the resource pre-occupancy judgment result indicates that it exists, then update the status of the customer's demand to a specific status indicating the reason for the resource pre-occupancy, and attach a status lock identifier to the data record of the customer's demand; the status lock identifier contains the service identifier that generated the status lock; S42, When a modification attempt occurs corresponding to the status of a customer's request, check whether the data record of the customer's request has a status lock identifier and obtain the identifier check result; S43, if the identifier check result indicates that it exists, then compare the service identifier in the state lock identifier with the identifier of the system module corresponding to the attempted modification behavior to obtain the identifier comparison result; S44. If the identifier comparison result indicates that the identifiers are inconsistent, then the system module's attempt to modify the identifier is prevented. S45, when the resource pre-occupancy information corresponding to the customer's request is detected to be invalid or the customer's request has been transferred to the next processing stage, the status lock flag is released.

[0036] Here, a customer requirement data record refers to a structured entity within the system that encapsulates all information related to customer requirements. This can be a row in a database table, an entry in a distributed ledger, or an object in in-memory data storage. Its purpose is to serve as a central repository for all attributes and historical events of customer requirements. A state lock identifier is a data element or flag attached to or associated with a customer requirement data record, indicating that the record is currently protected and restricting unauthorized modifications. It can be a boolean field, a specific status code, a reference to a separate lock object, or a JSON field containing lock metadata. Its purpose is to provide a clear mechanism for marking the restricted access status of customer requirement data records. A service identifier that generates the state lock is a string, numeric code, or enumeration value used to identify a specific service, application, or system component that sets the state lock on the customer requirement data record. It can be a service name, service ID, microservice instance ID, or user ID. Its purpose is to explicitly specify which entity has control over the state lock, thereby achieving owner-based access control. An attempt to modify refers to any attempt to change the value of one or more fields in a customer requirement data record. The operations can originate from data submissions from the user interface, API calls from other automated systems, or data updates from background batch processing tasks. The purpose is to cover all actions that may cause changes to customer request data. The system module identifier refers to the identification information of the system component or application that initiates the modification attempt. It can be the name of a calling service, module ID, API key, or user credentials. Its purpose is to identify the source of the modification attempt for comparison with the service identifier recorded in the state lock identifier. Resource pre-occupancy information invalidation means that the initial conditions that caused the customer request to be marked as resource pre-occupancy no longer exist. This could be that the pre-occupied resource has been released, the pre-occupied task has been completed, or the pre-occupancy time window has expired. Its purpose is to indicate that the customer request no longer needs to maintain the resource pre-occupancy status, thus removing the restriction on its data recording. Customer request has been transferred to the next processing stage means that the customer request has successfully moved from the current processing stage to the next processing stage in the business process. This could be an update of the system status field, a flow event from the process engine, or a confirmation operation by relevant business personnel. Its purpose is to indicate that the customer request has entered the subsequent processing stage and no longer needs the state lock protection of the current stage.

[0037] In some preferred embodiments, this application is implemented as follows. When the time a customer's request spends in the technical analysis stage exceeds a preset threshold, and the system determines that the technical analysis team has pre-occupied resources—for example, when the team's core technical personnel are assigned to execute a high-priority emergency upgrade project—the system will update the status of the customer's request to "Resource pre-occupation pending coordination." Simultaneously, the system will attach a status lock identifier to the data record of the customer's request. This status lock identifier can be a JSON object, such as {"lock_status": "locked", "locked_by_service":"ResourceCoordinationService"}, where "ResourceCoordinationService" is the service identifier that generated this status lock.

[0038] When a system module of the frontline customer service team attempts to modify a customer request that is in a "resource pre-occupancy pending coordination" state—for example, by attempting to update the "communication record" field—the system will first intercept the modification request. Before processing the request, the system will check whether a state lock identifier exists in the customer request's data record. If a state lock identifier is detected, the system will further extract the value of the "locked_by_service" field (e.g., "ResourceCoordinationService") from the state lock identifier and compare it with the identifier of the frontline customer service team's system module that initiated the modification request (e.g., "CustomerServiceModule"). Because "ResourceCoordinationService" and "CustomerServiceModule" are inconsistent, the system will prevent the frontline customer service team's system module from attempting to modify the request and may return a "resource locked, cannot be modified" message.

[0039] The system detects when a technical analysis team completes an emergency upgrade project and its resource pre-allocation information becomes invalid, or when a customer's request, after coordination, is manually or automatically transferred to the next processing stage (such as the "solution development stage"). Once the conditions are met, the system automatically removes the status lock flag on the customer's request data record. For example, it updates {"lock_status": "locked", "locked_by_service": "ResourceCoordinationService"} to {"lock_status": "unlocked"} or removes the flag altogether, thus allowing subsequent routine modifications and workflow.

[0040] Optional, combined Figure 3As shown, when S45 detects that the resource pre-occupancy information corresponding to the customer's request has expired or the customer's request has been transferred to the next processing stage, the steps to release the state lock flag include: S451, when the resource pre-occupancy information corresponding to the customer's demand is detected to be invalid, the actual resource status information of the processing unit is obtained; S452 continuously receives actual resource status information within a preset observation window period; S453, based on the actual resource status information, determine whether the resources of the processing unit have been actually released, and obtain the release judgment result; S454, if the release judgment result indicates that it has been actually released, then release the state lock flag; S455, if the release judgment result indicates that it has not been actually released, then keep the state lock flag; S456, or, when the customer request has moved to the next processing stage, release the status lock flag.

[0041] The acquisition of actual resource status information of the processing unit refers to the system interacting with the processing unit to obtain data reflecting its current resource usage and availability. For example, this can be achieved by querying the processing unit's internal task scheduling system, resource management platform, or personnel scheduling system to obtain information such as the current task queue length, number of tasks in progress, idle processing capacity, or personnel online status and workload. The purpose is to obtain more immediate and accurate resource usage information than pre-occupancy information, avoiding judgment errors due to information lag. The preset observation window period refers to the system not making an immediate judgment after detecting the failure of resource pre-occupancy information, but setting a continuous time period during which the system continuously collects and analyzes the actual resource status information of the processing unit. For example, it can be based on historical data... The window period is dynamically configured based on data analysis, business experience, or task type. Its purpose is to provide a buffer and verification time to ensure the stability and representativeness of the acquired resource status information, thereby avoiding judgment errors caused by instantaneous fluctuations or data delays. Determining whether the resources of the processing unit have been actually released means that the system, based on the actual resource status information collected during the observation window period, uses preset logic or rules to evaluate whether the resources of the processing unit have truly changed from an occupied state to an available state, and draws a clear judgment conclusion. For example, it can be by comparing the current task load with a preset idle threshold, or by checking whether specific resources (such as personnel or equipment) have been removed from the task queue. Its purpose is to provide a fact-based basis to determine the subsequent processing of the status lock identifier.

[0042] In some preferred embodiments, this application is implemented as follows: Assuming a customer demand collaborative response system, when a customer demand is pre-allocated resources by a technical analysis team, the system attaches a status lock identifier to the demand. When the resource pre-allocation information of the technical analysis team expires for some reason (e.g., the pre-allocation time expires, or the pre-allocated task is canceled), the system does not immediately release the status lock identifier. Specifically, the system first obtains the actual resource status information of the team by establishing a data channel with the task management system used by the technical analysis team. For example, it can obtain the current task queue length, the number of tasks being processed, and the online status and available working hours of team members. Subsequently, the system enters a preset observation window period, for example, set to 5 minutes. During this observation window period, the system continuously receives the actual resource status information of the technical analysis team from the task management system at a preset frequency (e.g., every 30 seconds). After the observation window period ends, the system determines whether the resources of the technical analysis team have been actually released based on the collected actual resource status information. For example, if the team's pending task queue length has dropped to zero or below a preset threshold, and all key members are shown as available, the resource is considered to have been actually released. If the release determination indicates actual release, the system will remove the state lock flag on the customer request, allowing other system modules or processes to perform normal operations on the request. However, if the release determination indicates that the resource has not been actually released—for example, even though the pre-occupancy information has expired, but the technical analysis team's task queue is still long, or key members are still busy—the system will maintain the state lock flag. This ensures that even if the pre-occupancy information has expired, as long as the resource is not truly idle, the state lock flag can continue to play its protective role, preventing undue modification of the customer request's status. Alternatively, as a supplementary mechanism, even if the technical analysis team's resource pre-occupancy information has not expired, if the system detects that the customer request has been explicitly moved to the next processing stage (e.g., spare parts scheduling) through some means (e.g., manual intervention or special process), the system will also immediately remove the state lock flag on the customer request. This is because once the demand enters a new processing stage, the resource pre-occupancy issue that the original state lock flag was targeting is no longer the focus of the current stage. Releasing the state lock flag can avoid causing unnecessary obstacles to subsequent processes.

[0043] Optionally, the steps for obtaining the actual resource status information of the processing unit include: Establish data channels with the internal workflow system or personnel management system of the processing unit; The current task load data or current personnel availability data of the processing unit are obtained through the data channel as actual resource status information.

[0044] Among these, a data channel refers to a connection mechanism used to transmit data between different systems, which can be implemented using application programming interfaces (APIs), message queues, direct database connections, or file transfer protocols. An internal workflow system refers to a software system within the processing unit used to manage and coordinate various task flows; it can record information such as task allocation, execution status, and completion status. A personnel management system refers to a software system within the processing unit used to manage human resource information; it can record information such as personnel on-duty status, skills, current task assignments, and idle time. Current task load data reflects the number of tasks currently being processed by the processing unit, the complexity of the tasks, or the estimated completion time; it can be used to assess the resource utilization of the processing unit. Current personnel availability data reflects the current working status of personnel within the processing unit, whether they are idle, and whether they have been assigned other tasks; it can be used to assess whether the processing unit's human resources are available for new tasks.

[0045] In some preferred embodiments, when the system needs to obtain the actual resource status information of the technical analysis team, it can first establish API interfaces with the task allocation system (as an internal workflow system) and the attendance management system (as a personnel management system) used by the team. Specifically, the API interface can be configured to automatically request the length of the current pending task queue and the average estimated processing time of each task from the task allocation system every five minutes as current task load data. Simultaneously, the API interface can also request the online status of the current technical analysis team members and the current task allocation status from the attendance management system as current personnel availability data. For example, if the task allocation system returns a pending task queue length of zero and no high-priority tasks, while the attendance management system shows that most technical personnel are idle, the system can determine that the technical analysis team's resources have been actually released. In this way, the system can obtain a resource status view, thereby accurately determining whether resource pre-occupancy information has expired and promptly releasing the status lock flag.

[0046] Optional, the steps for setting the preset observation window include: Obtain the reserved task types contained in the resource pre-occupancy information; Based on the reserved task type, select the observation window parameters from the preset observation window configuration set; Based on the observation window parameters, set the preset observation window period.

[0047] Resource pre-occupancy information refers to data records generated by the system when pre-locking or allocating resources for customer needs. This information may include reserved task type, reserved resource identifier, and reserved time. Reserved task type refers to the classification of specific business activities or operations related to resource pre-occupancy. It can be divided according to business nature, resource consumption characteristics, or expected processing time, for example, into types such as "emergency fault handling," "routine maintenance," and "system upgrade." Its purpose is to provide a basis for dynamically adjusting the observation window period. The preset observation window configuration set refers to a predefined data structure or database that stores the mapping relationship between different reserved task types and corresponding observation window parameters. For example, it can be a key-value pair set or a lookup table, and its purpose is to provide configuration data for dynamically setting the observation window period. Observation window parameters refer to the specific values ​​or rules used to define the observation window period. These may include the duration of the observation window, the starting offset, or the multiple sampling interval, and their purpose is to guide the system on how to accurately set the monitoring time range for resource release.

[0048] In some preferred embodiments, this solution is implemented as follows: Assume a customer service system where the processing unit reserves resources for different types of customer needs. For example, for a "online consultation" type need, the processing unit can reserve one customer service agent resource; for a "technical troubleshooting" type need, the processing unit can reserve one senior engineer resource. When the system detects that the resource reservation information corresponding to a customer need has expired—for example, the customer has ended the online consultation, but the system still needs to confirm whether the customer service agent has actually been released—the system will first obtain the reserved task type from the resource reservation information of that customer need, for example, identifying the task type as "online consultation." Subsequently, the system will search within a preset observation window configuration set based on this "online consultation" reserved task type. This configuration set can be a database table that stores the mapping relationship between different task types and corresponding observation window parameters. For example, it can be configured as follows: "online consultation" corresponds to an observation window parameter of 10 seconds; "technical troubleshooting" corresponds to an observation window parameter of 60 seconds; and "system maintenance" corresponds to an observation window parameter of 300 seconds. Based on the found "online consultation" task type, the system selects its corresponding observation window parameter, which is 10 seconds. Ultimately, the system sets a preset observation window period of 10 seconds based on this 10-second parameter. Within this observation window, the system continuously receives actual resource status information from customer service agents to determine whether the agent has actually been released. In this way, the system can flexibly adjust the monitoring duration for resource release according to the characteristics of different tasks, ensuring that the judgment of resource status is neither too hasty leading to misjudgment nor too lengthy causing unnecessary waiting, thereby improving the efficiency of resource management and process response.

[0049] Optionally, the steps for determining whether the resources of the processing unit have been actually released based on the actual resource status information, and obtaining the release determination result, include: Obtain the resource types of the processing unit and the corresponding resource release standards for each resource type; Obtain specific resource status information corresponding to the resource type from the actual resource status information received within the preset observation window period; Based on the resource release criteria corresponding to the resource type and specific resource status information, it is determined whether the resource has been actually released, and the resource release judgment result of the processing unit is obtained.

[0050] Among them, resource type refers to the different kinds of resources possessed by the processing unit, specifically human resources, equipment resources, software license resources, or storage resources, etc., with the aim of finely classifying the complex resource composition of the processing unit; resource release standard refers to the pre-set conditions or thresholds for each resource type to determine whether that type of resource is no longer occupied, specifically the quantitative definition of task completion status, equipment idle rate, license usage, or storage space occupancy rate, with the aim of providing accurate release basis for resources of different natures; preset observation window period refers to a predetermined time period during which the system continuously collects resource status data, with the aim of ensuring the timeliness and completeness of resource status information and avoiding judgments based on instantaneous or outdated data; actual resource status information refers to the raw data obtained from the processing unit within the observation window period, reflecting its current resource usage, with the aim of providing an objective basis for resource release judgment; specific resource status information refers to the status data directly related to the specific resource type, filtered or extracted from the actual resource status information, with the aim of focusing on key information related to the resource type to be judged and improving the pertinence of the judgment.

[0051] In some preferred embodiments, this application is implemented as follows. Assuming the processing unit is a team responsible for technical analysis, when its pre-occupied resource information becomes invalid, the system needs to determine whether the team's resources have actually been released. First, the system can obtain the resource types of the technical analysis team. For example, it can identify that the team mainly relies on resources including "technical personnel resources," "professional analysis software license resources," and "dedicated testing equipment resources." Simultaneously, the system can obtain the resource release criteria corresponding to each resource type: for "technical personnel resources," the release criteria can be set as "the average task load of team members is lower than a preset threshold, and there are no urgent tasks pending"; for "professional analysis software license resources," the release criteria can be set as "the concurrent usage of the software is lower than a certain percentage of the license capacity"; for "dedicated testing equipment resources," the release criteria can be set as "the continuous idle time of the equipment exceeds a preset duration."

[0052] Subsequently, within a pre-defined observation window, the system can continuously receive actual resource status information from the technical analysis team. This information can include real-time task allocation data for team members, concurrent user statistics for professional analysis software, and operation logs of dedicated testing equipment. The system can extract specific resource status information for each resource type from this actual resource status information. For example, it can extract the current task load of each technician from the task allocation data as specific status information for "technical personnel resources"; obtain the current number of concurrent users of the software from software usage statistics as specific status information for "professional analysis software license resources"; and analyze the idle time of the equipment from the equipment operation logs as specific status information for "dedicated testing equipment resources."

[0053] Finally, the system can determine whether each resource has been actually released based on the resource release criteria and specific resource status information corresponding to each resource type. For example, if the average workload of all technical personnel is below a threshold and there are no urgent tasks, the "technical personnel resource" is determined to be released; if the software concurrent usage is below a set percentage, the "professional analysis software license resource" is determined to be released; if the dedicated testing equipment has been idle for more than a preset duration, the "dedicated testing equipment resource" is determined to be released. Only when all these key resource types are determined to have been actually released can the system conclude that the resources of the technical analysis team have been actually released. This meticulous judgment method ensures that the processing unit's resources are indeed no longer occupied before the status lock is released, thus avoiding misjudgments.

[0054] Optional, combined Figure 4 As shown, the steps to determine whether the resources of the processing unit have been actually released and to obtain the release determination result include: A1, based on resource type, identifies the key resource types of the processing unit; A2, determine whether the key resource type has been actually released, and obtain the key release judgment result; A3, if the key release judgment result indicates that the resource has been actually released, then the release judgment result of the processing unit is determined to be actually released. A4. If the key release judgment result indicates that the resource has not been actually released, then the release judgment result of the processing unit is determined to be that the resource has not been actually released.

[0055] Among them, key resource types refer to resource categories that have a decisive impact on task completion, process advancement, or business continuity during the execution of tasks by the processing unit. They can be identified through a preset resource importance configuration table, dynamic identification based on business scenarios or customer needs, or manual configuration. The purpose is to focus resource release judgments on core resources with significant business impact, avoiding interference from the release status of non-core resources. The key release judgment result refers to the output information determining whether the identified key resource type has reached the actual release state. It can be represented as a Boolean value, such as true or false, yes or no, or an enumerated value, such as released or not released, or a status code. Its purpose is to clearly indicate the release status of key resources, serving as the basis for subsequent overall resource release judgments.

[0056] In some preferred embodiments, this application is implemented as follows. Assume a processing unit is a technical support team. This team needs to utilize various resources when handling customer requests, such as core technical personnel, dedicated testing equipment, general office space, and auxiliary tool software licenses. When determining whether the technical support team's resources have been actually released, the system first identifies core technical personnel and dedicated testing equipment as critical resource types based on a preset resource importance configuration. This is because the availability of core technical personnel and the idle status of dedicated testing equipment directly determine whether the team can accept new high-priority tasks. Subsequently, the system will determine the release status of these critical resource types. For example, the system can query the task queue of core technical personnel to determine whether they have completed all currently assigned tasks and are in an idle state; simultaneously, it can query the reservation system of dedicated testing equipment to determine whether it has been released from occupancy and is in an available state. Based on these query results, the system obtains the critical release judgment result. If the critical release judgment result indicates that both core technical personnel and dedicated testing equipment have been actually released, then even if non-critical resources such as general office space or auxiliary tool software licenses have not been completely released from occupancy, the system will determine that the technical support team's resources have been actually released and can accept new customer requests. Conversely, if the critical release judgment result indicates that at least one of the core technical personnel or dedicated testing equipment has not yet been actually released, the system will determine that the resources of the technical support team have not yet been actually released, and the customer's needs will continue to remain in a waiting state until the critical resources are released.

[0057] Optional, combined Figure 5 As shown, the step of identifying the key resource types of the processing unit in step A1 includes: A11, obtain the current business scenario information or current customer demand type information of the processing unit; A12, based on business scenario information or customer demand type information, obtain the matching resource importance configuration; A13, based on resource importance allocation, identifies the key resource types of the processing unit.

[0058] Among them, obtaining the current business scenario information or current customer demand type information of the processing unit refers to specific data reflecting the nature, priority or business domain of the task currently undertaken by the processing unit. This can be achieved by using task classification tags, project numbers, customer level identifiers, service level agreement (SLA) requirements, etc., with the aim of providing contextual basis for subsequent resource importance assessment. Resource importance configuration refers to predefined or dynamically adjusted rules or datasets used to measure the importance of different resource types in specific business scenarios or customer needs. It can be implemented using mapping tables stored in a database, configuration files, or weight parameters dynamically generated by machine learning models. Its purpose is to provide quantitative or qualitative judgment criteria for accurately identifying key resources.

[0059] In some preferred embodiments, this application is implemented as follows: Assume a technical analysis team handles two main types of tasks: routine equipment maintenance requests and emergency system upgrade projects. First, the system obtains the business scenario information of the tasks currently being handled by the technical analysis team. For example, if the team is handling an "emergency system upgrade project," the system will obtain the corresponding business scenario tag. Next, based on the obtained "emergency system upgrade project" business scenario information, the system queries a pre-defined resource importance configuration database for matching configurations. In this configuration, it may be defined that in the "emergency system upgrade project" scenario, "Senior Architect" and "Dedicated Diagnostic Software License" are marked as "extremely high" importance, while "Junior Technician" and "General Office Software" are marked as "low" importance. Finally, based on the queried resource importance configurations, the system identifies the key resource types of the current technical analysis team as "Senior Architect" and "Dedicated Diagnostic Software License." When it is necessary to determine whether the technical analysis team's resources have been actually released, the system will focus on whether these identified key resources have been removed from the project or are available, rather than simply checking all resource types. For example, even if a junior technician is idle, the system will not determine that the team's resources have actually been released as long as the senior architect is still occupied.

[0060] Optional, combined Figure 6 As shown, the steps for A11 to obtain the current business scenario information or current customer demand type information of the processing unit include: A111, Establish a data interface with the business system of the processing unit; A112, through the data interface, instantly obtains the type label or business priority identifier of the task being processed by the processing unit, which serves as information about the current business scenario or the current customer demand type.

[0061] The data interface refers to the connection mechanism used to enable data exchange and communication between different systems. This can be achieved through APIs (Application Programming Interfaces), message queues, direct database connections, or file transfers, aiming to ensure efficient data transmission between the processing unit's business system and the resource management system. The type label refers to text or coded information used to classify and identify tasks processed by the processing unit. This can be a predefined classification marker indicating the task's nature, project, or service category, clarifying its business attributes so the system can differentiate its processing based on task type. The business priority identifier is a numerical or symbolic representation used to measure the importance or urgency of tasks processed by the processing unit. This can be expressed through preset priority levels (e.g., high, medium, low), urgency codes, or Service Level Agreements (SLAs), guiding the system to prioritize resources needed for critical tasks. The business system refers to the software system that manages the processing unit's core business processes daily. This can include task management systems, work order systems, project management systems, or customer relationship management (CRM) systems, providing functions such as task processing, status updates, and data recording, serving as the source of real-time business information.

[0062] In some embodiments, this application is implemented as follows: To obtain the current business scenario information or current customer demand type information of the processing unit, firstly, a data interface is established with the processing unit's business system. For example, this data interface can be a RESTful API interface, allowing the resource management system to send requests and receive responses to the processing unit's work order management system (as a type of business system) via HTTP / HTTPS protocol. Alternatively, the data interface can also be a message queue, such as Apache Kafka, where the processing unit's business system publishes task information as a message to a specific topic when the task status changes, and the resource management system subscribes to that topic to receive it immediately. Through this data interface, the resource management system can immediately obtain the type label or business priority identifier of the task processed by the processing unit. For example, when the processing unit (e.g., a technical support team) processes a customer request in the work order management system, the request will be assigned a type label, such as "urgent fault repair," "routine consultation," or "new feature request," and will also have a business priority identifier, such as "P1 (highest priority)," "P2 (high priority)," or "P3 (medium priority)." The resource management system uses established data interfaces, such as calling the API interface of the work order management system, to instantly query the list of currently processed work orders and extract the type tag and business priority identifier for each work order. These instantly obtained type tags and business priority identifiers are then used by the system as information about the current business scenario or the current customer demand type, thereby providing an updated and unbiased data foundation for subsequent resource importance configuration.

[0063] A customer demand collaborative response system for executing customer demand collaborative responses, combined with Figure 7 As shown, the customer demand collaborative response system 1 includes: The resource occupancy acquisition module 11 is used to receive and store the resource reservation declaration submitted by the processing unit in order to obtain the resource occupancy information of the processing unit; The dwell time monitoring module 12 is used to monitor and record the dwell time of customer needs during the processing stage; The resource occupancy judgment module 13 is used to query the resource reservation declaration when the dwell time exceeds the preset threshold, determine whether there is corresponding resource pre-occupancy information in the processing stage, and obtain the resource pre-occupancy judgment result. The demand status update module 14 is used to update the status of the customer demand to a specific status indicating the reason for the resource pre-occupancy if the resource pre-occupancy judgment result indicates that it exists. The suppression trigger response module 15 is used to suppress the triggering of preset downstream processes when customer demand is in a specific state indicating the reason for resource pre-occupancy, so as to realize the identification and handling of process abnormalities in the collaborative response to customer demand.

[0064] The resource occupancy acquisition module is responsible for collecting and storing information about the pre-reservation or occupation of processing unit resources. It can take the form of a data interface component to interact with external systems, receive resource reservation declarations, and store them in an internal database or cache. Its purpose is to establish a preliminary understanding of resource usage at each processing stage, providing foundational data for subsequent anomaly detection. The dwell time monitoring module is responsible for continuously tracking and recording the actual dwell time of customer requests at each processing stage. It can take the form of a timer service or event listener to record timestamps when customer requests enter and leave specific processing stages and calculate their duration within the stage. Its purpose is to monitor the progress of customer requests in the process in real time and identify potential process stalls or bottlenecks. The resource occupancy judgment module is responsible for analyzing whether abnormal customer dwell time is caused by resource pre-occupancy, based on resource pre-occupancy information. It can take the form of a logic judgment engine to receive abnormal signals from the dwell time monitoring module and call the resource occupancy acquisition module to store the information. The system compares and analyzes stored data to output judgment results, aiming to accurately pinpoint the root cause of process anomalies and distinguish between anomalies caused by resource pre-occupancy and other reasons. The requirement status update module is responsible for modifying the status identifier of customer requirements in the system based on the resource occupancy judgment results. It can take the form of a status management service, calling the database operation interface based on the output of the resource occupancy judgment module to update the status field of customer requirements to a predefined specific status value. Its purpose is to clearly mark abnormal requirements caused by resource pre-occupancy and provide clear instructions for subsequent targeted processing. The suppression trigger response module is responsible for preventing or delaying the automatic triggering of preset downstream processes when customer requirements are marked as abnormal states of resource pre-occupancy. It can take the form of process control components or message queue filters to intercept or modify events or messages that would originally trigger downstream processes, preventing them from being executed in a specific state. Its purpose is to prevent process anomalies caused by resource pre-occupancy from further deteriorating, avoid invalid operations and data inconsistencies, and ensure that system behavior remains synchronized with the actual business state.

[0065] In some preferred embodiments, this customer demand collaborative response system can be deployed as a distributed microservice architecture. Specifically, the resource occupancy acquisition module can be a standalone microservice that subscribes to resource reservation events published by an Enterprise Resource Planning (ERP) system, project management system, or human resource management system via a RESTful API or message queue. Resource reservation claims received by this module, such as a time slot reserved for a high-priority project for a specific technical team, are parsed and stored in a NoSQL database, such as MongoDB, for fast querying. The dwell time monitoring module can be an event stream processing component, such as using Apache Kafka as a message bus. When customer demands flow between different processing stages, state change events are generated. This module subscribes to these events and starts a timer for each demand at each stage. The data from these timers can be stored in an in-memory database such as Redis to support real-time queries. The resource occupancy judgment module can be a business logic service that continuously listens for abnormal dwell time alerts issued by the dwell time monitoring module. When an alert is received, this module queries the resource occupancy acquisition module to check whether there is active resource pre-occupancy information in the corresponding processing stage. For example, if the technical analysis phase's requirement dwell time is too long, this module will query the technical analysis team to see if there are any ongoing reserved tasks causing resource strain. The requirement status update module can be a transactional service. When the resource occupancy judgment module confirms that the anomaly is caused by resource pre-occupancy, this module will update the customer requirement's status field in the main business database to "Resource Pre-occupancy Pending" or "High-priority Task Blocked" through database transaction operations. Simultaneously, it will attach a status lock identifier to the customer requirement's data record, containing the service identifier that generated this status lock, such as "ResourceLockService-001". The trigger suppression response module can be an interceptor of a process orchestration engine or a message routing rule engine. When a customer requirement is marked as "Resource Pre-occupancy Pending," any event attempting to trigger the downstream process of that requirement (e.g., an instruction automatically dispatched to the logistics stage) will be intercepted by this module. This module will check the requirement's status lock identifier and compare it with the identifier of the system module corresponding to the attempted modification behavior. If the identifiers are inconsistent, the attempt to modify the behavior is prevented, thereby avoiding the initiation of unnecessary downstream processes. For example, it prevents the logistics team from attempting to schedule spare parts before the technical analysis is completed, thus ensuring the logical consistency of the process.

[0066] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A collaborative response method for customer needs, characterized in that, include: Receive and store the resource reservation declaration submitted by the processing unit to obtain the resource pre-occupancy information of the processing unit; Monitor and record the time customer requests spend in the processing stage; When the dwell time exceeds a preset threshold, the resource reservation declaration is queried to determine whether there is corresponding resource pre-occupancy information in the processing step, and the resource pre-occupancy judgment result is obtained. If the resource pre-occupancy determination result indicates that it exists, then the status of the customer's demand will be updated to a specific status indicating the reason for the resource pre-occupancy. When a customer's demand is in a specific state that indicates the reason for the pre-occupancy of resources, the triggering of a preset downstream process is suppressed, so as to identify and handle process anomalies in the collaborative response to customer demands. The step of updating the status of the customer's demand to a specific status indicating the reason for resource pre-occupancy if the resource pre-occupancy determination result indicates that it exists includes: If the resource pre-occupancy determination result indicates that it exists, the status of the customer's demand will be updated to a specific status indicating the reason for the resource pre-occupancy, and a status lock identifier will be attached to the data record of the customer's demand; the status lock identifier includes the service identifier that generated the status lock; When a modification attempt occurs corresponding to the status of a customer's request, check whether the status lock identifier exists in the data record of the customer's request, and obtain the identifier check result. If the identifier check result indicates that it exists, then the service identifier in the state lock identifier is compared with the identifier of the system module corresponding to the attempted modification behavior to obtain the identifier comparison result; If the identifier comparison result indicates that the identifiers are inconsistent, then the system module's current attempt to modify the identifier is prevented. When the resource pre-occupancy information corresponding to the customer's request is detected to be invalid or the customer's request has been transferred to the next processing stage, the status lock identifier is released.

2. The customer demand collaborative response method according to claim 1, characterized in that, The step of releasing the state lock identifier when the resource pre-occupancy information corresponding to the customer's request is detected to be invalid or the customer's request has been transferred to the next processing stage includes: When the resource pre-occupancy information corresponding to the customer's demand is detected to be invalid, the actual resource status information of the processing unit is obtained. During the preset observation window period, the actual resource status information is continuously received; Based on the actual resource status information, determine whether the resources of the processing unit have been actually released, and obtain the release determination result; If the release determination result indicates that the release has actually occurred, then the state lock identifier is released; If the release determination result indicates that the lock has not actually been released, then the state lock identifier is retained; Alternatively, the status lock flag can be released when the customer's request has moved to the next processing stage.

3. The customer demand collaborative response method according to claim 2, characterized in that, The step of obtaining the actual resource status information of the processing unit includes: Establish a data channel with the internal workflow system or personnel management system of the processing unit; The current task load data or current personnel availability data of the processing unit are obtained through the data channel and used as the actual resource status information.

4. The customer demand collaborative response method according to claim 2, characterized in that, The steps for setting the preset observation window period include: Obtain the reserved task types contained in the resource pre-occupancy information; Based on the reserved task type, select observation window parameters from the preset observation window configuration set; Based on the observation window parameters, the preset observation window period is set.

5. The customer demand collaborative response method according to claim 2, characterized in that, The step of determining whether the resources of the processing unit have been actually released based on the actual resource status information, and obtaining the release determination result, includes: Obtain the resource types of the processing unit and the resource release standards corresponding to each resource type; From the actual resource status information received within the preset observation window period, obtain the specific resource status information corresponding to the resource type; Based on the resource release standard corresponding to the resource type and the specific resource status information, it is determined whether the resource has been actually released, and the resource release judgment result of the processing unit is obtained.

6. The customer demand collaborative response method according to claim 5, characterized in that, The step of determining whether the resource has been actually released and obtaining the release determination result of the processing unit includes: Based on the resource types, the key resource types of the processing unit are identified; Determine whether the key resource type has been actually released to obtain the key release determination result; If the key release judgment result indicates that the resource has been actually released, then the release judgment result of the processing unit's resource is determined to be actually released. If the key release judgment result indicates that the resource was not actually released, then the release judgment result of the processing unit is determined to be that the resource was not actually released.

7. A customer demand collaborative response method according to claim 6, characterized in that, The step of identifying the key resource types of the processing unit includes: Obtain the current business scenario information or current customer demand type information of the processing unit; Based on the business scenario information or the customer demand type information, obtain the matching resource importance configuration; Based on the resource importance configuration, the key resource types of the processing unit are identified.

8. The customer demand collaborative response method according to claim 7, characterized in that, The step of obtaining the current business scenario information or current customer demand type information of the processing unit includes: Establish a data interface with the business system of the processing unit; Through the data interface, the type label or business priority identifier of the task processed by the processing unit can be obtained in real time as the current business scenario information or the current customer demand type information.

9. A customer demand collaborative response system, used to execute customer demand collaborative response, characterized in that, include: The resource occupancy acquisition module is used to receive and store the resource reservation declaration submitted by the processing unit in order to obtain the resource pre-occupancy information of the processing unit; The dwell time monitoring module is used to monitor and record the dwell time of customer needs during the processing stage; The resource occupancy judgment module is used to query the resource reservation declaration when the dwell time exceeds a preset threshold, determine whether there is corresponding resource pre-occupancy information in the processing stage, and obtain the resource pre-occupancy judgment result. The demand status update module is used to update the status of the customer demand to a specific status indicating the reason for the resource pre-occupancy if the resource pre-occupancy judgment result indicates that it exists. It is also used to update the status of the customer demand to a specific status indicating the reason for the resource pre-occupancy if the resource pre-occupancy judgment result indicates that it exists, and to attach a status lock identifier to the data record of the customer demand; the status lock identifier includes the service identifier that generated the status lock; When a modification attempt occurs corresponding to the status of a customer's request, check whether the status lock identifier exists in the data record of the customer's request, and obtain the identifier check result. If the identifier check result indicates that it exists, then the service identifier in the state lock identifier is compared with the identifier of the system module corresponding to the attempted modification behavior to obtain the identifier comparison result; If the identifier comparison result indicates that the identifiers are inconsistent, then the system module's current attempt to modify the identifier is prevented. When the resource pre-occupancy information corresponding to the customer's request is detected to be invalid or the customer's request has been transferred to the next processing stage, the status lock identifier is released. The suppression trigger response module is used to suppress the triggering of preset downstream processes when customer requests are in a specific state indicating the reason for resource pre-occupancy, so as to realize the identification and handling of process anomalies in the collaborative response to customer requests.

Images