A cross-scene task scheduling method and system for marketing digital employees

Abstract

The application discloses a kind of marketing digital staff cross-scene task scheduling method and system, specifically related to marketing task intelligent scheduling technical field, for solving the existing marketing digital staff in multi-touch, multi-scene continuous interaction, it is difficult to accurately undertake the historical task state of the same customer, leading to task repeated touch, scene fragmentation, artificial undertaking and system execution state inconsistency Problem. By forming the interaction record and system execution record of the same customer at each marketing touch, cross-scene interaction sequence is formed according to customer identification, scene type and interaction time, and customer-level task state ledger, candidate marketing task pool and undertaking relationship are established, so that marketing digital staff can identify continuation, replacement, merging, conflict, dependence and transfer relationship based on existing task state, thereby avoiding task fragmentation, repeated touch, non-undertaking of previous and subsequent tasks and inconsistency between artificial and system state, improving the continuity and accuracy of cross-scene marketing task scheduling.

Description

Technical Field

[0001] This invention relates to the field of intelligent scheduling technology for marketing tasks, specifically to a cross-scenario task scheduling method and system for marketing digital employees. Background Technology

[0002] As businesses increase their online marketing touchpoints, customers may engage in various behaviors such as inquiries, registrations, claiming benefits, receiving outreach messages, manual transfers, or follow-up registrations through multiple entry points, including online customer service, WeChat Work, mini-program activity pages, SMS outreach, outbound calls, customer relationship management systems (CRM) systems, benefit systems, and ticketing systems. Existing digital marketing staff can typically perform automated replies, lead reminders, benefit pushes, and outbound follow-up calls based on customer messages, activity records, or task status from a single touchpoint. They can also record some customer behaviors and execution results in CRM systems or marketing platforms. This approach offers a certain level of efficiency within a single scenario, such as generating replies when a customer inquires, sending reminders after a customer claims benefits, or creating follow-up records after a failed outbound call.

[0003] However, in actual marketing operations, the behavior of the same customer is often not limited to a single touchpoint or a single task chain. A customer may first claim benefits on a mini-program, then inquire about usage conditions on WeChat Work, and subsequently enter scenarios involving outbound follow-ups, human intervention, or after-sales follow-ups. In existing technologies, records of each touchpoint, system receipts, human agent records, and benefit status are usually scattered across different business systems. These different systems are mostly processed on a per-task or per-interaction basis, lacking a cross-scenario task status interface for the same customer. When a customer re-enters the current marketing scenario, marketing digital staff often can only generate processing actions based on the current touchpoint information or partial task status, making it difficult to accurately determine whether the current task is a continuation, replacement, merger, conflict, dependency, or requires reassignment to a human agent. This easily leads to situations such as the same customer being repeatedly contacted, completed benefits still being reminded, human intervention being available but the system still automatically progressing, and old tasks continuing to execute even after the activity has changed.

[0004] Therefore, the main problem that existing marketing digital employees face in the process of continuous marketing across touchpoints and scenarios is that they lack a unified basis for task scheduling that can unify the cross-scenario interaction records, system execution records and task status of the same customer. This makes it difficult to accurately connect the current scenario task with the historical task status, thereby affecting the continuity, consistency and traceability of cross-scenario marketing task scheduling. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a cross-scenario task scheduling method and system for marketing digital employees, in order to solve the problems mentioned in the background.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a cross-scenario task scheduling method for marketing digital employees, comprising: S1. Obtain cross-scenario interaction records and system execution records of the same customer across various marketing touchpoints, and form a cross-scenario interaction sequence according to customer identifier, scenario type, and interaction time; S2. Establish a customer-level task status ledger based on cross-scenario interaction sequences to record marketing goal status, task stage, reach records, preferential rights status, manual acceptance status, and system execution status. S3. When a customer enters the current marketing scenario, a pool of candidate marketing tasks is formed based on the current scenario trigger information, unfinished tasks in the customer-level task status ledger, and historical task derivative conditions. S4. Compare the candidate tasks in the candidate marketing task pool with the existing tasks in the customer-level task status ledger to determine the relationships of continuation, substitution, merging, conflict, dependence, and reassignment. S5. Based on the relationship of undertaking, the candidate tasks are checked for contact frequency, silent period, preferential rights, activity period, customer stage, and manual occupation status to form a scheduling and handling result; S6. Execute marketing tasks according to the scheduling and handling results, and write back the task execution status, customer response status, and task change status to the customer-level task status ledger as the basis for subsequent scenario scheduling.

[0007] Furthermore, S1 includes: When forming a cross-scenario interaction sequence, the customer ID from the customer relationship management system is used as the primary customer identifier. Use the member number, the anonymized mobile phone number, the external contact number of the WeChat Work account, the open identifier of the mini program, and the anonymized outbound call number as the association identifier; When an associated identifier has a binding record and that binding record points to only one primary customer identifier, the corresponding record will be assigned to that primary customer identifier. Collect cross-scenario interaction records and system execution records according to customer identifiers; Determine the scenario type based on the source system fields and the version of the organization rules; The interaction sequence is formed in ascending order of interaction time, creating a cross-scene interaction sequence.

[0008] Furthermore, S2 includes: When establishing a customer-level task status ledger, read the cross-scenario interaction sequence according to the customer identifier; Write the basic records in ascending order of interaction time; The marketing objective status is determined based on the marketing objective identifier; Task stages are formed based on the location of task actions under the same marketing objective; Based on the record category and source record number, the system generates contact records, preferential rights status, manual acceptance status, and system execution status. The marketing goal status, task stage, reach record, preferential rights status, manual acceptance status, and system execution status are associated and stored with the ledger rule version.

[0009] Furthermore, S3 includes: When forming a candidate marketing task pool, read the current scenario trigger information after the customer enters the current marketing scenario; The current scenario trigger time is used as the effective boundary for reading the client-level task status ledger; Generate candidate tasks for the current scenario based on the trigger information of the current scenario; Candidate tasks are generated from the incomplete tasks in the customer-level task status ledger. Derivative candidate tasks are generated based on the state combinations in the client-level task status ledger and the historical task-derived conditions. Write the candidate marketing task into the candidate marketing task pool in the order of current scenario candidate task, ledger candidate task, and derivative candidate task.

[0010] Furthermore, S4 includes: When performing task acceptance comparison, the customer-level task status ledger of a single customer is locked according to the customer identifier; Select existing tasks under the same marketing objective based on the marketing objective identifier; Combine candidate tasks with existing tasks to form task pairs; Based on the current scenario type, task stage, reach record, preferential rights status, manual acceptance status, system execution status, trigger time, and source record number, the acceptance comparison is performed to form an acceptance relationship record.

[0011] Furthermore, S4 also includes: When the same task satisfies multiple succession relationships, the primary succession relationship shall be determined in the order of dispatch relationship, conflict relationship, dependency relationship, substitution relationship, merger relationship, and continuation relationship. The covered successor relationship will be recorded as evidence of the relationship formation. Write the primary successor relationship as the successor relationship type in the successor relationship record.

[0012] Furthermore, S5 includes: When generating scheduling and handling results, the verification criteria for candidate tasks are determined according to the type of undertaking relationship; Verify the frequency of contact, quiet period, preferential benefits, activity period, customer stage, and manual occupancy status of candidate tasks; The scheduling and handling results are formed based on the verification conclusions of contact frequency, silent period, preferential rights, activity period, customer stage and manual occupancy status, as well as the handling priority order in the scheduling verification rule version; The scheduling and processing results are associated with the candidate task number, the type of undertaking relationship, and the version of the scheduling verification rules and stored together.

[0013] Furthermore, S6 includes: When executing marketing tasks, determine the corresponding task actions based on the scheduling and handling results; The task execution status is determined by recording the internal status corresponding to the results returned by the execution end and the scheduling and handling results. Customer response status is generated based on customer response records after the marketing task is executed; The task change status is generated based on the task execution status and the customer response status. Write back to the customer-level task status ledger in the order of task execution status, customer response status, and task change status.

[0014] On the other hand, the present invention provides a cross-scenario task scheduling system for marketing digital employees, including: The cross-scenario sequence formation module is used to obtain cross-scenario interaction records and system execution records of the same customer at various marketing touchpoints, and form cross-scenario interaction sequences according to customer identifier, scenario type, and interaction time. The customer-level ledger creation module is used to create a customer-level task status ledger based on cross-scenario interaction sequences, and record marketing goal status, task stage, reach records, preferential rights status, manual acceptance status, and system execution status. The candidate task pool formation module is used to form a candidate marketing task pool when a customer enters the current marketing scenario, based on the current scenario trigger information, unfinished tasks in the customer-level task status ledger, and historical task derivative conditions. The task assignment module is used to compare the candidate tasks in the candidate marketing task pool with the existing tasks in the customer-level task status ledger, and to determine the continuation, substitution, merging, conflict, dependency and reassignment relationships. The scheduling and handling module is used to verify the frequency of contact, quiet period, preferential rights, activity period, customer stage and manual occupancy status of candidate tasks according to the undertaking relationship, and generate scheduling and handling results; The task execution write-back module is used to execute marketing tasks according to the scheduling and handling results, and write back the task execution status, customer response status and task change status to the customer-level task status ledger as the basis for subsequent scenario scheduling.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By forming a cross-scenario interaction sequence based on customer identifier, scenario type, and interaction time by recording cross-scenario interaction records and system execution records of the same customer across various marketing touchpoints, and further establishing a customer-level task status ledger, candidate marketing task pool, and succession relationship, marketing digital employees can identify continuation, substitution, merging, conflict, dependency, and reassignment relationships based on existing task status when a customer enters the current marketing scenario. This avoids problems such as task fragmentation, duplicate outreach, non-successful task succession, and inconsistency between human and system processing status between different marketing scenarios, thereby improving the continuity and accuracy of cross-scenario marketing task scheduling.

[0016] 2. By verifying the frequency of outreach, the period of silence, preferential benefits, the duration of the activity, the customer stage, and the status of manual occupancy for candidate tasks based on the acceptance relationship, and after executing the marketing task according to the scheduling and handling results, the task execution status, customer response status, and task change status are written back to the customer-level task status ledger. This allows each task execution result to update the subsequent scenario scheduling basis in reverse, thereby achieving a traceable, updatable, and closed-loop execution link for marketing task scheduling, reducing invalid outreach, mis-promotion of benefits, expired activity pushes, and conflicts caused by manual occupancy. Attached Figure Description

[0017] Figure 1 Flowchart of cross-scenario task scheduling methods for marketing digital employees; Figure 2 A schematic diagram illustrating the formation of the candidate marketing task pool; Figure 3 A schematic diagram is generated to illustrate the determination of the receiving relationship and the results of the scheduling and handling. Figure 4 A schematic diagram illustrating the closed loop of marketing task execution write-back and subsequent scenario scheduling. Detailed Implementation

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

