Service-oriented customer service intention auxiliary processing method and system

Abstract

The application discloses a service order circulation-oriented customer service intention auxiliary processing method and system, and relates to the technical field of customer service order processing. The method comprises the following steps: S1, real-time collection of order association data, and preprocessing of the order association data; S2, extraction of an order subsequent state change sequence and real-time business state, and identification of a state reverse change event corresponding to an action dependent state inconsistency of a current proposed action; S3, extraction of an action execution effectiveness analysis parameter, combination of execution effectiveness analysis data and the number of state reverse change events, comprehensive evaluation of the failure risk of the current proposed action, and determination of whether the execution condition is met; and S4, generation of a proposed action processing prompt and corresponding state change prompt information. The technical problem of the proposed action inconsistency with the real-time business state caused by the asynchronous change of the business state after the creation of the order, and the subsequent repeated execution, reverse execution and processing result distortion of the order action are solved.

Description

Technical Field

[0001] This invention relates to the field of customer service work order processing technology, and in particular to a customer service intent-assisted processing method and system for service work order flow. Background Technology

[0002] Against the backdrop of the continuous development of business-to-consumer (B2C) e-commerce services, customer interaction services, and information processing and storage support services such as data storage and backup services, order processing, payment management, logistics and distribution, and after-sales service are gradually forming a multi-platform collaborative work order flow system. With the widespread application of mobile smart terminals, cloud-integrated application operation support platform software, and data mining software, customer service systems are gradually combining user conversation content, work order information, and business status data to carry out customer service intent recognition and auxiliary processing, realizing the classification, flow, and collaborative management of service requests, and providing basic data support for customer service work order processing, business status synchronization, and service process management.

[0003] For example, Chinese patent CN116954386A discloses an information recommendation method, related apparatus, and medium in an input method. The information recommendation method includes: detecting the activation of a target input method; acquiring target text input using the target input method; inputting the target text into an intent recognition model, which outputs the target intent corresponding to the target text; searching for target information based on the target intent; and displaying the target information on a terminal using the target input method. The intent recognition model is pre-generated through the following process: adding a guiding phrase to each first sample text in a first sample text set to generate first sample guiding text; inputting the first sample guiding text into a large-scale pre-trained language model to obtain a first intent label; and generating an intent recognition model based on the first intent label. This disclosed embodiment improves the efficiency and accuracy of information recommendation in input methods. This disclosed embodiment can be applied to various scenarios such as input methods, information recommendation, and intelligent customer service.

[0004] For example, Chinese patent CN120560517A discloses a dynamic interaction method based on a multimodal dynamic fusion model and agent collaboration, including: extracting features from user speech information to obtain speech encoding vectors, text semantic vectors, and emotion feature vectors; dynamically weighting and fusing the speech encoding vectors, text semantic vectors, and emotion feature vectors through a multimodal dynamic fusion model to obtain a fused feature vector; and inputting the fused feature vector into the intent. A scene-coupled network identifies user intent tags; user profile tags are identified based on user behavior logs. These user intent tags and user profile tags are input into an autonomous decision-making agent, which generates target decision actions through a lightweight policy network, and then interacts with the user based on these actions. This invention improves the efficiency and accuracy of intelligent interaction in customer service systems, enhances the user experience, and has wide applicability in the field of artificial intelligence.

[0005] However, existing service-oriented work order processing systems typically collect and solidify business status information once when a work order is created, such as order status, payment result, logistics node, or after-sales order status, and determine the work order intent category and subsequent flow actions accordingly. Due to the prevalence of mobile self-service operations, users may initiate cancellation, re-payment, address modification, or withdrawal requests shortly after work order creation. This causes frequent changes in the status of independent subsystems such as orders, payments, logistics, and after-sales services under asynchronous update conditions, potentially leading to delays, out-of-order arrivals, or duplicate arrivals of status change events. This results in inconsistencies between the status snapshot used by the work order and the real-time business status. When the work order flow lacks consistency and applicability checks between the "intended action and the real-time business status" before executing actions such as refunds, cancellations, reissues, or order closures, it is prone to triggering duplicate or reverse execution, causing mismatches between funds, inventory, or work order conclusions and the actual status, and reducing the traceability and stability of the processing.

[0006] Therefore, in response to the above problems, there is an urgent need for customer service intent-assisted processing methods and systems for service work order flow. Summary of the Invention

[0007] To address the technical problem in existing technologies where asynchronous changes in business status after work order creation lead to inconsistencies between the intended action and the real-time business status, resulting in duplicate execution, reverse execution, and distorted processing results, this invention provides a customer service intent-assisted processing method and system for service work order workflow. The technical solution is as follows: A customer service intent-assisted processing method for service work order flow is provided. This method includes: S1, real-time collection of work order-related data, and processing of the data through association aggregation, time unification, duplicate event deduplication, and out-of-order event identification to form a standard event record; S2, extraction of the subsequent status change sequence and real-time business status based on the standard event record, and identification of status reversal events that are inconsistent with the action dependency status corresponding to the currently intended action based on the subsequent status change sequence; S3, extraction of action execution effectiveness analysis parameters by combining work order-related data, the subsequent status change sequence, and real-time business status, and comprehensive assessment of the failure risk of the currently intended action based on the execution effectiveness analysis data and the number of status reversal events, and determination of whether the currently intended action meets the execution conditions based on the failure risk; S4, generation of action processing prompts based on the determination result of the currently intended action, and generation of corresponding status change prompt information.

[0008] Furthermore, the specific process for real-time collection of work order-related data is as follows: Real-time collection of work order-related data includes: collecting work order number, user number, order number, after-sales order number, work order creation timestamp, proposed action, and proposed action verification timestamp from the customer service work order platform; collecting user number, order number, after-sales order number, and user operation timestamp from the user's operation log; collecting order number, order status, and order status update timestamp from the order management record; collecting order number, payment status, payment status update timestamp, refund status, and refund status update timestamp from the payment transaction record; collecting order number, logistics status, and logistics status update timestamp from the logistics and delivery record; and collecting order number, after-sales order number, after-sales status, and after-sales status update timestamp from the after-sales processing record.

[0009] Furthermore, the specific process for associating and aggregating work order-related data, unifying time, deduplicating duplicate events, and identifying out-of-order events to form standard event records is as follows: A customer service work order master record is established based on the work order number. Based on the user number, order number, and after-sales order number, work order-related data corresponding to the work order number is associated with the same customer service work order master record to obtain standard event records. All timestamps are unified to the same time format, and the work order creation timestamp, the timestamp for the action to be performed, the timestamp for the user operation, the timestamp for the order status update, the timestamp for the payment status update, the timestamp for the refund status update, the timestamp for the logistics status update, and the timestamp for the after-sales status update are used as the corresponding event occurrence timestamps. Simultaneously, the corresponding event reception timestamp is recorded. For the same... For customer service work order master records, records with the same event type, event status, and event occurrence timestamp are deduplicated, retaining the record with the earliest data reception timestamp, and marking the remaining records as duplicate event records. The number of duplicate event records is counted as the duplicate event count. For standard event records under the same customer service work order master record, they are sorted in ascending order by reception timestamp to form the reception order, and then sorted in ascending order by event occurrence timestamp to form the actual occurrence order. When the order of two adjacent standard event records in the reception order is inconsistent with the order of actual occurrence, the event received later but with an earlier event occurrence timestamp is marked as an out-of-order event, and the number of out-of-order events is counted. A work order flow processing database is established to store the pre-processed work order associated data.

