Data processing method and device, equipment, storage medium and product

Abstract

The application discloses a data processing method, device, equipment, storage medium and product, relates to the technical field of data processing, and comprises the following steps: receiving user events from a plurality of business subsystems, encapsulating the user events into unified event objects; determining a service obligation state record according to the unified event objects; determining marketing state information based on the service obligation state record; and performing product marketing according to the marketing state information and a marketing candidate task. The application achieves cross-system consistency control of customer service, after-sales service and marketing actions by converting cross-system user events into a service obligation state record through unified event encapsulation and driving dynamic gating of marketing access, avoids execution of business conflict actions from the source, significantly reduces invalid marketing overhead and manual takeover rate, and improves data accuracy and response efficiency of multi-system collaborative processing.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to data processing methods, apparatus, equipment, storage media and products. Background Technology

[0002] Current intelligent customer service systems typically employ technologies such as natural language understanding, dialogue generation, emotion recognition, and human intervention to handle user inquiries. They utilize ticketing, order, and marketing systems to handle after-sales processing, order inquiries, and outreach tasks, respectively. Because the data structures, event sequences, and execution permissions of these systems are independent, when a user simultaneously involves after-sales commitments, ticket progress, order status, and marketing outreach within the same conversation, the system struggles to establish a unified and computable state in a timely manner. This can easily lead to inconsistencies between response content, backend processes, and outreach actions. Summary of the Invention

[0003] The main purpose of this application is to provide a data processing method, apparatus, device, storage medium, and product, which aims to solve the technical problem in existing intelligent customer service systems where customer service conversations, after-sales work orders, and marketing outreach are separate subsystems. The dispersed business status makes it impossible for the system to identify and intercept behaviors that conflict with unclosed after-sales obligations before customer service responses and marketing actions are executed, ultimately resulting in a poor user experience.

[0004] To achieve the above objectives, this application proposes a data processing method, which includes: Receive user events from multiple business subsystems and encapsulate the user events into a unified event object; The service obligation status record is determined based on the unified event object; Marketing status information is determined based on the service obligation status record; Product marketing is conducted based on the marketing status information and marketing candidate tasks.

[0005] Optionally, the step of conducting product marketing based on the marketing status information and marketing candidate tasks includes: Identify marketing users and marketing content based on marketing candidate tasks; Determine the degree of obligation closure based on the marketing users and the marketing status information; Determine the degree of commitment conflict based on the marketing content and the marketing status information; Product marketing is conducted based on the aforementioned obligation closure degree, commitment conflict degree, emotional recovery degree, and marketing candidate tasks.

[0006] Optionally, the product marketing based on the obligation closure degree, the commitment conflict degree, the emotional recovery degree, and the marketing candidate tasks includes: Determine user complaint rate and marketing reach frequency based on marketing status information; The marketing risk value is determined based on the user complaint rate, the marketing reach frequency, the obligation closure degree, the commitment conflict degree, and the emotional recovery degree. The gate control result is determined based on the aforementioned marketing risk value and the preset marketing strategy; Product marketing is conducted based on the gating results and the marketing candidate tasks.

[0007] Optionally, after determining the service obligation status record based on the unified event object, the method further includes: Upon receiving a user's customer service conversation, determine the user's identifier; The service status is determined based on the user identifier and the service obligation status record; The user customer service session is responded to based on the service status.

[0008] Optionally, determining the service obligation status record based on the unified event object includes: Obligation identification is performed on the unified event object to obtain the obligation identification result; If the obligation identification result meets the preset conditions for creating an obligation, a corresponding target obligation is created based on the obligation identification result; The target obligation is associated with the existing obligations to obtain a service obligation status record.

[0009] Optionally, after determining the service obligation status record based on the unified event object, the method further includes: Traverse the service obligation status records to determine timeout obligation information; The timeout duration is determined based on the timeout obligation information, and the risk level is determined based on the timeout duration; Marketing risk control is conducted based on the aforementioned risk level.

[0010] Furthermore, to achieve the above objectives, this application also proposes a data processing apparatus, the data processing apparatus comprising: The receiving module is used to receive user events from multiple business subsystems and encapsulate the user events into a unified event object. The service obligation status recording module is used to determine the service obligation status record based on the unified event object; The marketing status information determination module is used to determine marketing status information based on the service obligation status record. The product marketing module is used to conduct product marketing based on the marketing status information and marketing candidate tasks.

[0011] In addition, to achieve the above objectives, this application also proposes a data processing apparatus, the apparatus comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data processing method described above.

[0012] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the data processing method described above.

[0013] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the data processing method described above.

[0014] This application receives user events from multiple business subsystems and encapsulates these user events into a unified event object. It then determines service obligation status records based on the unified event object, determines marketing status information based on the service obligation status records, and performs product marketing based on the marketing status information and marketing candidate tasks. This application's approach transforms cross-system user events into service obligation status records through unified event encapsulation, thereby driving dynamic gating of marketing access. This achieves cross-system consistency control of customer service, after-sales service, and marketing actions, preventing conflicting business actions from the outset, significantly reducing ineffective marketing costs and manual intervention rates, and improving data accuracy and response efficiency in multi-system collaborative processing. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a flowchart illustrating an embodiment of the data processing method of this application. Figure 2 This is a flowchart illustrating Embodiment 2 of the data processing method of this application; Figure 3 This is a flowchart illustrating Embodiment 3 of the data processing method of this application; Figure 4This is a schematic diagram of the module structure of the data processing device according to an embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the data processing method in the embodiments of this application.

[0018] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0020] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0021] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or data processing device capable of performing the above functions. The following description uses a data processing device as an example to illustrate this embodiment and the subsequent embodiments.

[0022] Based on this, the embodiments of this application provide a data processing method, referring to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the data processing method of this application.

[0023] In this embodiment, the data processing method includes the following steps: Step S10: Receive user events from multiple business subsystems and encapsulate the user events into a unified event object; It should be noted that the multiple business subsystems can be backend systems that generate changes in user-related business status, including customer service systems, order systems, work order systems, refund systems, compensation systems, marketing systems, and human agent terminals. The human agent terminal can be a terminal for human customer service personnel to handle user requests. The user events can be user-related behavioral information occurring in the business subsystems, such as user inquiries, after-sales intent confirmation, work order creation / upgrade / closure, refund initiation / completion, reissue creation, compensation commitment / completion, marketing candidate generation, marketing outreach, and user complaint recurrence. The unified event object can be a standardized data structure that solves the problems of heterogeneous fields, disordered timing, and lack of traceability across multiple systems. Encapsulating the user events into a unified event object can be done by normalizing the user events and converting the original user events into unified Event objects, for example, as shown in Table 1 - Unified Event Object Table: Table 1 - Uniform Event Object Table