[0019] Example 1: Combined with Appendix Figures 1-4 This embodiment provides a cross-scenario task scheduling method for marketing digital employees, including: S1. Obtain cross-scenario interaction records and system execution records of the same customer across various marketing touchpoints, and form a cross-scenario interaction sequence according to customer identifier, scenario type, and interaction time. The specific implementation is as follows: Marketing digital staff extract cross-scenario interaction records and system execution records of the same customer across various marketing touchpoints during the processing period following customer touchpoint interactions. The execution entity can be deployed on the task access side of the enterprise marketing platform, customer operations backend, or agent workbench. The on-site location corresponds to the aggregation location of business records in online customer service, WeChat Work, mini-programs, outbound calls, SMS outreach, marketing campaign pages, customer relationship management systems, preferential benefits systems, and work order systems. The same customer is identified by a customer identifier, which is an identification field that points to the same natural customer, enterprise customer, or member account across different marketing touchpoints. In the main embodiment, the customer ID from the customer relationship management system serves as the primary customer identifier, while the member number, mobile phone number (de-identified value), and WeChat Work ID are used. External contact number, mini-program open identifier, and anonymized outbound call number value are used as association identifiers. Association identifiers cannot be used as the sole basis for confirming the same customer. They are only included in the customer record corresponding to the primary customer identifier if there is a confirmed binding record in the source system or customer relationship management system, and the binding record points to only one primary customer identifier. If the same source record carries two or more primary customer identifiers and corresponds to different customer files, or if the same association identifier corresponds to two or more primary customer identifiers, the source record will not enter the cross-scenario interaction sequence and will be transferred to pending verification. If the source record lacks a primary customer identifier and the association identifier has not established a binding relationship, it will be transferred to pending supplementation. It is uncertain whether the same customer is identified solely by similar names, nicknames, device addresses, consultation content, or outbound call numbers.

[0020] Each marketing touchpoint is the business entry point through which customers and the enterprise's marketing system engage in inquiries, browsing, registration, claiming of benefits, receiving outreach, telephone communication, manual transfer, or follow-up registration. This name corresponds to "each marketing touchpoint" in the independent claim. Each touchpoint must provide the touchpoint source, the record number within the touchpoint, the time of occurrence, and the customer identifier or associated identifier. For example, if a customer first submits a trial application on the mini-program activity page, then inquires about discounts on WeChat, and then the outbound call agent registers and follows up on the result, all three records are considered as the original business traces formed by the customer at each marketing touchpoint and are included in this step.

[0021] Cross-scenario interaction records are those initiated by customers, responded to by customers, or registered by agents to reflect customer intentions. These include customer text inquiries, button clicks, event registrations, customer replies, agent notes, and follow-up conclusions. System execution records are those automatically generated by the business system, including sending, delivery, receipt, read, collection, cancellation, status changes, and transfer receipts. These records originate from SMS platform delivery receipts, WeChat message delivery receipts, preferential benefits system collection or cancellation records, customer relationship management system lead status change records, outbound call system connection results, and work order system transfer records. When the same original record contains both customer responses and system receipts, a cross-scenario interaction record is formed based on the customer response portion, and a system execution record is formed based on the system receipt portion. These records are then linked through the same source record number.

[0022] Records are recorded in "items" and time units are time stamps in milliseconds or seconds. The processing rhythm can be based on real-time triggering, near-real-time batching, or fixed-interval batching. The main implementation allows for coverage of records within a single customer's single day, a single marketing campaign cycle, or a customer service cycle. For unstructured content such as chat content and agent notes, this step only retains the facts of the occurrence, the source touchpoint, the time of occurrence, the associated customer, the original text index, and the necessary summary location. Subsequent task relationships are not determined in advance in this step.

[0023] After obtaining the above records, first, group them within the same customer range according to customer identifiers, and then label each record according to scenario type. Scenario type corresponds to the marketing business situation of the customer, which may include consultation scenario, lead follow-up scenario, event outreach scenario, preferential benefit scenario, manual transfer scenario, and after-sales follow-up scenario. Scenario type cannot be directly inferred from free text content, but is determined only based on the mapping relationship in the source system fields and the sorting rule version. When the scenario type corresponding to the source system scenario type, business document type, task type, and page source is inconsistent, the business document type is given the first priority, the outbound call task type or work order type is given the second priority, the page source is given the third priority, and the touchpoint source is given the fourth priority. If it still cannot be uniquely determined, it will be transferred to pending verification.

[0024] Interaction time refers to the business occurrence time of each cross-scenario interaction record or system execution record in the source system. Priority is given to the customer action occurrence time, followed by the business system receipt time, and then the marketing platform receiving time. When the customer action occurrence time is later than the business system receipt time of the same record, and the difference exceeds the time tolerance set in the sorting rule version, it is transferred to pending verification. If the time tolerance is not exceeded, the customer action occurrence time is still used as the interaction time. When only the marketing platform receiving time can be obtained, the receiving time is retained as the interaction time and recorded as the receiving time in the time source mark. Time alignment only changes the unified storage format and does not overwrite the original time of the source system. The original time, unified time, and time source mark are saved simultaneously.

[0025] The process begins by standardizing field names, unifying external contact IDs, member IDs, and customer IDs into customer identification fields, and unifying page channels, conversation channels, and outbound call channels into touchpoint source fields. Next, time alignment is performed, unifying timestamps from different time zones, formats, and precisions. Finally, noise is removed, limited to heartbeat records, test records, invalid records, silent page exposure records explicitly marked by the source system, and duplicate delivery receipts listed in the cleanup rules. Noise is not considered based on customer response intention, marketing value, or task success / failure. Elimination; finally, limited completion is performed, which is limited to records within the same source or between parent and child records with the same source record number. Completion of touchpoint source, source record number, and scenario type mapping value is allowed, but completion of customer identifier, interaction time, customer response content, and system execution status is not allowed across customers, touchpoints, or marketing activities. If the aforementioned core fields are missing, the system shall not enter the cross-scenario interaction sequence. The following fields are pending verification for customer identifier conflicts, scenario type conflicts, time sequence conflicts, and duplicate merging conflicts. The following fields are pending supplementation for missing customer identifier, missing interaction time, missing source record number, and missing system execution status.

[0026] When forming a cross-scenario interaction sequence, the scope of a single customer is limited by the customer identifier, and the business scenario mark of each record is retained according to the scenario type. Finally, the records are arranged in ascending order of interaction time. When two or more records have the same interaction time, they are arranged stably according to the order of receipt by the source system, the dictionary order of the source record number, and the order of the record generation batch, so as to ensure that the same batch of records is processed repeatedly. Duplicate records are judged based on the fact that the source system identifier, source record number, customer identifier, and interaction time are completely identical. If this condition is met, only one sequence record is retained, and the remaining records are recorded as duplicate sources. Similar business content is not used as a basis for automatic deduplication.

[0027] The rule version is standardized to include customer identification merging criteria, scenario type mapping criteria, interaction time value criteria, noise removal criteria, and field completion criteria. The rule version is locked and written to each sequence record before this step begins, and the records already recorded must not be overwritten by the new version. When a correction occurs, the correction record is appended to retain the record before correction, the record after correction, the reason for correction, the correction time, and the source of the operation.

[0028] Cross-scenario interaction sequences are uniformly stored in the task organization area of ​​the marketing platform using customer identifiers as indexes, and a customer identifier index is created in the customer record area. Each sequence record must include at least the customer identifier, associated identifier, touchpoint source, scenario type, interaction time, record category, source record number, original record index, organization rule version, and organization time. The next step can only call the sequence through the customer identifier and sequence index position, without directly modifying the sequence content already formed in this step. The minimum return result includes the customer identifier, sequence generation status, number of valid records, number of records to be verified, organization rule version, and sequence index position.

[0029] To ensure continuous operation on-site, single customer record compilation can be submitted after the customer touchpoint behavior occurs, or it can be submitted in batches according to marketing activities. Without interrupting the entire batch task, if a single customer record cannot form a sequence due to missing core fields, conflicting identifiers, or missing time, only that customer record will be transferred to pending verification or supplementation, while the remaining customers will continue to form a sequence. When submitting records from the same source repeatedly, the source system identifier, source record number, customer identifier, and interaction time will be used as idempotent criteria. Records that have already been recorded will not be overwritten; only new source traces will be added.

[0030] The security and compliance boundaries are limited to the customer identifiers and original records accessed in this step. Personal information such as mobile phone numbers, outbound call numbers, and open identifiers are anonymized or internally associated with numbers before entering the sorting area. Original chat content is stored in the source system or compliant storage area. Only the original record index and necessary business fields are saved in the cross-scenario interaction sequence. Unauthorized touchpoint records are not allowed to enter this step.

[0031] On-site spot checks can extract customer records that have formed a sequence from each batch, and verify the total number of source records, the consistency of customer identification merging, the consistency of scenario type labeling, the consistency of interaction time sequence, and the reason for transfer to be verified. If customer identification is found to be mis-merged or core time is missing and not intercepted, the continued accounting of records with the same source caliber in that batch will be stopped, the formed sequence will be frozen to a pending review status, and the handling traces will be preserved by adding correction records.

[0032] Preferably, within one marketing campaign cycle, the processing area receives one batch of touchpoint records every 5 minutes, with each batch covering no more than 50,000 source records. The default processing interval for continuous records for a single customer is the most recent 30 days. Customer identification is merged using the customer ID from the Customer Relationship Management System as the primary identifier, and the external contact ID and the mini-program open identifier as the association identifiers. Time is unified to the millisecond level, and the deviation between the source system time and the unified time synchronization benchmark is allowed to be no more than 3 seconds. The delay in forming a single customer sequence is no more than 10 seconds. Records with missing core fields are entered into the pending record entry. The sample size for batch sampling is not... For customers with fewer than 100 customers and a scenario type consistency rate of no less than 98%, for example, customer number C20260518001 received a discount through a mini-program at 10:02:15, inquired about usage conditions through WeChat Work at 10:07:40, and had the outbound call recorded as not being connected at 10:16:08. After sorting, three cross-scenario interaction sequences were formed in ascending order of time, where receiving the discount is a discount benefit scenario, inquiring through WeChat Work is a consultation scenario, and the outbound call record is a lead follow-up scenario. The next step is to continue to build a customer-level task status ledger based on this sequence.

[0033] Alternatively, if all touchpoints of an enterprise already share the same customer ID from the same customer relationship management system, multiple associated identifiers need not be saved; only the source touchpoint ID and the source record ID need to be retained. If the touchpoint system does not support real-time submission, end-of-day batch processing can be used, but the customer ID, scenario type, and interaction time must still be kept consistent, and records lacking core fields must not be forcibly merged into cross-scenario interaction sequences.

[0034] S2. Establish a customer-level task status ledger based on cross-scenario interaction sequences, recording marketing goal status, task stage, outreach records, promotional benefits status, manual acceptance status, and system execution status. Specific implementation details are as follows: After obtaining the cross-scenario interaction sequence formed in the previous step, marketing digital staff establish customer-level task status ledgers one by one according to customer identifiers. The execution entity can be located between the task organization area of ​​the enterprise marketing middle platform and the customer operation backend. The on-site sources correspond to business records in the customer relationship management system, enterprise WeChat outreach system, mini-program activity system, SMS platform, telephone outbound system, preferential benefits system, and work order system. The customer-level task status ledger is a continuous collection of records that save the marketing task status for a single customer. Its physical location can be the ledger record area established by customer identifier within the marketing middle platform. Each customer identifier corresponds to one currently valid ledger. The ledger distinguishes the status records under different marketing objectives according to the marketing objective identifier. When the same customer has more than two marketing objectives at the same time, they are not merged into the same marketing objective status. Instead, corresponding marketing objective status records are formed under the same customer-level task status ledger. The records in the ledger all come from the cross-scenario interaction sequence of the customer. Original records that have not entered the sequence are not accepted to avoid mixing records from different customers, different scenarios, and different time periods.

[0035] During the creation process, the cross-scenario interaction sequence is first read according to the customer identifier. It is confirmed that each record in the sequence has a scenario type, interaction time, record category, source record number, and sorting rule version. Then, the records are written into the ledger one by one in ascending order of interaction time to form basic records. If there are records in the cross-scenario interaction sequence that are missing customer identifier, scenario type, interaction time, or source record number, these records will not participate in the ledger creation. They will continue to be checked or supplemented in the previous step and will not be supplemented in this step by speculation.

