Discrete customer service record evidence storage and active tracing CRM system

Abstract

The invention discloses a discrete customer service record evidence storage and active tracing CRM system, and relates to the technical field of customer relationship management, and the system comprises a client discrete evidence storage module, a block chain evidence storage module, a block chain core module, an intelligent contract management module, an active tracing module, and an application service module. A complete service evidence chain which is high in credibility and easy to verify is constructed through discretization event chaining and chained hash linking, so that the problems that centralized records are easy to tamper and the tracing efficiency is low are solved, the generation and storage normal forms of the service records are changed, and the tracing efficiency is improved. Continuous service interaction is deconstructed into standardized service atomic events through a client discrete evidence storage module, each event is packaged into an event evidence storage packet containing a previous evidence storage packet hash through a block chain evidence storage module, and the event evidence storage packet is stored in a block chain core module in sequence, so that the content of each event is recorded in a tampering-free manner; any single-party modification can destroy the hash value on the chain, so that each recording node is endowed with evidence storage efficacy.

Description

Technical Field

[0001] This invention relates to the field of customer relationship management technology, specifically to a discrete customer service record storage and proactive traceability CRM system. Background Technology

[0002] Customer Relationship Management (CRM) systems are core tools for enterprises to manage customer interactions, and one of their core functions is recording service processes. Traditional systems generally use centralized database storage services to record communication content, solutions, and commitments in the form of work orders or continuous logs. This model is increasingly facing challenges in service traceability, clarification of responsibilities, and risk management. Especially when service disputes or internal audits occur, the authenticity, completeness, and verifiability of the records become critical bottlenecks. The shortcomings of existing technologies are mainly reflected in the following aspects: First, centralized storage of continuous records is technically susceptible to unilateral and traceless tampering, resulting in insufficient credibility and acceptance as evidence. Furthermore, the records exist in the form of continuous text streams, with coarse information granularity, making it difficult to accurately anchor and extract key decision-making nodes, commitment moments, or responsibility transfer moments in the service process. This leads to a significant amount of manpower required to sort through lengthy records when tracing back, resulting in low efficiency.

[0003] Secondly, the system's functions are limited to passive queries and post-event access, lacking a mechanism to automatically and proactively initiate notifications, warnings, or launch subsequent processes at critical moments such as when commitments expire, problems recur, or related events are triggered, resulting in lagging service management.

[0004] Finally, when a single service involves cross-departmental and multi-role collaboration, the records of each party are scattered in different systems or documents, making it difficult to form a unified chain of evidence with clear responsibilities, reliable timing, and non-repudiation around the same service event, which brings difficulties to internal collaboration and responsibility definition.

[0005] Therefore, existing CRM systems have significant limitations in terms of the reliability of service record storage, the accuracy of traceability, and the integrity of collaborative evidence chains. There is an urgent need for an innovative solution that can reliably solidify key points of the service process into tamper-proof evidence, and intelligently drive service processes based on this evidence, thereby achieving a paradigm shift from reactive post-event retrospective to proactive pre-event and in-event management. Summary of the Invention

[0006] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a discrete customer service record storage and proactive traceability CRM system. This system constructs a highly reliable, granular, and easily verifiable complete service evidence chain through discrete event on-chaining and chained hash links. This fundamentally solves the problems of centralized records being easily tampered with and having low traceability efficiency, changing the paradigm of service record generation and storage. Through the client-side discrete evidence storage module, continuous service interactions are deconstructed into standardized, semantically clear service atomic events. Each event is encapsulated by the blockchain evidence storage module into an event evidence package containing the hash of the previous evidence package, and stored sequentially in the blockchain core module. This mechanism ensures that the key content of each event is recorded in a distributed and immutable manner; any unilateral modification will destroy the hash value on the chain, thus giving each record node evidence validity. Simultaneously, through the hash field of the previous evidence package, the system tightly connects all discrete events under the same service request logically and temporally, forming a complete and rapidly verifiable service evidence chain.