[0010] Furthermore, the specific process for extracting the subsequent status change sequence and real-time business status of a work order based on standard event records is as follows: Read the standard event records under the same customer service work order master record, determine the work order creation timestamp and the proposed action verification timestamp corresponding to the customer service work order master record, and define the time range between the work order creation timestamp and the proposed action verification timestamp as the action verification time interval; within the action verification time interval, read the event records under the same customer service work order master record arranged in ascending order of event occurrence timestamps to form the subsequent status change sequence of the work order; extract the last update record of the order status, payment status, refund status, logistics status, and after-sales status before the proposed action verification timestamp from the subsequent status change sequence of the work order, as the real-time business status, and record the event occurrence timestamp of each real-time business status.

[0011] Furthermore, based on the subsequent status change sequence of the work order, the specific process for identifying state reversal change events that are inconsistent with the action dependency state corresponding to the currently intended action is as follows: based on the preset standard action dependency rules, the corresponding action dependency state is determined according to the currently intended action, and based on the subsequent status change sequence of the work order, state update events in the subsequent status change sequence of the work order that are inconsistent with the action dependency state corresponding to the intended action are identified, and the number of state reversal change events is counted.

[0012] Furthermore, combining work order association data, work order subsequent status change sequences, and real-time business status, the specific process for extracting action execution effectiveness analysis parameters is as follows: Read the work order subsequent status change sequence, real-time business status, action dependency status corresponding to the proposed action, number of status reverse change events, number of duplicate events, and number of out-of-order events corresponding to the same customer service work order master record; calculate the time difference between the proposed action verification timestamp and the work order creation timestamp to obtain the work order action verification duration; based on the user operation timestamps in the work order subsequent status change sequence, count the number of user operation events to obtain the number of subsequent user operation events; count the historical executed action records under the same order number that are the same as the current proposed action to obtain the number of times the same action is executed; based on the real-time business status, count the number of real-time business states that satisfy the action dependency status corresponding to the current proposed action to obtain the number of effective support states; take the minimum value among the event occurrence timestamps of each real-time business state as the earliest business state update timestamp, calculate the time difference between the proposed action verification timestamp and the earliest business state update timestamp to obtain the action state lag duration.

[0013] Furthermore, combining the execution effectiveness analysis data and the number of state reversal events, the specific process for comprehensively assessing the failure risk of the currently planned action is as follows: Add the number of subsequent user operation events, the number of state reversal events, and the number of times similar actions are executed to obtain the action failure trigger number; divide the action failure trigger number by the sum of the number of valid supporting states and one, add one to the ratio, and take the natural logarithm to obtain the action failure trigger component; add the work order action verification time and the action state lag time to obtain the total action time lag; divide the total action time lag by the work order action verification... The negative exponent is calculated by summing the verification duration with the preset positive time correction amount. The result of the negative exponent is subtracted by one to obtain the time lag impact component. The number of out-of-order events and the number of duplicate events are added together to obtain the number of event chain anomalies. The number of subsequent user operation events and the number of state reverse change events are added together to obtain the number of event chain corrections. The number of event chain anomalies is divided by the number of event chain corrections and then added together to obtain the event chain anomaly amplification component. The action failure trigger component, the time lag impact component, and the event chain anomaly amplification component are multiplied together to obtain the action failure verification value.

[0014] Furthermore, the specific process for determining whether the current proposed action meets the execution conditions based on the failure risk is as follows: match the real-time business status with the action dependency status corresponding to the current proposed action; when the real-time business status does not meet the action dependency status corresponding to the current proposed action, mark the current proposed action as a failed action; when the real-time business status meets the action dependency status corresponding to the current proposed action, compare the failure check value of the processing action with the failure judgment threshold. If the failure check value of the processing action is less than the failure judgment threshold, mark the current proposed action as a valid action; if the failure check value of the processing action is greater than or equal to the failure judgment threshold, mark the current proposed action as a failed action.

[0015] Furthermore, the specific process of generating a processing prompt for the proposed action based on the judgment result of the current proposed action, and generating corresponding status change prompt information, is as follows: When the current proposed action is marked as a valid action, a prompt indicating that the proposed action is allowed to be executed is output to the customer service ticket system; when the current proposed action is marked as an invalid action, a prompt indicating that the proposed action is suspended is output to the customer service ticket system; based on the status reverse change event, real-time business status, and action dependency status, the status difference items are located, failure reason tags are generated, and status change prompt information is generated, including order status change prompts, payment status change prompts, refund status change prompts, logistics status change prompts, and after-sales status change prompts; the current proposed action, real-time business status, processing action failure check value, proposed action mark, failure reason tag, and status change prompt information are written into the ticket flow processing database.

[0016] The second aspect of this invention provides a customer service intent-assisted processing system for service work order flow, comprising: a work order data acquisition and processing module, used to collect work order-related data in real time, and perform association aggregation, time unification, duplicate event deduplication, and out-of-order event identification processing on the work order-related data to form a standard event record; a work order intent status association module, used to extract the subsequent status change sequence of the work order and the real-time business status based on the standard event record, and to identify state reverse change events that are inconsistent with the action dependency status corresponding to the currently intended action based on the subsequent status change sequence of the work order; a processing action failure verification module, used to extract action execution effectiveness analysis parameters by combining work order-related data, subsequent status change sequence of the work order, and real-time business status, and to comprehensively evaluate the failure risk of the currently intended action by combining execution effectiveness analysis data and the number of state reverse change events, and to determine whether the currently intended action meets the execution conditions based on the failure risk; and an auxiliary handling write-back module, used to generate a processing prompt for the intended action based on the determination result of the currently intended action, and to generate corresponding status change prompt information.

[0017] The beneficial effects of the technical solutions provided in the embodiments of the present invention include at least the following: (1) By unifying customer service work orders, user operations, orders, payments, refunds, logistics and after-sales data to the same customer service work order master record, and performing time unification, deduplication and out-of-order identification, the state chaos caused by multi-source asynchronous data can be reduced, and the consistency and traceability of the work order flow data base can be improved.

[0018] (2) By extracting the sequence of subsequent status changes of work orders and real-time business status, and identifying the reverse status change events that are inconsistent with the status of the action, the risk of action failure caused by subsequent user operations or changes in business status can be detected before the action is executed, thus avoiding the need to continue processing based on the old status.

[0019] (3) By comprehensively considering user subsequent operation events, status reverse change events, the number of times similar actions are executed, the number of valid support states, the number of out-of-order events and the number of duplicate events, the failure risk assessment of the current action to be executed can reduce the risk of abnormal handling such as duplicate refunds, incorrect cancellations, incorrect reissues and incorrect order closures.

[0020] (4) By outputting execution permission prompts, execution pause prompts and status change prompts based on the results of valid or invalid actions, customer service can promptly identify whether the current action can still be executed, thereby improving the stability, efficiency and consistency of work order processing. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a flowchart of a customer service intent-assisted processing method for service work order flow provided in an embodiment of the present invention; Figure 2 This is a structural diagram of a customer service intent-assisted processing system for service work order flow provided in an embodiment of the present invention; Figure 3 This is a bar chart for risk assessment of processing action failure verification values ​​provided in the embodiments of the present invention; Figure 4 This is a flowchart of a customer service intent-assisted processing framework for service work order flow provided in an embodiment of the present invention. Detailed Implementation

[0023] The technical solution of the present invention will now be described with reference to the accompanying drawings.