[0036] The marketing goal status describes the overall progress of the same customer under a single marketing goal, while the task stage describes the execution position of specific task actions under the same marketing goal. The two are recorded separately and do not substitute for each other. The marketing goal status is formed based on records such as activity registration, product consultation, discount collection, plan sending, follow-up registration, and lead status change in the cross-scenario interaction sequence. It indicates that the marketing goal corresponding to the customer is currently in one of the following states: unconfirmed, triggered, in progress, completed, or terminated. This status is not directly inferred from free text, but is obtained by comparing the activity identifier, product identifier, lead stage, benefit identifier, work order type, and agent registration conclusion in the source record with the pre-locked target status mapping.

[0037] Marketing goal statuses are recorded in a fixed order, with later statuses not overwriting earlier ones. When only product browsing, activity page visits, or generalized inquiries exist without activity, product, lead stage, or benefit indicators, it is recorded as "unconfirmed." When any source record exists (activity registration, product inquiry registration, discount claiming, or lead creation), it is recorded as "triggered." When any source record exists (solution sending, agent follow-up, customer supplementation of information, or customer re-inquiry), it is recorded as "in progress." When any source record exists (transaction registration, benefit redemption completion, activity registration completion, or lead closure with a successful closure reason), it is recorded as "completed." When any source record exists (customer explicit rejection, activity expired, lead closure with a failure reason, or benefit revocation), it is recorded as "terminated." For example, if a customer submits a product trial application in the mini-program, the corresponding marketing goal status record in the ledger is "triggered." If the subsequent customer relationship management system registers the solution as sent, this goal status continues to be recorded as "in progress."

[0038] Task stages are formed based on the position of task actions under the same marketing objective in the cross-scenario interaction sequence. The recording criteria include pending contact, contacted, pending response, pending follow-up, transferred to human agent, and closed. Pending contact is recorded when there are records of messages to be sent, calls to be made, or agent contact but no actual contact has occurred. Contact is recorded when there are records of SMS sending, WeChat delivery, phone calls, or agent contact. Pending response is recorded when no customer reply, action, or conclusion has been obtained after contact. Follow-up is recorded when the customer has already replied, received, registered, inquired, or refused to answer but still needs further contact. Transferred to human agent is recorded when there is a work order transfer or agent access record. Closed is recorded when the source system explicitly indicates task closure, objective termination, or task cancellation. If multiple task stage records exist for the same customer under the same marketing objective, the stage change chain is retained in ascending order of interaction time, without later records overwriting earlier ones.

[0039] Outreach records are generated based on proactive outreach activities via SMS, WeChat Work, outbound phone calls, mini-program in-app messages, and customer service representative notes. Records are counted in "times," and include the outreach channel, time, recipient, subject, source record number, and delivery status. Outreach records are counted from the point where the enterprise initiates a proactive contact. Sending an SMS, submitting a WeChat Work message, making an outbound phone call, submitting a mini-program in-app message, and registering a customer service representative contact are all counted as one outreach. Failed delivery, unanswered outbound calls, and no customer response do not cancel the outreach record, but the corresponding execution result is recorded in the system's execution status. Silent page exposure, system heartbeats, test sending, and voided records do not generate outreach records. If the source system identifier, source record number, customer identifier, and outreach time are completely identical, it is only counted as one outreach; others are recorded as duplicate sources.

[0040] The status of preferential benefits is formed based on the records of claiming, locking, using, expiring, and canceling in the preferential benefits system and activity system. The record scope includes unclaimed, claimed, locked, used, expired, and canceled. When there is only a customer inquiry about the benefit in the cross-scenario interaction sequence but no record in the benefits system, it is not automatically recorded as claimed; only the fact that the customer inquired about the benefit is recorded. When the benefits system receipt shows that the claim was successful but the customer replied that they did not receive it, the benefits system receipt is used to form the benefits status, while the customer's reply is retained as the basis for subsequent manual verification. The benefits status is not changed in this step. When there are multiple preferential benefits records under the same benefits identifier, a status change chain is formed in ascending order of interaction time. The current status is based on the benefit record with the latest time and a valid source system receipt. If there are more than two mutually exclusive preferential benefits statuses at the same interaction time, the current status is determined according to the priority of canceled, expired, used, locked, claimed, and unclaimed, and the mutually exclusive source records are transferred to the pending verification record.

[0041] The status of a manually accepted call is determined based on the transfer, access, processing, completion, and return records in the work order system, outbound call system, and agent workbench. The record scope includes unaccepted, pending, accepted, processing, completed, and returned. Pending acceptance requires at least a customer request for manual communication or a system transfer to a human agent record. Accepted requires at least a work order number or agent access record. Processing requires at least an agent number and access time. Completed requires at least a completion time and completion conclusion. Returned requires at least a return time and return reason. If the necessary fields for the corresponding status are missing, the status will not be promoted to that status. If the customer explicitly requests manual communication but the work order system has not yet generated an acceptance order, the ledger record will be pending acceptance and will not be automatically recorded as accepted.

[0042] The system execution status is formed based on the business execution facts returned by the SMS platform, WeChat Work system, customer relationship management system, preferential benefits system, outbound call system, and work order system. The recording scope includes not executed, executing, successful execution, failed execution, executed cancellation, and execution timeout. Execution success and execution failure are based on the receipt from the source system. If there is no receipt but a submission record exists, it is recorded as executing. Customers not replying are not directly recorded as execution failure. Outbound calls that are not connected are recorded as execution failure in the system execution status, and the original result of the outbound call system is retained as not connected in the source record index. Execution timeout is only formed when the source system has not returned execution success, execution failure, or execution cancellation after the receipt waiting period set by the ledger rule version.

[0043] When a record from the same source contains both customer action facts and system receipt facts, it is split into customer fact records and system fact records according to the record category. Customer fact records form corresponding records in marketing goal status, task stage, and manual acceptance status, while system fact records form corresponding records in reach records, preferential rights status, and system execution status. The split records share the same source record number and each record category is saved separately.

[0044] When establishing a customer-level task status ledger, the marketing goal status is formed first, followed by the task stage, and then the reach record, preferential rights status, manual acceptance status, and system execution status are entered. The ledger creation order only limits the order in which the ledger fields are entered, without changing the interaction time order in the cross-scenario interaction sequence. All ledger statuses of the same customer are ordered according to the interaction time. Each status retains the source record number and interaction time to ensure that it can be traced back to the original position in the cross-scenario interaction sequence.

[0045] The ledger rule version is locked before this step begins. This includes the mapping criteria for marketing goal status, task stage, reach record count, preferential benefit status, manual acceptance status, and system execution status. Existing ledger records must not be directly overwritten by the new version. When corrections occur, the pre-correction status, post-correction status, correction reason, correction time, and operation source are saved by appending correction records. The following need to be checked: status mapping conflicts, mutually exclusive statuses under the same marketing goal, duplicate mapping of records from the same source to the same status, and source record number conflicts. The following need to be supplemented: missing necessary ledger fields, missing necessary status fields, missing source record indexes, and missing ledger rule versions.

[0046] The customer-level task status ledger is stored in the ledger record area of ​​the marketing platform with the customer identifier as the main index. Each ledger record includes at least the customer identifier, marketing target identifier, marketing target status, task stage, reach record index, preferential rights status, manual acceptance status, system execution status, source record number, interaction time, ledger rule version, and ledger generation time. The next step reads the marketing target status that is not in the completed or terminated state, the task stage that is not in the closed state, and related status records in the ledger according to the customer identifier, without directly rewriting the historical status already recorded in this step.

[0047] To maintain continuous operation on-site, ledger creation can be triggered immediately after the cross-scenario interaction sequence is formed, or it can be triggered in batches according to marketing activities. When the ledger for the same customer is created repeatedly, the customer identifier, marketing target identifier, source record number, interaction time, and ledger rule version are used as idempotent criteria. Statuses that have already been recorded are not written repeatedly; only the status corresponding to the newly added source record is appended. When a single customer's ledger cannot be fully created due to status mapping conflicts, source record number conflicts, or missing necessary status fields, only that customer is transferred to pending verification or pending supplementation, while the ledgers for other customers continue to be created.

[0048] The security boundary is limited to the customer identifier, status field, and source record index accessed in this step. The original chat content and plaintext number are not written to the customer-level task status ledger. The ledger only saves the anonymized identifier, status value, time, and source index. On-site spot checks can be conducted by batching customer ledgers to verify whether the ledger status can be traced back to the cross-scenario interaction sequence, and whether the marketing goal status, task stage, reach record, preferential rights status, manual acceptance status, and system execution status all comply with the ledger rule version.

[0049] Preferably, within one marketing campaign cycle, the ledger creation task reads new cross-scenario interaction sequences every 5 minutes, with a single batch covering no more than 30,000 customers. The ledger for a single customer defaults to covering cross-scenario interaction sequences from the most recent 30 days. The ledger generation delay is no more than 15 seconds, and no less than 100 customers are randomly selected for each batch, with a status backtracking consistency rate of no less than 98%. For example, if customer number C20260518001 receives a discount at 10:02:15, inquires about usage conditions at 10:07:40, and fails to connect to an outbound call at 10:16:08, the ledger will show a marketing goal status of "triggered," a task stage of "pending follow-up," a contact record including one outbound call record, a discount status of "received," a manual handling status of "not handled," and system execution status recording successful discount receipt and failed outbound call execution. The next step will form a candidate marketing task pool based on the customer-level task status ledger.

[0050] Alternatively, if the enterprise's existing customer relationship management system can directly save customer-level task status, the customer-level task status ledger can be set up within the customer relationship management system, and the ledger index can be saved by the marketing middle platform. However, the value caliber, source tracing caliber, and version locking caliber for marketing target status, task stage, reach record, preferential rights status, manual acceptance status, system execution status, etc., should remain consistent.

[0051] S3. When a customer enters the current marketing scenario, a candidate marketing task pool is formed based on the current scenario trigger information, incomplete tasks in the customer-level task status ledger, and historical task derivative conditions. The specific implementation is as follows: When a customer enters the current marketing scenario, the marketing digital staff reads the current scenario trigger information and combines it with the incomplete tasks and historical task derivative conditions in the task status ledger to form a candidate marketing task pool. The execution entity can be located on the task scheduling access side of the enterprise marketing platform. The on-site sources correspond to online customer service conversation entry, enterprise WeChat customer conversation, mini program activity page, telephone outbound agent workbench, SMS outreach system, customer relationship management system, preferential benefits system, and work order system. The current marketing scenario is the marketing business scene where the customer is currently interacting or being triggered by the business system. Its value follows the scenario type caliber in the cross-scenario interaction sequence and can be consultation scenario, lead follow-up scenario, activity outreach scenario, preferential benefits scenario, manual transfer scenario, and after-sales follow-up scenario. The current marketing scenario is determined by the scenario type of the customer's current touchpoint behavior or the current pending system record, and does not temporarily expand new scenario names based on free text.

[0052] Customer entry into the current marketing scenario includes both customer-initiated actions that trigger the current touchpoint and pending records in the current business system associated with the customer's identifier entering the scope of the marketing digital staff's processing. Confirmation is based on the simultaneous existence of the customer identifier, touchpoint source, current scenario trigger time, and source record number. Customers opening the activity registration page in the mini-program and submitting their mobile phone number, sending inquiry messages in WeChat Work, entering the waiting queue in the outbound calling system, and generating a pending verification reminder in the benefits system can all be considered as on-site triggering facts for entering the current marketing scenario. Only silent page exposure, system heartbeat, test tasks, and temporary access records without customer identifiers are not considered as customers entering the current marketing scenario, and the corresponding records are not included in the formation of the candidate marketing task pool.