[0007] To solve the above-mentioned technical problems, this invention provides the following technical solution: a discrete customer service record storage and proactive traceability CRM system, the components of which include: The client-side discrete evidence storage module is used to identify and generate standardized service atomic events during customer service interactions. The blockchain evidence storage module is used to receive the service atomic events, encapsulate them into event evidence storage packages with chain-like relationships, and send the event evidence storage packages to the blockchain core layer. The blockchain core module is used to store event evidence packages from the blockchain evidence storage module in the form of a distributed ledger, making the event evidence storage immutable. The smart contract management module is used to deploy and execute one or more smart contracts. The smart contracts are configured to listen to event storage packages of a preset type on the blockchain core module and automatically generate traceability tasks when preset business rules are met. The proactive tracing module is used to receive and execute the tracing task, the execution of which includes triggering internal notifications, customer outreach, internal process advancement, and generating new service atomic events; The application service module provides a human-computer interaction interface and an evidence traceability query interface, allowing users to query a service evidence chain view consisting of multiple event evidence packages.

[0008] Furthermore, the service atomic event generated by the client discrete evidence storage module is a set of standardized data units with a predefined data structure, which includes the following elements: event unique identifier, associated main service request identifier, event type, event timestamp, responsible entity identifier, event content summary, and detailed data fingerprint. The event type is selected from a predefined set of event types, which includes: customer commitment, solution provision, internal responsibility assignment, service node completion, external dependency notification, and customer feedback reception.

[0009] Furthermore, when generating the service atomic event, the client-side discrete evidence storage module also performs event feature value calculation to calculate an event feature value for each service atomic event, quantifying its importance and urgency. This event feature value is referenced by the smart contract management module. The event feature value calculation steps are as follows: Obtain calculation parameters, including event type importance coefficients. Historical weight of responsible entities Keyness of the commitment content The importance coefficient of the event type Based on the event type in the service atomic events, the historical weight of the responsible entity is obtained by querying the fixed importance coefficients pre-configured by the system and bound to each event type. Based on the responsible entity identifier in the current service atomic event, retrieve all completed service records of that responsible entity within a preset historical period from the system's historical database, calculate its historical performance success rate and average task processing time, and substitute them into... Calculations are performed, in which, To ensure the historical success rate of fulfilling contracts, This represents the average processing time for the task. The system's preset standard processing time, and The weighting adjustment factor represents the keyness of the committed content. Natural language processing is performed on the summary text of the event content in the atomic service event to extract keywords and compare them with the key item database preset by the system. The keywords are then assigned values ​​based on the probability of the matched key items. Substitute the obtained calculation parameters into The calculated final event feature values, where, This represents the final event feature value calculated. A pre-set weighting coefficient for the system, used to balance the importance coefficient of event type, the historical weight of responsible party, and the criticality of commitment content; The calculated event feature values It is stored and transmitted as an additional field of the service atomic event.

[0010] Furthermore, the event evidence package encapsulated by the blockchain evidence storage module is an enhanced data package formed by adding the hash value of the previous evidence package and the digital signature of the submitter to the service atomic event; the hash value of the previous evidence package points to the last successfully stored event evidence package in the current service process, thereby forming a time-sequential and tamper-proof evidence chain on the blockchain core module for all event evidence packages under the same main service request identifier.

[0011] Furthermore, the smart contract in the smart contract management module includes: a condition monitoring unit, a rule logic unit, and a task triggering unit; The condition monitoring unit is configured to continuously scan the blockchain core module to monitor whether the event type in the newly added event storage package matches the monitoring type preset by the contract. The rule logic unit includes programmable business judgment logic. When the condition monitoring unit captures a matching event storage package, the rule logic unit parses the event content summary in the event storage package and, in conjunction with the external data source, determines whether the triggering conditions are met. The task triggering unit is activated when the rule logic unit determines that the triggering condition is met, generates a structured tracing task, and sends the tracing task to the task queue of the active tracing module.