[0024] Step S20: Determine the service obligation status record based on the unified event object; It should be noted that the determination of service obligation status records based on the unified event object can be a core data structure that transforms unstructured business commitments, work order statuses, and compensation actions into machine-readable and computable statuses based on the unified event object. See Table 2 below for details – Service Obligation Status Record Table: Table 2 - Service Obligation Status Record Table

[0025] Step S30: Determine marketing status information based on the service obligation status record; It should be noted that the marketing status information may include factors affecting marketing effectiveness such as obligation closure degree, commitment conflict degree, emotional recovery degree, complaint rate, and reach frequency. The obligation closure degree (O) indicates whether the user's relevant after-sales obligations have been completed. The higher the O, the closer the after-sales obligations are to closure; the lower the O, the less suitable it is for automated marketing or continued commitment. The commitment conflict degree (C) measures the degree of verbal conflict between the candidate marketing content and the user's unclosed obligations, taking a value of [0,1]. A higher value indicates that the marketing content should not be sent. The emotional recovery degree (E) is calculated based on the most recent N rounds of emotional scores, manual evaluation, and complaint recurrence events. The emotional recovery degree (E) measures whether the user's negative emotions have recovered, taking a value of [0,1]. A higher value indicates a more stable emotional state and is more suitable for marketing. Reach frequency is defined as: freq = the number of marketing outreaches to the user within the statistical window W (suggested 7 days). The complaint rate can be the number of complaints from the user within a predefined period (suggested 7 days).

[0026] Step S40: Perform product marketing based on the marketing status information and marketing candidate tasks.

[0027] It should be noted that the product marketing based on the marketing status information and marketing candidate tasks can be determined by assessing whether it is currently suitable to market to the user based on the marketing status information. If it is not suitable, marketing will not be conducted. Otherwise, marketing can be conducted. For example, if the obligation closure degree is low, it means that there are still many after-sales issues that have not been resolved, and marketing is not suitable at this time. The higher the commitment conflict degree, the higher the degree of conflict between the marketing content and the user's unresolved obligations, and marketing is also not suitable.

[0028] In its implementation, this embodiment includes two modules: a service obligation status ledger module and a marketing access control module. The service obligation status ledger module records the outstanding obligations the system imposes on users (i.e., generates service obligation status records). The marketing access control module reads the ledger status (service obligation status records) before marketing content is generated or sent, and determines whether marketing outreach is allowed, what kind of outreach is allowed, and when to resume normal marketing. Specifically, the service obligation status ledger module unifies scattered information such as customer service conversations, agent commitments, after-sales work orders, order refunds, reissues, compensation, follow-ups, and marketing outreach into calculable, queryable, and traceable obligation records (unified event objects). Any explicit or implicit commitment made by the system or an agent to a user should be written into the ledger (service obligation status record). Distinguishing and Identifying Explicit and Implicit Commitments: Explicit commitments refer to text containing explicit action words and time or quantity limits (see Obligation Identification: Determining whether user events include specific descriptions of commitments, after-sales requests, complaint escalations, refunds, replacements, compensation, or manual follow-ups), such as "Refund before 6 PM today." Implicit commitments refer to text that does not directly give action words, but can be inferred from the context and platform after-sales rules that the system has an obligation. Implicit commitments are identified using "business rule inference + contextual attribution resolution": When a user states a problem that meets the after-sales acceptance conditions (such as product quality, missing items, wrong items, logistics abnormalities), and customer service replies with acceptance-type phrases such as "I'll register it for you / I'll ​​give you feedback / A specialist will contact you later / I'll ​​handle it for you," even if the words "refund" or "compensation" do not appear, it is presumed to be an accepted after-sales obligation according to platform rules. A status=pending fulfillment and obligation_type are created, temporarily set to after-sales processing or pending obligation, and due_time is set according to the default service time limit SLA (such as 48 hours). Implicit commitments generally have lower confidence levels than explicit commitments (clear commitments). When creating an implicit commitment, the risk level can be set to the middle, and the source can be marked as "implicit presumption" for human verification. Later, when a clear refund, reissue, or compensation event occurs, the obligations are grouped together and the obligation type is refined. For example: A user message says, "The cup I received is cracked," and customer service replies, "I'll register it for you first, and a specialist will contact you later." The text doesn't contain action words like "refund" or "compensation," but it matches the "quality issue + accepted" rule, presumed to be an after-sales obligation. Therefore, the following settings are created: obligation_type=after-sales processing, status=pending fulfillment, due_time=registration time + 48 hours, risk_level=medium, promise_source=AI customer service, source=implicit presumption. The service obligation status ledger module addresses the following questions: Does the system currently owe the user something? Has this thing been completed? Has it timed out? Does it conflict with subsequent AI responses or marketing actions?

[0029] The core data in the ledger (service obligation status record) is the obligation record. Each obligation represents a task that the system needs to perform for the user, such as refund, return, exchange, replacement, discount compensation, manual follow-up, supplementary information, complaint escalation, or after-sales explanation.

[0030] Furthermore, determining the service obligation status record based on the unified event object includes: Obligation identification is performed on the unified event object to obtain the obligation identification result; If the obligation identification result meets the preset conditions for creating an obligation, a corresponding target obligation is created based on the obligation identification result; The target obligation is associated with the existing obligations to obtain a service obligation status record.

[0031] The specific operating procedure is as follows: Step S1: Receive user events by receiving raw messages from systems such as customer service, orders, work orders, and marketing.

[0032] Step S2: User event normalization. Convert the original message into a unified Event object, completing the user_id, session_id, event_type, timestamp, and trace_id to obtain the unified event object.

[0033] Step S3: Obligation Identification. Determine if the event includes commitments, after-sales requests, complaint escalations, refunds, replacements, compensation, or follow-up visits, and generate a service obligation status record accordingly. Specifically, obligation identification employs a three-layer judgment process: "keyword and sentence structure triggers + event type mapping + semantic intent model." If any layer is matched, the obligation creation process begins. The first layer (keyword and sentence structure triggers): Maintains a commitment trigger dictionary, including action words (refund, return, exchange, reissue, compensation, follow-up visit, door-to-door service, expedited processing) and commitment sentence structures (such as "today / within X hours / before X o'clock + completed / received / processed" or "give you + refund / replacement / compensation"). When the text simultaneously matches an action word and a time or quantity limit, it is determined as an explicit commitment.