[0053] The current scenario trigger information is the trigger record generated by the current touchpoint or the current business system when a customer enters the current marketing scenario. It includes at least the customer identifier, current scenario type, touchpoint source, trigger time, source record number, trigger action, and associated marketing target identifier. The trigger action can be customer inquiry, event registration, discount collection, message reply, outbound call queuing, manual transfer application, or follow-up registration. The trigger time is based on the time of the customer action recorded by the source system or the time of task generation by the business system. If only the marketing middle platform receiving time exists, the receiving time is retained and the time source is marked. If the current scenario trigger information lacks the customer identifier, current scenario type, trigger time, or source record number, it will not form a candidate marketing task pool and will be transferred to the pending record. If the same source record corresponds to more than 2 customer identifiers or more than 2 current scenario types, it will be transferred to the pending verification.

[0054] The reasons for the formation of candidate tasks in the current scenario are jointly determined by the triggering action, the current scenario type, and the associated marketing target identifier in the current scenario triggering information, and new candidate reasons are not generated directly based on free text content.

[0055] After obtaining the current scenario trigger information, the task status ledger is read according to the customer identifier, and the current scenario trigger time is used as the effective boundary for reading the task status ledger. Status records written to the task status ledger after the current scenario trigger time will not participate in the formation of the candidate marketing task pool. The reading scope is limited to marketing goals that are not in the completed or terminated state, tasks that are not in the closed stage, and related contact records, preferential rights status, manual acceptance status, and system execution status under the customer identifier.

[0056] Incomplete tasks in the task status ledger are those that can be matched with a marketing objective in the customer-level task status ledger but have not yet been recorded as completed, terminated, or closed. The on-site definition includes tasks that are pending contact, have been contacted, are pending response, are pending follow-up, or have been transferred to human agents but not yet completed. It does not include closed tasks, completed marketing objectives, terminated marketing objectives, or revoked execution records. Tasks that have been transferred to human agents but not yet completed are only entered into the candidate marketing task pool as candidate tasks in the ledger and are not directly executed by digital employees in this step.

[0057] The confirmation of incomplete tasks does not reinterpret the original customer session content, but filters according to the status values ​​already formed in the ledger rule version; when there are multiple incomplete tasks under the same marketing goal, all task sources are retained in ascending order of interaction time, and the latest task does not cover the earlier task. Subsequently, the corresponding marketing goal identifier and task stage are only marked in the candidate marketing task pool, and the continuation, substitution, merging, conflict, dependence or reassignment relationship is not determined in this step.

[0058] Historical task derived conditions are fixed conditions that are transformed from historical state records already existing in the task state ledger to generate candidate tasks. They correspond to the "historical task derived conditions" in the independent claims. They are locked on-site by the ledger rule version and are not temporarily filled in by the current operator. Each historical task derived condition has a fixed condition number, which corresponds to a unique state combination, candidate formation reason and candidate task source. The same condition number is not allowed to correspond to more than two state combinations under the same ledger rule version.

[0059] This condition is formed based on the combination of records between marketing goal status, task stage, outreach records, promotional benefit status, manual acceptance status, and system execution status. For example, when the promotional benefit status is "claimed" and the task stage is "pending follow-up," a candidate task for benefit usage reminder is formed; when there are outreach records showing failed outbound calls and the task stage is still "pending follow-up," a candidate task for re-contact is formed; when the manual acceptance status is "pending acceptance," a candidate task for manual acceptance reminder is formed; and when the system execution status is "execution timeout" and the marketing goal status is not completed, a candidate task for execution result confirmation is formed.

[0060] Once the conditions for a historical task are met, a corresponding derivative candidate task is formed. The current operator does not choose whether to form it. Within the same candidate pool batch, only one derivative candidate task is formed for the same customer, the same marketing objective, and the same trigger status record under the same historical task derivative condition. The historical task derivative condition only generates the source of the candidate task and does not determine whether the candidate task is executed in this step, nor is it subject to business constraint verification. When the status combination lacks a marketing objective identifier, lacks a source record number, or the statuses correspond to different customer identifiers, the historical task derivative condition is not triggered, and the relevant record enters the pending verification stage.

[0061] When forming a candidate marketing task pool, first generate candidate tasks for the current scenario from the current scenario trigger information, then add incomplete tasks from the task status ledger as candidate tasks, and finally generate derivative candidate tasks according to the historical task derivative conditions. The candidate marketing task pool is a set of candidate tasks for the same customer in the current marketing scenario that are pending subsequent scheduling and judgment. Each candidate task must record the customer identifier, current scenario type, marketing target identifier, candidate task source, task stage, trigger time, source record number, reason for candidate formation, ledger rule version, and candidate pool generation time. The candidate task source is limited to one of three categories: current scenario trigger information, incomplete tasks in the task status ledger, and historical task derivative conditions. The candidate pool does not directly write the execution channel, execution order, or scheduling and handling results to avoid premature entry into subsequent acceptance relationship judgment and business constraint verification.

[0062] The reason for candidate formation only records the combination of fields that formed the candidate task, and does not record open subjective descriptions; the current scenario candidate task records the current scenario type and triggering action; the ledger candidate task records the task stage and marketing goal status; the derived candidate task records the historical task derived condition number and the status record number that triggered the condition.

[0063] During the formation of the candidate task pool, the candidate tasks for the current scenario are uniquely formed based on the source record number, customer identifier, current scenario type, and trigger time; the candidate tasks for the ledger are formed based on the customer identifier, marketing target identifier, task stage, and source record number; the candidate tasks for the derivative are formed based on the customer identifier, marketing target identifier, historical task derivative condition number, and ledger status record number that triggered the condition; if the three types of candidate tasks have different sources but the same marketing target, they are all retained in the candidate marketing task pool and are not merged or deleted in this step. Only the different sources of the candidate tasks are marked, and the succession relationship will be determined in subsequent steps.

[0064] To ensure order stability, candidate marketing tasks for the same customer are written in the order of current scenario candidate tasks, ledger candidate tasks, and derived candidate tasks. Within the same type of candidate task, they are arranged in ascending order according to trigger time or ledger interaction time. If the trigger times are the same, they are arranged in dictionary order according to the source record number. The writing order in the candidate marketing task pool is only the record order and does not indicate execution priority, scheduling order, or succession relationship.

[0065] When duplicate tasks are generated, the customer identifier, marketing target identifier, candidate task source, source record number, and ledger rule version are used as idempotent criteria. Existing candidate tasks are not written again; only new source traces are added. If the customer identifier, marketing target identifier, source record number, or ledger rule version in the candidate task generation criteria are missing, the candidate task will not enter the candidate marketing task pool and will be moved to the pending supplementation stage. If the same source record is mapped to two or more mutually exclusive candidate task sources, or if there are inconsistencies in the customer identifier or marketing target identifier among the status records corresponding to the historical task derivative conditions, the task will be moved to the pending verification stage.

[0066] The following conditions need to be verified: current scenario type conflict, records from the same source being mapped to mutually exclusive candidate task sources, conflict of historical task derivative condition numbers, and the number of candidate tasks exceeding the upper limit of the candidate pool capacity and unable to form a candidate pool overflow record; the following conditions need to be supplemented: missing customer identifier, missing current scenario type, missing trigger time, missing source record number, missing marketing target identifier, and missing ledger rule version.

[0067] The candidate marketing task pool is stored in the candidate task record area of ​​the marketing platform using customer identifiers and candidate pool batch identifiers. The minimum record content includes customer identifier, current scenario type, marketing target identifier, candidate task source, task stage, trigger time, source record number, reason for candidate formation, ledger rule version, and candidate pool generation time. The next step reads the candidate marketing task pool according to the customer identifier and candidate pool batch identifier, and compares the candidate tasks with the existing tasks in the task status ledger. The candidate pool records formed in this step are not directly overwritten by the next step.

[0068] To maintain continuous operation on-site, the candidate marketing task pool can be formed immediately after a customer enters the current marketing scenario, or it can be formed after the marketing platform reads the current scenario trigger information in batches. When a single customer's candidate pool cannot be formed, only that customer enters the pending verification or pending supplementation pool, without blocking the formation of candidate pools for other customers in the same batch.

[0069] The security boundary is limited to the customer identifier, status field, and source record index accessed in this step. The original chat content and plaintext number are not written to the candidate marketing task pool. The reason for the formation of candidates is only saved by the combination of status fields and the source record index.

[0070] Preferably, the confirmation window for the current scenario trigger information can be set within 30 seconds after the customer's current touchpoint behavior occurs. The task status ledger reading range can be set to the status records that have not been closed in the last 30 days. The formation delay of the single customer's candidate marketing task pool can be set to no more than 8 seconds. The number of candidate tasks for a single customer in a current marketing scenario can be set to no more than 20. When the upper limit of the number of candidate tasks is exceeded, the excess candidate tasks are not deleted. Instead, the excess candidate tasks are marked as candidate pool overflow records and the source index is retained. The next step prioritizes reading candidate tasks within the upper limit. Overflow records are retained for verification or batch expansion processing. For example, if customer number C20260518001 enters the enterprise WeChat consultation scenario at 10:20:00 and inquires about the use of discounts, the task status ledger contains records of received discount benefits, pending follow-up tasks, and 1 failed outbound call. The system first forms 1 candidate task for the current scenario, then reads 1 candidate task from the pending follow-up ledger, and forms 1 derivative candidate task for benefit usage reminder based on the received discount benefits. Finally, 3 candidate marketing task records are formed for the next step to determine the succession relationship.

[0071] Alternatively, if the enterprise customer relationship management system already has the ability to temporarily store candidate tasks, the candidate marketing task pool can be stored in the task temporary storage area of ​​the customer relationship management system. The marketing platform only saves the batch identifier and index position of the candidate pool, but the formation criteria of the current scenario trigger information, the incomplete tasks in the task status ledger, the historical task derivative conditions, and the candidate task pool field criteria are consistent.

[0072] S4. Compare the candidate tasks in the candidate marketing task pool with the existing tasks in the customer-level task status ledger to determine the continuation, substitution, merging, conflict, dependency, and reassignment relationships. The specific implementation is as follows: After the candidate marketing task pool is formed, marketing digital staff read the candidate tasks one by one and compare them with the existing tasks in the task status ledger. The execution entity can be located on the task scheduling and judgment side of the enterprise marketing platform, with the on-site source corresponding to the candidate task record area and the customer-level task status ledger record area. The candidate task is a task record formed in the previous stage and awaiting scheduling and judgment. Its source is limited to one of the following: current scenario trigger information, incomplete tasks in the task status ledger, or historical task derivative conditions. The candidate task must at least carry a customer identifier, current scenario type, marketing target identifier, candidate task source, and task details. The task stage, trigger time, source record number, reason for candidate formation, and ledger rule version are included. Existing tasks in this step include task stage records under the same marketing target identifier that have not yet been closed in the task status ledger, as well as contact records, preferential rights status, manual acceptance status, and system execution status associated with the task stage. The scope of reading is limited to marketing target status that is not in a completed or terminated state, and task stage that is not in a closed state. The task status of other customers is not read, nor are status records written to the ledger after the candidate pool generation time. Status records that exist alone and cannot be associated with a marketing target identifier are not included in the acceptance comparison as existing tasks.

[0073] This step only compares the candidate tasks in the candidate marketing task pool with the existing tasks in the task status ledger, and does not directly establish a connection relationship between the candidate tasks. When there is a potential conflict between two candidate tasks, a connection relationship record will only be formed through the existing task if one of the candidate tasks can be matched with an existing reach record, existing task stage, or existing system execution status in the task status ledger.