[0012] Furthermore, when the rule logic unit executes business judgment logic, if multiple service atomic events simultaneously meet the initial triggering conditions, it determines the order in which the traceability task is generated by performing dynamic priority evaluation. The steps of the dynamic priority evaluation are as follows: The event feature value is directly read from the event storage package corresponding to the service atomic event that has met the initial triggering conditions and is to be evaluated. ; The smart contract reads and calculates system business metrics in real time, including the total number of traceability tasks currently in the pending state. Average wait time of service queues related to the current service atomic event After standardizing the system's business metrics, a weighted sum is calculated: ,in, and This is the maximum baseline value preset by the system for standardizing indicators. and These are the weighting coefficients; Parse the task processing deadline contained in the event storage package corresponding to the currently evaluated service atomic event. And combined with the current system time Calculate the remaining time margin ,when At that time, the system's preset positive minimum constant will be used. As value; Based on the calculated event characteristic values System state coefficients Remaining time margin Calculate priority evaluation value ; The rule logic unit of the smart contract calculates the dynamic priority scores of all service atomic events. The tasks are sorted in descending order and activated sequentially to generate and send traceability tasks of corresponding priorities.

[0013] Furthermore, the tracing task executed by the active tracing module is an instruction set that includes a task identifier, a source event evidence package identifier, a task type, a target object, execution content, an expected deadline, and a priority evaluation value. The proactive tracing engine invokes different execution units based on the task type. These execution units include: an internal notification execution unit, a customer outreach execution unit, a process advancement execution unit, and a new event generation unit.

[0014] Furthermore, when the new event generation unit creates a new service record based on the execution content of the tracing task, the new event generation unit is invoked, takes the execution result of the tracing task as input, constructs a new service atomic event with the event type of tracing action execution, and stores it through the blockchain evidence storage module and the blockchain core module, thereby incorporating the active tracing behavior itself into the tamper-proof evidence chain.

[0015] Furthermore, the workflow of the evidence storage traceability query interface provided by the application service module includes: Receives a main service request identifier from user input; Initiate a query to the blockchain core module to obtain all event storage packets associated with the main service request identifier; Based on the timestamp in each event evidence package and the hash value of the previous evidence package, a complete and chronologically correct chain of evidence can be reconstructed. The service evidence chain view is presented in the form of a timeline in the visualization interface, with each node in the view corresponding to an event evidence package.

[0016] Compared with existing technologies, this discrete customer service record storage and proactive traceability CRM system has the following advantages: This invention constructs a highly reliable, granular, and easily verifiable complete service evidence chain by discretizing events on the blockchain and linking them with chained hashes. This fundamentally solves the problems of centralized records being easily tampered with and having low traceability efficiency. It changes the paradigm of service record generation and storage. Through the client-side discrete evidence storage module, continuous service interactions are deconstructed into standardized, semantically clear service atomic events. Each event is encapsulated by the blockchain evidence storage module into an event evidence package containing the hash of the previous evidence package and stored sequentially in the blockchain core module. This mechanism ensures that the key content of each event is recorded in a distributed and immutable manner. Any unilateral modification will destroy the hash value on the chain, thereby giving each record node evidence storage validity. At the same time, through the hash field of the previous evidence package, the system tightly connects all discrete events under the same service request in logic and time sequence, forming a complete and rapidly verifiable service evidence chain.

[0017] Other advantages, objectives and features of the invention will be set forth in part in the description which follows, and in part will be apparent to those skilled in the art from the following examination or study, or may be learned from the practice of the invention. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating the operation of a discrete customer service record storage and proactive traceability CRM system; Figure 2 A block diagram of the modules of a discrete customer service record storage and proactive traceability CRM system; Figure 3 This is a flowchart of the event evidence package encapsulation process in an embodiment of the present invention. Detailed Implementation

[0020] To better understand the above technical solutions, a detailed description of the solutions will be provided below in conjunction with the accompanying drawings and specific embodiments. Obviously, the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0021] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a discrete customer service record storage and proactive traceability CRM system,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms, and “plural” generally includes at least two unless the context clearly indicates otherwise.

[0022] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that an article or device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such an article or device. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the article or device that includes said element.