[0024] In embodiments of the present invention, words such as "exemplarily," "for example," etc., are used to indicate that something is an example, illustration, or description. Any embodiment or design described as "exemplary" in the present invention should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of the word "exemplary" is intended to present the concept in a concrete manner. Furthermore, in embodiments of the present invention, the meaning expressed by "and / or" can be both, or either one.

[0025] In the embodiments of this invention, the terms "image" and "picture" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning. Similarly, the terms "of," "corresponding (relevant)," and "corresponding" may sometimes be used interchangeably. It should be noted that, without emphasizing the distinction between them, they convey the same meaning.

[0026] In this embodiment of the invention, sometimes a subscript such as W1 may be written in a non-subscript form such as W1. When the difference is not emphasized, the meaning they express is the same.

[0027] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0028] This invention provides a customer service intent-assisted processing method for service order workflow, such as... Figure 1 As shown, the processing flow of this method may include the following steps: S1, real-time collection of work order associated data, and processing of work order associated data through association aggregation, time unification, deduplication of duplicate events, and identification of out-of-order events to form standard event records; S2, extraction of subsequent status change sequences and real-time business status based on standard event records, and identification of status reverse change events that are inconsistent with the action dependency status corresponding to the currently proposed action based on the subsequent status change sequences of the work order; S3, extraction of action execution effectiveness analysis parameters by combining work order associated data, subsequent status change sequences of the work order, and real-time business status, and comprehensive assessment of the failure risk of the currently proposed action by combining execution effectiveness analysis data and the number of status reverse change events, and determination of whether the currently proposed action meets the execution conditions based on the failure risk; S4, generation of action processing prompts based on the determination results of the currently proposed action, and generation of corresponding status change prompt information.

[0029] Optionally, the specific process of real-time collection of work order-related data is as follows: Real-time collection of work order-related data includes: collecting work order number, user number, order number, after-sales order number, work order creation timestamp, proposed action, and proposed action verification timestamp from the customer service work order platform; wherein, the work order number is used to uniquely identify the customer service processing task in the customer service work order platform; the user number is used to identify the user subject corresponding to the current customer service work order; the order number is used to identify the order object associated with the current customer service work order; the after-sales order number is used to identify the after-sales processing object associated with the current customer service work order; the work order creation timestamp is used to represent the time when the current customer service work order was generated; the proposed action is the pending processing action generated by the customer service work order platform based on the service request and customer service processing result corresponding to the current work order, including but not limited to refund action, order cancellation action, address modification action, and order closure action; the proposed action verification timestamp comes from the verification trigger record generated by the customer service work order system after generating the proposed action and before submitting the proposed action to the corresponding business processing link for execution, which is used to represent the time node when the system verifies the execution conditions of the proposed action and reflects the state change process from the generation of the proposed action to the formal execution. The system collects user ID, order ID, after-sales order ID, and user operation timestamps from user-end operation logs. User-end operation logs are records of user actions performed via mobile clients, web pages, and self-service terminals. The user operation timestamps represent the actual trigger time of the user's business operation, which includes, but is not limited to, order cancellation, re-payment, resubmitting after-sales requests, withdrawing requests, and changing addresses. The system also collects order ID, order status, and order status update timestamps from order management records. Order status includes pending payment, pending shipment, shipped, cancelled, completed, and closed states. The order status update timestamps represent the time when the order status changed. Finally, the system collects order ID, payment status, payment status update timestamps, refund status, and refund status update timestamps from payment transaction records. Payment status includes unpaid, successful payment, and failed payment, while refund status includes non-refundable, processing refund, successful refund, and failed refund. The corresponding update timestamps represent the time when the payment and refund statuses changed. Collect order number, logistics status, and logistics status update timestamp from logistics and delivery records. Logistics status includes "Pending Out," "Out," "In Transit," "Signed," "Rejected," and "Logistics Abnormality." The logistics status update timestamp indicates the time when the logistics status changes. Collect order number, after-sales order number, after-sales status, and after-sales status update timestamp from after-sales processing records.The after-sales status includes pending review, processing, completed, cancelled, and closed status. The after-sales status update timestamp is used to indicate the time when the after-sales status changes. The above-mentioned work order related data are all linked through order number, after-sales order number, and user number to reflect the real-time status changes of the same customer service work order in different business stages.

[0030] This implementation plan unifies the collection and field definition of customer service work orders, user operations, orders, payments, refunds, logistics, and after-sales status data, clarifying the data sources, time bases, and associated objects for various business statuses. This enables the accurate collection and tracking of status changes of the same customer service work order in different business stages, thereby improving the consistency, integrity, and traceability of work order flow data and providing a reliable data foundation for subsequent action verification, status change identification, and work order auxiliary processing.

[0031] Optionally, the specific process of performing association and aggregation, time unification, duplicate event deduplication, and out-of-order event identification processing on work order-related data to form standard event records is as follows: A customer service work order master record is established based on the work order number. This master record serves as the aggregation carrier for various business status data under the same customer service processing task. Based on the user ID, order number, and after-sales order number, the work order-related data corresponding to the work order number is associated with the same customer service work order master record to obtain standard event records. Specifically, the order number is used to associate order management records, payment transaction records, and logistics delivery records; the after-sales order number is used to associate after-sales processing records; and the user ID is used for... Verify whether data from different sources belong to the same user entity; when the same customer service work order master record does not have an after-sales order number, record the after-sales order number as empty, which does not affect the association and aggregation of order status, payment status, refund status, and logistics status; standard event records include work order number, user number, order number, after-sales order number, event type, event status, event occurrence timestamp, and event receipt timestamp. Event types include user operation events, order status update events, payment status update events, refund status update events, logistics status update events, and after-sales status update events. Event status is the specific status content collected under the corresponding event type. Unify all timestamps to the same time format, which is a timestamp format under a unified clock reference. The unified clock reference is the standard system time of this system server, and unified time synchronization is performed through the Network Time Protocol (NTP). Time data from different data sources are all converted to the millisecond-level timestamp format corresponding to the unified clock reference to ensure that the time sequence of different data sources can be compared. The timestamps for work order creation, proposed action verification, user operation, order status update, payment status update, refund status update, logistics status update, and after-sales status update are used as the corresponding event occurrence timestamps, while the corresponding event reception timestamps are also recorded. The event occurrence timestamps are used to characterize the actual time when the corresponding business status and user operation occur, while the event reception timestamps are used to characterize the time when the work order-related data enters the system and is recorded.For records with the same event type, event status, and event occurrence timestamp under the same customer service work order master record, deduplication is performed. The record with the earliest data reception timestamp is retained, and the remaining records are marked as duplicate event records. The number of duplicate event records is counted as the number of duplicate events. Among them, the same event type, event status, and event occurrence timestamp are used to determine the same business event generated by multi-source push and duplicate callback. Retaining the record with the earliest data reception timestamp means that among multiple standard event records with the same event type, event status, and event occurrence timestamp, the standard event record that enters the system and is recorded first is regarded as the valid record. Since multiple duplicate event records represent the same business status change, the records that arrive later usually come from duplicate push, duplicate callback, or message retry mechanism, and their event content is consistent with the first record that arrives. Therefore, retaining the earliest received record can reduce duplicate statistics and maintain the original time sequence of the event chain reception process. For standard event records under the same customer service work order master record, they are sorted in ascending order by reception timestamp to form the reception order, and then sorted in ascending order by event occurrence timestamp to form the actual occurrence order. When the chronological order of two adjacent standard event records is inconsistent with their chronological order of occurrence, the later-received event with an earlier occurrence timestamp is marked as an out-of-order event, and the number of out-of-order events is counted. Out-of-order events are used to characterize situations where the actual occurrence order of business events is inconsistent with the system's reception order, reflecting the impact of asynchronous callbacks, message delays, and cross-platform status synchronization delays on work order status judgment. A work order flow processing database is established to store pre-processed work order-related data, including the customer service work order master record, standard event records, the number of duplicate events, and the number of out-of-order events. This serves as the data foundation for subsequent extraction of work order subsequent status change sequences, real-time business status, and action execution effectiveness analysis parameters.