[0074] The comparison process assumes that the customer identifier is consistent. The comparison fields are marketing target identifier, current scenario type, task stage, reach record, preferential rights status, manual acceptance status, system execution status, trigger time, and source record number. If the customer identifier of the candidate task is inconsistent with that of the existing task, no comparison will be performed and the task will be transferred to the pending verification stage. If the candidate task is missing marketing target identifier, candidate task source, trigger time, or source record number, it will be transferred to the pending supplementation stage. During the comparison, a single customer ledger is first locked according to the customer identifier, and then existing tasks under the same marketing target are selected according to the marketing target identifier. If the candidate task is missing an existing task that can be matched with the same marketing target, no continuation, substitution, merging, conflict, dependency, or reassignment relationship will be formed. Only a mark indicating that there is no existing task to compare will be added to the candidate task record, and the task will enter the next stage with the candidate pool batch. This mark is not considered as the acceptance relationship type.

[0075] The acceptance comparison does not change the original records in the candidate task pool and task status ledger, but only forms acceptance relationship records between candidate tasks and existing tasks. The same candidate task can form acceptance relationship records with more than 2 existing tasks. Each candidate task and each existing task constitute a task pair, and each task pair retains only 1 main acceptance relationship type. The acceptance relationship record includes at least the customer identifier, candidate task number, existing task number, marketing target identifier, comparison field, acceptance relationship type, relationship formation basis, relationship formation time, and acceptance rule version.

[0076] A continuation relationship must simultaneously meet the following conditions: consistent customer identification, consistent marketing objective identification, the candidate task trigger time is later than the existing task interaction time, the existing task is not in a closed, completed, or terminated state, the candidate task's task stage is after the existing task stage in the task stage sequence locked by the acceptance rule version, or the candidate task and the existing task are in the same task stage but have different source record numbers and the trigger time is later than the existing task interaction time, and the conditions for determining substitution, merging, conflict, dependence, or transfer relationships are not met. The task stage sequence is as follows: pending contact, contacted, pending response, pending follow-up, transferred to human, and closed and locked. Transferred to human and closed are not considered as ordinary continuation stages. For example, if the existing task is pending response after contacting, and the candidate task is a pending follow-up record formed by the customer's further consultation or supplementary information, then the record is a continuation relationship.

[0077] A substitution relationship is only determined when the actual occurrence of the candidate task has achieved the completion objective of the existing task. The completion objective is based on the reason for the candidate formation of the existing task or the target field corresponding to the task stage, and is not determined based on similar contact scripts or similar customer expressions. If the existing task has already triggered manual acceptance, involves complaint handling, or has an incomplete pre-requisite status, it is uncertain whether it is a substitution relationship. For example, if the existing task is a discount description or discount claim reminder, and the discount benefits corresponding to the candidate task have already been claimed, locked, or used, then it is determined to be a substitution relationship. If there is only a customer inquiry about discounts but no discount benefit system receipt, it is uncertain whether it is a substitution relationship.

[0078] The merging relationship is only determined when the candidate task and the existing task have the same customer identifier, marketing target identifier, target touchpoint source, touch method, and touchpoint target, and neither has entered the manual acceptance state, neither has a customer explicit rejection record, and neither has mutually exclusive preferential rights status or system execution status. Whether the touch topics can be presented side by side is based on the list of topics that can be merged for the same touchpoint registered in the acceptance rule version, and is not determined by the current operator on the spot. For example, if both the activity reminder and the rights usage reminder correspond to the Enterprise WeChat touchpoint and neither shows customer rejection or manual access, then it is recorded as a merging relationship.

[0079] The scope for confirming conflict relationships is based on the access restriction window or status mutual exclusion window locked in the acceptance rule version; access conflict includes more than two proactive access tasks for the same customer within the access restriction window, and the access methods belong to the mutually exclusive access methods registered in the acceptance rule version; status conflict includes the simultaneous existence of used and revoked, claimed and expired, locked and revoked under the same rights identifier, or the simultaneous existence of processing and returned under the same manual acceptance record; conflict relationships only record the mutually exclusive facts and do not determine which task to retain in this step.

[0080] Dependencies are only determined when a candidate task has a prerequisite status field registered in the candidate formation reason, and the existing task in the task status ledger has not yet reached the prerequisite status field. Candidate tasks that do not have a prerequisite status field registered in the acceptance rule version are not determined to be dependencies. For example, if the candidate task is a rights redemption reminder, and the preferential rights status in the existing task has not yet reached the status of claimed or locked, then it is recorded as a dependency.

[0081] A transfer relationship is only determined when the status of the candidate task or existing task corresponding to the manual acceptance is pending, accepted, or being processed, or when the source record shows that the customer requested manual communication, complaint handling, abnormal verification, or price confirmation. If there are only polite customer greetings, ordinary inquiries, ordinary reminders, or ordinary price inquiries, and no application for transfer to manual service, work order record, or agent access record is generated, a transfer relationship is not determined.

[0082] For the same task pair that simultaneously satisfies two or more types of succession relationships, the primary relationship is retained in the order of dispatch relationship, conflict relationship, dependency relationship, substitution relationship, merging relationship, and continuation relationship, while the covered secondary relationship is recorded as the basis for relationship formation. The succession relationship priority order only applies to a single task pair consisting of the same candidate task and the same existing task, and is not used to delete the succession relationship records that have been formed between the candidate task and other existing tasks, nor does it indicate the subsequent execution priority or scheduling result.

[0083] The succession rule version is locked before this step begins. The content includes the field combination, status value, exclusion cases, priority order, reach restriction window, status mutual exclusion window, and list of topics that can be merged at the same touchpoint for continuation relationship, replacement relationship, merging relationship, conflict relationship, dependency relationship, and dispatch relationship. The existing succession relationship record shall not be directly overwritten by the new version. When a correction occurs, the relationship before correction, the relationship after correction, the reason for correction, the time of correction, and the source of operation shall be saved as an append correction record.

[0084] To maintain order stability, candidate tasks are compared one by one in the order of records in the candidate marketing task pool. When the same candidate task corresponds to multiple existing tasks, they are compared in ascending order of interaction time of the existing tasks. When comparing repeatedly, the customer identifier, candidate task number, existing task number, marketing target identifier, and acceptance rule version are used as idempotent criteria. Records of acceptance relationships that have already been formed are not written repeatedly, and only new source traces are added.

[0085] The acceptance relationship record is stored in the acceptance relationship record area of ​​the marketing platform with customer identifier and candidate pool batch identifier. The next step reads the record according to customer identifier, candidate pool batch identifier and acceptance relationship type, and performs business constraint verification on candidate tasks. This step does not generate execution channel, execution order and scheduling results.

[0086] If a single customer has inconsistent customer identifiers, conflicting marketing target identifiers, the same task cannot be uniquely determined to the main relationship, missing or conflicting acceptance rule versions, or conflicting existing task source records, the corresponding candidate task will be put into pending verification. If the candidate task number is missing, the existing task number is missing, the marketing target identifier is missing, the trigger time is missing, the source record number is missing, or the comparison field is missing, the corresponding candidate task will be put into pending supplementation, without blocking the acceptance comparison of other customers in the same batch.

[0087] The security boundary is limited to the candidate task fields, ledger status fields, and source record indexes accessed in this step. The original chat content and plaintext number are not written into the acceptance relationship record. On-site spot checks can be performed by batching acceptance relationship records to verify whether candidate tasks and existing tasks belong to the same customer, whether the basis for the relationship can be traced back to the candidate marketing task pool and task status ledger, and whether the acceptance relationship type conforms to the acceptance rule version.

[0088] Preferably, the acceptance comparison confirmation interval can be set to existing tasks that have not been closed within 30 days prior to the candidate pool generation time. The number of comparison tasks per customer per candidate pool can be set to no more than 20 candidate tasks and 50 existing tasks. The acceptance comparison delay per customer can be set to no more than 10 seconds. Each batch of random checks should include no less than 100 task pairs, and the consistency rate of relationship backtracking should be no less than 98%. For example, the candidate task for customer number C20260518001 is a rights and benefits usage reminder. The existing tasks in the task status ledger include records of discounts claimed, records of outbound call execution failures, and tasks in the pending follow-up stage. In this case, the candidate task and the pending follow-up existing tasks can form a continuation relationship. If the existing task records in the same confirmation interval show that the same customer has a telephone outbound call proactive contact task, and the telephone outbound call and the enterprise WeChat reminder are mutually exclusive contact methods registered in the acceptance rule version, then the candidate task and the existing contact task form a conflict relationship. Subsequent steps will then conduct business constraint verification based on this acceptance relationship.

[0089] Alternatively, if the enterprise customer relationship management system already has the ability to temporarily store task relationships, the acceptance relationship record can be stored in the task relationship area of ​​the customer relationship management system. The marketing middle platform only saves the customer identifier, candidate pool batch identifier and relationship index position, but the field scope, acceptance relationship type, priority order and version locking scope of the candidate task are consistent with those of the existing tasks in the task status ledger.

[0090] S5. Based on the relationship of assignment, the candidate tasks are checked for contact frequency, quiet period, preferential rights, activity period, customer stage, and manual occupancy status to form a scheduling and handling result. The specific implementation is as follows: After obtaining the assignment relationship record, marketing digital staff read the corresponding candidate tasks according to the customer identifier and the batch identifier of the candidate pool. Based on the assignment relationship, they verify the candidate tasks for reach frequency, quiet period, preferential benefits, activity period, customer stage, and manual occupancy status, and form a scheduling and disposal result. The executing entity can be located on the task scheduling and verification side of the enterprise marketing middle platform. The on-site sources are the corresponding assignment relationship record area, candidate task record area, customer-level task status ledger record area, preferential benefits system, activity management system, customer relationship management system, manual agent workbench, and outbound call system. The assignment relationship is a record of continuation, substitution, merging, conflict, dependence, and transfer relationships formed in the previous step. This step only reads the customer identifier, candidate task number, existing task number, marketing target identifier, assignment relationship type, relationship formation basis, and assignment rule version in the relationship record. It does not re-determine the assignment relationship type, nor does it change the original status in the candidate task pool and task status ledger.

[0091] When verifying candidate tasks, first, the customer identifier and marketing target identifier corresponding to the candidate task are locked based on the succession relationship. Then, the verification criteria that the candidate task needs to enter are determined according to the succession relationship type. Candidate tasks corresponding to continuation relationships and merging relationships are verified based on reach frequency, quiet period, activity period, and customer stage. Candidate tasks corresponding to substitution relationships are verified based on preferential rights and customer stage. Candidate tasks corresponding to conflict relationships are verified based on reach frequency, quiet period, preferential rights, and manual occupancy status. Candidate tasks corresponding to dependency relationships are verified based on preferential rights, activity period, and customer stage. If the result of the preceding execution is involved, the system execution status is only used as the source field for the verification of preferential rights, activity period, or customer stage, and does not form an independent verification item. Candidate tasks corresponding to dispatch relationships are verified based on manual occupancy status and customer stage. The above verification criteria are locked by the version of the scheduling verification rules. The same succession relationship type cannot correspond to more than two sets of verification criteria under the same version.

