Cross-border customer service work order automatic preprocessing and shunting system based on rule engine

Abstract

The application discloses a kind of based on rule engine's cross-border customer service work order automatic pre-processing and shunting system, comprising: event standardization module, heterogeneous original event is uniformly processed;Composite event detection module, through calculating causal strength and adaptive sliding window, time series correlation events are merged into single work order;Adaptive pre-processing module, cold start stage uses deterministic rule, after data is sufficient, switch to thompson sampling decision, automatically execute retry, synchronization and other actions;Dynamic shunting module, comprehensive customer service load, skill matching degree and work order dynamic priority calculate matching cost and distribute;Closed-loop feedback module, build event causal diagram, spread root cause identification and automatically clean up derivative work order, continuously optimize decision parameters by counterfactual reasoning.The application can effectively reduce derivative work order inundation, improve automation solution rate and distribution efficiency, and have new type abnormal fast adaptation capacity, significantly reduce manual intervention cost.

Description

Technical Field

[0001] This invention belongs to the field of cross-border e-commerce data processing technology, specifically involving an automatic preprocessing and distribution system for cross-border customer service work orders based on a rule engine. Background Technology

[0002] In cross-border e-commerce scenarios, sellers (hereinafter referred to as "B-end customers") typically use third-party supply chain service platforms to integrate the entire chain of services, including product procurement, warehousing, logistics, and order fulfillment. B-end customers synchronize their store orders from e-commerce platforms such as Shopify, TikTok Shop, and Amazon to the supply chain platform, which then handles subsequent procurement, packaging, shipping, and logistics tracking. However, in actual operation, due to frequent changes in order status on e-commerce platforms, complex internal supply chain status flows, unstable integration with third-party ERP systems, payment and balance management issues, and abnormal logistics tracking information, a large number of abnormal situations and customer inquiries requiring manual intervention arise.

[0003] Under current technological conditions, customer service teams on supply chain platforms typically rely on unstructured methods such as WeChat groups, DingTalk groups, or emails to receive customer issue reports. Customer service personnel must manually understand the problem, check orders, determine the type of issue, and forward it to the appropriate specialist. This model presents the following two technical problems:

[0004] 1. Lack of ability to handle the temporal relationships between events.

[0005] Existing customer service ticketing systems process transactions on a "single event" basis, failing to identify the temporal causal relationships between multiple abnormal events. For example, if a brief network outage in a warehouse causes hundreds of orders to simultaneously fail to retrieve tracking numbers, the current system will generate a separate ticket for each failure, resulting in customer service staff being overwhelmed by a massive number of duplicate tickets, making it difficult to prioritize and identify the true root cause. More seriously, due to the lack of event correlation analysis, these tickets may be assigned to different personnel, each spending time investigating the same root cause, leading to a significant waste of human resources.

[0006] 2. The work order preprocessing and triage strategies are static and fixed, unable to adapt to dynamic changes.

[0007] The preprocessing actions (such as automatic retries and status synchronization) and routing rules (such as fixed assignment of processing groups according to problem type) of existing systems are usually pre-configured statically. However, the actual operating environment is highly dynamic: the load of each processing role varies greatly at different times (such as peak promotional periods); new anomaly patterns (such as new error codes returned by newly integrated ERP systems) are constantly emerging. Static rules cannot be dynamically adjusted according to the real-time queue length, average processing time, and skill matching degree of each role, nor can they proactively learn from unknown anomaly patterns. As a result, high-priority work orders may be assigned to already overloaded groups, causing further delays, while new anomalies are thrown into the default queue because there are no matching rules, and remain unprocessed for a long time.

[0008] In summary, existing technologies lack the ability to model the temporal correlation of events, and also lack the ability to adapt to processing resources and problem patterns. Summary of the Invention

[0009] This invention provides an automatic preprocessing and routing system for cross-border customer service work orders based on a rules engine. The system includes an event standardization module, a composite event detection module, an adaptive preprocessing module, a dynamic routing module, and a closed-loop feedback module. This reduces the flood of derivative work orders, improves the rate of automated resolution and allocation efficiency, and has the ability to quickly adapt to new anomalies, significantly reducing the cost of manual intervention, thereby solving the problems mentioned in the background art.

[0010] To achieve the above objectives, the present invention provides the following technical solution: an automatic preprocessing and triage system for cross-border customer service work orders based on a rule engine, comprising:

[0011] The event standardization module is used to receive and uniformly process heterogeneous raw events from multiple external systems and output a standardized event stream.

[0012] The composite event detection module is used to detect candidate composite events in the standardized event stream, calculate the causal strength between events within the candidate composite events, and merge the candidate composite events into a single work order only when the causal strength meets a preset condition.