[0032] In this implementation plan, work order related data from multiple sources are uniformly collected using work order number, order number, after-sales order number, and user number. A unified clock reference is used to complete the time format conversion, enabling the status data of different business processes to be compared on the same timeline. At the same time, by deduplicating duplicate events and identifying out-of-order events, data interference caused by duplicate callbacks, message delays, and asynchronous synchronization is reduced, improving the accuracy, timing consistency, and traceability of standard event records. This provides a stable and reliable data foundation for subsequent work order status change analysis, real-time business status extraction, and action execution validity verification.

[0033] Optionally, the specific process for extracting the subsequent status change sequence and real-time business status of a work order based on standard event records is as follows: Read the standard event records under the same customer service work order master record. These standard event records include event type, event status, event occurrence timestamp, and event reception timestamp. The standard event records have been associated and aggregated according to the same customer service work order master record, and are used to characterize the status change process of customer service work orders in user operations, orders, payments, refunds, logistics, and after-sales processes. Determine the work order creation timestamp and the proposed action verification timestamp corresponding to the customer service work order master record, and define the time range between the work order creation timestamp and the proposed action verification timestamp as the action verification time interval. The action verification time interval is used to limit the range of status changes that need to be considered when judging the validity of the current proposed action. The work order creation timestamp is the starting point of the time interval, and the proposed action verification timestamp is the ending point of the time interval. Within the action verification time interval, event records in the same customer service work order master record, sorted in ascending order by event occurrence timestamp, are read to form a work order subsequent status change sequence. This sequence includes one or more of the following: user operation events, order status update events, payment status update events, refund status update events, logistics status update events, and after-sales status update events. These events reflect the changes in business status from work order creation to the generation of the currently intended action, based on their actual occurrence time. If no status update event for a particular business step exists within the action verification time interval, the corresponding status for that step is recorded as null. A null value indicates that no corresponding status record has been generated for that business step in the current customer service work order master record, and it is not included in the subsequent status statistics for that business step. The last update record of the order status, payment status, refund status, logistics status, and after-sales status before the verification timestamp of the intended action is extracted from the work order subsequent status change sequence and used as the real-time business status. The event occurrence timestamp for each real-time business status is also recorded. The real-time business status is used to represent the latest available status of each business link (order, payment, refund, logistics, and after-sales) before the current action to be executed is generated. When a business link has only one status update record in the subsequent status change sequence of the work order, the status update record is used as the real-time business status of the business link. When a business link has no status update record, the real-time business status of the business link is recorded as a null value, and null values ​​do not participate in the action dependency status matching corresponding to the business link. To ensure the consistency of the source of the last update record, the order status, payment status, refund status, logistics status, and after-sales status all originate from the status field and its update timestamp field in the corresponding business record.

[0034] In this implementation plan, by limiting the time interval for action verification and forming a sequence of subsequent status changes for work orders according to the event timestamp, the business status change process from the creation of the work order to the generation of the action to be executed can be accurately restored. At the same time, the latest available status of each business link is extracted as the real-time business status, avoiding the execution of processing actions based on expired status, and improving the accuracy, timeliness and traceability of the verification of the current action to be executed.

[0035] Optionally, based on the subsequent status change sequence of the work order, the specific process for identifying a status reversal event that is inconsistent with the action dependency status corresponding to the currently intended action is as follows: Based on preset standard action dependency rules, which are derived from the work order processing flow rules, order status flow rules, payment transaction processing rules, logistics delivery status rules, and after-sales processing rules pre-configured on the customer service work order platform, an action dependency status mapping table is established based on the business processing conditions corresponding to different intended actions. This table records the business status conditions that different intended actions need to meet before execution. The standard action dependency rules include at least the type of intended action, the dependent business links, and the scope of dependent status. For example, the dependent business links corresponding to the refund action include the payment link, the refund link, and the after-sales link, and the scope of dependent status includes the payment status being successful, the refund status being not refunded or the refund failing, and the after-sales status not being cancelled; the dependent business links corresponding to the order cancellation action include the order link and the logistics link, and the scope of dependent status includes the order status not being cancelled or completed, and the logistics status not being signed for; the dependent business links corresponding to the address modification action include the logistics link, and the scope of dependent status includes the logistics status not being signed for. Action-dependent states are stored using a structured mapping method of "business process fields plus allowed state sets". Based on the current action to be executed, the corresponding action dependency state is determined. Then, based on the subsequent status change sequence of the work order, status update events in the subsequent status change sequence that are inconsistent with the action dependency state corresponding to the action to be executed are identified. Specifically, each status update event in the subsequent status change sequence is matched sequentially with the action dependency state according to its occurrence timestamp. When the business process to which the status update event belongs belongs to the dependent business process of the current action to be executed, and the event state of the status update event does not fall within the range of the corresponding dependency state, the status update event is identified as a status reversal event. For example, if the current action to be executed is a refund, and the subsequent status change sequence of the work order shows a refund status of "refund successful," an after-sales status of "cancelled," or a payment status of "unpaid," then the corresponding status update event is identified as a status reversal event. If the current action to be executed is an order cancellation, and the subsequent status change sequence of the work order shows an order status of "completed" or a logistics status of "signed," then the corresponding status update event is identified as a status reversal event. Based on the above steps, update events that cause the real-time business state to change from meeting the dependency conditions to not meeting the dependency conditions are counted, resulting in the number of status reversal events. Among them, the number of status reversal events is the total number of status update events identified as status reversal events under the same customer service work order master record. It is used to characterize the degree to which the business status changes in a direction that does not support the continued execution of the currently intended action after the work order is created.

[0036] In this implementation plan, the range of executable states corresponding to different proposed actions is clearly defined by standard action dependency rules. The state update events in the subsequent state change sequence of the work order are matched one by one with the action dependency states. This can promptly identify situations where the business state changes in a direction that does not support the continued execution of the current proposed action after the work order is created. This improves the accuracy and predictability of the identification of reverse state change events and provides a clear basis for subsequent action failure risk assessment and proposed action verification.