[0034] The second layer (event type mapping): For structured events, the obligation type is directly mapped by event_type, without the need for text interpretation. For example: Refund initiation - Refund obligation; After-sales work order creation - Corresponding after-sales obligation; Compensation commitment - Compensation obligation.

[0035] The third layer (semantic intent model): For natural language text not covered by the first two layers, the intent classification model is invoked to output "whether to promise / request after-sales service" and the corresponding obligation type, along with a confidence score. An obligation is created only when confidence is greater than or equal to the recognition threshold θ_recog (recommended 0.7); otherwise, it is registered as a normal event without creating an obligation, thus avoiding false generation.

[0036] Example: The customer service text "I will refund you before 6 PM today" matches the action word "refund" and the time limit "before 6 PM" at the first level, which is determined to be an explicit refund commitment. The semantic model gives confidence = 0.86 ≥ 0.7, so an obligation record is created with obligation_type = refund, promise_content = "refund to be completed before 6 PM today", and due_time = 6 PM today.

[0037] Step S4: Obligation Creation. If the event generates a new commitment, an Obligation record is created, and its status is set to pending or being fulfilled.

[0038] Step S5: Obligation Association. Based on user_id, order_id, ticket_id, and semantic similarity, attach the new event to an existing obligation or create a new obligation.

[0039] Obligation association is used to address the issue of "when the same after-sales matter is mentioned multiple times or reported across systems, it should be merged into a single obligation rather than being created repeatedly." Association determination is performed in the order of "strong identifier priority, semantic fallback": Step 1 (Constructing the candidate set): Take all non-closed obligations under the user_id whose status belongs to {pending, in progress, and expired} as the candidate set; obligations that have been performed or withdrawn are not included in the association.

[0040] Step 2 (Strong identifier matching): If a new event carries order_id or ticket_id and is exactly the same as the order_id or ticket_id of a candidate obligation, it is directly attached to that obligation (the process terminates upon a match, and semantic similarity is no longer calculated); if multiple events are matched at the same time, the one with the most recent due_time is selected.

[0041] Step 3 (Semantic fallback matching): If the event does not contain a strong identifier or the strong identifier is not matched, then calculate the association score assoc for each obligation in the candidate set: assoc=w1·same_type+w2·sim_text+w3·time_prox Where `same_type` is 1 if the obligation type is the same, and 0 otherwise; `sim_text` is the semantic similarity between the event text and the obligation `promise_content` (definition below); `time_prox` is the time proximity = exp( Δt / τ), where Δt is the number of hours between the event time and the obligation creation time interval, and τ is recommended to be 48; the recommended weights are w1=0.40, w2=0.45, and w3=0.15.

[0042] Step 4 (Decision): Select the candidate with the largest assoc value from the candidate set. assoc ≥θ_high (recommended 0.75) - attach to this obligation and append the event to evidence_events (list of evidence events); assoc ≤θ_low (recommended 0.45) - classify as a new item and create a new obligation; θ_low <assoc <θ_high- mark as suspected association, suspend and transfer to human agent for confirmation, do not automatically merge.

[0043] Semantic similarity calculation sim_text: A sentence vector model is preferred, encoding the event text and the obligation commitment text into vectors va and vb respectively. The cosine similarity is then calculated and truncated to the non-negative interval: sim_text=max(0,(va·vb) / (|va|·|vb|)), with values ​​in the range [0,1]. In the regular version without a vector model, the Jaccard similarity of the keyword sets can be used instead: sim_text=|A∩B| / |A∪B|, where A and B are the keyword sets of the two texts after word segmentation and stop word removal.

[0044] Example: A user appends the message "Why hasn't the money for my order arrived yet?", without order_id. There is one refund obligation in the candidate set (promise_content = "Refund to be completed before 6 PM today", created 3 hours ago). same_type = 1 (all are refunds), sim_text = 0.82 ("Money not arrived" and "Refund completed" are semantically similar), time_prox = exp( Since 3 / 48)≈0.94, then assoc=0.40×1+0.45×0.82+0.15×0.94≈0.91≥0.75. Therefore, it is attached to the refund obligation instead of creating a new one, so as to avoid duplicate obligations and duplicate commitments.

[0045] Step S6: Status Update. Upon receiving events such as refund completed, reissue completed, compensation completed, and work order closed, update the corresponding obligation status. Status updates need to address two issues: first, correctly matching the write-back event to the corresponding obligation; and second, migrating according to the valid state machine.

[0046] Complete event matching: Write back events (refund completion, reissue receipt, compensation payment, work order closure, etc.) and locate obligations according to the "strong identifier priority" rule in step S5. Prioritize accurate matching using the obligation_id, order_id, or ticket_id carried by the event; if no match is found, use user_id + obligation_type + semantic similarity as a fallback; if multiple matches are found, take the one with the closest due_time that is not closed.

[0047] Obligation State Machine: The state transitions between {Pending - In Progress - Performed / Cancelled}, and any incomplete state can be marked with a "Timeout" flag. The transition rules are: Creation or Acceptance - Pending; Processing Begins (e.g., Initiating a Refund) - In Progress; Receive Completion Event - Performed; Due Time Expired but Not Yet Performed - Marked Timeout (preserving atomic state); User Cancellation, Customer Service Cancellation, or Merging - Cancelled. Illegal transitions (e.g., Performed - In Progress) are rejected and written to an exception event.

[0048] Closed-loop determination: Only an obligation with a status of "fulfilled" is considered closed-loop; even if an obligation that has timed out is subsequently fulfilled, a timeout record is retained for historical risk calculation of the closed-loop degree O. A change in status immediately triggers a recalculation of the user's O and notifies the marketing access control system.

[0049] Example: The refund obligation obl_refund_001 currently has the status "in progress". The refund system writes back the event (event_type=refund completed, order_id=order_123, amount=200). When obl_refund_001 is precisely matched by order_id, the "completed event" migration is triggered, the status is changed to "fulfilled", the event is appended to evidence_events, and an O-recalculation (handling incomplete business transactions) and a gating status refresh (user control over whether marketing is conducted and the intensity of marketing) are triggered.

[0050] Furthermore, to avoid business processing timeouts, after determining the service obligation status record based on the unified event object, the process also includes: Traverse the service obligation status records to determine timeout obligation information; The timeout duration is determined based on the timeout obligation information, and the risk level is determined based on the timeout duration; Marketing risk control is conducted based on the aforementioned risk level.