[0092] The frequency of contact refers to the number of proactive contacts made to the same customer within the verification and confirmation period. The unit of measurement is "times". It is derived from the contact records in the customer-level task status ledger and is counted by customer identifier, contact channel, contact time, and marketing target identifier. SMS submission, WeChat message submission, telephone outbound dialing, mini-program in-site message submission, and manual agent contact registration are all included in the contact frequency. Silent page exposure, system heartbeat, test sending, and invalid records are not included in the contact frequency. If the number of contacts made by the contact channel to which the candidate task belongs within the confirmation period reaches the frequency limit set by the scheduling verification rule version, the candidate task shall not generate an immediate execution type scheduling result and shall be put on hold to wait for the result. If the contact record is missing contact time or contact channel, the candidate task shall be put into the supplementary recording stage.

[0093] The silence period is the time range during which contact is temporarily suspended after a customer refuses to reach you, is handling a complaint, cancels a subscription, or registers as temporarily unreachable by an agent. It is derived from customer response records, manual acceptance status, system execution status, and customer relationship management system registration records in the task status ledger. The silence period is recorded with the silence start time, silence reason, silence end time, or silence effective duration. If the current verification time falls within the silence period, the candidate task cannot form an active contact scheduling result, but can only form one of the following: suspension and waiting, transfer to manual agent, or termination of the task. If the silence period only has a start time and no end time, it is determined according to the default effective duration in the scheduling verification rule version, and is not subject to temporary judgment by the operator.

[0094] The verification of preferential rights is based on the preferential rights status in the preferential rights system and the customer-level task status ledger. It checks whether the rights identifier associated with the candidate task is in one of the following states: unclaimed, claimed, locked, used, expired, or revoked. Candidate tasks for rights usage reminders are only allowed to continue to generate executable processing results when the preferential rights status is claimed or locked. Candidate tasks for rights reissue are only allowed to continue to generate scheduling processing results when the rights status is used, expired, or revoked. If the same rights identifier has mutually exclusive rights statuses at the same time, the candidate task will enter the pending verification stage and will not generate a scheduling processing result.

[0095] The activity duration verification is performed based on the activity start time, activity end time, activity status, and marketing target identifier in the candidate tasks in the activity management system. If the current verification time is earlier than the activity start time, the activity will be suspended and waited for. If the current verification time is between the activity start time and the activity end time and the activity status is active, verification can continue. If the current verification time is later than the activity end time or the activity status is suspended, terminated, or invalidated, no immediate execution result will be generated. If the activity duration field is missing but the marketing target identifier associated with the candidate task exists, the activity will be moved to the pending entry stage. If the same marketing target identifier corresponds to more than two mutually exclusive activity statuses in the activity system, the activity will be moved to the pending verification stage.

[0096] Customer stage verification is based on the marketing goal status, task stage, and lead stage in the customer relationship management system and customer-level task status ledger. Customer stages can be recorded as unconfirmed, triggered, in progress, completed, or terminated. The customer stage required for a candidate task is determined by the applicable stages registered in the scheduling verification rule version. If the current customer stage is not within the applicable stage range, the candidate task shall not generate an immediate execution result. For example, if the customer stage has been terminated, no rights reminder or activity invitation result will be generated. If the candidate task is a transfer relationship and the customer stage is in progress or triggered, it will continue to enter the manual occupancy status verification.

[0097] The manual occupancy status verification is based on the agent number, work order number, access time, and processing status in the agent workbench, work order system, and outbound call system. The manual occupancy status includes unoccupied, pending, occupied, processing, and released. When the same customer or the same marketing target already has an occupied or processing status, the digital employee candidate task cannot form an independent proactive execution result. The candidate task corresponding to the transfer relationship can form a transfer to human or be suspended pending processing result. When the manual occupancy status is unoccupied and there is no pending record, the processing result can continue to be formed according to other verification results.

[0098] Each verification is recorded in the order of frequency of contact, silent period, preferential rights, activity period, customer stage, and manual occupancy status. The order of recording does not indicate business priority. If any verification item results in a conclusion that it is prohibited from immediate execution, subsequent verification items will still retain the verification records that can be obtained. However, the scheduling and handling results will be determined according to the handling priority order registered in the version of the scheduling and verification rules. The handling priority order can be set as: transfer to manual, suspend and wait, terminate task, merge execution, continue execution, substitute closure, and supplementary confirmation.

[0099] The scheduling and handling result is a structured record of the results generated in this step. Values ​​include: Continued Execution, Merged Execution, Suspended Waiting, Transferred to Manual Personnel, Terminated Task, Alternative Closure, and Supplementary Confirmation. Continued Execution occurs when the acceptance relationship is continued and the reach frequency, silence period, activity period, or customer stage are not blocked. Merged Execution occurs when the acceptance relationship is merged and the reach frequency does not exceed the limit, the silence period is not hit, and the manual personnel status is not occupied. Suspended Waiting occurs when the silence period is hit, the activity has not started, the prerequisite status is not met, or the manual personnel status is in processing. Transferred to Manual Personnel occurs when the acceptance relationship is transferred and the manual personnel status is pending acceptance or the customer stage requires manual confirmation. Terminated Task occurs when the activity is terminated, the customer stage has terminated, the preferential rights have been revoked, and there are no subsequent available rights. Alternative Closure occurs when the acceptance relationship is alternative and the preferential rights or customer stage have achieved the existing task completion objective. Supplementary Confirmation occurs when necessary verification fields are missing but can still be supplemented through the business system. The scheduling and handling result does not include the actual sent content, execution channel call instructions, or execution time arrangements.

[0100] The version of the scheduling verification rules is locked before this step begins. The content includes the field source, confirmation interval, frequency limit, default value of silent period, rights status adaptation relationship, activity period adaptation relationship, customer stage adaptation relationship, manual occupation status adaptation relationship and disposal priority order of each verification item. The scheduling disposal results that have been formed shall not be directly overwritten by the new version. If correction is necessary, the result before correction, the result after correction, the reason for correction, the correction time and the source of operation shall be saved by adding correction records.

[0101] The dispatch and handling results are stored in the dispatch and handling record area of ​​the marketing platform with customer identifier and candidate pool batch identifier. Each record includes at least the customer identifier, candidate task number, acceptance relationship type, contact frequency verification conclusion, silent period verification conclusion, preferential rights verification conclusion, activity period verification conclusion, customer stage verification conclusion, manual occupancy status verification conclusion, dispatch and handling result, dispatch verification rule version, and result formation time. The next step reads the dispatch and handling results according to the customer identifier and candidate task number and executes the corresponding marketing task. This step does not call SMS, WeChat Work, outbound calls, or manual agent execution terminals.

[0102] When performing duplicate verifications, the customer identifier, candidate task number, undertaking relationship record number, and scheduling verification rule version are used as idempotent criteria. Existing scheduling and handling results are not written repeatedly; only new verification sources are added to the record. When the customer identifier, candidate task number, undertaking relationship record number, or scheduling verification rule version is missing, the result is entered into the pending record. When the same candidate task generates more than two mutually exclusive scheduling and handling results under the same rule version, the result is entered into the pending verification.

[0103] The security boundary is limited to the status fields, rights status, activity status, and manual occupation status accessed in this step. Plain text customer numbers and original session content are not written into the dispatch and handling record. On-site spot checks can be conducted by batch to extract dispatch and handling results and verify whether each verification conclusion can be traced back to the acceptance relationship record, candidate task record, and customer-level task status ledger, and whether the dispatch and handling results comply with the version of the dispatch verification rules.

[0104] Preferably, the frequency confirmation interval can be set to 24 hours before the current verification time, the upper limit of the frequency of contacting a single customer through the same contact channel can be set to 3 times, the default effective duration of the silent period can be set to 72 hours, the activity period is based on the registration time of the activity management system, the verification delay of a single customer in a single candidate pool can be set to no more than 10 seconds, and each batch of random checks should include no less than 100 scheduling and handling results with a consistency rate of no less than 98%; for example, if the candidate task of customer number C20260518001 is a rights and benefits usage reminder, the undertaking relationship is a continuation relationship, there has been one outbound call contact in the ledger within 24 hours, the preferential rights and benefits status is "claimed", the activity is in effect, the customer stage is "progressing", and the manual occupation status is "not occupied", then a scheduling and handling result of continued execution is formed; if the same customer has a 72-hour silent period, then a scheduling and handling result of suspension and waiting is formed.

[0105] Alternatively, if the enterprise customer relationship management system already has the ability to verify rules and temporarily store processing results, the scheduling and processing results can be stored in the processing record area of ​​the customer relationship management system. The marketing platform only saves the customer identifier, candidate task number and processing record index location, but the frequency of contact, silent period, preferential rights, activity period, customer stage, manual occupation status verification criteria and scheduling and processing result values ​​remain consistent.

[0106] S6. Execute marketing tasks according to the scheduling and handling results, and write the task execution status, customer response status, and task change status back to the customer-level task status ledger as the basis for subsequent scenario scheduling. The specific implementation is as follows: After obtaining the dispatch and handling results, marketing digital staff will execute the corresponding marketing tasks according to the dispatch and handling results, and write back the task execution status, customer response status, and task change status to the customer-level task status ledger. The executing entity can be located on the task execution access side of the enterprise marketing platform, and the on-site sources can be the dispatch and handling record area, SMS platform, enterprise WeChat outreach system, mini-program in-site messaging system, telephone outbound system, human agent workbench, customer relationship management system, preferential rights system, and work order system. The dispatch and handling results are the structured result records formed in the previous step. This step only reads the customer identifier, candidate task number, undertaking relationship type, dispatch and handling result, dispatch verification rule version, and result formation time, and does not re-verify the outreach frequency, silence period, preferential rights, activity period, customer stage, and human occupancy status.

[0107] When executing marketing tasks based on the dispatch and handling results, first confirm whether the dispatch and handling result is an executable action; if the dispatch and handling result is to continue execution or merge execution, submit a marketing task execution request to the corresponding outreach system according to the contact point source corresponding to the candidate task; if the dispatch and handling result is to transfer to human agents, submit a transfer record to the human agent workbench or work order system; if the dispatch and handling result is to suspend and wait, only a suspension status record is generated and the suspension reason is retained, without calling external outreach systems; if the dispatch and handling result is to terminate the task or replace the closure, only a task closure or replacement completion record is generated, without generating new customer proactive outreach; if the dispatch and handling result is to supplement confirmation, submit supplementary confirmation items to the customer relationship management system, preferential benefits system, activity management system, or human agent workbench.

[0108] All the above actions are based on the results already determined in the scheduling and handling results. The on-site operators shall not temporarily change the scheduling and handling results in this step. If the scheduling and handling record is missing the customer identifier, candidate task number, scheduling and handling result, or result formation time, the execution will be stopped and transferred to the pending supplementation stage. If there are more than two mutually exclusive scheduling and handling results for the same candidate task number under the same rule version, the process will be transferred to the pending verification stage.

[0109] Marketing tasks are the actual tasks submitted to the execution end based on the scheduling and handling results. The recording unit is "item". Each marketing task corresponds to at least 1 customer identifier, 1 candidate task number and 1 handling type. Continued execution corresponds to the task action of continuing to advance the original marketing goal. Combined execution corresponds to the task action of combining candidate tasks that can be merged at the same touchpoint into a single outreach task action. Transfer to manual processing corresponds to the task action of manual acceptance. Suspended waiting corresponds to the task action of waiting to resume. Terminated task and alternative closure correspond to the task action of closure. Supplementary confirmation corresponds to the task action of field confirmation.