[0013] The adaptive preprocessing module is used to select and execute automated actions for each work order. In the early stage of system operation, deterministic rules are used for decision-making. After accumulating sufficient data, it switches to adaptive decision-making based on probability sampling. When the success probability estimate of all optional actions is lower than a preset threshold, manual action is forcibly selected.

[0014] The dynamic routing module is used to receive work orders that require manual processing, calculate the matching cost based on the customer service load status, the skill matching degree between the work order and the customer service representative, and the dynamic priority of the work order, and allocate the work order to the customer service representative for processing based on the matching cost.

[0015] The closed-loop feedback module is used to construct and maintain a causal graph between events, automatically identify root cause events and propagate root cause identifiers, automatically clean up derived work orders, and optimize and adjust the decision-making strategy of the adaptive preprocessing module and the matching cost weight of the dynamic diversion module based on counterfactual reasoning.

[0016] As a further option, in the composite event detection module, the causal strength is calculated in the following manner:

[0017] Let P(A) be the probability of candidate cause event A occurring, P(B|A) be the conditional probability of candidate result event B occurring given that A has occurred, and P(B|¬A) be the background probability of B occurring when A has not occurred.

[0018] If P(B∣A)−P(B∣¬A)≤0, then the causal strength directly takes the value of 0;

[0019] Otherwise, causal strength , where λ is the time decay coefficient and Δt is the time interval between A and B.

[0020] As a further option, the composite event detection module is also configured to: adaptively adjust the sliding window length W used for composite event matching according to the current event arrival rate r, wherein the value is...

[0021]

[0022] Where N is the number of events expected to be contained within the window, W min W max These are the preset minimum window length and maximum window length, respectively.

[0023] As a further option, in the adaptive preprocessing module, the execution result of the automated action is divided into immediate success and eventual success:

[0024] The term "instant success" refers to the system directly determining from the return code or status change after the action is executed that the operation has been completed as expected, which is used to update the decision model in real time.

[0025] The term "final success" refers to the removal of the original abnormal state corresponding to the work order within a preset time window after the action is executed, without the need for manual intervention, and is used for counterfactual reasoning in the closed-loop feedback module.

[0026] As a further option, in the dynamic traffic splitting module, the customer service load index L j Defined as Where n is the number of pending customer service orders, t0 is the average processing time, T0 is the remaining working time, and ϵ is a very small positive number; the load index is normalized to... The matching cost C i,jThe calculation formula is:

[0027]

[0028] Where sim i,j The cosine similarity between the skill vector required for a work order and the customer service skill vector is calculated using succ. j The success rate of customer service in handling similar work orders recently is represented by w1, w2, and w3, which are configurable weights.

[0029] As a further option, in the dynamic traffic allocation module, the dynamic priority of work orders is updated recursively in the following manner:

[0030]

[0031] Where P cur For the current priority, t wait Where D is the time since the last priority update, K is the expected response time according to the service level agreement for the category to which the work order belongs, and P is an adjustable constant. max The priority level is the upper limit; the updated priority is used to adjust the matching cost so that high-priority work orders are assigned first.

[0032] As a further option, in the closed-loop feedback module, the system automatically determines that the root cause event must simultaneously meet the following conditions:

[0033] There are no incoming edges in the causal graph.

[0034] The average conditional probability of all its direct downstream events exceeds a preset threshold;

[0035] The global first occurrence time of this event type in all historical logs is earlier than the global first occurrence time of its downstream event types;

[0036] Root causes automatically identified by the system are added to the root cause database after being manually verified.

[0037] As a further option, in the closed-loop feedback module, the counterfactual reasoning is executed periodically:

[0038] For each work order, if action A is actually performed but another action B might be better, the cumulative regret value increases by max(0, actual time spent - baseline time spent);

[0039] The actual time consumed is the total time from the first entry of the work order into the adaptive preprocessing module to its final closure.

[0040] The baseline time is the arithmetic average of the actual time spent by similar work orders that were successfully closed through action B in history.

[0041] When the total regret value within a period exceeds the dynamic threshold, a fine-tuning of the decision model of the adaptive preprocessing module and the matching cost weight of the dynamic diversion module is triggered.

[0042] As a further option, the adaptive preprocessing module is in a cold start phase before the number of work orders reaches a preset threshold. It uses deterministic rule-based decision-making and does not perform random sampling, but maintains the Beta distribution of each action and records the immediate success results. When the number of work orders reaches the preset threshold, the system switches to full mode, retains the Beta distribution parameters accumulated in the cold start phase as the initial distribution, and enables Thompson sampling decision-making based on random sampling of the Beta distribution.

[0043] As a further option, the closed-loop feedback module also includes a novel anomaly adapter: maintaining feature vectors of historical events, calculating the Euclidean distance between a new event type and each historical event type when a new event type appears, selecting several historical types with the closest distance, and recommending the action with the highest success probability among these historical types to the adaptive preprocessing module as the initial action strategy for the new event type.