[0051] It should be noted that the overdue obligation information can be business information that has not been fulfilled within the time limit, such as refunds or answers to user questions. Determining the risk level based on the overdue duration can mean that the longer the overdue period, the higher the risk level. Marketing risk control based on the risk level can mean that the higher the risk level, the stricter the control over marketing; when the risk level is high, marketing is prohibited; when the risk level is medium, the number of marketing activities is controlled to not exceed a preset marketing threshold; and when the risk level is low, the number of marketing activities can be increased as needed.

[0052] In practice, tasks whose due time has passed but whose status is not yet complete are periodically scanned, marked as timed out, and their risk level is increased. The detailed rules for timeout detection are as follows: Scanning mechanism: A scheduled task (recommended every 5 minutes) scans for obligations with status ∈ {pending, in progress} and due_time < current time; it can also be triggered directly by a delayed message whose due_time has expired, and the two can be used together.

[0053] Timeout classification and risk_level upgrade: Classified by timeout duration Δover = current time - due_time, with minor timeouts (0 < Δover ≤ 24 hours) and severe timeouts (Δover > 24 hours). For each higher level, the risk_level increases by one level (low-medium-high, capped at high), and the timeout coefficient is updated accordingly (can be set: no timeout = 1, minor = 1.5, severe = 2).

[0054] Upgrade linkage and anti-shake: After the risk_level or timeout coefficient changes, the user's O is immediately recalculated and the status change is pushed to the marketing access control, so that the freeze or cooldown (freezing means that marketing cannot be carried out, and cooling can control the number of marketing) takes effect immediately; the same obligation is only upgraded once within the same level to avoid duplicate alarms.

[0055] Example: Refund obligation due_time=18:00, risk_level=medium. When scanning at 10:00 the next day, Δover=16 hours, which is a slight timeout. The risk_level is raised to high, the timeout coefficient is set to 1.5, and a recalculation is triggered. If it is still not processed, when scanning on the third day, Δover>24 hours, it is set to severe timeout with a coefficient of 2 (risk_level is already capped at high).

[0056] This embodiment receives user events from multiple business subsystems and encapsulates these user events into a unified event object. It then determines service obligation status records based on the unified event object, determines marketing status information based on the service obligation status records, and performs product marketing based on the marketing status information and marketing candidate tasks. This embodiment transforms cross-system user events into service obligation status records through unified event encapsulation, thereby driving dynamic gating of marketing access. This achieves cross-system consistency control of customer service, after-sales service, and marketing actions, preventing conflicting business actions from the outset, significantly reducing ineffective marketing costs and manual intervention rates, and improving data accuracy and response efficiency in multi-system collaborative processing.

[0057] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to that in the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2 This is a flowchart illustrating a second embodiment of the data processing method of this application. Step S40 further includes the following steps: Step S401: Identify marketing users and marketing content based on marketing candidate tasks; It should be noted that the marketing candidate task can be a marketing task generated by the marketing system and prepared for marketing. For example, the system may be preparing to send a new product discount SMS to users. The marketing user can be any user who can participate in this marketing, i.e., the target audience. The marketing content may include specific display text / materials and marketing keywords, such as "instant discount of 10 yuan" or "7-day no-reason return policy".

[0058] Step S402: Determine the degree of obligation closure based on the marketing user and the marketing status information; It should be noted that the obligation closure degree O is used to indicate whether the user's relevant after-sales obligations have been fulfilled. The higher the O, the closer the after-sales obligations are to being closed; the lower the O, the less suitable it is for automated marketing or continued commitment. The determination of the obligation closure degree based on the marketing user and the marketing status information can be based on the marketing status information to determine the obligation closure degree of the marketing user.

[0059] In practice, the obligation closure degree can be calculated based on the number of unfulfilled obligations, risk level, and timeout severity. Specifically, O = 1 - sum(risk weight of unfulfilled obligations × timeout coefficient) / sum(risk weight of all obligations). High-risk obligations can be defined as 5, medium-risk as 3, and low-risk as 1 (or can be customized according to the actual scenario); the timeout coefficient is 1, slight timeout as 1.5, and severe timeout as 2 (or can be customized according to the actual scenario). For example, if a user has a high-risk refund obligation that has severely timed out, the user's O will be significantly reduced, and subsequent marketing access control should be put into a prohibited or cooled-down state.

[0060] To facilitate implementation, a complete example of the risk_level value selection rules and O is provided: The risk level is determined when an obligation is created based on "obligation type baseline + amount / timeliness adjustment": refunds, compensation, and complaint escalation obligations have a high baseline; replacements and exchanges have a medium baseline; and manual follow-up, data supplementation, and after-sales explanations have a low baseline. Based on this baseline, if the amount involved exceeds a set threshold (e.g., 500 yuan), the risk level is increased by one level; if a timeout has occurred, it is increased by another level, with a maximum of high. Risk weights are mapped as follows: High = 5, Medium = 3, Low = 1; Timeout coefficients are: No timeout = 1, Minor timeout (timeout ≤ 24 hours) = 1.5, Severe timeout (timeout > 24 hours) = 2. For example: A user currently has three obligations: Obligation A (refund, high risk, weight 5, severe timeout, coefficient 2), Obligation B (replacement, medium risk, weight 3, no timeout, coefficient 1, fulfilled), and Obligation C (follow-up, low risk, weight 1, minor timeout, coefficient 1.5). Obligation B has been fulfilled and is not included in the numerator. O = 1 (5×2+1×1.5) / (5+3+1)=1 11.5 / 9≈1 1.278= 0.278, truncated to O=0 by the lower limit, indicates that the user's after-sales obligations are seriously unclosed, and marketing access control should directly enter the prohibited state. To ensure that O∈[0,1], it is agreed that the calculation result is 0 when it is less than 0 and 1 when it is greater than 1; when there are no unclosed obligations, the numerator is 0, O=1, indicating a complete closure.

[0061] Step S403: Determine the degree of commitment conflict based on the marketing content and the marketing status information; It should be noted that determining the commitment conflict degree based on the marketing content and the marketing status information can be achieved by determining conflicting keywords based on the marketing status information. For example, a refund obligation might generate keywords such as "refund," "received," and "returned," while a compensation obligation might generate keywords such as "compensation," "reimbursement," and "coupon." By comparing the marketing content and the conflicting keywords, the more conflicting keywords are matched, the higher the commitment conflict degree. This can be defined as: Commitment Conflict Degree = Number of Matched Conflicting Keywords / Total Number of Conflicting Keywords.