[0023] To address the shortcomings of existing Customer Relationship Management (CRM) systems, such as low reliability of service record storage, inefficient tracing, lack of proactive management capabilities, and incomplete cross-departmental collaborative evidence chains, this invention provides a discrete customer service record storage and proactive tracing CRM system. It aims to construct a highly reliable and granular complete service evidence chain by discretizing continuous service processes into standardized service atomic events and utilizing blockchain technology to achieve immutable storage and chain-like association of these events. Simultaneously, smart contracts monitor and rule-basedly judge on-chain events in real time, automatically triggering proactive tracing tasks when preset conditions are met. This transforms service management from a passive, post-event retrospective model to a proactive, in-process intervention-based intelligent paradigm. This invention is primarily applied to scenarios requiring refined process recording, clear responsibilities, and proactive risk control, such as customer service, after-sales support, and complaint handling. In these scenarios, the service process involves multiple stages and roles, numerous commitments, and high dispute risks. Traditional centralized, continuous log-based recording methods are insufficient to meet the demands for reliable evidence, accurate tracing, and proactive early warning. This invention provides a systematic solution to the above pain points by constructing a complete technical system for on-chain evidence storage of discrete events, smart contract triggering, active engine execution, and visual evidence chain query.

[0024] Specifically, this embodiment provides a discrete customer service record storage and proactive traceability CRM system, such as... Figure 2 As shown, the system includes: a client-side discrete evidence storage module, a blockchain evidence storage module, a blockchain core module, a smart contract management module, an active traceability module, and an application service module; The client-side discrete evidence storage module is used to identify and generate standardized service atomic events during customer service interactions. The blockchain evidence storage module is used to receive the service atomic events, encapsulate them into event evidence storage packages with chain-like relationships, and send the event evidence storage packages to the blockchain core layer. The blockchain core module is used to store event evidence packages from the blockchain evidence storage module in the form of a distributed ledger, making the event evidence storage immutable. The smart contract management module is used to deploy and execute one or more smart contracts. The smart contracts are configured to listen to event storage packages of a preset type on the blockchain core module and automatically generate traceability tasks when preset business rules are met. The proactive tracing module is used to receive and execute the tracing task, the execution of which includes triggering internal notifications, customer outreach, internal process advancement, and generating new service atomic events; The application service module provides a human-computer interaction interface and an evidence traceability query interface, allowing users to query a service evidence chain view consisting of multiple event evidence packages.

[0025] The client-side discrete evidence storage module, deployed on the terminal device used by service personnel, is used to identify key service nodes in real time during customer service interactions. Based on a predefined standardized data structure, it generates independent service atomic events, serving as the starting point for human-computer interaction and transforming unstructured communication content into structured, machine-readable event data. In specific implementation, when service personnel communicate with customers or perform operations such as problem diagnosis, solution formulation, and task assignment, a pre-built rule engine captures key interaction moments. Once a predefined key action is identified, the construction process of service atomic events is initiated. Each service atomic event is a set of standardized data units with a predefined data structure, which includes: Unique event identifier: A globally unique string that ensures the independence of each event; Associated main service request identifier: The core work order or request ID associated with this service, used to link discrete events into the same service process; Event type: Selected from a predefined set of event types, which includes: customer commitment, solution provision, internal responsibility assignment, service node completion, external dependency notification, and customer feedback reception. Each type corresponds to a specific service semantic. Event timestamp: Records the time of the current communication or execution of problem diagnosis, solution formulation, and task assignment; Responsible entity identifier: The identity of the operator who performed the action; Event Summary: A textual summary of the core content of the event; Detailed data fingerprint: The hash value calculated using the SHA-256 algorithm from the complete dialogue record, attachments, and other content of the event, used for subsequent integrity verification; In addition, the client-side discrete evidence storage module is also used to perform event feature value calculation, calculating a quantified comprehensive event feature value E for each service atomic event, representing its business importance and processing urgency. This value is referenced by the smart contract for dynamic decision-making. The calculation steps for the event feature value E are as follows: Obtain calculation parameters: Event type importance coefficient The system administrator pre-configures a fixed base importance coefficient for each event type, and retrieves this coefficient directly based on the event type of the current event; historical weight of the responsible entity. Based on the responsible party identifier for the current event, a query is initiated into the system's historical performance database to retrieve all service records marked as completed by that responsible party within the past preset historical period. Based on these records, the historical performance success rate is calculated. and average task processing time Calculate the historical weight of the responsible entity ,in, This is the system's preset standard processing time for this type of task. and It is a preset weight adjustment coefficient used to balance the impact of success rate and efficiency; it promises content criticality. The text of the event summary field is processed using Natural Language Processing (NLP). First, it undergoes word segmentation and stop word removal. Then, nouns and verb phrases are extracted as keywords. These keywords are compared with preset key information. Based on the matched keywords and their weights, a weighted average is calculated to determine the event summary. value; Calculate the final event feature value: Substitute the obtained calculation parameters into ,in, The weighting coefficients preset for the system are used to balance the impact of different types of parameters on the overall characteristics of the event; Storage and transmission: The calculated event feature values... It is stored and transmitted as an additional field of the service atomic event.