[0037] Optionally, the specific process of extracting action execution effectiveness analysis parameters by combining work order association data, work order subsequent status change sequence, and real-time business status is as follows: read the work order subsequent status change sequence, real-time business status, action dependency status corresponding to the proposed action, number of status reverse change events, number of duplicate events, and number of out-of-order events corresponding to the same customer service work order master record; among them, the work order subsequent status change sequence is used to provide user operation events and status update events from work order creation to the generation of the proposed action; the real-time business status is used to provide the latest status of each business link before the generation of the proposed action; the action dependency status is used to represent the business status conditions that need to be met when the current proposed action continues to be executed; the number of status reverse change events is used to characterize the number of status update events that do not support the continued execution of the current proposed action; and the number of duplicate events and out-of-order events are used to characterize the abnormal event situation in the multi-source event synchronization process. The time difference between the verification timestamp of the action to be executed and the work order creation timestamp is calculated to obtain the work order action verification duration. The work order action verification duration is the non-negative time length obtained by subtracting the work order creation timestamp from the verification timestamp of the action to be executed, used to characterize the flow time experienced by the current customer service work order from creation to verification of the current action to be executed. Based on the user operation timestamps in the subsequent status change sequence of the work order, the number of user operation events is counted to obtain the number of subsequent user operation events. Subsequent user operation events are user operation events formed by user-end operation logs within the action verification time interval, and the number of subsequent user operation events is the statistical count of user operation events within the action verification time interval; only user operation events whose occurrence timestamps are between the work order creation timestamp and the verification timestamp of the action to be executed are counted. The system counts historically executed actions that are identical to the currently planned action under the same order number, thus determining the execution count of similar actions. These historically executed action records are derived from the work order processing database, specifically from action records that have been completed and whose execution results have been written. When counting similar actions, historically executed action records under the same order number but prior to the verification timestamp of the planned action are read, and the statistical scope is limited to action records within a preset action backtracking time window. This preset backtracking time window limits the retrieval time range of historically executed action records, preferably ranging from 1 to 10 days, to avoid interference from premature historical actions in assessing the failure risk of the currently planned action. For historically executed action records with the same action type, order number, and action completion time, only one record is retained for the similar action execution count statistics.Based on real-time business status, the number of real-time business states that satisfy the action dependency status corresponding to the currently planned action is counted to obtain the number of effective support states. The number of effective support states is the number of business state dimensions among the real-time business states that satisfy the action dependency status corresponding to the currently planned action. Business state dimensions include at least one or more of the following: order status, payment status, refund status, logistics status, and after-sales status. A real-time business state that belongs to a business link dependent on the currently planned action and satisfies the action dependency status is counted as one effective support state dimension. Real-time business states that do not belong to a business link dependent on the currently planned action are not included in the count of effective support states. The minimum event timestamp among all real-time business states is taken as the earliest business state update timestamp. The time difference between the planned action verification timestamp and the earliest business state update timestamp is calculated to obtain the action state lag time. The earliest business status update timestamp is used to characterize the update time corresponding to the earliest updated business status among the real-time business statuses. The action status lag time is the non-negative time length obtained by subtracting the earliest business status update timestamp from the verification timestamp of the proposed action, used to characterize the time lag of the current proposed action relative to the oldest business status. When there is no real-time business status, the action status lag time is recorded as zero. The minimum value among the occurrence timestamps of each real-time business status event is taken because the validity of the current proposed action depends on the real-time status of multiple business links. If the status of any business link has not been updated for a long time, it may cause the current proposed action to continue to be executed based on the expired status. Therefore, using the minimum value can reflect the update time corresponding to the oldest business status among the real-time business statuses.

[0038] In this implementation plan, by extracting parameters such as user subsequent operations, reverse status changes, execution of similar actions, effective support status, repeated events, out-of-order events, and time lag from the subsequent status change sequence of work orders, real-time business status, and action dependency status, the execution basis of the currently planned action can be quantified into analyzable data, improving the accuracy and traceability of action failure risk assessment, and reducing the risk of error handling caused by status lag, repeated execution, or inconsistent business status.

[0039] Optionally, the specific process for comprehensively assessing the failure risk of the currently planned action by combining the execution effectiveness analysis data and the number of state reversal change events is as follows: The number of subsequent user operation events, the number of state reversal change events, and the number of times similar actions are executed are added together to obtain the action failure trigger number. The action failure trigger number is used to characterize the degree of failure triggering caused by user re-operation after work order creation, reverse changes in business status, and repeated execution of similar actions on the currently planned action. The action failure trigger number is divided by the sum of the number of effective supporting states and one, where adding one is used to avoid division by zero when the number of effective supporting states is zero, and to reduce the failure impact when the current real-time business status still supports the currently planned action. The ratio is then incremented by one and the natural logarithm is taken to obtain the action failure trigger component. Taking the natural logarithm is used to suppress the sudden increase in value caused by an excessively large action failure trigger number, ensuring that the action failure trigger component increases smoothly with the increase of risk factors. The total action time lag is obtained by adding the work order action verification time and the action status lag time. This total action time lag characterizes the combined impact of the current customer service work order's creation time from the generation of the proposed action and the lag time of the proposed action relative to the latest business status. The total action time lag is then divided by the sum of the work order action verification time and the preset positive time correction, and a negative exponent is calculated. The preset positive time correction is the smallest time unit corresponding to the unified clock reference, derived from the time sampling accuracy under the unified clock reference. When the unified clock reference uses second-level time accuracy, the preset positive time correction is 1 second; when the unified clock reference uses millisecond-level time accuracy, the preset positive time correction is 1 millisecond, used to ensure the denominator is positive and the exponent term remains dimensionless. Subtracting the negative exponent from the result yields the time lag impact component. The time lag impact component increases with the increase of the total action time lag, characterizing the enhanced effect of time lag on the failure risk of the currently proposed action. The number of out-of-order events and the number of duplicate events are added together to obtain the number of event link anomalies. This number characterizes the degree of abnormal receiving order and duplicate record anomalies when multi-source work order associated data enters the system. The number of subsequent user operation events and the number of reverse status change events are added together to obtain the number of event link correction events. This number is used to correct the impact of event link anomalies based on the scale of subsequent actual business changes in the work order, preventing a small number of out-of-order and duplicate events from being excessively amplified when there are many subsequent user operations and reverse status changes. The number of event link anomalies is divided by the number of event link correction events and then added together to obtain the event link anomaly amplification component. This component characterizes the amplification effect of out-of-order and duplicate events on the risk of failure of the currently planned action. The action failure triggering component, the time lag impact component, and the event link anomaly amplification component are multiplied together to obtain the action failure verification value.The action failure check value characterizes the overall failure risk level between the currently planned action and the real-time business status, and is a dimensionless indicator. A higher check value indicates that the planned action is more likely to no longer be applicable to the real-time business status corresponding to the current customer service work order master record. The action failure check value is calculated by multiplying the action failure trigger component, the time lag impact component, and the event link anomaly amplification component. Essentially, whether the planned action fails is affected not only by changes in the business status itself but also by the combined effects of time lag and data link reliability. Therefore, using a product form to couple and characterize these three types of influences better reflects the risk formation process in actual work order workflow scenarios. The action failure trigger component reflects whether the business status no longer supports the continued execution of the currently planned action. The greater the number of subsequent user operation events, the greater the number of reverse state change events, and the greater the number of times similar actions are executed, the higher the risk of continuing the current intended action. This indicates that the user has re-performed business operations after the work order was created, the business state has changed in the opposite direction to the currently intended action, or similar actions have already been executed. Conversely, a larger number of effective supporting states indicates that there are still many business conditions in the real-time business state that satisfy the action's dependent state, thus requiring a reduction in the degree of failure triggering. The natural logarithm is used because business risks in real-world scenarios typically exhibit a "rapid increase in the early stages and a gradual slowdown in the later stages," which avoids the possibility of a large number of state changes causing the verification value to increase indefinitely. The time lag component reflects the "degree of time deviation between the currently intended action and the latest business state." The longer the work order action verification time, the more processing stages the work order undergoes during its flow; the longer the action state lag time, the longer the time since the latest business state update has been for the currently intended action, making it easier to generate errors when continuing to execute actions based on the old state. The negative exponential form is used because the impact of time on the effectiveness of actions typically exhibits a gradually diminishing trend; that is, the impact is small when the time is short, but as time continues to increase, the risk of action failure gradually increases and tends to stabilize. The event link anomaly amplification component reflects the "impact of multi-source data link anomalies on state reliability." The larger the number of out-of-order events and duplicate events, the more obvious asynchronous callbacks, message delays, and duplicate pushes exist during the synchronization process of multi-source business events. At this time, the reliability of real-time business status decreases, so the overall failure risk needs to be amplified. However, when the number of subsequent user operation events and the number of state reverse change events are already large, it indicates that the changes in business status mainly originate from real business changes. Therefore, the impact of event link anomalies needs to be appropriately corrected to avoid a small number of link anomalies from excessively amplifying the overall risk.Therefore, the failure verification value of the processing action can comprehensively reflect the real failure risk of the action to be executed from three dimensions: business consistency, time validity, and data reliability by coupling and evaluating three types of factors: changes in business status, time lag, and event link anomalies.