[0044] Compared with the prior art, the beneficial effects of the present invention are:

[0045] 1. By using composite event detection and temporal causality strength verification, multiple abnormal events with the same root cause and temporal correlation are merged into a single work order, effectively preventing customer service from being overwhelmed by a massive number of derivative work orders. This effect is particularly evident in fault scenarios where "a single root cause triggers a large number of events".

[0046] 2. The adaptive preprocessing strategy using Thompson sampling can gradually learn the optimal handling actions for different anomaly types during operation, resulting in an overall automated resolution rate that is better than that of static fixed rules.

[0047] 3. The dynamic task allocation module takes into account the real-time load of customer service, skill matching degree, and dynamic decay priority of work orders, so as to make task allocation more reasonable and reduce the waiting time of high-priority work orders.

[0048] 4. The system can automatically discover new time-series patterns, learn causal graphs between events, and recommend initial handling strategies for newly emerging anomaly types without frequent downtime for rule modification.

[0049] 5. Cause-effect diagrams and root cause propagation mechanisms can automatically identify root cause events and clean up downstream derivative work orders in batches after the root cause is resolved, significantly reducing the manual input of repeatedly investigating the same problem. Attached Figure Description

[0050] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. Obviously, the drawings described below are merely some embodiments of the present invention, and those skilled in the art can obtain other drawings based on these drawings without any creative effort.

[0051] In the attached diagram:

[0052] Figure 1 : Diagram of the overall system architecture and data flow.

[0053] Figure 2 : Schematic diagram of the internal structure of the time alignment and standardization module.

[0054] Figure 3 Workflow diagram of the time-series correlation detection and work order merging module.

[0055] Figure 4 : Decision flowchart for automated preprocessing execution module.

[0056] Figure 5 Flowchart for dynamic traffic diversion and personnel matching module matching cost calculation and allocation.

[0057] Figure 6 : Schematic diagram of the internal structure and feedback path of the root cause analysis and closed-loop feedback module.

[0058] Figure 7 : Sequence diagram of the transition from cold start to full mode progressive learning. Detailed Implementation

[0059] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0060] Example 1: Please refer to Figure 1 This embodiment provides an automated preprocessing and routing system for cross-border customer service work orders based on a rules engine. The system is deployed within a supply chain service platform and interacts with e-commerce platforms (such as Shopify, TikTok Shop, and Amazon), core supply chain business systems, third-party ERP systems, and logistics systems via application programming interfaces (APIs).

[0061] This system consists of five core functional modules that collaborate in a data flow sequence, and includes a reverse feedback loop from the end to the front end. The data flow path is: raw event → time alignment and standardization module → time sequence correlation detection and work order merging module → automated preprocessing execution module → dynamic traffic routing and personnel matching module → customer service processing → root cause analysis and closed-loop feedback module → (feedback to the second and third modules). The following describes the internal structure, working method, inter-module relationships, and technical effects of each module along this data flow main line.

[0062] 1. Time Alignment and Standardization Module

[0063] Please see Figure 2 This module, located at the system data entry layer, acts as an adapter between external systems and internal processing flows. It connects to multiple external systems (e-commerce platforms, ERP, logistics systems, etc.), each employing different data formats and communication protocols (Webhook, message queue, REST API). The module contains a protocol adapter pool that automatically selects the correct receiving method based on the source system. Received raw events first enter an event format converter, where they are standardized into a structure containing standard fields such as event type, timestamp, order number, and error code. Subsequently, the time calibration engine corrects the timestamp: due to potential differences in clocks across external systems, the engine maintains a gateway clock (synchronized with the national time service center) and records the difference between the raw timestamp and the gateway's received time for several recent events. The median is used as the calibration offset, and the aligned event occurrence time is obtained by subtracting this offset from the gateway's received time. For events without an original timestamp, the gateway's received time is used directly.

[0064] The standardized and aligned event stream is then pushed to the next module (the time-series correlation detection and work order merging module). Each event output by this module has a unified format and a reliable time reference, providing a foundation for subsequent causal analysis. This eliminates format differences and time deviations from heterogeneous data sources, preventing subsequent modules from misclassifying normal events as causal relationships or missing true time-series patterns due to clock asynchrony, thus improving the overall data quality and processing accuracy of the system.

[0065] 2. Timing Correlation Detection and Work Order Merging Module

[0066] Please see Figure 3 This module receives a standardized event stream and inputs it in parallel into multiple nondeterministic finite automata (NFAs). Each NFA corresponds to a "composite event template," which defines multiple event types and their allowed time intervals. For example, the same type of failure event for the same order may occur repeatedly within a short period of time, reaching a set number of times, or the same type of failure event may occur in large numbers for different orders within a short period of time.

[0067] The relationship between composite event matching and causal strength verification:

[0068] When an NFA reaches the acceptance state, a candidate composite event is initially detected. To avoid accidental co-occurrence being misjudged as a genuine causal relationship, the system needs to further verify the causal strength between events within the candidate composite event. Specifically, for any pair of events A (candidate cause) and B (candidate result) in the candidate composite event, the system calculates the causal strength. Only when the causal strength of the main event pair in the candidate composite event (i.e., the key cause event and result event defined by the template) exceeds a preset threshold S (e.g., 0.6) is the composite event confirmed as valid and merged into a single work order; if the causal strength does not meet the threshold, merging is abandoned, and the event is still processed as a separate event. This mechanism ensures the rationality of merging and avoids erroneous work order compression due to false associations.

[0069] The definition of causal strength is as follows:

[0070] Let P(A) be the probability of event A occurring, P(B|A) be the conditional probability of B occurring given that A has occurred, and P(B|¬A) be the background probability of B occurring without A. Then the original lift is:

[0071]

[0072] When Lift≤0, it is considered that A has no positive causal effect on B, and Strength=0 is directly determined, and no further merging is performed.

[0073] When Lift > 0, the normalized causality strength is:

[0074]

[0075] Where the denominator 1-P(B∣¬A) is the maximum possible increase value, λ is the time decay coefficient (default 0.1), and Δt is the time interval (seconds) between A and B.

[0076] Finally, Strength∈(0,1], and when Strength>S (e.g., 0.6), it is considered that A and B have a credible causal relationship.

[0077] Cold start instructions: If the system has fewer than 5000 accumulated work orders, the causal strength calculation will degenerate due to unreliable conditional probability estimation. (Relies only on time decay), and automatically switches to the full formula once sufficient data is available.

[0078] Furthermore, the sliding window length of the NFA is adaptively adjusted based on the event arrival rate: the system counts the number of events received in a recent period (e.g., the last 10 seconds) in real time and calculates the current arrival rate r (events / second). Assuming each window is expected to contain a fixed number of N events (e.g., 100), the formula for calculating the window length W is:

[0079]

[0080] Where N=100 (an empirical value that can be adjusted based on the average complexity of work orders); r is the current event arrival rate, obtained by dividing the total number of events received in the last 10 seconds by 10, and is updated every second;

[0081] W min =1 second, W max =300 seconds. In this way, the window automatically shortens when the arrival rate is high to avoid false merging, and automatically extends when the arrival rate is low to capture sparse patterns.

[0082] Once enough historical logs have been accumulated, the system periodically performs sequence pattern mining (such as PrefixSpan) to automatically discover new frequent time series patterns, which are then manually reviewed and added to the NFA pool as new templates.

[0083] This module receives the standardized event stream from the preceding stage and outputs work order entities (work orders corresponding to composite events, rather than one work order for each simple event). These work orders are sent to the automated preprocessing execution module. Simultaneously, this module receives updated composite event templates from the root cause analysis and closed-loop feedback module, enabling template self-evolution. Multiple time-related events are merged into a single work order, significantly reducing the number of work orders generated in typical fault scenarios and preventing customer service from being overwhelmed by duplicate work orders. Causal strength judgment filters out false associations, ensuring the rationality of the merging. An adaptive window mechanism enables the system to cope with event surges during sudden faults, maintaining the stability of the merging strategy.

[0084] 3. Automated preprocessing execution module

[0085] Please see Figure 4 This module automatically selects one action from a predefined set for each incoming work order. Actions include: no action, single retry, multiple retries (exponential backoff), status synchronization, sending an expiration notice, suspending the order, and escalating to manual processing.

[0086] The two-stage definition of "successful" action:

[0087] Immediate Success (for real-time update in Thompson Sampling): After the action is executed, the system can directly determine whether the operation is completed as expected from the return code or status change. For example: the retry request returns HTTP200 and the business status code is normal; the status synchronization interface returns success. At this time, immediately update the corresponding a (success) or b (failure) of the Beta distribution for the next decision.

[0088] Final Success (for offline evaluation and model fine-tuning): After the action is executed, the system continues to monitor the original abnormal status corresponding to the work order. If the same abnormality does not occur again within the preset time window (such as 5 minutes) and no manual intervention is required, it is considered a final success; otherwise, it is considered a final failure. This result is used for root cause analysis and counterfactual reasoning, but not for the distribution update of real-time Thompson Sampling to avoid decision-making delays caused by the waiting window.

[0089] For the "escalate to human" action, its immediate success is defined as the work order being successfully written into the customer service queue and confirmed to be received by the system; the final success is defined as the work order being successfully assigned to a customer service agent and the agent accepting and starting to process it within the preset response time (such as 30 minutes). In the automated resolution rate statistics, "escalate to human" is considered not automatically resolved.

[0090] The decision-making is divided into two stages:

[0091] Cold Start Phase (at the initial stage of the system, the total number of work orders < N2 = 5000): Use deterministic rules. Example of rules: If the error code belongs to {"timeout", "connection failure", "network error"}, then execute "multiple retries (exponential backoff)"; if the error code belongs to {"status inconsistency", "data out of sync"}, then execute "status synchronization"; otherwise, execute "escalate to human". This stage does not rely on any probability sampling. However, the system still maintains a Beta distribution counter (a, b) for each action, with the initial values a = 1, b = 1, and updates (a, b) according to the immediate success result after each action execution, which is only used for data accumulation and does not participate in decision-making.

[0092] Regular Phase (the total number of work orders ≥ N2 = 5000): Adopt the Thompson Sampling strategy. Each action maintains a Beta distribution, which is described by the number of successes a and the number of failures b (this distribution inherits the a, b values accumulated in the cold start phase). When making a decision, randomly draw a value from the Beta distribution of each action, and select the action with the largest drawn value to execute; after execution, update the corresponding a or b of the distribution according to the immediate success result. This mechanism explores (random sampling) while utilizing historical experience (distribution mean), and can adaptively discover the optimal action.

[0093] If the current mean of all actions (i.e., a / (a + b)) is lower than the preset threshold P (such as 0.3), then force the selection of "escalate to human" to avoid continuing ineffective attempts at a very low success rate.

[0094] This module receives work orders from the preceding level (which may have been merged). After execution, if the automatic resolution is successful, the work order is closed and no longer passed down; if it fails or requires manual intervention, the work order is marked as "requires manual processing" and sent to the dynamic triage and personnel matching module. Simultaneously, the execution result (immediate success / failure) is fed back to the root cause analysis and closed-loop feedback module for counterfactual reasoning and model fine-tuning (such as adjusting the initial prior or threshold of the Beta distribution). The automated resolution rate is significantly improved, especially during peak periods, avoiding invalid retries; the Thompson sampling mechanism allows the system to proactively try new strategies and quickly adapt to new error codes or anomaly patterns without requiring manual rule rewriting.

[0095] 4. Dynamic triage and personnel matching module

[0096] Please see Figure 5 This module receives work orders requiring manual processing and obtains the real-time status of all online customer service representatives, including: the current number of pending work orders n, average processing time t0, skill vector (scoring for each dimension), and remaining working time T0. It defines the customer service load index:

[0097]

[0098] Where ε is a very small positive number (e.g., 0.001). When L j When the threshold L0 is exceeded (e.g., 1.5), the customer service representative is marked as overloaded and no new work orders will be assigned to them.

[0099] To eliminate the dimensional differences between the load index and other items in the matching cost, the load index is normalized:

[0100]

[0101] Make its value fall within the interval [0,1).

[0102] For each work order i and customer service representative j, the matching cost is calculated using the following formula:

[0103]

[0104] Where sim i,j It is the cosine similarity between the skill vector required for the work order and the customer service skill vector, succ j This represents the success rate of the customer service representative in handling similar work orders recently. w1, w2, and w3 are configurable weights (each defaults to 1 / 3, and w1+w2+w3=1).

[0105] Allocation Algorithm: The scheduler processes orders in batches at fixed intervals (e.g., 30 seconds). If the product of the number of work orders to be allocated and the number of online customer service representatives is less than a set threshold M (e.g., 2500), the Hungarian algorithm is used to find the globally optimal match that minimizes the total cost; otherwise, a greedy approximation algorithm is used, allocating the work order-customer service pair with the lowest current cost each time.

[0106] Work order priority is dynamically adjusted: the initial priority P of each work order is... cur (1-5, the higher the value, the more urgent the situation), updated every 30 seconds during the waiting period, using the following formula:

[0107]

[0108] Where t wait This is the time elapsed since the last priority update (t during the first update). wait D is the waiting time since the work order was generated; K is the expected SLA response time (in seconds) for this type of work order; P is an adjustable constant (e.g., 10). max This is the upper limit of priority (e.g., 10). After each update, the new current priority P... cur Saved for the next iteration. The final matching cost is modified to C. i,j / P cur This makes it easier for high-priority work orders to be handled by low-load, highly skilled customer service representatives.

[0109] This module receives "requires manual processing" work orders from the preprocessing module, and after allocation, sends the work order to the corresponding customer service representative's work queue. After the customer service representative completes the processing, closed-loop information (root cause, processing time, success status, etc.) is sent to the root cause analysis and closed-loop feedback module. This achieves customer service load balancing, reduces the average wait time for work orders, and significantly reduces the load difference between customer service representatives; dynamic priority adjustment ensures that urgent work orders are not waited for a long time, improving SLA achievement rate.

[0110] 5. Root Cause Analysis and Closed-Loop Feedback Module