[0062] In practice, conflict keyword generation can be based on the type of obligation to generate conflict_keys. For example, a refund obligation generates "refund, payment received, return", while a compensation obligation generates "compensation, refund, coupon". The generation of conflict_keys can be broken down into three steps: "type basic dictionary + commitment content extraction + synonym expansion". Type basic dictionary (obligation type - basic conflict words): Refund - {refund, payment received, return, refund}; Reissue - {reissue, resend, reship, logistics}; Compensation - {compensation, refund, claim, coupon}; Exchange - {exchange, replacement, repair}; Complaint escalation - {complaint, processing result, feedback}; Manual follow-up - {follow-up, contact, follow-up}.

[0063] Promise content extraction: Extract entities such as amount, time, and product name from promise_content and add them to conflict_keys to make conflict detection more accurate. For example, extract "cup" and "200 yuan".

[0064] Synonyms and Hypernym Expansion: Expand basic words using thesaurus or word vectors (e.g., expand "refund" to "refund fee" or "return payment") to reduce the probability of marketing language circumventing keywords. Conflict_keys are valid as long as the obligation exists; they expire after the obligation is closed or revoked and no longer participate in the commitment conflict calculation.

[0065] Example: The promise_content for compensation is "I'll give you a coupon as compensation". The basic dictionary definition is {compensation, compensation, claim, coupon}. The promise is to draw {coupon}, and the synonym extension is {voucher, discount coupon}. Finally, conflict_keys = {compensation, compensation, claim, coupon, voucher, discount coupon}. The marketing content "claim voucher" will be blocked.

[0066] Step S404: Conduct product marketing based on the obligation closure degree, the commitment conflict degree, the emotional recovery degree, and the marketing candidate tasks.

[0067] It should be noted that the product marketing based on the obligation closure degree, the commitment conflict degree, the emotional recovery degree, and the marketing candidate task can prohibit marketing to users when the obligation closure degree is greater than a preset obligation closure degree threshold, the commitment conflict degree is greater than a preset commitment conflict degree threshold, or the emotional recovery degree is less than a preset emotional recovery degree threshold.

[0068] In practical implementation, this embodiment involves the following interfaces, which can be directly called to obtain the corresponding data: Refer to Table 3 - Interface Design Table: Table 3 - Interface Design Table

[0069] Furthermore, in order to conduct precise user marketing, step S404 may include: determining the user complaint rate and marketing reach frequency based on marketing status information; The marketing risk value is determined based on the user complaint rate, the marketing reach frequency, the obligation closure degree, the commitment conflict degree, and the emotional recovery degree. The gate control result is determined based on the aforementioned marketing risk value and the preset marketing strategy; Product marketing is conducted based on the gating results and the marketing candidate tasks.

[0070] It should be noted that the marketing access control module in this embodiment is used for pre-judgment before marketing content is generated or sent. This module does not simply filter after marketing content is generated, but rather determines whether to allow outreach based on user complaint rate, marketing outreach frequency, obligation closure degree, commitment conflict degree, and emotional recovery degree before candidate marketing tasks enter execution. The problem this module solves is that the system cannot continue sending content such as repeat purchases, promotions, or new product recommendations when a user's after-sales issue is not resolved; if outreach is necessary, only service-oriented content such as refund progress instructions or reissue progress instructions can be sent. The inputs and outputs of this module can be referred to in Table 4 - Marketing Access Control Module Input and Output Table, and the marketing status rules of this module can be referred to in Table 5 - Marketing Status Rules Table. Table 4 - Input and Output Table of Marketing Access Control Module

[0071] Table 5 - Marketing Status Rules Table

[0072] In practice, product marketing may include the following steps: Step S1: The marketing system generates candidate tasks (i.e., marketing candidate tasks). For example, the system prepares to send a new product discount SMS to users.

[0073] Step S2: The gating module (marketing access control module) receives marketing candidate tasks and reads user_id, marketing content, channel and strategy number.

[0074] Step S3: Call the service obligation status record to query the user's unclosed obligations and obligation closure degree O.

[0075] Step S4: Calculate the commitment conflict degree C. If the candidate marketing content matches the conflict_keys of the unclosed obligations, then increase C.

[0076] The commitment conflict level (C) measures the degree of verbal conflict between the candidate marketing content and the user's unfulfilled obligations, taking a value of [0,1]. A higher value indicates that the marketing content should not be sent. The calculation steps are as follows: For each unclosed obligation i, take its conflict_keys set K_i and risk weight w_i (high=5, medium=3, low=1). Calculate the matching strength m_i between candidate marketing content M and obligation i, taking the larger value between literal matching coverage and semantic similarity: m_i=max(|hit(M,K_i)| / |K_i|,sim(M,promise_content_i)), where |hit(M,K_i)| is the number of K_i keywords appearing in M, and sim is the semantic similarity (see the sim_text explanation in the obligation association section for definition). Weight the matching strength of each obligation according to the risk weight and sum and normalize: C=Σ_i(w_i·m_i) / Σ_iw_i, with values ​​[0,1]. Example 1 (High Conflict): The user has an unclosed compensation obligation (high risk, w=5, conflict_keys={compensation, compensation, coupons}). Candidate marketing content = "Claim exclusive coupons for instant discounts on orders," hitting "coupon," literal coverage = 1 / 3 ≈ 0.33, semantic similarity 0.6, take m = 0.6. If there are no other unclosed obligations, then C = 5 × 0.6 / 5 = 0.6, C is too high, the user is waiting for compensation, at this time pushing coupons will be interpreted as using promotion to evade compensation, after adding R (number of complaint recurrences in the statistics window), it usually triggers prohibition or cooling. Example 2 (low conflict): Under the same compensation obligation, candidate marketing = "Member points are about to expire reminder," no keyword hit, semantic similarity 0.05, m = 0.05, C = 0.05, low commitment conflict, will not trigger blocking due to C.

[0077] Step S5: Calculate the emotional recovery score E. This is calculated based on the most recent N rounds of emotional scores, human evaluations, and recurring complaint events. The emotional recovery score E measures whether the user's negative emotions have recovered, with a value of [0,1]. A higher value indicates a more stable emotional state and greater suitability for marketing. The calculation combines "the most recent N rounds of emotional scores (with time decay) + recurring complaint penalties + human evaluation corrections": Base sentiment: Take the sentiment score_k (score∈[0,1], higher is more positive) from the most recent N rounds (N=5 recommended), weighted by time decay, with more recent rounds having greater weight: base=Σ_k(λ^(N k)·score_k) / Σ_kλ^(N k), and the attenuation factor λ is recommended to be 0.7.

[0078] Recurrence penalty: The number of recurrences of complaints within the statistical window, r, is calculated as penalty = min(1, 0.3 × r).

[0079] Human evaluation adjustment: If the human agent marks the action as "soothed / resolved", E increases by 0.1; if it marks the action as "unresolved / emotionally agitated", E is capped at 0.4. The overall result is E = clip(base × (1 penalty) + manual floating item, 0, 1), clip means to cut off to [0, 1].