[0040] The specific formula for the failure check value of the processing action is as follows: ; In the formula, The value represents the failure check value of the processing action. It is used to comprehensively assess the degree of failure risk of the current action to be executed in the work order process. By combining the user's subsequent operations, reverse status changes, action execution history, event chain anomalies and action time delays, it is determined whether the current action to be executed still meets the execution conditions. The larger the failure check value of the processing action, the higher the degree of inconsistency between the current action to be executed and the real-time business status, and the greater the risk of action failure. This indicates the number of subsequent user action events, used to characterize how frequently a user performs business operations again after a work order is created; This indicates the number of state reversal events, used to characterize the degree of inconsistency between the real-time business state and the state that the action to be executed depends on. This indicates the number of times a similar action has been executed, and is used to characterize the degree of repetition of the historical action corresponding to the action to be executed now; This indicates the number of valid support states, used to characterize the degree to which the real-time business status supports the currently planned action; This indicates the number of out-of-order events, used to characterize the degree of abnormality in the arrival order of multi-source events; This indicates the number of duplicate events, used to characterize the degree of repeated writing or receiving of events; This indicates the work order action verification duration, which represents the time from work order creation to action verification for the currently scheduled action. Indicates the time lag of the action status, used to characterize the degree of time lag between the current action to be executed and the latest business status; This represents the preset positive time correction amount, used to avoid the time denominator being zero and to smoothly correct time changes in short-time scenarios. The value is the smallest time measurement unit corresponding to the unified clock reference.

[0041] In this embodiment, Table 1 is a data table of processing action failure verification values. The preset positive time correction is 1. The table details the number of subsequent user operation events, the number of status reversal events, the number of times similar actions were executed, the number of valid support states, the number of out-of-order events, the number of duplicate events, the work order action verification time, the action status lag time, and the processing action failure verification value for each of the five customer service work order master records. Among them, record 1 corresponds to 0 user subsequent operation events, 0 status reverse change events, 0 times of similar action execution, 1 number of valid support states, 0 out-of-order events, 0 duplicate events, 42 work order action verification time, 6 action status lag time, and 0.0000 processing action failure verification value; record 2 corresponds to 1 user subsequent operation event, 0 status reverse change events, 0 times of similar action execution, 2 valid support states, 0 out-of-order events, 1 duplicate event, 95 work order action verification time, 18 action status lag time, and 0.2985 processing action failure verification value; record 3 corresponds to 1 user subsequent operation event, 1 status reverse change event, 0 times of similar action execution, 1 valid support state, and out-of-order events. Record 4 has the following characteristics: 1. Number of subsequent user operation events, 0. Number of recurring events, 210. Number of action status delays, 66. Number of processing action failures: 0.6743. Record 5 has the following characteristics: 1. Number of subsequent user operation events, 2. Number of status reversal events, 1. Number of similar actions executed, 1. Number of valid support states, 1. Number of out-of-order events, 1. Number of recurring events, 367. Number of action status delays, 151. Number of processing action failures: 1.2446. Record 5 has the following characteristics: 2. Number of subsequent user operation events, 3. Number of status reversal events, 1. Number of similar actions executed, 0. Number of valid support states, 2. Number of out-of-order events, 1. Number of recurring events, 554. Number of action status delays, 240. Number of processing action failures: 2.2208.

[0042] Table 1 Data table of failure verification values ​​for processing actions

[0043] like Figure 3The chart shown is a bar chart for assessing the risk of processing action failure verification values. The chart uses the customer service ticket master record as the horizontal axis and the processing action failure verification value as the vertical axis, displaying the degree of processing action failure risk for five groups of customer service tickets under different business status changes. The bars represent the processing action failure verification values ​​for each customer service ticket master record, and the dashed lines represent failure judgment thresholds. When the processing action failure verification value is lower than the failure judgment threshold, it indicates a high consistency between the currently planned action and the real-time business status, and the risk of continuing the action is low. When the processing action failure verification value is higher than the failure judgment threshold, it indicates that the currently planned action has been affected by factors such as subsequent user operations, reverse status changes, time lags, and event chain anomalies, and continuing execution carries a high risk of failure. (Combined with Table 1 and...) Figure 3 As can be seen, the failure check value for processing actions shows a significant upward trend as the number of subsequent user operation events, the number of reverse state change events, the number of similar actions executed, and the number of link anomalies gradually increase, while the number of effectively supporting states gradually decreases. Specifically, the failure check values ​​for processing actions corresponding to records 1 to 3 are all below the failure judgment threshold, indicating that the currently intended action still has a high degree of business state support. However, the failure check values ​​for processing actions corresponding to records 4 and 5 exceed the failure judgment threshold, indicating a significant inconsistency between the currently intended action and the real-time business state. This allows for the identification of action failure risks and triggers pause execution and status prompt processing.

[0044] This implementation plan, by coupling and evaluating changes in business status, time lag, and event chain anomalies, can more comprehensively characterize the failure risk between the current action to be executed and the real-time business status. At the same time, by effectively supporting the suppression of risk amplification by status, smoothing abnormal growth with natural logarithm, characterizing the impact of time lag with negative exponentiation, and correcting the credibility of status by combining out-of-order events and duplicate events, it improves the accuracy, stability, and traceability of action failure judgment, and reduces the risk of duplicate execution, reverse execution, and incorrect handling based on expired status in the work order process.

[0045] Optionally, the specific process for determining whether the current proposed action meets the execution conditions based on failure risk is as follows: Match the real-time business status with the action dependency status corresponding to the current proposed action; when the real-time business status does not meet the action dependency status corresponding to the current proposed action, mark the current proposed action as a failed action; the real-time business status not meeting the action dependency status means that at least one real-time business status related to the current proposed action does not belong to the corresponding dependency status range. When the real-time business status meets the action dependency status corresponding to the current proposed action, compare the processing action failure check value with the failure judgment threshold; if the processing action failure check value is less than the failure judgment threshold, mark the current proposed action as a valid action; wherein, the real-time business status meeting the action dependency status corresponding to the current proposed action means that the order status, payment status, refund status, logistics status, and after-sales status in the real-time business status fall within the dependency status range of the dependent business links corresponding to the current proposed action; after being marked as a valid action, it indicates that the current proposed action has not experienced a failure risk exceeding the failure judgment threshold, and the current business status still supports the continued flow of the proposed action. If the failure check value for a processing action is greater than or equal to the failure judgment threshold, the currently intended action is marked as a failed action. Once marked as a failed action, it indicates that the currently intended action has the risk of inconsistent status, expired action basis, or repeated execution, and will no longer be used as the direct basis for subsequent customer service work order processing.