[0111] Please see Figure 6 This module is located at the end of the system, but it influences preceding modules through feedback loops. It maintains a causal graph (directed acyclic graph), where nodes represent event types, and directed edges X→Y indicate that X may lead to Y. The edge weight is a conditional probability P(Y|X) (based on historical data statistics). The causal graph initially has basic edges defined by experts, and new edges are automatically learned daily based on historical logs (using a PC algorithm with a confidence threshold of 0.95), and added after manual review. The system maintains a reachability matrix in memory (recalculated offline daily) to quickly determine whether one event type can reach another.

[0112] Automatic root cause identification conditions:

[0113] When an event is identified as the root cause, it is mainly done through the following two methods:

[0114] Manual labeling: Customer service representatives clearly label the event as the root cause when processing work orders.

[0115] The system automatically identifies an event type as a candidate root cause when it simultaneously meets the following three conditions:

[0116] (a) There are no incoming edges in the causal graph (i.e., no other event type points to it);

[0117] (b) The average of the conditional probabilities P(downstream|the event) of all its direct downstream events exceeds a set value (e.g., 0.8).

[0118] (c) In the historical log, the global first occurrence time of this event type (i.e., the earliest timestamp of this type in all historical logs) is strictly earlier than the global first occurrence time of its downstream event types.

[0119] Root causes automatically identified by the system must be manually reviewed before they can be permanently added to the root cause database.

[0120] Root cause propagation and derivative ticket cleanup:

[0121] A globally unique identifier R0 is generated for each identified root cause. For each newly generated standardized event, the system checks: (a) whether there exists a directed path from the root cause event type to the current event type in the reachability matrix; and (b) whether the difference between the event occurrence time and the root cause start time is less than a preset causal window T1 (e.g., 1 hour). For composite event-type root causes (e.g., root causes composed of multiple sub-events), its "root cause event occurrence time" is defined as the occurrence time of the first sub-event in the composite event; for simple event root causes, the timestamp of the event is used directly. If both conditions are met, the root cause identifier R0 is copied to the metadata of the current event.

[0122] When each work order is generated, the root cause identifiers carried by all events are extracted, and the frequency of each identifier is counted. If the frequency of a certain identifier exceeds 50%, the event type corresponding to that identifier is marked as the presumed root cause of the work order and written into the work order title.

[0123] When a root cause work order is marked as "resolved", the automatic cleanup executor queries all derivative work orders with the same root cause identifier that have not yet been closed. For each derivative work order, it automatically performs a cleanup retry (such as re-calling the interface), waits for an appropriate time (such as 10 seconds), closes the derivative work order if the retry is successful, and generates a new work order for those that fail and marks it as "root cause resolved but downstream recovery failed".

[0124] Counterfactual reasoning and model fine-tuning:

[0125] The counterfactual reasoning unit operates on a cyclical basis (e.g., processing N1=1000 work orders constitutes one cycle). For each work order within a cycle, if action A was actually executed, but executing another candidate action B might be better, then the accumulated regret value R1 is calculated, and its increase is max(0, actual time spent - baseline time spent).

[0126] The "actual time spent" is defined as the total time elapsed from the first entry of the work order into the automated preprocessing execution module to the final closure of the work order (automatic resolution or customer service completion), including all retries, waiting, and manual processing time.

[0127] "Successfully closed via Action B" is precisely defined as follows: In the entire lifecycle of a work order, after Action B is executed for the first time (or the first time if executed multiple times), the system detects within a preset time window (e.g., 5 minutes) that the original abnormal state corresponding to the work order has been resolved, and no other automated actions (other than Action B) are executed within this window, nor is any manual intervention performed; subsequently, the work order is closed normally. If the above conditions are met, the work order is considered successfully closed via Action B.

[0128] The baseline time is defined as the arithmetic mean of the actual times taken by all historical work orders of the same type as the current work order that meet the condition of "successfully closed by action B". If no such historical work orders exist, the baseline time is taken as the default value (e.g., 300 seconds).

[0129] When the total regret value R1 within a given period exceeds the dynamic threshold R2, model fine-tuning is triggered. The dynamic threshold is defined as R2 = C × N1, where C is a constant (e.g., 0.5 seconds), meaning that fine-tuning is triggered when the average regret value for each work order exceeds 0.5 seconds. During fine-tuning, the initial prior parameters of the Beta distribution for each action are adjusted (e.g., the initial values ​​of a and b are reset based on historical success rates), and the weights w1, w2, and w3 of the traffic diversion cost function are adjusted using a hill-climbing method with small step sizes (step size 0.01).

[0130] Novel anomaly adapter: Maintains historical event feature vectors (including error codes, occurrence time, frequency of occurrence, module to which it belongs, etc.). When a new event type appears, it calculates the Euclidean distance between the event and historical types, selects the most similar historical types (e.g., 3), and recommends the action with the highest success probability in the history of these types to the preprocessing module as the initial strategy (i.e., when initializing the Beta distribution of the action corresponding to the new event, the mean of similar historical actions is used as the prior).