[0026] The aforementioned blockchain evidence storage module is responsible for receiving service atomic events generated from one or more client-side discrete evidence storage modules, encapsulating them to form an event evidence storage package containing chain-linked information, and calling the blockchain network's access interface to send the event evidence storage package to the blockchain core module for persistent storage; in specific implementation processes, such as Figure 3 As shown, the encapsulation process of the event evidence package is as follows: Receive a complete service atomic event data packet; Query the core blockchain module to obtain the hash value of the latest successfully uploaded event storage package associated with the currently associated main service request identifier, and use it as the hash value field of the previous storage package; Using the private key identified by the current responsible entity, digitally sign the entire data packet to generate the submitter signature field; The original service atomic event data, hash value field, submitter signature field, and timestamp of this evidence storage are packaged together to form the final event evidence storage package; The event evidence package is submitted to the blockchain core module through a predefined API interface.

[0027] The aforementioned blockchain core module, built upon blockchain technology, operates as a decentralized distributed ledger network. It stores all event evidence packages submitted by the blockchain evidence storage module in a distributed and tamper-proof manner. Each node maintains a complete copy of the ledger, and any attempt to tamper with the stored data will be rejected by the network due to hash value mismatches, thus ensuring absolute data trustworthiness. In its specific implementation, its workflow is as follows: Receive event evidence package; Consensus nodes in the network verify the validity of the evidence storage packet; After successful verification, the evidence package is packaged into a new block; The block is confirmed by all nodes on the network and added to the blockchain via a consensus algorithm. Each evidence package is permanently recorded on the chain, and a unique transaction hash is generated as its address credential on the chain. Each key node in the service process is solidified into an on-chain evidence package, and a complete, time-verifiable service evidence chain is formed through hash linking.

[0028] The smart contract management module, deployed on a blockchain network, manages and executes a series of pre-compiled smart contract programs. These smart contract programs are configured to continuously monitor event storage packages of a preset monitoring type on the blockchain core module. Once a matching event is detected, the smart contract program automatically executes its internally encoded business rule logic, generating a structured traceability task when the conditions are met. In specific implementation, this module includes: Conditional Listening Unit: Configured to continuously scan newly added blocks in the core blockchain module and listen to whether the event type field in the newly added event storage package matches the default listening type of the contract; Rule logic unit: Contains programmable business judgment logic. When the condition listening unit captures a matching event evidence package, the rule logic unit is triggered, parses the event content in the evidence package, and performs business judgment in conjunction with the obtained external data source. Task triggering unit: When the rule logic unit determines that all triggering conditions are met, the task triggering unit is activated, generates a structured traceability task instruction set according to the preset template, and sends the task to the task queue of the active traceability module.