[0046] In this implementation plan, by comparing the failure verification value of the processing action with the failure judgment threshold and combining it with whether the real-time business status meets the action dependency status for dual judgment, it is possible to avoid misjudgment caused by relying solely on risk values ​​or single status conditions. This makes the validity or failure mark of the currently intended action more accurate, executable, and traceable, thereby reducing the risk of continued circulation, repeated execution, or erroneous execution based on the expired status.

[0047] Optionally, the specific process of generating a processing prompt for the proposed action based on the determination result of the current proposed action, and generating corresponding status change prompt information, is as follows: When the current proposed action is marked as a valid action, a prompt indicating that the proposed action can be executed is output to the customer service ticket system; wherein, the prompt indicating that the proposed action can be executed is used to indicate to the customer service ticket system that the current proposed action has passed the failure risk check and action dependency status check, and can serve as the basis for subsequent flow in the current customer service ticket master record. When the current proposed action is marked as a failed action, a prompt indicating that the proposed action can be suspended is output to the customer service ticket system; wherein, the prompt indicating that the proposed action can be suspended is used to indicate to the customer service ticket system to suspend submitting the current proposed action to the corresponding business processing stage, so as to avoid continuing the flow when the real-time business status does not match or the risk of action failure is high. Based on state reversal events, real-time business status, and action dependency status, state difference items are located. These state difference items are either business status items in the real-time business status that do not belong to the action dependency status range of the business link corresponding to the currently intended action, or state update items identified as state reversal events in the subsequent state change sequence of the work order. Failure reason labels are generated based on the business link and status content to which the state difference item belongs, including at least one of the following: order status not satisfied, payment status not satisfied, refund status not satisfied, logistics status not satisfied, after-sales status not satisfied, and the existence of a state reversal. State change prompts are also generated, including order status change prompts, payment status change prompts, refund status change prompts, logistics status change prompts, and after-sales status change prompts. These prompts include at least the business status dimension where the state reversal occurred, the status content before and after the update, the event timestamp of the corresponding state update event, and a conflict explanation with the action dependency status corresponding to the currently intended action. This information displays the business link, real-time business status, action dependency status, and event timestamp of the state reversal event corresponding to the state difference item, enabling customer service personnel to identify the specific state basis for the currently intended action being marked as a failed action. The system writes the currently planned action, real-time business status, action failure check value, planned action flag, failure reason label, and status change prompt information into the work order processing database. The data written to the work order processing database is used to create a check result record for the currently planned action, enabling subsequent customer service work order processing, status tracing, and anomaly review to retrieve the corresponding processing basis.

[0048] In this implementation plan, by outputting a prompt to allow execution or a prompt to suspend execution based on the validity or invalidity determination result of the action to be executed, and further locating the status difference items, generating failure reason labels and status change prompt information, the customer service work order system can clearly understand whether the current action can continue to flow and the basis for judgment, thereby improving the interpretability, traceability and status consistency of work order processing, and reducing the risk of erroneous execution caused by mismatch of business status.

[0049] like Figure 2 As shown, the second aspect of the present invention provides a customer service intent auxiliary processing system for service work order flow, applied to the aforementioned customer service intent auxiliary processing method for service work order flow, including: a work order data acquisition and processing module, used to collect work order related data in real time, and perform association aggregation, time unification, duplicate event deduplication, and out-of-order event identification processing on the work order related data to form a standard event record; a work order intent status association module, used to extract the subsequent status change sequence of the work order and the real-time business status based on the standard event record, and to identify the status reverse change event that is inconsistent with the action dependency status corresponding to the currently intended action based on the subsequent status change sequence of the work order; a processing action failure verification module, used to extract action execution effectiveness analysis parameters by combining work order related data, subsequent status change sequence of the work order, and real-time business status, and to comprehensively evaluate the failure risk of the currently intended action by combining execution effectiveness analysis data and the number of status reverse change events, and to determine whether the currently intended action meets the execution conditions based on the failure risk; and an auxiliary handling write-back module, used to generate a processing prompt for the intended action based on the determination result of the currently intended action, and to generate corresponding status change prompt information.

[0050] like Figure 4 The diagram shows the framework flowchart for customer service intent-assisted processing in service order workflow. It illustrates the overall processing flow of the customer service intent-assisted processing system for service order workflow. First, multi-source business data, including work orders, users, orders, payments, logistics, and after-sales service, is collected. Through correlation aggregation, unified time formatting, duplicate event deduplication, and out-of-order event identification, standard event records are generated and written to the work order workflow database. Based on this, the subsequent status change sequence of the work order and the real-time business status are extracted. Status reversal events that are inconsistent with the status dependency of the currently planned action are identified, and the number of status reversal events is counted. Subsequently, further parameters for action execution effectiveness analysis are extracted, including the number of subsequent user operation events, the number of duplicate events, the number of out-of-order events, and time lag parameters. A failure check value for the processing action is calculated, and a comprehensive assessment of the failure risk of the currently planned action is performed. During the risk assessment phase, the system first determines whether the real-time business status meets the action dependency status corresponding to the currently planned action. If not, the planned action is directly marked as a failed action. If it does, the system further compares the action failure check value with the failure judgment threshold. If the check value is lower than the failure judgment threshold, the action is marked as valid and an execution permission prompt is output. If the check value is greater than or equal to the failure judgment threshold, the action is marked as failed and a pause execution prompt is output, along with failure reason and status change prompts. Finally, the processing result is written back to the work order workflow database to achieve auxiliary decision-making and risk control in the customer service work order workflow process.

[0051] In this implementation plan, through modular collaboration of work order data collection and processing, work order intent status association, processing action failure verification, and auxiliary disposal write-back, it is possible to uniformly collect, time-series correct, and dynamically verify multi-source work order status data, promptly identify situations where the intended action is inconsistent with the real-time business status, and output traceable processing prompts, thereby improving the accuracy, stability, and consistency of customer service work order flow.

[0052] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0053] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0054] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0055] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0056] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0057] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the devices, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0058] In the several embodiments provided by this invention, it should be understood that the disclosed devices, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0059] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0060] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0061] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0062] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A customer service intent-assisted processing method for service order flow, characterized in that, The method includes: S1 collects work order related data in real time, and performs association aggregation, time unification, duplicate event deduplication and out-of-order event identification processing on the work order related data to form standard event records; S2, extract the subsequent status change sequence of the work order and the real-time business status based on the standard event record, and identify the status reverse change event that is inconsistent with the action dependency status corresponding to the current action to be executed based on the subsequent status change sequence of the work order. S3 combines work order associated data, work order subsequent status change sequence and real-time business status to extract action execution effectiveness analysis parameters. Combining execution effectiveness analysis data and the number of status reverse change events, it comprehensively assesses the failure risk of the current proposed action and determines whether the current proposed action meets the execution conditions based on the failure risk. S4. Generate a processing prompt for the proposed action based on the determination result of the current proposed action, and generate corresponding status change prompt information.

2. The customer service intent-assisted processing method for service order flow according to claim 1, characterized in that, The specific process for real-time collection of work order-related data is as follows: Real-time collection of work order-related data, including: work order number, user number, order number, after-sales order number, work order creation timestamp, planned action, and planned action verification timestamp from the customer service work order platform; user number, order number, after-sales order number, and user operation timestamp from user-end operation logs; order number, order status, and order status update timestamp from order management records; order number, payment status, payment status update timestamp, refund status, and refund status update timestamp from payment transaction records; order number, logistics status, and logistics status update timestamp from logistics and delivery records; and order number, after-sales order number, after-sales status, and after-sales status update timestamp from after-sales processing records.