[0131] The synergistic relationship between the composite event template and the cause-effect graph:

[0132] The causal strength calculation in Module 2 is used to determine in real time whether events within the same order or short window should be merged into a composite work order. Its calculation relies on the conditional probability (sliding window update) of online statistics and does not rely on the global causal graph of Module 5.

[0133] The causal graph maintained by Module 5 (built offline based on PC algorithm and historical logs) is used for root cause localization and long-term causal propagation across orders.

[0134] When log mining discovers a new frequent time-series pattern, the system converts the pattern into a candidate composite event template and uses the edge weights of the causal graph of the corresponding event pair in Module 5 (i.e., P(Y|X)) as a reference for the initial causal strength threshold. If there is no corresponding edge in the causal graph, it must be manually reviewed before being added to the template pool.

[0135] Conversely, strong causal relationships confirmed in Module 2 (Strength > 0.8 and occurrences exceeding 100 times) will be automatically recommended to Module 5 as potential new causal edges, and added to the causal graph after offline verification.

[0136] Through the aforementioned two-way feedback, the two causal relationship modeling methods mutually verify each other and evolve together.

[0137] This module receives closed-loop information from all work orders (including those automatically resolved and those manually processed). It periodically pushes updates forward: new composite event templates (discovered through pattern mining) to the time-series correlation detection module, updated Beta initial prior parameters (fine-tuned through counterfactual reasoning) to the automated preprocessing module, and adjusted cost weights to the triage module. Simultaneously, the root cause propagation mechanism of this module directly provides causal evidence for time-series correlation detection and work order merging. Automatic root cause location and propagation enable the unified identification and processing of numerous derivative work orders caused by a single root cause; automatic cleanup of downstream work orders after root cause resolution reduces redundant work; counterfactual reasoning allows the system to continuously learn and optimize from historical decisions; and rapid adaptation to new anomalies allows the system to handle unknown error codes without reprogramming.

[0138] 6. Cold start and progressive learning behavior

[0139] Please see Figure 7 In the initial stage of system deployment (when there are fewer accumulated work orders), a simplified configuration is adopted: composite event templates use only a few expert templates; causal strength calculation is degraded to rely solely on time decay (without using the conditional probability part); the adaptive window is fixed to the default value (e.g., 60 seconds); preprocessing uses deterministic rules (see Module 3 for details); the historical success rate in the traffic splitting cost uses the global average value; the causal graph only contains predefined edges; counterfactual reasoning and pattern mining are not enabled.

[0140] Cold start phase decision-making mechanism: Before the total number of work orders reaches N²=5000, the decision-making of Module 3 is entirely based on deterministic hard-coded rules (without relying on any probability sampling). However, the system still maintains a Beta-distributed (a,b) counter for each action (initially a=1, b=1), and updates (a,b) based on the immediate success result after each action execution. This is only used for data accumulation and does not participate in decision-making. During this phase, no random sampling using Thompson's sampling is performed to ensure that the behavior is completely deterministic and predictable.

[0141] Switch to Full Mode: When the number of processed work orders reaches the preset threshold N2 = 5000, the system automatically switches to full mode. The following operations are performed during the switchover:

[0142] Preserve and inherit the Beta distribution (a,b) accumulated during the cold start phase: Use the historical success / failure counts of each action as the initial distribution of Thompson sampling in full mode, without resetting it to (1,1), thus inheriting the learning results from the cold start phase.

[0143] Enable full Thompson sampling decision (i.e., random sampling from the Beta distribution to balance utilization and exploration).

[0144] Enables adaptive windows, pattern mining, counterfactual reasoning, and dynamic expansion of causal graphs.

[0145] Through the above design, the system achieves a smooth and lossless transition from cold start to full learning, avoiding the waste of cold start data and logical contradictions.

[0146] 7. Inter-module collaboration effect

[0147] The first two modules compress massive amounts of raw events into meaningful work orders; the third module attempts to automate the resolution process to reduce manual workload; the fourth module efficiently assigns remaining work orders to suitable customer service representatives; and the fifth module learns from the entire process, continuously optimizing the rules, models, and cause-effect graphs of the preceding modules. This collaboration enables the system not only to handle current problems but also to continuously improve itself as operational data accumulates, adapting to the ever-changing anomalies in cross-border e-commerce operations.