[0080] Example 1 (Recovered): The last 5 rounds of emotion were [0.2, 0.3, 0.5, 0.6, 0.7] (continuously rising), with no recurrence of complaints (r=0), manually marked as "soothed". The base, after attenuation weighting, is approximately 0.55, penalty=0, with an artificial increase of 0.1, E≈0.65. Example 2 (Not Recovered): The last 5 rounds were [0.2, 0.3, 0.2, 0.1, 0.2], with one recurrence of complaints within the window (r=1, penalty=0.3). The base≈0.19, E=0.19×(1 0.3)≈0.13, far below 0.5, gated cooling.

[0081] Step S6: Calculate the marketing risk value R. The risk result is obtained by combining factors such as O (obligation closure degree), C (commitment conflict degree), E (emotional recovery degree), complaint rate, and reach frequency.

[0082] Step S7: Execution Status Determination. Based on the marketing risk value R and the rules (preset marketing strategy), output prohibition, cooling-off, service-oriented outreach, low-frequency marketing, or normal marketing. The upper limit of the outreach frequency and the downgrade rules corresponding to each marketing status need to be quantified; otherwise, "low-frequency" and "normal" cannot be effectively implemented. Frequency of contact definition: freq = the number of marketing contacts that a user has been reached within the statistics window W (7 days recommended) (calculated by channel after conversion).

[0083] Frequency limits for each status (recommended default values, can be configured according to channel and strategy): Prohibited = 0 promotions (service notifications only, not counted in marketing frequency); Cooling down = 0 promotions, service notifications on demand; Service outreach = service only, 0 promotions; Low-frequency marketing = a maximum of 1 per week with an interval of ≥72 hours between two marketing campaigns, only low-stimulation content is allowed (excluding time-limited and order-chasing scripts); Normal marketing = a maximum of 3 per week with an interval of ≥24 hours.

[0084] Frequency-based circuit breaking: When the frequency (reach frequency) reaches its limit, even if R falls within that state range, it will be downgraded to a more conservative state (e.g., low frequency has reached 1 time - downgraded to service-type reach), and an explanation event will be written. Channel conversion: Different channels are weighted and combined to calculate the frequency (e.g., SMS 1.0, WeChat 0.8, APP push 0.5) to avoid multiple channels overlapping and causing harassment.

[0085] Example: The user is in a low-frequency marketing state, having sent 1 marketing SMS in the past 7 days (freq=1.0, already at the limit). A new candidate marketing SMS arrives; although R=0.2 falls within the low-frequency range, the freq is already full, so it is downgraded to service-oriented outreach, and the reason is recorded as "low-frequency frequency has reached the limit".

[0086] Step S8: Generate gating results. If sending is prohibited, write an explanation event; if service-type access is allowed, rewrite it as a service notification task.

[0087] Step S9: Write back to the marketing system. The marketing system sends, suspends, downgrades, or cancels candidate tasks based on the gating results.

[0088] The marketing risk value R can be calculated using the following formula: R = alpha × (1-O) + beta × C + gamma × (1-E) + delta × recent_complaint_rate. Where O represents the obligation closure degree, C represents the commitment conflict degree, and E represents the emotional recovery degree.

[0089] Complex models can be replaced by rules: if there is a high-risk unclosed-loop obligation, directly enter the prohibition; if C is greater than 0.8, directly prohibit; if E is less than 0.5, enter the cooling-off period; only when O is greater than 0.9, C is less than 0.2 and E is greater than 0.7, low-frequency marketing or normal marketing can be resumed.

[0090] To facilitate implementation, we have added suggestions for the values ​​of each weight coefficient, the definition of recent_complaint_rate, and examples of R calculations and threshold mappings: The recommended coefficients are alpha=0.30, beta=0.30, gamma=0.25, delta=0.15 (totaling 1, so that R∈[0,1]). The recent_complaint_rate is defined as the ratio of the number of complaints made by the user to the number of marketing outreaches in the past 30 days, truncated to [0,1]; if there are no outreach records, it is counted as 0.

[0091] State threshold mapping: R≥0.7 or high-risk unclosed-loop obligations or C>0.8 - prohibited; 0.5≤R<0.7 or E<0.5 - cooling down; 0.3≤R<0.5 - service-oriented outreach; 0.15≤R<0.3 - low-frequency marketing; R<0.15 and O>0.9 and C<0.2 and E>0.7 - normal marketing. Example: A user has O=0.2, C=0.6, E=0.13, and recent_complaint_rate=0.4. R=0.30×(1 0.2)+0.30×0.6+0.25×(1 0.13)+0.15×0.4=0.24+0.18+0.2175+0.06≈0.70. R≈0.70 falls into the prohibited range, and there is a high-risk unclosed refund obligation. Therefore, the gate output is "prohibited", and only service-type access such as refund progress descriptions is allowed, which is consistent with the example in Section 3.6.

[0092] Gating output example: When a user has an outstanding refund obligation, the gating module should return the following structured result: { "allow":false, "marketing_status":"Prohibited", "reason":"There is an outstanding obligation to refund." "allowed_touch_type":"Refund progress description", "freeze_until":"2026-05-2718:00:00" } Example of two modules working together: A user enters into the APP customer service: "Yesterday customer service said I'd get a refund today, but the money hasn't arrived; you also sent me a text message asking me to buy new products." The system first generates a user inquiry event (Event) and identifies two intentions: a refund fulfillment complaint and a marketing refusal. The service obligation status ledger module finds that the user has a refund obligation, the status is "in progress," the due_time is approaching or has exceeded, and the risk_level is high. Subsequently, the marketing access control module calculates that: the obligation closure degree O is below the threshold, the emotional recovery degree E is low, and there is a contact conflict between the candidate new product text message and the refund complaint scenario. The system sets the marketing status to prohibited or cooled, withdraws the pending new product promotion task, and only allows sending refund progress instructions.

[0093] If the refund system writes back the refund completion event two hours later, the ledger module will update the refund obligation to "fulfilled." However, the marketing access control module will not immediately resume normal marketing; instead, a 24-hour cooldown period will be set. If the user does not complain again during the cooldown period, the marketing status will first revert to service-oriented outreach, and then to low-frequency marketing. Marketing recovery uses a tiered state machine, and the cooldown duration and recovery conditions need to be quantified: Cooldown duration T_cool: The base duration is determined based on the triggering reason and risk. Generally, after the after-sales obligation is closed, T_base = 24 hours; for high-risk obligations (high-amount refunds, escalated complaints, etc.), T_base = 72 hours; for complaints that have recurred, each recurrence adds 24 hours to the base duration, capped at 7 days, i.e., T_cool = min(7 days, T_base + 24 hours × number of recurrences).