[0110] The task execution status represents the execution fact formed by the execution end or marketing platform after the marketing task is submitted. Values ​​include not executed, submitted, successful execution, failed execution, executed cancellation, and execution timeout. The task execution status only indicates whether the marketing task has been received, submitted, completed, or returned as a failure by the execution end; it does not indicate whether the customer has achieved their marketing goals. Whether the customer has achieved their marketing goals is recorded jointly by the customer response status and the task change status. The task execution status only corresponds to the execution fact after the marketing task is executed according to the scheduling results in this step. The system execution status refers to the business system execution status already recorded in the previous customer-level task status ledger. The two are recorded separately according to the stage of occurrence and do not substitute for each other. Successful execution is recorded when the SMS platform returns "sent successfully," the WeChat system returns "message submitted successfully," the mini-program in-site message returns "delivery successfully," the outbound call system returns "dialing completed," or the work order system returns "work order generated successfully." Execution is considered successful when the execution end returns "rejection" or an invalid customer identifier. When a contact point is unreachable or a work order generation fails, it is recorded as an execution failure. When the execution end does not return a success, failure, or cancellation result within the execution confirmation period, it is recorded as an execution timeout. The execution status of a suspended waiting task is recorded as not executed, and the reason for not executing is recorded as suspended waiting. The execution status of a terminated task or a substitute closure task is recorded as successful, and the execution source is recorded as an internal status record. For internal status records formed by suspended waiting, terminated tasks, and substitute closure, the execution end source record number can be generated by the marketing platform. This internal source record number is bound to the scheduling and handling result number and is not considered as a missing field. Supplementary confirmation is recorded as successful when the supplementary confirmation is received by the target system. It is recorded as a failure when the target system rejects it or returns a field that cannot be supplemented. It is recorded as an execution timeout when no receiving result is returned after the execution confirmation period. Supplementary confirmation does not directly change the customer response status unless the supplementary confirmation subsequently forms a customer action record.

[0111] Customer response status refers to the recordable response facts generated by customers after the execution of marketing tasks. These responses originate from WeChat replies, mini-program clicks, SMS unsubscriptions, phone call results, agent notes, and records of rights redemption or verification. Values ​​include no response, responded, rejected, unsubscribed, completed action, and requires manual processing. Customer response status is based on records that are linked to the same customer identifier and candidate task number after the task execution time, and is not replaced by historical records before execution. If a customer's response is merely polite and does not constitute a business action, rejection, unsubscription, or manual request, it is recorded as a response, and the source record index is retained, without directly changing the task completion result. When more than two customer response records appear for the same candidate task within the customer response observation period, the current customer response status is determined according to the priority order: requires manual processing, unsubscribed, rejected, completed action, responded, and no response, while retaining the source index of all customer response records. If a customer response record lacks a customer identifier or cannot be linked to a candidate task number, it enters the pending verification or supplementary entry stage and is not automatically merged into the task.

[0112] The task change status refers to the status change of the corresponding task in the customer-level task status ledger caused by this execution and customer response. Values ​​include: Hold, Progress, Suspended, Transfer to Human, Closed, Canceled, and Pending Entry. When the customer response status is "Completed Action," the task change status is recorded as "Progress" or "Closed," with "Closed" only recorded when the marketing goal status reaches "Completed," and "Progressed" when it hasn't. When the customer response status is "Rejected" or "Unsubscribed," the task change status is recorded as "Closed." When the customer response status requires human intervention, the task change status is recorded as "Transferred to Human." When the customer response status is "No Response" and the task execution status is "Execution Successful," the task change status is recorded as "Hold." "Suspended" corresponds to "Suspended," "Transferred to Human" corresponds to "Transferred to Human," "Terminated Task" and "Alternative Closure" correspond to "Closed," and "Execution Canceled" corresponds to "Canceled." When the task execution status is "Execution Failed" or "Execution Timeout," the task change status... The status is recorded as pending entry or retained, and is determined by the scope of failures that can be supplemented registered in the execution rule version. The scope of failures that can be supplemented is locked by the execution rule version and includes at least the following: the touchpoint is unreachable but other authorized touchpoints exist; the rights field is missing but the rights system allows for supplementation; and the work order field is missing but the agent's workbench allows for supplementation. When the execution end clearly returns a customer unsubscribe, customer refuses, activity terminates, or rights are revoked, it is not recorded as pending entry, but is recorded according to the corresponding customer response status or task change status. Mutually exclusive task change statuses include the same candidate task being simultaneously promoted and closed, suspended and closed, transferred to human and canceled, and closed and canceled. If the mutually exclusive statuses come from different execution end receipts, all mutually exclusive sources are retained and transferred to pending verification. The task change status only changes the status associated with the corresponding candidate task number, marketing target identifier, and source record number in the ledger, and does not cover the task status of other marketing targets under the same customer.

[0113] When writing back to the customer-level task status ledger, the task execution status is written first, followed by the customer response status, and finally the task change status. This order only indicates the order of writing and does not change the actual occurrence time of the execution end and the customer's response. Each write-back must include at least the customer identifier, candidate task number, marketing target identifier, scheduling and handling result number, task execution status, customer response status, task change status, status occurrence time, source system, source record number, execution rule version, and write-back time. When writing back the same candidate task repeatedly, the customer identifier, candidate task number, scheduling and handling result number, execution end source record number, and execution rule version are used as idempotent criteria. Statuses that have already been written are not overwritten, but only new source traces are added. If the execution end subsequently returns a more accurate execution result, the status before correction, the status after correction, the reason for correction, the correction time, and the source system are saved by adding a correction record, and the original status is not directly deleted.

[0114] After the write-back status is completed, it will only be a new status record in the customer-level task status ledger and will be read by subsequent scenarios. Whether a candidate marketing task pool is formed in subsequent scenarios will still be determined by the current scenario trigger information when the customer enters the subsequent scenario, the unfinished tasks in the task status ledger, and the conditions derived from historical tasks. No new candidate marketing task pool, succession relationship, or scheduling result will be formed in advance in this step.

[0115] The security boundary is limited to the customer identifier, execution status, response status, and source record index accessed in this step. The customer number in plaintext, the complete original chat text, and sensitive business notes are not written to the customer-level task status ledger; only the anonymized identifier, status value, time, source index, and execution end return summary are saved when necessary.

[0116] If the execution end is unavailable, the execution confirmation period expires, the customer response cannot be associated with the candidate task, or the same task forms a mutually exclusive task change status, the corresponding record will be put into pending verification; if the customer identifier, candidate task number, status occurrence time, or execution rule version is missing, it will be put into pending supplementation, without blocking the execution and write-back of other customer tasks in the same batch.

[0117] The execution rule version differs from the scheduling verification rule version. The execution rule version only defines the execution action, execution confirmation deadline, status value, and write-back criteria corresponding to each scheduling action result in this step. The execution rule version is locked before the start of this step and includes the execution action, execution confirmation deadline, task execution status value, customer response status value, task change status value, scope of failure recovery, write-back order, and correction record criteria corresponding to each scheduling action result. The already written-back ledger status must not be directly overwritten by the new version.

[0118] Preferably, the execution confirmation period for continued execution and merged execution can be set to 30 seconds, the manual confirmation period for transfer can be set to 60 seconds, the customer response observation period can be set to 24 hours after task execution, and the status write-back delay for a single customer and a single candidate task can be set to no more than 10 seconds. Each batch of random checks should include no less than 100 write-back records and the status traceability consistency rate should be no less than 98%. For example, the scheduling and handling result for customer number C20260518001 is continued execution. The marketing digital employee submits a rights usage reminder to the enterprise WeChat outreach system. The execution end returns a successful submission within 3 seconds, and the task execution status in the ledger is recorded as successful execution. The customer clicks the verification entry 20 minutes later, and the customer response status is recorded as completed action. If the marketing goal has not yet been achieved, the task change status is recorded as progress. These three statuses serve as the scheduling basis when the customer enters the after-sales follow-up scenario.

[0119] Alternatively, if the enterprise customer relationship management system already has the ability to execute tasks and write back status, the customer relationship management system can complete the execution of marketing tasks and write back the ledger status. The marketing middle platform only saves the execution index and status index, but the value caliber, write-back order, idempotency basis and version locking caliber of task execution status, customer response status and task change status are consistent.

[0120] In the operational scenario shown in this embodiment: During a "new product trial conversion" campaign, a company integrates online customer service, WeChat Work, mini-program activity pages, outbound calling system, preferential benefits system, customer relationship management system, and work order system into its marketing platform. Marketing digital staff then perform cross-scenario task scheduling for the continuous behavior of the same customer across multiple marketing touchpoints. Customer C20260518001 clicks on the new product trial entry and claims preferential benefits through the mini-program activity page at 10:02:15. The mini-program activity page generates a customer identifier, touchpoint source, scenario type, interaction time, source record number, and preferential claim record. The preferential benefits system simultaneously generates a successful claim receipt. During the processing time, the marketing digital staff extracts the cross-scenario interaction record generated by the customer's click and the system execution record generated by the preferential benefits system, and groups them together according to the customer ID in the customer relationship management system. This record is marked as a preferential benefits scenario and written into the cross-scenario interaction sequence according to the interaction time of 10:02:15. Subsequently, at 10:07:40, the customer inquired via WeChat Work about "how to use this offer." The WeChat Work touchpoint generated a customer inquiry record, which was categorized into the aforementioned customer's cross-scenario interaction sequence under the same customer identifier, with the scenario type labeled as an inquiry scenario. At 10:16:08, the outbound calling system generated an outbound call task based on previous activity leads, but the call was unanswered. The outbound calling system generated a system execution record, which was written into the cross-scenario interaction sequence as a lead follow-up scenario. Thus, the customer's cross-scenario interaction sequence is formed in the chronological order of: 10:02:15 offer claim, 10:07:40 WeChat Work inquiry, and 10:16:08 unanswered outbound call. Each record in the sequence retains the customer identifier, scenario type, interaction time, record category, source record number, and organization rule version.

[0121] Marketing digital staff establish a customer-level task status ledger based on this cross-scenario interaction sequence. For the discount claim record at 10:02:15, the ledger shows the marketing goal status as "triggered," the discount benefit status as "claimed," and the system execution status as "executed successfully." For the WeChat inquiry record at 10:07:40, the ledger records the fact that the customer inquired about the discount usage and marks the task stage as "pending follow-up." For the outbound call failure record at 10:16:08, the ledger shows one contact record, the system execution status as "execution failed," and retains the original outbound call system result as "failed" in the source record index. Since this customer has not yet generated a transaction, redemption completion, activity closure, or customer explicit refusal record, the corresponding marketing goal in the customer-level task status ledger is not yet in a completed or terminated state, and the task stage is not yet in a closed state. Therefore, this ledger can be read by subsequent scenarios.

[0122] At 10:20:00, the customer re-entered the WeChat Work consultation scenario and sent the message "Can the coupon still be used today?" The marketing digital staff read the trigger information of this current scenario, confirming that the customer identifier, current scenario type, trigger time, source record number, and associated marketing target identifier all existed. They then read the customer's customer-level task status ledger. Since the ledger contained incomplete tasks awaiting follow-up, claimed discount statuses, and outbound call execution failure records, the marketing digital staff created a candidate marketing task pool: First, candidate tasks for the current scenario were created based on this WeChat Work consultation; second, candidate tasks for the ledger were created based on tasks awaiting follow-up; third, derivative candidate tasks for benefit usage reminders were created based on the historical task derivative condition of "discount status is claimed and task stage is awaiting follow-up." All three candidate tasks recorded the customer identifier, current scenario type, marketing target identifier, candidate task source, task stage, trigger time, source record number, reason for candidate formation, ledger rule version, and candidate pool generation time, and the execution channel or execution order was not determined in this step.