[0148] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A cross-border customer service work order automatic preprocessing and triage system based on a rule engine, characterized in that, include: The event standardization module is used to receive and uniformly process heterogeneous raw events from multiple external systems and output a standardized event stream. The composite event detection module is used to detect candidate composite events in the standardized event stream, calculate the causal strength between events within the candidate composite events, and merge the candidate composite events into a single work order only when the causal strength meets a preset condition. The adaptive preprocessing module is used to select and execute automated actions for each work order. In the early stage of system operation, deterministic rules are used for decision-making. After accumulating sufficient data, it switches to adaptive decision-making based on probability sampling. When the success probability estimate of all optional actions is lower than a preset threshold, manual action is forcibly selected. The dynamic routing module is used to receive work orders that require manual processing, calculate the matching cost based on the customer service load status, the skill matching degree between the work order and the customer service representative, and the dynamic priority of the work order, and allocate the work order to the customer service representative for processing based on the matching cost. The closed-loop feedback module is used to construct and maintain a causal graph between events, automatically identify root cause events and propagate root cause identifiers, automatically clean up derived work orders, and optimize and adjust the decision-making strategy of the adaptive preprocessing module and the matching cost weight of the dynamic diversion module based on counterfactual reasoning.

2. The system according to claim 1, characterized in that, In the composite event detection module, the causal strength is calculated in the following manner: Let P(A) be the probability of candidate cause event A occurring, P(B|A) be the conditional probability of candidate result event B occurring given that A has occurred, and P(B|¬A) be the background probability of B occurring when A has not occurred. If P(B∣A)−P(B∣¬A)≤0, then the causal strength directly takes the value of 0; Otherwise, causal strength , where λ is the time decay coefficient and Δt is the time interval between A and B.

3. The system according to claim 2, characterized in that, The composite event detection module is further configured to: adaptively adjust the sliding window length W used for composite event matching based on the current event arrival rate r, where the value is... Where N is the number of events expected to be contained within the window, W min W max These are the preset minimum and maximum window lengths, respectively.

4. The system according to claim 1, characterized in that, In the adaptive preprocessing module, the execution result of the automated action is divided into immediate success and eventual success: The term "instant success" refers to the system directly determining from the return code or status change after the action is executed that the operation has been completed as expected, which is used to update the decision model in real time. The term "final success" refers to the removal of the original abnormal state corresponding to the work order within a preset time window after the action is executed, without the need for manual intervention, and is used for counterfactual reasoning in the closed-loop feedback module.

5. The system according to claim 1, characterized in that, In the dynamic traffic distribution module, the customer service load index L j Defined as Where n is the number of pending customer service orders, t0 is the average processing time, T0 is the remaining working time, and ϵ is a very small positive number; the load index is normalized to... The matching cost C i,j The calculation formula is: Where sim i,j The cosine similarity between the skill vector required for a work order and the customer service skill vector is calculated using succ. j The success rate of customer service in handling similar work orders recently is represented by w1, w2, and w3, which are configurable weights.

6. The system according to claim 5, characterized in that, In the dynamic traffic allocation module, the dynamic priority of work orders is updated recursively in the following manner: Where P cur For the current priority, t wait Where D is the time since the last priority update, K is the expected response time according to the Service Level Agreement (SLA) for the category to which the work order belongs, and P is an adjustable constant. max The priority level is the upper limit; the updated priority is used to adjust the matching cost so that high-priority work orders are assigned first.

7. The system according to claim 1, characterized in that, In the closed-loop feedback module, the system automatically determines that the root cause event must simultaneously meet the following conditions: There are no incoming edges in the causal graph. The average conditional probability of all its direct downstream events exceeds a preset threshold; The global first occurrence time of this event type in all historical logs is earlier than the global first occurrence time of its downstream event types; Root causes automatically identified by the system are added to the root cause database after being manually verified.

8. The system according to claim 1, characterized in that, In the closed-loop feedback module, the counterfactual reasoning is executed periodically: For each work order, if action A is actually performed but another action B might be better, the cumulative regret value increases by max(0, actual time spent - baseline time spent); The actual time consumed is the total time from the first entry of the work order into the adaptive preprocessing module to its final closure. The baseline time is the arithmetic average of the actual time spent by similar work orders that were successfully closed through action B in history. When the total regret value within a period exceeds the dynamic threshold, a fine-tuning of the decision model of the adaptive preprocessing module and the matching cost weight of the dynamic diversion module is triggered.

9. The system according to claim 1, characterized in that, The adaptive preprocessing module is in a cold start phase before the number of work orders reaches a preset threshold. It uses deterministic rule-based decision-making and does not perform random sampling, but maintains the Beta distribution of each action and records the immediate success results. When the number of work orders reaches the preset threshold, the system switches to full mode, retains the Beta distribution parameters accumulated in the cold start phase as the initial distribution, and enables Thompson sampling decision-making based on random sampling of the Beta distribution.

10. The system according to claim 1, characterized in that, The closed-loop feedback module also includes a novel anomaly adapter: maintaining feature vectors of historical events, calculating the Euclidean distance between a new event type and each historical event type when a new event type appears, selecting several historical types with the closest distance, and recommending the action with the highest success probability among these historical types to the adaptive preprocessing module as the initial action strategy for the new event type.

Images