[0094] Tiered recovery path: Prohibition / Cooldown - (Obligation closed loop, T_cool expired, and no new complaints) - Service-oriented outreach - (Observe T_obs again, with a recommendation of no negative feedback within 24 hours) - Low-frequency marketing - (Continue observation, with O>0.9, E>0.7, and no new obligations) - Normal marketing. If a complaint recurs or a new high-risk obligation arises at any stage, immediately revert to Prohibition / Cooldown and reset the timer.

[0095] Recovery threshold (consistent with the threshold in Section 3.5): R < 0.3 is required to enter low-frequency marketing; R < 0.15 and O > 0.9, C < 0.2, E > 0.7 are required to enter normal marketing.

[0096] Example: A closed-loop system for high-refund obligations is implemented, with T_base set to 72 hours. If there are no recurrences during this period, the system switches from a prohibited approach to a service-oriented approach. After another 24 hours of observation with no negative feedback and E recovering to 0.72, O=0.95, and C=0.1, the system switches to low-frequency marketing. Only after continued stability does the system switch to normal marketing. If a user complains again during the observation period, the system immediately reverts to a cooling-off period and adds an additional 24 hours to T_cool.

[0097] This embodiment determines marketing users and marketing content based on marketing candidate tasks; determines the obligation closure degree based on the marketing users and the marketing status information; determines the commitment conflict degree based on the marketing content and the marketing status information; and conducts product marketing based on the obligation closure degree, the commitment conflict degree, the emotional recovery degree, and the marketing candidate tasks. This embodiment does not simply prohibit marketing, but dynamically adjusts the reach type and frequency according to indicators, balancing after-sales compliance and marketing effectiveness.

[0098] Based on the above embodiments of this application, in the third embodiment of this application, the same or similar content as the above embodiments can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating the data processing method of Embodiment 3 of this application. After step S20, the method further includes the following steps: Step S201: Upon receiving a user customer service conversation, determine the user identifier; It should be noted that the user identifier can be a unique user identifier, i.e., the user_id mentioned above. The user customer service session can be a question-and-answer session initiated by the user.

[0099] Step S202: Determine the service status based on the user identifier and the service obligation status record; It should be noted that the service status can refer to either an outstanding, unfulfilled obligation of the user or a historical obligation that has already been fulfilled, such as information like refunds or bill settlements.

[0100] Step S203: Respond to the user customer service session according to the service status.

[0101] It should be noted that responding to the user's customer service conversation based on the service status can be a response to the user's questions based on the user's outstanding unfulfilled obligations or fulfilled historical obligations. For example, if a user enters "My refund request from last week hasn't arrived yet, and you're still pushing new product promotions?" in the APP customer service, the system extracts the user identifier u_hash_9a21, finds that the user has an outstanding refund obligation, and determines the service status to be "after-sales priority." The system prioritizes calling the refund status API and replies: "Your refund is being processed by the bank and is expected to arrive in 1-2 business days." At the same time, the new product inquiry request is suspended, and the user's marketing outreach permissions are frozen. After the 24-hour cooling-off period, if the user does not complain again, the service status returns to normal, and the system allows the push of new product promotions and compliant marketing content to the user. Actual testing shows that after adopting the customer service response rules of this embodiment, it avoids requiring the user to re-enter the historical context each time, reducing the secondary complaint rate from 18% to 4%, and the average number of conversation rounds from 7.2 to 3.5.

[0102] The specific implementation steps can be as follows: Step 1: Create database tables event_log and obligation_ledger to store unified event and obligation records respectively.

[0103] Step 2: Develop an event access service to connect with customer service, order, work order, refund, compensation and marketing systems.

[0104] Step 3: Develop obligation identification rules, first using keywords and event types to identify obligations such as refunds, reissues, compensation, follow-ups, and escalation of complaints.

[0105] Step 4: Develop an obligation status updater to update the ledger based on events such as refund completion, reissue completion, work order closure, and complaint recurrence.

[0106] Step 5: Develop a closure degree calculator to output the O value and a summary of unclosed obligations.

[0107] Step 6: Develop a marketing gating service to receive marketing candidate tasks, call the ledger interface, and output allow, marketing_status, and reason.

[0108] Step 7: Change the marketing system's sending action to first call the gate control service, and only allow sending after the gate control is approved.

[0109] Step 8: Develop the ability to explain event write-back and record why a particular marketing campaign was banned, cooled down, or downgraded.

[0110] Step 9: Write regression tests to cover scenarios such as incomplete refunds, incomplete compensation, recurring complaints, end of the cooling-off period, and resumption of normal marketing.

[0111] The acceptance criteria for each module's functionality can be found in Table 6 below - Acceptance Criteria Table: Table 6 - Acceptance Criteria Table

[0112] This embodiment, upon receiving a user's customer service conversation, determines the user identifier; determines the service status based on the user identifier and the service obligation status record; and responds to the user's customer service conversation according to the service status. This embodiment achieves consistency control between customer service responses and users' unfinished after-sales obligations by querying the service obligation status record based on the user identifier and determining the service status before responding to the customer service conversation. On the one hand, the after-sales-first response strategy avoids conflicts between customer service responses and backend fulfillment status, reducing the rate of secondary complaints. On the other hand, cross-channel user identifier normalization and service status synchronization ensure consistent customer service responses received by users across different channels, reducing redundant evidence and invalid follow-up questions, and significantly shortening conversation rounds. Simultaneously, the service status conflict warning mechanism can automatically trigger manual intervention in complex scenarios and simultaneously push the complete obligation context, improving the efficiency and accuracy of manual intervention.

[0113] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the data processing method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0114] This application also provides a data processing apparatus, please refer to... Figure 4 The data processing device includes: The receiving module 10 is used to receive user events from multiple business subsystems and encapsulate the user events into a unified event object; Service obligation status recording module 20 is used to determine the service obligation status record based on the unified event object; Marketing status information determination module 30 is used to determine marketing status information based on the service obligation status record; Product marketing module 40 is used to conduct product marketing based on the marketing status information and marketing candidate tasks.

[0115] This embodiment receives user events from multiple business subsystems and encapsulates these user events into a unified event object. It then determines service obligation status records based on the unified event object, determines marketing status information based on the service obligation status records, and performs product marketing based on the marketing status information and marketing candidate tasks. This embodiment transforms cross-system user events into service obligation status records through unified event encapsulation, thereby driving dynamic gating of marketing access. This achieves cross-system consistency control of customer service, after-sales service, and marketing actions, preventing conflicting business actions from the outset, significantly reducing ineffective marketing costs and manual intervention rates, and improving data accuracy and response efficiency in multi-system collaborative processing.