[0029] In this context, when multiple service atomic events simultaneously meet the triggering conditions, to avoid task queue congestion and resource mismatch, the smart contract executes the following steps to determine the order in which traceability tasks are generated: Read the event feature value directly from the event evidence package corresponding to each event to be evaluated; The smart contract reads global system status metrics in real time, including the total number of traceability tasks currently in the pending state. And the average wait time of the service queues related to the current event. ; These indicators are standardized and then weighted and summed to obtain the system state coefficients. ,in, and The maximum preset baseline value for the system. and These are the weighting coefficients; Analyze the implicit or associated task processing deadlines in the event storage package, and combine them with the current system time. Calculate the remaining time margin If it has expired ( ), then Let it be a very small positive constant. To avoid the denominator being zero; Calculate the dynamic priority evaluation value for each event. Considering the importance of the event itself, the current system load, and the urgency of handling it; The rule logic unit calculates all events... The values ​​are sorted in descending order, and the task triggering units are activated sequentially in this order to generate and send trace tasks of the corresponding priorities.

[0030] The aforementioned proactive tracing module monitors the task queue from the smart contract management module. Upon receiving a new tracing task, it invokes different execution units based on the task type and content, triggering corresponding internal notifications, customer outreach, and internal process advancement actions. It can also generate new service atomic events based on the execution results, thus forming a management system. In specific implementation, a tracing task is a structured instruction set, including: task ID, source event storage packet hash value, task type, target object, execution content, expected deadline, and priority score. Different execution units are invoked based on the task type. Internal notification execution unit: For tasks that require internal follow-up, a notification message is sent to the designated person or department through the enterprise's internal communication system. The message includes an on-chain query link for the source event evidence package.

[0031] Customer outreach execution unit: For tasks that need to be communicated to customers, progress updates, commitment reminders, or satisfaction surveys are sent to customers via SMS, APP push, or automated outbound calling system according to preset templates.

[0032] Process Execution Unit: For tasks that need to trigger downstream business processes, sub-tasks are automatically created, statuses are changed, or processes are pushed to the next stage in the work order system, ERP, or project management system via API calls.

[0033] New Event Generation Unit: Whenever the active tracing module completes a task, this unit is called to take the execution result of the current tracing task as input and construct a new service atomic event with the event type of tracing action execution. This event is then stored through the blockchain evidence module and the blockchain core module, which makes each automatic tracing intervention itself part of an immutable chain of evidence, forming a system where events trigger tracing and tracing generates new events.

[0034] The application service module provides a human-computer interaction interface and evidence traceability query interface for system users, including service personnel, administrators, and auditors. It allows users to input the main service request identifier, and the system retrieves all related events from the blockchain core module, reconstructs and visualizes the complete service evidence chain view. In specific implementation, the query process of the evidence traceability query interface includes: Receives a main service request identifier from user input; Initiate a query to the blockchain core module to obtain all event storage packets associated with the main service request identifier; Based on the timestamp in each event evidence package and the hash value of the previous evidence package, a complete and chronologically correct chain of evidence can be reconstructed. The service evidence chain view is presented in the form of a timeline in the visualization interface, with each node in the view corresponding to an event evidence package.

[0035] In summary, this invention constructs a new, trustworthy, transparent, efficient, and intelligent customer service management system by utilizing real-time event-based client interaction points, the immutable evidence storage and chain-linking of blockchain, the automated business rule judgment of smart contracts, and the closed-loop execution of proactive traceability. The system not only fundamentally solves the problems of the credibility and evidentiary validity of service records but also, through a proactive traceability mechanism, shifts risk management and service quality control from reactive post-event review to proactive, in-process automatic early warning and intervention, thus revolutionizing the service management paradigm. Simultaneously, all actions are recorded on the blockchain, forming a complete, verifiable chain of evidence that spans the entire service lifecycle, clearly defines responsibilities, and provides a solid data foundation for internal collaboration and performance evaluation.

[0036] like Figure 1 As shown, this paper details the operational process of a discrete customer service record storage and proactive traceability CRM system in handling a service from recording to proactive traceability. The specific process is as follows: (1) Identify and generate service atomic events During customer service interactions, the client-side discrete evidence storage module automatically identifies key nodes.

[0037] These key nodes are used to generate standardized service atomic events, which contain core information such as a unique ID, the associated service request ID, the event type, the timestamp, the person in charge, and a content summary.