[0123] Subsequently, marketing digital staff compared the candidate tasks in the candidate marketing task pool with the existing tasks in the task status ledger. For candidate tasks related to benefit usage reminders, the task status ledger already has records of claimed benefits and tasks awaiting follow-up. Furthermore, the candidate task's trigger time is later than the interaction time of the existing task, the customer identifier and marketing target identifier are consistent, and the existing task is not closed. Therefore, this candidate task forms a continuation relationship with the existing task awaiting follow-up. Simultaneously, since the benefit status corresponding to this candidate task is already claimed, and there is no need to execute the benefit claim reminder again, this candidate task can also form a substitution relationship with the original benefit claim reminder purpose. However, within the same task pair, only the primary relationship is retained according to the priority order set in the version of the acceptance rules, and the secondary relationship is recorded as the basis for relationship formation. If there are also outbound call proactive outreach tasks within the same confirmation interval, and outbound calls and WeChat notifications are mutually exclusive outreach methods registered in the version of the acceptance rules, then this candidate task can also form a conflict relationship with the corresponding existing outreach task. This is used in the subsequent verification stage to determine whether to suspend or avoid duplicate outreach.

[0124] After obtaining the task assignment records, marketing digital staff conduct business verification on candidate tasks. The system reads the contact records in the customer-level task status ledger to confirm that the customer has been contacted by outbound phone once within 24 hours before the current verification time, which does not reach the frequency limit of the same contact channel; it reads the customer relationship management system and task status ledger to confirm that the customer is not in a dormant period and there are no records of unsubscription, complaint processing, or agent registration not to contact; it reads the benefits system to confirm that the benefits are claimed and not yet used; it reads the activity management system to confirm that the activity is in effect; it reads the customer relationship management system to confirm that the customer stage is in progress; and it reads the agent workbench and work order system to confirm that the agent occupancy status is not occupied. Since the candidate task corresponds to a continuation relationship, and the frequency of contact, the silent period, preferential benefits, the activity period, the customer stage, and the manual occupancy status have not prevented execution, the marketing digital staff formed a scheduling and disposal result of "continuation execution", and wrote the verification conclusions of the frequency of contact, the silent period, the preferential benefits, the activity period, the customer stage, the manual occupancy status, and the scheduling verification rule version into the scheduling and disposal record area.

[0125] Marketing digital staff execute marketing tasks according to the "continued execution" scheduling results, submitting a reminder task for the use of benefits to the WeChat Work outreach system, reminding customers that the preferential benefits are still available within the activity period, and guiding customers to the redemption portal. The WeChat Work outreach system returns a message indicating successful submission within 3 seconds, and the marketing digital staff records the task execution status as successful. Twenty minutes later, the customer clicks the redemption portal in the WeChat Work message and enters the mini-program to complete the redemption action. The mini-program and the preferential benefits system respectively generate customer click records and benefit redemption records. The marketing digital staff records the customer's response status as completed within the customer response observation period.

[0126] Since the customer's marketing goal has not yet reached the final completed state, but has progressed from discount redemption to benefit redemption, the task change status is recorded as "progressing." Finally, the marketing digital staff writes these three statuses back to the customer-level task status ledger in the order of task execution status, customer response status, and task change status, retaining the customer identifier, candidate task number, marketing goal identifier, scheduling and handling result number, status occurrence time, source system, source record number, execution rule version, and write-back time. This write-back result serves as the basis for subsequent scenario scheduling. When the customer subsequently enters the after-sales follow-up scenario, the marketing digital staff can read the status records showing that the customer has completed the benefit redemption action, the previous successful execution of the WeChat outreach, and that the current task stage has progressed. This avoids sending the same discount redemption reminder again and allows the subsequent task to be transferred to the candidate task formation process for subsequent marketing scenarios such as user feedback, repeat purchase guidance, or manual follow-up.

[0127] Example 2: A cross-scenario task scheduling system for marketing digital employees, comprising: The cross-scenario sequence formation module is used to obtain cross-scenario interaction records and system execution records of the same customer at various marketing touchpoints, and form cross-scenario interaction sequences according to customer identifier, scenario type, and interaction time. The customer-level ledger creation module is used to create a customer-level task status ledger based on cross-scenario interaction sequences, and record marketing goal status, task stage, reach records, preferential rights status, manual acceptance status, and system execution status. The candidate task pool formation module is used to form a candidate marketing task pool when a customer enters the current marketing scenario, based on the current scenario trigger information, unfinished tasks in the customer-level task status ledger, and historical task derivative conditions. The task assignment module is used to compare the candidate tasks in the candidate marketing task pool with the existing tasks in the customer-level task status ledger, and to determine the continuation, substitution, merging, conflict, dependency and reassignment relationships. The scheduling and handling module is used to verify the frequency of contact, quiet period, preferential rights, activity period, customer stage and manual occupancy status of candidate tasks according to the undertaking relationship, and generate scheduling and handling results; The task execution write-back module is used to execute marketing tasks according to the scheduling and handling results, and write back the task execution status, customer response status and task change status to the customer-level task status ledger as the basis for subsequent scenario scheduling.

[0128] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0129] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0130] The above embodiments can be implemented, in whole or in part, by software, hardware, 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 this application 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 wireless or wired transmission; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. 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 containing 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.

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

[0132] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, 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 apparatuses or modules may be electrical, mechanical, or other forms.

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

[0134] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0135] If the aforementioned functions are implemented as software functional modules 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 application, in essence, 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 application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] 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.

[0137] In conclusion, the above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cross-scenario task scheduling method for marketing digital employees, characterized in that, include: S1. Obtain cross-scenario interaction records and system execution records of the same customer across various marketing touchpoints, and form a cross-scenario interaction sequence according to customer identifier, scenario type, and interaction time; S2. Establish a customer-level task status ledger based on cross-scenario interaction sequences to record marketing goal status, task stage, reach records, preferential rights status, manual acceptance status, and system execution status. S3. When a customer enters the current marketing scenario, a pool of candidate marketing tasks is formed based on the current scenario trigger information, unfinished tasks in the customer-level task status ledger, and historical task derivative conditions. S4. Compare the candidate tasks in the candidate marketing task pool with the existing tasks in the customer-level task status ledger to determine the continuation, substitution, merging, conflict, dependency and reassignment relationships. S5. Based on the relationship of undertaking, the candidate tasks are checked for contact frequency, silent period, preferential rights, activity period, customer stage, and manual occupation status to form a scheduling and handling result; S6. Execute marketing tasks according to the scheduling and handling results, and write back the task execution status, customer response status, and task change status to the customer-level task status ledger as the basis for subsequent scenario scheduling.

2. The cross-scenario task scheduling method for marketing digital employees according to claim 1, characterized in that, S1 includes: When forming a cross-scenario interaction sequence, the customer ID from the customer relationship management system is used as the primary customer identifier. Use the member number, the anonymized mobile phone number, the external contact number of the WeChat Work account, the open identifier of the mini program, and the anonymized outbound call number as the association identifier; When an associated identifier has a binding record and that binding record points to only one primary customer identifier, the corresponding record will be assigned to that primary customer identifier. Collect cross-scenario interaction records and system execution records according to customer identifiers; Determine the scenario type based on the source system fields and the version of the organization rules; The interaction sequence is formed in ascending order of interaction time, creating a cross-scene interaction sequence.

3. The cross-scenario task scheduling method for marketing digital employees according to claim 1, characterized in that, S2 include: When establishing a customer-level task status ledger, read the cross-scenario interaction sequence according to the customer identifier; Write the basic records in ascending order of interaction time; The marketing objective status is determined based on the marketing objective identifier; Task stages are formed based on the location of task actions under the same marketing objective; Based on the record category and source record number, the system generates contact records, preferential rights status, manual acceptance status, and system execution status. The marketing goal status, task stage, reach record, preferential rights status, manual acceptance status, and system execution status are associated and stored with the ledger rule version.

4. The cross-scenario task scheduling method for marketing digital employees according to claim 1, characterized in that, S3 includes: When forming a candidate marketing task pool, read the current scenario trigger information after the customer enters the current marketing scenario; The current scenario trigger time is used as the effective boundary for reading the client-level task status ledger; Generate candidate tasks for the current scenario based on the trigger information of the current scenario; Candidate tasks are generated from the incomplete tasks in the customer-level task status ledger. Derivative candidate tasks are generated based on the state combinations in the client-level task status ledger and the historical task-derived conditions. Write the candidate marketing task into the candidate marketing task pool in the order of current scenario candidate task, ledger candidate task, and derivative candidate task.

5. A cross-scenario task scheduling method for marketing digital employees according to claim 1, characterized in that, S4 include: When performing task acceptance comparison, the customer-level task status ledger of a single customer is locked according to the customer identifier; Select existing tasks under the same marketing objective based on the marketing objective identifier; Combine candidate tasks with existing tasks to form task pairs; Based on the current scenario type, task stage, reach record, preferential rights status, manual acceptance status, system execution status, trigger time, and source record number, the acceptance comparison is performed to form an acceptance relationship record.

6. A cross-scenario task scheduling method for marketing digital employees according to claim 5, characterized in that, S4 also includes: When the same task satisfies multiple succession relationships, the primary succession relationship shall be determined in the order of dispatch relationship, conflict relationship, dependency relationship, substitution relationship, merger relationship, and continuation relationship. The covered successor relationship will be recorded as evidence of the relationship formation. Write the primary successor relationship as the successor relationship type in the successor relationship record.

7. A cross-scenario task scheduling method for marketing digital employees according to claim 1, characterized in that, S5 include: When generating scheduling and handling results, the verification criteria for candidate tasks are determined according to the type of undertaking relationship; Verify the frequency of contact, silence period, preferential benefits, activity period, customer stage, and manual occupancy status of candidate tasks; The scheduling and handling results are formed based on the verification conclusions of contact frequency, silent period, preferential rights, activity period, customer stage and manual occupancy status, as well as the handling priority order in the scheduling verification rule version; The scheduling and handling results are associated with the candidate task number, the type of undertaking relationship, and the version of the scheduling verification rule and stored together.

8. A cross-scenario task scheduling method for marketing digital employees according to claim 1, characterized in that, S6 include: When executing marketing tasks, determine the corresponding task actions based on the scheduling and handling results; The task execution status is determined by recording the internal status corresponding to the results returned by the execution end and the scheduling and handling results. Customer response status is generated based on customer response records after the marketing task is executed; The task change status is generated based on the task execution status and the customer response status. Write back to the customer-level task status ledger in the order of task execution status, customer response status, and task change status.

9. A cross-scenario task scheduling system for marketing digital employees, used to implement the cross-scenario task scheduling method for marketing digital employees as described in any one of claims 1-8, characterized in that, include: The cross-scenario sequence formation module is used to obtain cross-scenario interaction records and system execution records of the same customer at various marketing touchpoints, and form cross-scenario interaction sequences according to customer identifier, scenario type, and interaction time. The customer-level ledger creation module is used to create a customer-level task status ledger based on cross-scenario interaction sequences, and record marketing goal status, task stage, reach records, preferential rights status, manual acceptance status, and system execution status. The candidate task pool formation module is used to form a candidate marketing task pool when a customer enters the current marketing scenario, based on the current scenario trigger information, unfinished tasks in the customer-level task status ledger, and historical task derivative conditions. The task assignment module is used to compare the candidate tasks in the candidate marketing task pool with the existing tasks in the customer-level task status ledger, and to determine the continuation, substitution, merging, conflict, dependency and reassignment relationships. The scheduling and handling module is used to verify the frequency of contact, quiet period, preferential rights, activity period, customer stage and manual occupancy status of candidate tasks according to the undertaking relationship, and generate scheduling and handling results; The task execution write-back module is used to execute marketing tasks according to the scheduling and handling results, and write back the task execution status, customer response status and task change status to the customer-level task status ledger as the basis for subsequent scenario scheduling.

Images