3. The customer service intent-assisted processing method for service work order flow according to claim 2, characterized in that, The specific process of associating and aggregating work order-related data, unifying time, deduplicating duplicate events, and identifying out-of-order events to form standard event records is as follows: A customer service work order master record is established based on the work order number, and the work order related data corresponding to the work order number is associated with the same customer service work order master record based on the user number, order number, and after-sales order number to obtain a standard event record; All timestamps are standardized to the same time format, and the timestamps for work order creation, action verification, user operation, order status update, payment status update, refund status update, logistics status update, and after-sales status update are used as the corresponding event occurrence timestamps. At the same time, the corresponding event reception timestamps are also recorded. For records with the same event type, event status, and event occurrence timestamp under the same customer service work order master record, deduplication is performed, and the record with the earliest data reception timestamp is retained. The remaining records are marked as duplicate event records, and the number of duplicate event records is counted as the number of duplicate events. For standard event records under the same customer service work order master record, sort them in ascending order according to the receiving timestamp to form the receiving order, and sort them in ascending order according to the event occurrence timestamp to form the actual occurrence order. When the order of two adjacent standard event records in the receiving order is inconsistent with the order of the actual occurrence order, the event that was received later but has an earlier event occurrence timestamp is marked as an out-of-order event, and the number of out-of-order events is counted. Establish a work order flow processing database to store pre-processed work order associated data.

4. The customer service intent-assisted processing method for service work order flow according to claim 3, characterized in that, The specific process for extracting the subsequent status change sequence and real-time business status of work orders based on standard event records is as follows: Read the standard event records under the same customer service work order master record, determine the work order creation timestamp and the action verification timestamp corresponding to the customer service work order master record, and determine the time range between the work order creation timestamp and the action verification timestamp as the action verification time interval; Within the action verification time interval, read the event records under the same customer service work order master record, which are arranged in ascending order according to the event occurrence timestamp, to form the subsequent status change sequence of the work order. Extract the last update record of the order status, payment status, refund status, logistics status and after-sales status before the verification timestamp of the action to be executed from the subsequent status change sequence of the work order, and use it as the real-time business status, and record the event occurrence timestamp of each real-time business status.

5. The customer service intent-assisted processing method for service order flow according to claim 4, characterized in that, The specific process for identifying state-reverse change events that are inconsistent with the action dependency state corresponding to the currently intended action, based on the subsequent state change sequence of the work order, is as follows: Based on the preset standard action dependency rules, the corresponding action dependency state is determined according to the action to be executed. Based on the subsequent status change sequence of the work order, status update events that are inconsistent with the action dependency state corresponding to the action to be executed in the subsequent status change sequence of the work order are identified, and the number of status reverse change events is counted.

6. The customer service intent-assisted processing method for service order flow according to claim 4, characterized in that, The specific process for extracting action execution effectiveness analysis parameters by combining work order associated data, subsequent work order status change sequences, and real-time business status is as follows: Read the sequence of subsequent status changes, real-time business status, action dependency status corresponding to the action to be executed, number of status reverse change events, number of duplicate events and number of out-of-order events corresponding to the same customer service work order master record; Calculate the time difference between the verification timestamp of the action to be executed and the work order creation timestamp to obtain the work order action verification duration; Based on the user operation timestamps in the subsequent status change sequence of the work order, the number of user operation events is counted to obtain the number of subsequent user operation events; Count the historical execution records of the same action that is the same as the action to be executed under the same order number to obtain the number of times the same action is executed. Based on the real-time business status, the number of real-time business states that satisfy the action dependency states corresponding to the current intended action is counted to obtain the number of effective support states. Take the minimum value among the event timestamps of each real-time business status as the earliest business status update timestamp, calculate the time difference between the verification timestamp of the action to be executed and the earliest business status update timestamp, and obtain the action status lag time.

7. The customer service intent-assisted processing method for service order flow according to claim 6, characterized in that, The specific process for comprehensively assessing the failure risk of the currently planned action by combining execution effectiveness analysis data and the number of state reversal events is as follows: Add the number of subsequent user operation events, the number of state reversal events, and the number of times the same action is executed to get the number of action failure triggers. Divide the number of action failure triggers by the sum of the number of valid supporting states and one, add one to the ratio, and take the natural logarithm to get the action failure trigger component. Add the work order action verification time to the action status lag time to get the total action time lag. Divide the total action time lag by the sum of the work order action verification time and the preset positive time correction amount to calculate the negative exponent. Subtract the negative exponent from the result to get the time lag impact component. Add the number of out-of-order events to the number of duplicate events to get the number of event chain anomalies; Add the number of subsequent user operation events and the number of reverse state change events, then add one to get the number of event chain corrections; Divide the number of event link anomalies by the number of event link corrections and then add one to obtain the event link anomaly amplification component. The action failure trigger component, the time lag impact component, and the event link anomaly amplification component are multiplied together to obtain the action failure verification value.

8. The customer service intent-assisted processing method for service order flow according to claim 7, characterized in that, The specific process for determining whether the currently planned action meets the execution conditions based on failure risk is as follows: Match the real-time business status with the action dependency status corresponding to the current action to be executed; when the real-time business status does not meet the action dependency status corresponding to the current action to be executed, mark the current action to be executed as a failed action; When the real-time business status meets the action dependency status corresponding to the action to be executed, the failure check value of the processing action is compared with the failure judgment threshold. If the failure check value of the processing action is less than the failure judgment threshold, the action to be executed is marked as a valid action. If the failure check value of the processing action is greater than or equal to the failure judgment threshold, the action to be executed is marked as a failed action.

9. The customer service intent-assisted processing method for service order flow according to claim 8, characterized in that, The specific process of generating a processing prompt for the proposed action based on the determination result of the current proposed action, and generating corresponding status change prompt information is as follows: When the action to be executed is marked as a valid action, output a prompt to the customer service ticket system indicating that the action to be executed is allowed. When the currently scheduled action is marked as a failed action, output a message to the customer service ticket system indicating that the scheduled action should be suspended. Based on state reversal events, real-time business status, and action-dependent status, identify state difference items, generate failure reason tags, and generate state change prompts, including order status change prompts, payment status change prompts, refund status change prompts, logistics status change prompts, and after-sales status change prompts. Write the current action to be executed, real-time business status, action failure check value, action to be executed flag, failure reason label, and status change prompt information into the work order flow processing database.

10. A customer service intent-assisted processing system for service work order flow, characterized in that: include: The work order data acquisition and processing module is used to collect work order related data in real time, and to perform association and aggregation, time unification, duplicate event deduplication and out-of-order event identification processing on the work order related data to form standard event records; The work order intent status association module is used to extract the subsequent status change sequence and real-time business status of the work order based on standard event records, and to identify the status reverse change event that is inconsistent with the action dependency status corresponding to the currently intended action based on the subsequent status change sequence of the work order. The action failure verification module is used to combine work order associated data, work order subsequent status change sequence and real-time business status to extract action execution validity analysis parameters, combine execution validity analysis data and the number of status reverse change events to comprehensively assess the failure risk of the current action to be executed, and determine whether the current action to be executed meets the execution conditions based on the failure risk. The auxiliary processing write-back module is used to generate a processing prompt for the action to be executed based on the judgment result of the current action to be executed, and to generate corresponding status change prompt information.

Images