[0038] (2) Calculate the event feature value The system calculates an event feature value for each service atomic event to quantify the importance and urgency of the event.

[0039] The calculation takes into account the importance of the event type itself, the historical performance of the employee responsible for the event, and whether the event content contains key commitments or matters.

[0040] (3) Construct and submit the event evidence package The blockchain evidence storage module receives service atomic events.

[0041] Attach the following to the event: the hash value of the previous related event evidence package and the digital signature of the submitter, thus encapsulating it into an event evidence package to ensure that the sequence and correlation between events cannot be tampered with.

[0042] (4) On-chain storage The packaged event evidence is sent to the blockchain core module for permanent and tamper-proof storage.

[0043] (5) Smart contract monitoring and judgment The smart contract management module continuously scans for newly added event storage packages on the blockchain.

[0044] When a predefined type of event is detected on the blockchain, the smart contract will parse the event content and may combine it with external data to determine whether it meets the business rules.

[0045] (6) Dynamic priority assessment If multiple events meet the triggering conditions simultaneously, the smart contract will perform a dynamic priority evaluation to determine the processing order.

[0046] The evaluation criteria include: the event characteristic value of each event, the current level of system busyness, and the remaining time margin before the preset processing deadline for that event.

[0047] All pending events are prioritized based on the calculation results.

[0048] (7) Generate traceability task For events that meet the conditions and are prioritized, the smart contract will automatically generate a structured tracing task.

[0049] The proactive tracing module receives tracing tasks and calls different execution units based on the task type: internal notification unit, customer outreach unit, process advancement unit, and new event generation unit.

[0050] (8) Record and trace actions When a new event generation unit is invoked, the execution result of the trace action is constructed as a new service atomic event and stored on the blockchain.

[0051] Users can enter a service request ID through the query interface of the application service module.

[0052] The system will retrieve all associated event evidence packages from the blockchain and reconstruct a complete, chronologically correct chain of service evidence based on timestamps and hash pointers.

[0053] Ultimately, the user interface clearly displays all key nodes and traceability activities of the entire service process in a visual format such as a timeline.

[0054] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A discrete customer service record storage and proactive traceability CRM system, characterized in that, The system comprises: The client-side discrete evidence storage module is used to identify and generate standardized service atomic events during customer service interactions. The blockchain evidence storage module is used to receive the service atomic events, encapsulate them into event evidence storage packages with chain-like relationships, and send the event evidence storage packages to the blockchain core layer. The blockchain core module is used to store event evidence packages from the blockchain evidence storage module in the form of a distributed ledger, making the event evidence storage immutable. The smart contract management module is used to deploy and execute one or more smart contracts. The smart contracts are configured to listen to event storage packages of a preset type on the blockchain core module and automatically generate traceability tasks when preset business rules are met. The proactive tracing module is used to receive and execute the tracing task, the execution of which includes triggering internal notifications, customer outreach, internal process advancement, and generating new service atomic events; The application service module provides a human-computer interaction interface and an evidence traceability query interface, allowing users to query a service evidence chain view consisting of multiple event evidence packages.

2. The discrete customer service record storage and proactive traceability CRM system according to claim 1, characterized in that, The service atomic events generated by the client discrete evidence storage module are a set of standardized data units with a predefined data structure. The elements they contain are: a unique event identifier, an associated main service request identifier, an event type, an event timestamp, a responsible entity identifier, an event content summary, and a detailed data fingerprint. The event type is selected from a predefined set of event types, which includes: customer commitment, solution provision, internal responsibility assignment, service node completion, external dependency notification, and customer feedback reception.

3. The discrete customer service record storage and proactive traceability CRM system according to claim 2, characterized in that, When generating the service atomic event, the client-side discrete evidence storage module also performs event feature value calculation to calculate an event feature value for each service atomic event, quantifying its importance and urgency. This event feature value is referenced by the smart contract management module. The event feature value calculation steps are as follows: Obtain calculation parameters, including event type importance coefficients. Historical weight of responsible entities Keyness of the commitment content ; Substitute the obtained calculation parameters into The calculated final event feature values, where, This represents the final event feature value calculated. A pre-set weighting coefficient for the system, used to balance the importance coefficient of event type, the historical weight of responsible party, and the criticality of commitment content; The calculated event feature values It is stored and transmitted as an additional field of the service atomic event.