[0116] The data processing apparatus provided in this application, employing the data processing method described in the above embodiments, can solve the technical problem in existing intelligent customer service systems where customer service sessions, after-sales work orders, and marketing outreach are independent subsystems. This fragmented business status prevents the system from identifying and intercepting behaviors that conflict with unclosed after-sales obligations before customer service responses and marketing actions are executed, ultimately leading to a poor user experience. Compared with the prior art, the beneficial effects of the data processing apparatus provided in this application are the same as those of the data processing method provided in the above embodiments, and other technical features in the data processing apparatus are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0117] This application provides a data processing apparatus, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the data processing method in Embodiment 1 above.

[0118] The following is for reference. Figure 5 The diagram illustrates a structural schematic of a data processing device suitable for implementing embodiments of this application. The data processing device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 5 The data processing device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0119] like Figure 5As shown, the data processing device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the data processing device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the data processing device to communicate wirelessly or wiredly with other devices to exchange data. Although the figures show data processing devices with various systems, it should be understood that it is not required to implement or possess all of the systems shown. More or fewer systems may be implemented alternatively.

[0120] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0121] The data processing device provided in this application, employing the data processing method described in the above embodiments, can solve the technical problem in existing intelligent customer service systems where customer service conversations, after-sales work orders, and marketing outreach are separate subsystems. This fragmented business status prevents the system from identifying and intercepting behaviors that conflict with unclosed after-sales obligations before customer service responses and marketing actions are executed, ultimately leading to a poor user experience. Compared with the prior art, the beneficial effects of the data processing device provided in this application are the same as those of the data processing method provided in the above embodiments, and other technical features of this data processing device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0122] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

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

[0124] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the data processing method described in the above embodiments.

[0125] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0126] The aforementioned computer-readable storage medium may be included in a data processing device or may exist independently without being assembled into a data processing device.

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

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

[0129] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0130] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the above-described data processing method. This addresses the technical problem in existing intelligent customer service systems where customer service sessions, after-sales work orders, and marketing outreach are independent subsystems. This fragmented business state prevents the system from identifying and intercepting behaviors that conflict with unclosed after-sales obligations before customer service responses and marketing actions are executed, ultimately leading to a poor user experience. Compared to the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the data processing method provided in the above embodiments, and will not be elaborated upon here.

[0131] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the data processing method described above.

[0132] The computer program product provided in this application can solve the technical problem in existing intelligent customer service systems where customer service sessions, after-sales work orders, and marketing outreach are separate subsystems. This fragmented business state prevents the system from identifying and intercepting behaviors that conflict with unclosed after-sales obligations before customer service responses and marketing actions are executed, ultimately leading to a poor user experience. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the data processing method provided in the above embodiments, and will not be repeated here.

[0133] All user-related data involved in this application (e.g., user events from multiple business subsystems) was obtained with the user's permission or consent. In other words, when this application is applied to specific products or technologies, user permission is required to acquire and process the relevant data, and the processing of the data must comply with the relevant laws, regulations, and regulatory standards of the relevant countries and regions. For example, when it is necessary to obtain a user's current geographical location, a location acquisition prompt can be displayed on the user's terminal. After receiving confirmation from the user regarding the location acquisition prompt, the terminal can obtain the user's current geographical location.

[0134] The above description is only a part of the embodiments of this application and does not limit the scope of protection of this application. All equivalent structural transformations made under the technical concept of this application and using the content of this application specification and drawings, or direct / indirect applications in other related technical fields, are included in the scope of protection of this application.

Claims

1. A data processing method, characterized in that, The data processing method includes the following steps: Receive user events from multiple business subsystems and encapsulate the user events into a unified event object; The service obligation status record is determined based on the unified event object; Marketing status information is determined based on the service obligation status record; Product marketing is conducted based on the marketing status information and marketing candidate tasks.

2. The data processing method as described in claim 1, characterized in that, The step of conducting product marketing based on the marketing status information and marketing candidate tasks includes: Identify marketing users and marketing content based on marketing candidate tasks; Determine the degree of obligation closure based on the marketing users and the marketing status information; Determine the degree of commitment conflict based on the marketing content and the marketing status information; Product marketing is conducted based on the aforementioned obligation closure degree, commitment conflict degree, emotional recovery degree, and marketing candidate tasks.

3. The data processing method as described in claim 2, characterized in that, The product marketing based on the obligation closure degree, the commitment conflict degree, the emotional recovery degree, and marketing candidate tasks includes: Determine user complaint rate and marketing reach frequency based on marketing status information; The marketing risk value is determined based on the user complaint rate, the marketing reach frequency, the obligation closure degree, the commitment conflict degree, and the emotional recovery degree. The gate control result is determined based on the aforementioned marketing risk value and the preset marketing strategy; Product marketing is conducted based on the gating results and the marketing candidate tasks.

4. The data processing method as described in claim 1, characterized in that, After determining the service obligation status record based on the unified event object, the method further includes: Upon receiving a user's customer service conversation, determine the user's identifier; The service status is determined based on the user identifier and the service obligation status record; The user customer service session is responded to based on the service status.

5. The data processing method according to any one of claims 1-4, characterized in that, The step of determining the service obligation status record based on the unified event object includes: Obligation identification is performed on the unified event object to obtain the obligation identification result; If the obligation identification result meets the preset conditions for creating an obligation, a corresponding target obligation is created based on the obligation identification result; The target obligation is associated with the existing obligations to obtain a service obligation status record.

6. The data processing method according to any one of claims 1-4, characterized in that, After determining the service obligation status record based on the unified event object, the method further includes: Traverse the service obligation status records to determine timeout obligation information; The timeout duration is determined based on the timeout obligation information, and the risk level is determined based on the timeout duration; Marketing risk control is conducted based on the aforementioned risk level.

7. A data processing apparatus, characterized in that, The data processing device includes: The receiving module is used to receive user events from multiple business subsystems and encapsulate the user events into a unified event object. The service obligation status recording module is used to determine the service obligation status record based on the unified event object; The marketing status information determination module is used to determine marketing status information based on the service obligation status record. The product marketing module is used to conduct product marketing based on the marketing status information and marketing candidate tasks.

8. A data processing device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the data processing method as described in any one of claims 1 to 6.

9. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the data processing method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the data processing method as described in any one of claims 1 to 6.

Images