4. The discrete customer service record storage and proactive traceability CRM system according to claim 1, characterized in that, The event storage package encapsulated by the blockchain storage module is an enhanced data package formed by adding the hash value of the previous storage package and the digital signature of the submitter to the service atomic event. The hash value of the previous evidence package points to the last successfully stored event evidence package in the current service process, thereby forming a time-sequential and tamper-proof evidence chain on the blockchain core module for all event evidence packages under the same main service request identifier.

5. The discrete customer service record storage and proactive traceability CRM system according to claim 1, characterized in that, The smart contract in the smart contract management module includes: a condition monitoring unit, a rule logic unit, and a task triggering unit; The condition monitoring unit is configured to continuously scan the blockchain core module to monitor whether the event type in the newly added event storage package matches the monitoring type preset by the contract. The rule logic unit includes programmable business judgment logic. When the condition monitoring unit captures a matching event storage package, the rule logic unit parses the event content summary in the event storage package and, in conjunction with the external data source, determines whether the triggering conditions are met. The task triggering unit is activated when the rule logic unit determines that the triggering condition is met, generates a structured tracing task, and sends the tracing task to the task queue of the active tracing module.

6. The discrete customer service record storage and proactive traceability CRM system according to claim 5, characterized in that, When the rule logic unit executes business judgment logic, if multiple service atomic events simultaneously meet the initial triggering conditions, it determines the order in which the traceability task is generated by performing dynamic priority evaluation. The steps of the dynamic priority evaluation are as follows: The event feature value is directly read from the event storage package corresponding to the service atomic event that has met the initial triggering conditions and is to be evaluated. ; The smart contract reads and calculates system business metrics in real time, including the total number of traceability tasks currently in the pending state. Average wait time of service queues related to the current service atomic event After standardizing the system's business metrics, a weighted sum is calculated: ,in, and This is the maximum baseline value preset by the system for standardizing indicators. and These are the weighting coefficients; Parse the task processing deadline contained in the event storage package corresponding to the currently evaluated service atomic event. And combined with the current system time Calculate the remaining time margin ,when At that time, the system's preset positive minimum constant will be used. As value; Based on the calculated event characteristic values System state coefficients Remaining time margin Calculate priority evaluation value ; The rule logic unit of the smart contract calculates the dynamic priority scores of all service atomic events. The tasks are sorted in descending order and activated sequentially to generate and send traceability tasks of corresponding priorities.

7. The discrete customer service record storage and proactive traceability CRM system according to claim 1, characterized in that, The tracing task executed by the active tracing module is a set of instructions that includes a task identifier, a source event evidence package identifier, a task type, a target object, execution content, an expected deadline, and a priority evaluation value. The proactive tracing engine invokes different execution units based on the task type. These execution units include: an internal notification execution unit, a customer outreach execution unit, a process advancement execution unit, and a new event generation unit.

8. The discrete customer service record storage and proactive traceability CRM system according to claim 7, characterized in that, When the new event generation unit creates a new service record based on the execution content of the tracing task, the new event generation unit is invoked, takes the execution result of the tracing task as input, constructs a new service atomic event with the event type of tracing action execution, and stores it through the blockchain evidence storage module and the blockchain core module, thereby incorporating the active tracing behavior itself into the tamper-proof evidence chain.

9. A discrete customer service record storage and proactive traceability CRM system according to claim 1, characterized in that, The workflow of the evidence storage traceability query interface provided by the application service module includes: Receives a main service request identifier from user input; Initiate a query to the blockchain core module to obtain all event storage packets associated with the main service request identifier; Based on the timestamp in each event evidence package and the hash value of the previous evidence package, a complete and chronologically correct chain of evidence can be reconstructed. The service evidence chain view is presented in the form of a timeline in the visualization interface, with each node in the view corresponding to an event evidence package.

Images