A customer relationship data processing system, method and storage medium

Abstract

This invention discloses a customer relationship data processing system, method, and storage medium, relating to the field of data processing. The system includes a request receiving module, a relationship building module, and a data synchronization and transfer module. The request receiving module receives transfer requests; the relationship building module extracts the key person identifier field from customer records and constructs a relationship data model, traversing the relationship data model starting from the identifier of the customer to be transferred to obtain a complete set of related customer identifiers; the data synchronization and transfer module uses the identifiers in this set as indexes to extract the corresponding target customer record, updating the responsible person field to the target responsible person identifier; it also obtains the associated target related order record and synchronously updates its responsible person field to the target responsible person identifier. This invention allows related customers and their orders to belong to the same responsible person, alleviating the problem of scattered related customer affiliation and difficulty in unified maintenance by a single responsible person.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more particularly to a customer relationship data processing system, method, and storage medium. Background Technology

[0002] A customer relationship data processing system is a computer system used to centrally store and maintain enterprise customer information. It saves customer records in a database, and each customer record contains a responsible person field to identify the person currently responsible for maintaining the customer, and can be associated with the customer's group data and business orders.

[0003] In related technologies, when it is necessary to change a customer's manager from one person to another, the operator typically selects the customer's record, and the system updates the manager's field of that customer record with the new manager's identifier. When multiple customers need to be changed, each record is selected and updated sequentially.

[0004] However, customer records within the same company often have interrelationships, such as multiple contacts from the same organization. These relationships are recorded through the key person identifier field in the customer records. In related technologies, when an operator selects a customer for transfer, the system only updates the responsible person field of the selected customer's record. Other customer records associated with the selected customer through the key person identifier field are not transferred; similarly, order records associated with the selected customer are also not transferred and remain under the original responsible person. This results in originally related customers being assigned to different responsible persons, leading to inconsistent customer and order attribution, and making it difficult for a single responsible person to maintain unified customer records. Summary of the Invention

[0005] To address the aforementioned technical problems and deficiencies, the purpose of this invention is to provide a customer relationship data processing system, method, and storage medium that can reduce the omission and fragmented ownership of related customers, enabling related customers to be uniformly maintained by the same person in charge.

[0006] To achieve the above objectives, in a first aspect, the present invention provides a customer relationship data processing system, including a request receiving module, an association relationship building module, and a data synchronization and transfer module;

[0007] The request receiving module is configured to receive customer data transfer requests, wherein the customer data transfer request includes the identifier of the customer to be transferred and the identifier of the target person in charge.

[0008] The relationship building module is connected to the request receiving module and is configured to extract the key person identifier field of the customer record, build a relationship data model reflecting the relationship between customers based on the key person identifier field, and traverse the relationship data model starting from the identifier of the customer to be transferred to obtain a complete set of related customer identifiers.

[0009] The data synchronization and transfer module is connected to both the request receiving module and the association construction module, and the data synchronization and transfer module is configured as follows:

[0010] Using the identifiers in the complete set of associated customer identifiers as the retrieval index, the corresponding target customer record is extracted from the preset business database, and the responsible person field of the target customer record is updated to the target responsible person identifier;

[0011] Retrieve the target associated order record associated with the complete set of associated customer identifiers;

[0012] Update the responsible person field of the target associated order record to the target responsible person identifier, so that the related customers and their orders belong to the same responsible person.

[0013] The customer relationship data processing system of this invention, upon receiving a customer data transfer request containing a customer identifier to be transferred and a target responsible person identifier, extracts the key person identifier field from the customer records using the relationship construction module. Based on the key person identifier field, it constructs a relational data model reflecting the relationships between customers. Starting from the customer identifier to be transferred, it traverses the relational data model to obtain a complete set of related customer identifiers, including the customer identifier to be transferred itself and all customer identifiers directly or indirectly related to it. Then, the data synchronization and transfer module synchronously updates the responsible person field of all target customer records and the responsible person field of all target related order records corresponding to the complete set of related customer identifiers to the same target responsible person identifier. Thus, interconnected customers and their orders belong to the same responsible person, eliminating the need for manual identification and selection of related customers by operators, reducing the omission and dispersion of related customers, and enabling related customers to be maintained uniformly by the same responsible person, thereby improving the efficiency of customer relationship management.

[0014] In a second aspect, the present invention provides a customer relationship data processing method for use in the system provided in the first aspect, the method comprising:

[0015] In response to a customer data transfer request, the key person identification field of the customer record is obtained, wherein the customer data transfer request includes the identifier of the customer to be transferred and the identifier of the target person in charge;

[0016] Based on the key person identification field, a relational data model reflecting the relationships between customers is constructed;

[0017] Starting with the customer identifier to be transferred, traverse the associated data model to obtain a complete set of associated customer identifiers;

[0018] Using the identifiers in the complete set of associated customer identifiers as the retrieval index, the corresponding target customer records are extracted from the preset business database;

[0019] Update the responsible person field of the target customer record to the target responsible person identifier;

[0020] Retrieve the target associated order record associated with the complete set of associated customer identifiers;

[0021] Update the responsible person field of the target associated order record to the target responsible person identifier, so that the related customers and their orders belong to the same responsible person.

[0022] Thirdly, the present invention provides a customer relationship data processing system, comprising: a memory and one or more processors; the memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors calling the computer instructions to cause the customer relationship data processing system to perform the methods described in the second aspect and any possible implementation thereof.

[0023] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions that, when executed on a customer relationship data processing system, cause the customer relationship data processing system to perform the methods described in the second aspect and any possible implementation thereof.

[0024] Fifthly, the present invention provides a computer program product including computer instructions that, when executed on a customer relationship data processing system, cause the customer relationship data processing system to perform the method described in the second aspect and any possible implementation thereof.

[0025] Understandably, the method provided in the second aspect, the system provided in the third aspect, the storage medium provided in the fourth aspect, and the computer program product provided in the fifth aspect all adopt the same technical concept as the system in the first aspect, and the beneficial effects they can achieve can be referred to the beneficial effects in the system in the first aspect, which will not be repeated here. Attached Figure Description

[0026] Figure 1 This is a schematic diagram of the architecture of a customer relationship data processing system according to an embodiment of the present invention;

[0027] Figure 2 This is a schematic diagram of the architecture of another customer relationship data processing system according to an embodiment of the present invention;

[0028] Figure 3 This is a flowchart illustrating a customer relationship data processing method according to an embodiment of the present invention;

[0029] Figure 4 This is a schematic diagram of the electronic device hardware architecture of a customer relationship data processing system according to an embodiment of the present invention. Detailed Implementation

[0030] The terminology used in the following embodiments of the present invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used in the specification and appended claims of the present invention, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in the present invention refers to any or all possible combinations comprising one or more of the listed items.

[0031] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of the present invention, unless otherwise stated, "a plurality of" means two or more.

[0032] It should also be noted that, unless otherwise explicitly specified and limited, the terms "setting" and "connection" in the embodiments of the present invention should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components; it can be a wired communication connection or a wireless communication connection. Those skilled in the art can understand the specific meaning of the above terms in the present invention according to the specific circumstances. The embodiments of the present invention will be described in detail below.

[0033] In related technologies, in some application scenarios, such as a company's customer relationship data processing system, there are three customer records: Customer A, Customer B, and Customer C. All three come from the same work unit. The key person identifier fields of Customer B and Customer C are both recorded as Customer A's customer identifier. All three are currently managed by salesperson Zhang, and there is an order record under Customer A's name.

[0034] When Zhang resigned and it was necessary to transfer Customer A to salesperson Li, the operator selected Customer A from the customer list and designated Li as the transferee. The system only updated the responsible person field of Customer A's record to Li, while Customers B and C, which were related to Customer A, as well as the order records under Customer A's name, were not transferred and remained under the name of the resigned Zhang.

[0035] This resulted in customers A, B, and C, who originally came from the same work unit, being assigned to different responsible persons. The affiliation of related customers was scattered, and the ownership of customers and their orders was inconsistent, making it difficult for a single responsible person to maintain them uniformly.

[0036] In this application scenario, in the technical solution of the present invention, after the operator selects customer A and designates Li as the recipient, the receiving module requests the customer data transfer request and parses it to obtain the customer identifier of customer A to be transferred and the person in charge identifier of Li as the target person in charge.

[0037] The relationship building module reads the customer identifier and key person identifier fields from the customer records, and identifies that the key person identifier fields of both customer B and customer C are recorded as customer A's customer identifier. Based on this, a bidirectional relationship is established between customer A and customer B, and between customer A and customer C, thus constructing a relationship data model. Then, starting from customer A's customer identifier, the relationship data model is traversed to obtain a complete set of related customer identifiers containing customer A, customer B, and customer C.

[0038] The data synchronization and transfer module uses the complete set of associated customer identifiers as the retrieval index, updates the responsible person fields of Customer A, Customer B, and Customer C to the responsible person identifier of Li, and retrieves the order records under Customer A as the target associated order records. The responsible person field of the order records is then updated synchronously to the responsible person identifier of Li, so that the related customers and their orders belong to the same responsible person, Li.

[0039] As can be seen, this invention utilizes the existing key person identifier field in customer records to construct a relational data model reflecting the relationships between customers. It expands the object of a single transfer operation from a single customer record to a complete set of related customer identifiers, and synchronously updates the responsible person fields in both customer and order records. Therefore, it eliminates the need for manual identification and selection of related customers, ensuring that related customers and their orders always belong to the same responsible person, thus solving the problems of scattered related customer attribution and inconsistencies between customer and order attribution.

[0040] To more clearly illustrate the technical solution of the present invention, a customer relationship data processing system provided by an embodiment of the present invention will be described in detail below.

[0041] It should be noted that all modules involved in this embodiment are software modules. A software module refers to a program unit composed of computer program code that is loaded into the server's processor and can perform specific data processing functions after execution.

[0042] In some specific implementations, the customer relationship data processing system can be deployed on a containerized server. This server is based on the Java language and written using a web service-oriented application development framework. Each software module exists in the form of an interface class and an implementation class. The application development framework instantiates these modules when the system starts and maintains their inter-module calling relationships. Each software module passes data to the other through method calls and reads and writes to the preset business database through the data access interface.

[0043] A business database is a relational database used to centrally store customer records, order records, and related business data. In some specific implementations, it can be implemented using a relational database management system that supports transaction processing.

[0044] To facilitate understanding, some key nouns, entities, and technical terms involved in this embodiment will be explained first.

[0045] The server refers to the computer equipment that deploys and runs the various software modules of the customer relationship data processing system. The computer equipment includes a processor and a memory. The memory stores the computer program code that constitutes the software modules. The processor loads and runs the computer program code to complete the data processing functions corresponding to the software modules. In one specific implementation, the server is a single physical server. In another specific implementation, it is a server cluster consisting of multiple physical servers or a virtual server deployed on a cloud computing platform.

[0046] The front-end interface refers to the client display interface for human-computer interaction by operators. This client display interface communicates with the server through the network, displays customer records to operators, and receives selected and specified operations from operators. In one specific implementation, it is a web page interface running in a browser, and in another specific implementation, it is an application interface running on the operator's terminal.

[0047] A customer record is a data record stored in the business database that describes a customer. Each customer record includes multiple fields such as customer identifier, responsible person field, and key person identifier field.

[0048] A customer identifier is an identifier value that uniquely identifies a customer record in the business database. It can be a long integer value generated using a universally unique identification code algorithm, and the customer identifiers of different customer records are different from each other.

[0049] The "Responsible Person" field in a customer record identifies the person currently responsible for maintaining that record. The value of this field is a personnel identifier. When the "Responsible Person" field is empty, it means the customer record is not currently owned by any specific person and is in a public state. When the "Responsible Person" field is a personnel identifier, it means the customer record is maintained by the person corresponding to that identifier.

[0050] The Key Person Identifier field is a field in a customer record used to record the relationship between that customer record and another customer record. The value of this field is the customer identifier of the other customer record. When the Key Person Identifier field of a customer record is the same as the customer identifier of a second customer record, it indicates that there is a relationship between these two customer records. In actual business operations, this relationship could be, for example, between multiple contacts from the same workplace, or between customers referred by a single customer.

[0051] The responsible person identifier is an identifier value used to identify a person. The target responsible person identifier is the responsible person identifier specified in the customer data transfer request who is to take over the customer being transferred.

[0052] A relational data model refers to a data structure used to express the relationships between multiple customer identifiers. This can include adjacency lists, adjacency matrices, graph databases, and relational graphs. In some implementations, adjacency lists can be specifically used. These adjacency lists are implemented as mapping tables, where the customer identifier is the key and the values ​​are lists of other customer identifiers that are related to that customer identifier. This records which customer identifiers are related to each other.

[0053] An order record is a data record stored in the business database that describes a business order. Each order record contains an associated field corresponding to the customer identifier and a responsible person field. A target associated order record is an order record whose associated field matches any customer identifier in the complete set of associated customer identifiers.

[0054] The following is combined with Figure 1 The customer relationship data processing system of this embodiment will be described. The customer relationship data processing system includes a request receiving module 101, an association relationship building module 102, and a data synchronization and transfer module 103.

[0055] The request receiving module 101 is configured to receive customer data transfer requests, which include the identifier of the customer to be transferred and the identifier of the target person in charge.

[0056] In some implementations, the request receiving module 101 is a controller-type software module that provides a network access point. This software module registers itself as a processing unit capable of receiving Hypertext Transfer Protocol (HTTP) requests through annotations provided by the application development framework. When an operator selects one or more customers to be transferred and designates a receiving person on the front-end interface, the front-end interface sends an HTTP request carrying a data transfer object to the server. The request receiving module 101 receives the request and parses the data transfer object carried in the request into the identifier of the customer to be transferred and the identifier of the target person in charge.

[0057] The customer identifier to be transferred is the customer identifier of one or more customers selected by the operator, and the target person in charge identifier is the person in charge identifier of the person designated by the operator to take over.

[0058] After parsing and obtaining the above-mentioned customer identifier to be transferred and target person identifier, the request receiving module 101 transmits the customer identifier to be transferred to the association construction module 102 and the target person identifier to the data synchronization and transfer module 103.

[0059] The relationship building module 102 is connected to the request receiving module 101 and is configured to extract the key person identifier field of the customer record, build a relationship data model reflecting the relationship between customers based on the key person identifier field, and traverse the relationship data model starting from the identifier of the customer to be transferred to obtain a complete set of related customer identifiers.

[0060] In some implementations, the relationship building module 102 is a service implementation software module running on the server. This software module initiates a query to the business database through the data access interface, reads the customer identifier and key person identifier fields of the customer record, and completes the construction and traversal of the relationship data model in the server memory.

[0061] The association construction module 102 receives the customer identifier to be transferred from the request receiving module 101 in the form of a method return value, and outputs a complete set of associated customer identifiers to the data synchronization and transfer module 103 in the form of a method return value, thereby realizing the connection between the two software modules.

[0062] Taking the adjacency list as an example, the process of constructing the adjacency list by the association relationship construction module 102 is as follows:

[0063] The relationship building module 102 first reads a set of customer records from the business database and extracts the customer identifier and key person identifier fields for each customer record. Then, the relationship building module 102 creates a mapping table as an adjacency table in the server's memory. For each customer record read, the relationship building module 102 first places an empty list in the mapping table with the customer identifier of that customer record as the key. After the placement is complete, the relationship building module 102 iterates through the read customer records again. For customer records where the key person identifier field is not empty and the customer identifier recorded in that key person identifier field falls within the set of read customer identifiers, the customer identifier of that customer record is added to the list corresponding to the key person identifier field as the key, and simultaneously, the customer identifier recorded in that key person identifier field is added to the list corresponding to the customer identifier of that customer record as the key. This establishes a bidirectional association between the customer identifiers of two related customer records, ultimately forming the adjacency table.

[0064] The process by which the relationship building module 102 traverses the relational data model (continuing to use the adjacency list as an example) to obtain the complete set of relational customer identifiers is as follows:

[0065] The association construction module 102 creates a list of associated customer identifiers and a tag table for marking processed customer identifiers. First, customer identifiers to be transferred are added to the associated customer identifier list and marked in the tag table. Then, starting from the beginning of the associated customer identifier list, the association construction module 102 retrieves customer identifiers one by one. For each retrieved customer identifier, it searches the adjacency list for the list of customer identifiers associated with that customer identifier. For each associated customer identifier in that list, the association construction module 102 checks the tag table to see if the associated customer identifier has already been marked. If it hasn't been marked, it adds the associated customer identifier to the associated customer identifier list and marks it in the tag table; otherwise, it skips that associated customer identifier. Since newly added associated customer identifiers will also be traversed subsequently, the traversal process continues until there are no more unprocessed customer identifiers in the associated customer identifier list. With the help of the tag table, the same customer identifier will not be added repeatedly, thus completing deduplication.

[0066] The list of associated customer identifiers obtained after the traversal is the complete set of associated customer identifiers. This complete set of associated customer identifiers includes the customer identifier to be transferred itself and all customer identifiers directly or indirectly associated with it.

[0067] The data synchronization and transfer module 103 is connected to both the request receiving module 101 and the association construction module 102. The data synchronization and transfer module 103 receives the target person identifier transmitted by the request receiving module 101 as a method parameter, and receives the complete set of associated customer identifiers output by the association construction module 102 as a method parameter, thereby realizing the connection with the two software modules mentioned above.

[0068] In some implementations, the data synchronization and transfer module 103 is a service implementation software module running on the server side. This software module performs batch update operations on the business database through a data access interface. The data synchronization and transfer module 103 is configured to perform the following operations.

[0069] The data synchronization and transfer module 103 uses the identifiers in the complete set of associated customer identifiers as the retrieval index to extract the corresponding target customer records from the preset business database and updates the responsible person field of the target customer records to the target responsible person identifier.

[0070] In some implementations, the data synchronization and transfer module 103 uses all customer identifiers in the complete set of associated customer identifiers and the target manager identifier as parameters, and calls a batch update statement that uses the customer identifier set as the filtering condition and the manager field as the update content. This allows the business database to update the manager field of all target customer records matched by the search index to the target manager identifier in one go. A target customer record refers to a customer record whose customer identifier falls within the complete set of associated customer identifiers.

[0071] The data synchronization and transfer module 103 obtains the target associated order record associated with the complete set of associated customer identifiers, and updates the responsible person field of the target associated order record to the target responsible person identifier.

[0072] In some implementations, the data synchronization and transfer module 103 encapsulates the complete set of associated customer identifiers and the target responsible person identifier into an order transfer data transmission object. Based on the order transfer data transmission object, it retrieves the order record in the business database whose associated field matches any customer identifier in the complete set of associated customer identifiers to obtain the target associated order record. Then, it updates the responsible person field of the target associated order record to the target responsible person identifier through a batch update operation.

[0073] With the above system configuration, when the customer relationship data processing system of this embodiment responds to a customer data transfer request, it does not only transfer the customer to be transferred selected by the operator, but also uses the association data model built by the association relationship construction module 102 based on the key person identifier field to include all customer identifiers that have direct or indirect relationship with the customer to be transferred into the complete set of associated customer identifiers. Then, with the help of the data synchronization transfer module 103, the responsible person field of all target customer records and the responsible person field of all target associated order records corresponding to the complete set of associated customer identifiers are synchronously updated to the same target responsible person identifier, so that the related customers and their orders belong to the same responsible person.

[0074] Therefore, the customer relationship data processing system solves the problems in related technologies where related customers are assigned to different responsible persons, and the ownership of related customers is scattered and difficult to be uniformly maintained by the same responsible person. Furthermore, it eliminates the need for operators to manually identify and select related customers one by one, thus avoiding the omission of related customers.

[0075] The following uses a specific application scenario and example data to illustrate the workflow of the customer relationship data processing system in this embodiment.

[0076] (a) Application scenario setting:

[0077] A company uses the aforementioned customer relationship data processing system to manage its customers. The company has two sales personnel; the first salesperson's supervisor is identified as U001, and the second salesperson's supervisor is identified as U002. The first salesperson currently maintains five customer records, and the storage status of these five customer records in the business database is listed in the table below.

[0078] The customer record with customer ID C001 has the customer name Zhang Gong, the employer is Company A, the person in charge field is U001, and the key person identifier field is empty.

[0079] The customer record with customer identifier C002 has the customer name "Li Gong", the employer is Company A, the person in charge field is U001, and the key person identifier field is C001.

[0080] The customer record with customer identifier C003 has the customer name "Wang Gong", the employer is Company A, the person in charge field is U001, and the key person identifier field is C002.

[0081] The customer record with customer ID C004 has the customer name Manager Zhao, the work unit is Unit B, the person in charge field is U001, and the key person identifier field is empty.

[0082] The customer record with customer ID C005 has the customer name Manager Qian, the work unit is Unit C, the person in charge field is U001, and the key person identifier field is empty.

[0083] Of the five customer records mentioned above, the three records with customer identifiers C001, C002, and C003 are interconnected through a key person identifier field. These correspond to three contacts within the same work unit, Company A, and there is a relationship between them. Specifically, the key person identifier field of the customer record with customer identifier C002 records customer identifier C001, and the key person identifier field of the customer record with customer identifier C003 records customer identifier C002. The key person identifier fields of the two customer records with customer identifiers C004 and C005 are both empty, and there is no relationship between them and the other customer records.

[0084] In addition, the business database stores two order records. The first order record has a customer identifier of C002 and a responsible person field of U001 in its associated fields; the second order record has a customer identifier of C001 and a responsible person field of U001 in its associated fields. Both order records are handled by the first salesperson and are associated with customers identified as C002 and C001, respectively.

[0085] Due to a job reassignment of the first salesperson, customer Li (identified as customer C002) needs to be transferred to the second salesperson. The operator selects the customer record with customer identification C002 in the front-end interface, designates the second salesperson as the receiving personnel, and then triggers the transfer operation.

[0086] (II) Workflow Example:

[0087] The first step is for the request receiving module 101 to receive and parse the customer data transfer request.

[0088] The front-end interface sends a Hypertext Transfer Protocol (HTTP) request carrying a data transfer object to the server. The data transfer object contains the identifier of the customer to be transferred, C002, and the identifier of the target person in charge, U002. The request receiving module 101 receives the request and parses the data transfer object into the identifier of the customer to be transferred, C002, and the identifier of the target person in charge, U002. Then, it passes the identifier of the customer to be transferred, C002, to the association construction module 102 and passes the identifier of the target person in charge, U002, to the data synchronization and transfer module 103.

[0089] The second step involves the relationship building module 102 iterating through local queries of customer records under the original person in charge and extracting the key person identifier field.

[0090] The relationship building module 102 reads the related customer records under the name of the first salesperson from the business database based on the customer identifier C002 to be transferred. Based on the key person identifier clue, it only reads the three related customer records with customer identifiers C001, C002 and C003, without reading the unrelated records C004 and C005, and extracts the customer identifier and key person identifier fields of these three customer records.

[0091] The third step is to construct the association data model (such as an adjacency list) using the association relationship construction module 102.

[0092] The association construction module 102 creates a mapping table as an adjacency table in the server's memory, initially using the three read customer identifiers C001, C002, and C003 as keys, each occupying an empty list. Then, the association construction module 102 iterates through the three customer records again, processing as follows:

[0093] For a customer record with customer identifier C002, the customer identifier recorded in its key person identifier field is C001. C001 falls within the set of customer identifiers under the original person in charge. Therefore, customer identifier C002 is added to the list corresponding to C001 as the key, and customer identifier C001 is added to the list corresponding to C002 as the key.

[0094] For a customer record with customer identifier C003, the key person identifier field records a customer identifier of C002. Therefore, customer identifier C003 is added to the list corresponding to C002, and customer identifier C002 is added to the list corresponding to C003.

[0095] For customer records with customer identifier C001, no outward association is actively established because the key person identifier field is empty (but it is already associated with C002).

[0096] The resulting adjacency list is as follows:

[0097] Using customer identifier C001 as the key, the corresponding list of associated customer identifiers is C002.

[0098] Using customer identifier C002 as the key, the corresponding list of associated customer identifiers is C001 and C003.

[0099] Using customer identifier C003 as the key, the corresponding list of associated customer identifiers is C002.

[0100] The fourth step involves the association construction module 102 traversing the adjacency list to obtain a complete set of associated customer identifiers.

[0101] The association construction module 102 creates an associated customer identifier list and a tag table. First, the customer identifier C002 to be transferred is added to the associated customer identifier list and the customer identifier C002 is marked in the tag table.

[0102] Then, starting from the beginning of the associated customer identifier list, customer identifiers are retrieved one by one for processing. Customer identifier C002 is retrieved, and the list of customer identifiers associated with C002 is found in the adjacency list: C001 and C003. Customer identifier C001 is not yet marked, so it is added to the associated customer identifier list and marked. Customer identifier C003 is also not yet marked, so it is added to the associated customer identifier list and marked. At this point, the associated customer identifier list is C002, C001, and C003. Customer identifier C001 is retrieved again, and the list of customer identifiers associated with C001 is found in the adjacency list: C002. Customer identifier C002 is already marked, so it is skipped. Customer identifier C003 is retrieved again, and the list of customer identifiers associated with C003 is found in the adjacency list: C002. Customer identifier C002 is already marked, so it is skipped. At this point, there are no more unprocessed customer identifiers in the associated customer identifier list, the traversal ends, and the complete set of associated customer identifiers is obtained: C002, C001, and C003.

[0103] It is evident that although the operator selected only one customer with customer identifier C002, the complete set of associated customer identifiers included all three contacts of Unit A associated with it, while customer identifiers C004 and C005, which were not associated with it, were not included.

[0104] Step 5: The data synchronization and transfer module 103 updates the responsible person field of the target customer record.

[0105] The data synchronization and transfer module 103 uses customer identifiers C002, C001, and C003 from the complete set of associated customer identifiers as the retrieval index. It then uses this complete set of associated customer identifiers along with the target responsible person identifier U002 as parameters, and calls a batch update statement that uses the customer identifier set as the filtering condition and the responsible person field as the update content. This allows the business database to update the responsible person field of all three target customer records with customer identifiers C001, C002, and C003 to U002 in one go. After the update, the three contacts of Company A—Engineer Zhang, Engineer Li, and Engineer Wang—are all assigned to the second sales personnel.

[0106] Step 6: The data synchronization and transfer module 103 obtains the target associated order record and updates its responsible person field.

[0107] The data synchronization and transfer module 103 encapsulates the complete set of associated customer identifiers C002, C001, and C003 with the target person in charge identifier U002 into an order transfer data transmission object. Based on this order transfer data transmission object, it retrieves the order record in the business database that matches any customer identifier in the complete set of associated customer identifiers in the associated field.

[0108] Since the customer identifier of the associated field record of the first order record is C002 and the customer identifier of the associated field record of the second order record is C001, both of which fall within the complete set of associated customer identifiers, these two order records are retrieved as target associated order records. The data synchronization and transfer module 103 updates the responsible person field of the above two target associated order records from U001 to U002 in a batch update operation.

[0109] After the above process, the operator selects only one customer with customer identifier C002 and triggers a transfer operation. The customer relationship data processing system will then synchronously update the responsible person field of all target customer records corresponding to the three contacts of Unit A associated with this customer, as well as all order records associated with them, to the same target responsible person identifier U002. Meanwhile, the responsible persons of Unit B and Unit C customers who are not associated with this customer will remain unchanged.

[0110] Therefore, the three related contacts of Unit A and their orders are always attributed to the same person in charge as a whole. This avoids the problem of related customers being assigned to different persons in related technologies, which leads to the dispersed ownership of related customers and the difficulty in maintaining them uniformly by the same person in charge. At the same time, it saves operators the process of manually identifying and selecting related customers one by one, and avoids the omission of related customers.

[0111] In some embodiments, the relationship building module 102 may build and traverse the relationship data model in the following manner.

[0112] First, we introduce the term entity "original responsible person identifier". The original responsible person identifier refers to the responsible person identifier currently recorded in the responsible person field of the customer record corresponding to the customer identifier to be transferred before the customer data transfer request is executed. In other words, it is the identifier of the responsible person to whom the transferred customer currently belongs.

[0113] The relationship building module 102 queries the business database for the corresponding original person in charge based on the customer identifier to be transferred.

[0114] In some implementations, the association construction module 102 reads the responsible person field of the corresponding customer record through the data access interface, using the customer identifier to be transferred as the filtering condition, and determines the value of the read responsible person field as the original responsible person identifier.

[0115] Subsequently, the relationship building module 102 uses the identifier of the customer to be transferred as the query clue to iteratively obtain the related customer records under the original person in charge's identifier, and extracts the customer identifier and key person identifier fields from the related customer records. Iterative acquisition refers to the process of using the identifier of the customer to be transferred as the initial clue, and using the customer identifier parsed in each round as the input for the next round of data retrieval, dynamically loading all related customer records from the database layer by layer along the business relationship chain formed by the key person identifier fields.

[0116] In some implementations, the relationship building module 102 uses the original responsible person's identifier as a filtering condition to initiate an iterative partial query to the business database. It reads only customer records where the responsible person's field equals the original responsible person's identifier and where there is a direct or indirect relationship through the key person's identifier field. Then, it extracts the customer identifier and key person's identifier fields from each of the read customer records. The iterative partial query abandons the practice of extracting all customer data under the original responsible person's name at once. Instead, it uses the currently traversed customer identifier as a precise filtering condition to initiate multiple rounds of lightweight searches to the business database, querying and returning only customer records with a direct key person mapping relationship. This avoids the risk of memory overflow caused by loading large amounts of irrelevant data at the source.

[0117] Since the associated customers and the customer to be transferred both belonged to the original responsible person's identifier before the transfer, the query scope was limited to the associated customer records under the original responsible person's identifier. Compared to reading all customer records under the responsible person's name at once, the iterative retrieval of associated records can accurately cover all customer records that may be related to the customer to be transferred, while avoiding loading a large amount of unrelated customer data into memory at once. This reduces the amount of data loaded in a single query and the server's memory usage, avoids the risk of server memory overflow due to an excessive number of customers under a single person's name, and improves the stability of system execution.

[0118] Next, the relationship building module 102 extracts the first customer identifier and key person identifier fields from each related customer record, and establishes a bidirectional mapping between the second customer identifier recorded in the first customer identifier and key person identifier fields to generate a related data model.

[0119] Here, the first customer identifier refers to the customer identifier of the currently extracted associated customer record itself, and the second customer identifier refers to the customer identifier recorded in the key person identifier field of the associated customer record, which points to another associated customer record.

[0120] In some implementations, the relationship building module 102 creates a mapping table in the server memory as a relationship data model. First, for each customer identifier of all read related customer records, an empty list is placed in the mapping table with the customer identifier as the key.

[0121] Then, for related customer records where the key person identifier field is not empty, the first customer identifier of the related customer record is added to the list corresponding to the second customer identifier as the key, and the second customer identifier is added to the list corresponding to the first customer identifier as the key, thereby establishing a two-way mapping between the first customer identifier and the second customer identifier that have a relationship.

[0122] The associated data model reflects the local customer relationship topology under the original person in charge. It refers to the local relationship network formed by customer identifiers with related relationships under the original person in charge as nodes and the related relationships expressed by the key person identifier field as the edges connecting the nodes.

[0123] Next, the relationship construction module 102 iteratively traverses the relationship data model starting from the customer identifier to be transferred, stores the matched customer identifiers in the pending processing set, and performs deduplication on the pending processing set after the traversal is completed, outputting the complete set of matched customer identifiers. The pending processing set refers to the set used to temporarily store the customer identifiers encountered during the traversal.

[0124] In some implementations, the relationship building module 102 creates a list as a set to be processed and creates a tag table to record customer identifiers that have been added to the set to be processed. The relationship building module 102 first adds the customer identifiers to be transferred to the set to be processed and marks them in the tag table. Then, starting from the beginning of the set to be processed, it retrieves customer identifiers one by one. For each retrieved customer identifier, it searches for related customer identifiers that have established a bidirectional mapping with the customer identifier in the relationship data model. For each related customer identifier found, it first checks whether the related customer identifier has been marked in the tag table. If it has not been marked, it adds the related customer identifier to the set to be processed and marks it in the tag table. If it has been marked, it does not add it again. Thus, the tag table is used to complete the deduplication process during the traversal.

[0125] The iterative traversal continues until there are no more unretrieved customer identifiers in the unprocessed set. The unprocessed set obtained after the traversal is completed is the complete set of associated customer identifiers.

[0126] The following embodiment further explains the method by which the association construction module 102 traverses the association data model (taking the adjacency list as an example), so that the association construction module 102 diffuses layer by layer in a breadth-first traversal manner, and limits the diffusion range of the association by setting the diffusion depth value and the relationship diffusion threshold.

[0127] First, let's explain the noun entities mentioned below.

[0128] Breadth-first traversal refers to a traversal method that starts from the starting point, visits all nodes directly adjacent to the starting point, and then visits the nodes of the next level that are adjacent to the nodes of the previous level in turn.

[0129] The diffusion depth value refers to the level of a customer identifier relative to the customer identifier to be transferred, which is the starting point of the traversal. It is used to indicate how many hops the customer identifier goes through to be associated with the customer identifier to be transferred.

[0130] The next-hop customer identifier refers to the customer identifier located at the next lower level that is directly associated with a customer identifier at the current level through a two-way mapping during the traversal process.

[0131] The relationship diffusion threshold is a pre-set value used to limit the maximum diffusion depth of customer identifiers that are allowed to be included in the set to be processed.

[0132] In some implementations, the association construction module 102 traverses the association data model in the following manner, wherein the association data model may be specifically implemented using an adjacency list in this implementation.

[0133] The association construction module 102 takes the customer identifier to be transferred as the starting point of the breadth-first traversal and sets the diffusion depth value of the customer identifier to be transferred to zero.

[0134] In some implementations, the association construction module 102 adds the customer identifier to the set to be processed, records the diffusion depth value corresponding to the customer identifier in a depth mapping table, and records the diffusion depth value corresponding to the customer identifier to be transferred as zero.

[0135] During the iterative traversal of the associated data model (e.g., adjacency list), the association construction module 102 determines the diffusion depth value of the next-hop customer identifier, which is the diffusion depth value of the previous-level associated customer identifier plus one.

[0136] In some implementations, the association construction module 102 retrieves customer identifiers one by one from the set to be processed as the upper-level associated customer identifiers, searches the adjacency table for the next-hop customer identifier that has established a bidirectional mapping with the upper-level associated customer identifier, and increments the diffusion depth value recorded by the upper-level associated customer identifier in the depth mapping table by one, and uses it as the diffusion depth value of the next-hop customer identifier.

[0137] The relationship building module 102 compares the diffusion depth value of the next-hop customer identifier with the preset relationship diffusion threshold.

[0138] If the diffusion depth value is not greater than the relationship diffusion threshold, the association construction module 102 stores the next-hop customer identifier in the pending set and records the diffusion depth value corresponding to the next-hop customer identifier in the depth mapping table, so that the next-hop customer identifier continues to diffuse to the next level in the subsequent layer-by-layer traversal.

[0139] If the diffusion depth value is greater than the relationship diffusion threshold, the association construction module 102 refuses to store the next-hop customer identifier in the pending set and truncates the next-hop customer identifier to the next level, that is, it no longer uses the next-hop customer identifier as the starting point to search for the next level customer identifier.

[0140] By setting a relationship diffusion threshold and comparing diffusion depth values ​​layer by layer in the manner described above, the relationship construction module 102 can limit the customer identifiers included in the complete set of related customer identifiers to be transferred within a range of no more than the relationship diffusion threshold hops from the customer identifier to be transferred. This avoids including weakly related customer identifiers in the transfer scope due to multiple levels of indirect transmission of the relationship when the customer relationship topology is large and the relationship is dense. This controls the number of customer identifiers involved in a single transfer operation.

[0141] Next, this embodiment further explains the group association record processing operation performed by the data synchronization and transfer module 103 in addition to updating the responsible person field.

[0142] First, let's explain the noun entities mentioned below.

[0143] Group association records are data records stored in the business database that record the affiliation between customer records and groups. Each group association record contains a customer identifier and a group identifier, indicating that the customer record corresponding to that customer identifier is assigned to the group corresponding to that group identifier. In actual business operations, groups are created and maintained by the responsible person to categorize their customers in a certain way. Therefore, the customer classification relationship expressed by the group association record is only meaningful under the name of the person who created the group.

[0144] A target group association record refers to a group association record whose customer identifier falls within the complete set of associated customer identifiers.

[0145] In some implementations, the data synchronization and transfer module 103 retrieves the corresponding target group association record from the business database based on the complete set of associated customer identifiers.

[0146] Specifically, the data synchronization and transfer module 103 uses the customer identifiers in the complete set of associated customer identifiers as the filtering condition, initiates a query to the business database, and retrieves the grouped associated records whose customer identifiers fall within the complete set of associated customer identifiers, as the target grouped associated records.

[0147] Subsequently, the data synchronization and transfer module 103 deletes the target group association record to sever the group affiliation relationship between the customer corresponding to the complete set of associated customer identifiers and the original person in charge.

[0148] Specifically, the data synchronization and transfer module 103 uses the customer identifiers in the complete set of associated customer identifiers as the filtering condition, calls a deletion statement, and deletes the grouped association records in the business database whose customer identifiers fall into the complete set of associated customer identifiers.

[0149] Since the target customer records will be maintained by the personnel identified by the target manager after the transfer, and the original groups were created by the original manager and are only meaningful under the original manager's name, by deleting the target group association records, the affiliation between the transferred customers and the groups created by the original manager can be severed, thus preventing the transferred customers from remaining in the original manager's groups after the transfer.

[0150] The following embodiment will further explain the operation of the data synchronization and transfer module 103 in generating and saving the data transfer history record.

[0151] First, let's explain the noun entities mentioned below.

[0152] The information on changes in the responsible person field of the target customer record refers to information describing the changes in the responsible person field before and after the execution of this transfer operation. In some implementations, it includes the value of the responsible person field of the target customer record before the update and the value of the responsible person field after the update.

[0153] Data transfer history refers to data records used to retain the process of a customer data transfer operation. In some implementations, it includes the identifier of the customer being transferred, the identifier of the person in charge before the transfer, the identifier of the target person in charge after the transfer, and the time when the transfer occurred.

[0154] Log storage space refers to the storage area used to save the history of data transfer. In some implementations, it is a data table in the business database specifically used to save historical records.

[0155] In some implementations, the data synchronization and transfer module 103 acquires information on changes in responsible persons before and after the target customer record is updated.

[0156] Specifically, before updating the responsible person field of the target customer record to the target responsible person identifier, the data synchronization and transfer module 103 first reads the current value of the responsible person field of the target customer record as the responsible person identifier before the update, and then uses the target responsible person identifier as the updated responsible person identifier after the update, thereby obtaining the responsible person change information.

[0157] Subsequently, the data synchronization and transfer module 103 generates a data transfer history record based on the complete set of associated customer identifiers and the change information of the person in charge, and saves the data transfer history record to the log storage space.

[0158] Specifically, the data synchronization and transfer module 103 takes the customer identifier in the complete set of associated customer identifiers, assembles the customer identifier, the previous responsible person identifier in the responsible person change information, the updated target responsible person identifier, and the current time into a data transfer history record, and writes the data transfer history record into the log storage space through the data access interface.

[0159] By generating and saving data transfer history records, the customer relationship data processing system can retain the process of each customer data transfer operation, making it easier to trace and query changes in customer ownership later.

[0160] In some embodiments, such as Figure 2 As shown, the customer relationship data processing system also includes a concurrent deduplication control module 104. The following further defines the processing procedure of this concurrent deduplication control module 104 when a customer data transfer request is assigned to a public customer.

[0161] In this embodiment, the concurrent deduplication control module 104 is a software module. In some implementations, it is a service implementation software module running on the server side. This software module reads the responsible person field of the customer record in the business database through the data access interface and performs set operations on the customer identifier set in the server memory. The concurrent deduplication control module 104 is connected between the association relationship construction module 102 and the data synchronization and transfer module 103. Specifically, the concurrent deduplication control module 104 receives the complete set of associated customer identifiers output by the association relationship construction module 102 as a method return value, and inputs the processed set of customer identifiers to the data synchronization and transfer module 103 as a method parameter, thereby connecting the two software modules.

[0162] First, we will define the noun entities mentioned below.

[0163] A public sea customer allocation request refers to a customer data transfer request that requests a customer in the public sea state to be allocated to a specific person in charge. In a public sea customer allocation request, the customer in the public sea state is a customer record with a null value in the person in charge field, and the target person in charge identifier is the person in charge identifier of the person requesting to receive the public sea customer.

[0164] The set of occupied customer identifiers refers to the set of customer identifiers in the complete associated customer identifier set whose responsible person field is not empty when executing the public sea customer allocation request, that is, customer identifiers that have been claimed by other personnel and are no longer in the public sea state.

[0165] The set of customer identifiers to be allocated refers to the set of customer identifiers that remain in the open market and are available for allocation after removing the set of customer identifiers that have been occupied from the complete set of associated customer identifiers.

[0166] Concurrent conflict failure results refer to the result data used to report to the requesting party that the customer identifier could not be successfully allocated during this allocation process because it had already been claimed by other personnel.

[0167] In some implementations, when a customer data transfer request is a public sea customer allocation request, the concurrent deduplication control module 104 operates as follows.

[0168] The concurrent deduplication control module 104 queries the current responsible person field of each customer record. Specifically, the concurrent deduplication control module 104 initiates a query to the business database using customer identifiers in the complete set of associated customer identifiers as the filtering condition, and reads the current responsible person field of each customer record corresponding to the complete set of associated customer identifiers. Subsequently, the concurrent deduplication control module 104 extracts the customer identifiers whose current responsible person field is not empty into a set of occupied customer identifiers. Then, the concurrent deduplication control module 104 removes the set of occupied customer identifiers from the complete set of associated customer identifiers to obtain the set of customer identifiers to be allocated.

[0169] Subsequently, the concurrent deduplication control module 104 inputs the set of customer identifiers to be assigned as a valid execution parameter to the data synchronization and transfer module 103, so that the data synchronization and transfer module 103 updates the responsible person field of the records corresponding to the set of customer identifiers to be assigned, with the responsible person field being empty as the database condition.

[0170] Specifically, when the data synchronization and transfer module 103 calls the batch update statement, in addition to using the customer identifier in the set of customer identifiers to be assigned as the filtering condition, it also adds the database condition that the responsible person field is empty. Therefore, the responsible person field of the customer record will only be updated to the target responsible person identifier if the responsible person field of the customer record is still empty at the time of update execution.

[0171] Since the database condition is determined by the business database when executing the update statement, even if other people claim the same public sea customer within the time interval between the query of the current person in charge field by the concurrent deduplication control module 104 and the execution of the update statement, the customer record will not be overwritten by this update because the person in charge field is no longer empty and therefore does not meet the database condition. This avoids the same public sea customer being claimed concurrently by multiple people and causing data overwriting.

[0172] Then, the concurrent deduplication control module 104 outputs the set of occupied customer identifiers as the result of the concurrent conflict failure, and sends feedback to the requesting party that the customer identifiers that could not be successfully allocated during this allocation process were taken by other personnel.

[0173] The following example illustrates the process by which the concurrent deduplication control module 104 handles public sea customer allocation requests.

[0174] Suppose there are three related customer records in the business database, with customer identifiers C101, C102, and C103. These three records are linked by a key person identifier field, and the current responsible person field is empty, meaning they are all in a public pool state. A third salesperson (responsible person identifier U003) selects the public pool customer with customer identifier C101 on the front-end interface and requests to claim the customer, triggering a public pool customer allocation request. The customer to be transferred is identified as C101, and the target responsible person is identified as U003.

[0175] Under the public sea customer allocation request, since the responsible person field of the customer to be allocated is empty, the association relationship construction module 102 uses the empty responsible person field as the same attribution condition, iteratively obtains public sea customer records that are directly or indirectly related to C101 through the key person identifier field, and constructs an association data model accordingly. The association relationship construction module 102 traverses the association data model starting from C101, obtains the complete set of associated customer identifiers as C101, C102, and C103, and outputs them to the concurrent deduplication control module 104.

[0176] The concurrent deduplication control module 104 queries the current responsible person field of each customer record using the complete associated customer identifier set C101, C102, and C103 as the filtering condition. It finds that the responsible person field of C102 has been claimed by the fourth salesperson (responsible person identifier U004) and is now non-empty, while the responsible person fields of C101 and C103 remain empty. Based on this, the concurrent deduplication control module 104 extracts C102 as an occupied customer identifier set and removes C102 from the complete associated customer identifier set, resulting in the unassigned customer identifier sets C101 and C103.

[0177] The concurrent deduplication control module 104 inputs the customer identifier sets C101 and C103 to be assigned to the data synchronization and transfer module 103. When the data synchronization and transfer module 103 calls the batch update statement, it uses C101 and C103 as filtering conditions and adds the database condition that the person in charge field is empty, and updates the person in charge field to U003.

[0178] Suppose that during the time interval between the completion of the concurrent deduplication control module 104 and the execution of the batch update statement, a fifth salesperson (identified as U005) preemptively claims C103, causing the responsible person field of C103 to become non-null at the time of update execution. Since the batch update statement includes a database condition that the responsible person field is null, C103 will not be overwritten by this update because it does not meet this condition. Ultimately, only the responsible person field of C101 is updated to U003, and the actual number of rows affected by this batch update is one.

[0179] The concurrent deduplication control module 104 outputs the occupied customer identifier set C102 as a concurrent conflict failure result, and reports to the third sales personnel that C102 failed to be allocated because it has been claimed by someone else; as for C103 that was preempted in the update window, it is identified by the difference between the actual number of rows affected by the batch update statement and the set of customer identifiers to be allocated, and is also reported to the requester as a customer identifier that was not successfully allocated.

[0180] Therefore, even if multiple sales personnel simultaneously claim the same batch of public sea customers, this system can ensure that the same public sea customer is not repeatedly assigned by multiple personnel and data is not overwritten by the dual control of the application layer's already occupied removal and the database layer's empty person-in-charge field.

[0181] The following embodiment will further explain how the data synchronization and transfer module 103 updates the responsible person field of the target associated order record.

[0182] In this embodiment, as Figure 2 As shown, the customer relationship data processing system also includes a distributed consistency guarantee module 105, which is used to ensure the consistency of the updates of the responsible person field of customer records and order records in a distributed deployment scenario where customer records and order records are managed by different service nodes.

[0183] First, we will define the noun entities mentioned below.

[0184] An order microservice node is an independently deployed service node specifically designed to manage order records. The target associated order records are stored in the data storage managed by the order microservice node. The order microservice node provides a remote call interface to update the responsible person field of the order record.

[0185] A remote call request refers to a network request sent by the data synchronization and transfer module 103 to the order microservice node to request an update of the responsible person field of the target associated order record.

[0186] A message table is a data table located in the business database that is in the same database as the target customer's record, used to store order synchronization messages.

[0187] Order synchronization messages refer to data records used to describe a task of updating the order owner field. In some implementations, they include a complete set of associated customer identifiers, the target owner identifier, and the message status.

[0188] The pending status refers to the state where the update task for the order manager field corresponding to the order synchronization message has not yet been confirmed as completed.

[0189] The "Completed" status refers to the status where the update task for the order manager field corresponding to the order synchronization message has been confirmed as completed.

[0190] A retry request refers to a network request initiated by the distributed consistency guarantee module 105 to the order microservice node based on an order synchronization message that is in a pending state, in order to request an update to the responsible person field of the target associated order record.

[0191] In this embodiment, the distributed consistency guarantee module 105 is a software module. In some implementations, it is a timed task software module that runs on the server and is triggered to execute according to a preset period. The software module reads the order synchronization messages in the pending state in the message table through the data access interface and initiates a retry request to the order microservice node through the network.

[0192] In some implementations, the data synchronization and transfer module 103 updates the responsible person field of the target associated order record by sending a remote call request to an independent order microservice node.

[0193] Specifically, the data synchronization and transfer module 103 encapsulates the complete set of associated customer identifiers and the target responsible person identifier in a remote call request, and sends the remote call request to the order microservice node. The order microservice node then updates the responsible person field of the target associated order record that matches any customer identifier in the complete set of associated customer identifiers to the target responsible person identifier.

[0194] To ensure consistency in updating the responsible person fields of the target customer record and the target associated order record, which are managed by the business database and the order microservice node respectively, the data synchronization and transfer module 103 works in the following manner.

[0195] In the business database, the data synchronization and transfer module 103 updates the responsible person field of the target customer record and simultaneously writes the pending order synchronization message to the message table in the business database. Since both the update of the responsible person field and the writing of the order synchronization message are completed in the business database, they can be within the same database transaction, ensuring that a corresponding order synchronization message is written simultaneously with the update of the responsible person field of the target customer record. Subsequently, the data synchronization and transfer module 103 sends a remote call request to the order microservice node and, upon receiving a successful response to the remote call request, updates the status of the order synchronization message to "completed."

[0196] The distributed consistency guarantee module 105 is configured to listen for order synchronization messages in the message table that are in a pending state, and to initiate retry requests to the order microservice node based on the order synchronization messages until a successful response is received.

[0197] Specifically, the distributed consistency guarantee module 105 reads order synchronization messages in the message table that are still in the pending state according to a preset period. For each order synchronization message in the pending state, it initiates a retry request to the order microservice node based on the complete set of associated customer identifiers and the target person in charge identifier recorded in the order synchronization message. After receiving a successful response, the status of the order synchronization message is updated to the completed state.

[0198] Therefore, even if the remote call request sent by the data synchronization and transfer module 103 fails due to delays or interruptions in the service node or network, the order synchronization message in the pending state will be retried by the distributed consistency guarantee module 105 until the responsible person field of the target associated order record is successfully updated, thereby avoiding the inconsistency where the responsible person field of the customer record has been updated but the responsible person field of the order record has not been updated.

[0199] When the order microservice node receives a retry request, if it verifies that the current responsible person field of the target associated order record is not equal to the target responsible person identifier, it will perform an operation to update the target responsible person identifier.

[0200] Specifically, after receiving a retry request, the order microservice node first reads the current responsible person field of the target associated order record and compares the read current responsible person field with the target responsible person identifier carried in the retry request. If the two are not equal, the responsible person field of the target associated order record is updated to the target responsible person identifier; if the two are equal, it indicates that the target associated order record has been successfully updated in the previous request, and the order microservice node does not repeat the update operation but directly returns a success response.

[0201] By comparing data before deciding whether to perform an update, even if remote call requests and retry requests are sent to the order microservice node multiple times, the update result for the responsible person field of the target associated order record remains consistent, thereby avoiding the impact of repeated requests on the target associated order record.

[0202] In some embodiments, after receiving a retry request, the order microservice node uses whether the current responsible person field is not equal to the target responsible person identifier as a criterion for whether to perform an update. However, this criterion has shortcomings in scenarios where customers are transferred multiple times consecutively, as detailed below.

[0203] Consider this scenario: An operator transfers a customer's manager from the original manager to the first target manager, but within a short time discovers the assignment is incorrect, and then transfers the same customer's manager back to the second target manager.

[0204] Therefore, the data synchronization and transfer module 103 writes two order synchronization messages into the message table in succession. The first order synchronization message, which is written first, carries the target person identifier as the first target person identifier, and the second order synchronization message, which is written later, carries the target person identifier as the second target person identifier.

[0205] In a distributed deployment scenario, due to network jitter, uneven load on order microservice nodes, or the failure of the first order synchronization message to be sent initially and the distributed consistency guarantee module 105 re-initiating a retry request, there may be an out-of-order situation where the second order synchronization message arrives at the order microservice node first and the first order synchronization message arrives at the order microservice node later.

[0206] The order microservice node first processes the second order synchronization message, updating the responsible person field of the target associated order record to the second target responsible person identifier; then it receives the delayed first order synchronization message. Based on the aforementioned inequality judgment condition, the order microservice node verifies that the current responsible person field of the target associated order record, the second target responsible person identifier, is not equal to the first target responsible person identifier carried in the first order synchronization message, and thus performs an update, incorrectly reverting the responsible person field of the target associated order record to the first target responsible person identifier.

[0207] Ultimately, the responsible person field of the target customer record is the second target responsible person identifier, while the responsible person field of the target associated order record is the first target responsible person identifier, resulting in a discrepancy between the customer and the order's attribution.

[0208] It should be noted that the first order synchronization message and the second order synchronization message correspond to two separate legitimate transfer operations, and are not the same message with duplicate content. Therefore, conventional idempotent methods for determining message content deduplication cannot identify and intercept the aforementioned out-of-order late messages.

[0209] To address the aforementioned issues, this embodiment introduces a mechanism for transferring the logical clock. The following section will first explain the nouns and entities involved in this embodiment.

[0210] The transfer logic clock field is an integer field added separately for each customer record in the business database. It is used to record the cumulative number of times the responsible person field of the customer record has been transferred and updated. The value of the transfer logic clock field increases monotonically with each transfer of the responsible person of the customer record.

[0211] The transfer logical clock value refers to the value of the transfer logical clock field at a certain moment. The transfer clock watermark field is an integer field maintained separately for each associated customer identifier on the order microservice node side. It is used to record the maximum transfer logical clock value corresponding to the associated customer identifier that the order microservice node has updated based on the order manager field.

[0212] It should be noted that the transfer logic clock field is bound to the business entity of the customer record, rather than to a single message. Therefore, it can express the chronological order of multiple transfer operations that occur successively for the same customer, that is, the causal chronological order at the customer entity level.

[0213] In some implementations, the processing procedure of this embodiment is as follows.

[0214] On the data synchronization and transfer module 103 side, each time the data synchronization and transfer module 103 updates the responsible person field of a customer record, in the same local database transaction that updates the responsible person field, the transfer logic clock field of the customer record is incremented by a preset step size.

[0215] Since the update of the responsible person field and the increment of the transfer logical clock field are within the same local database transaction, they either take effect together or roll back together, thus ensuring that each successful responsible person transfer corresponds to a strictly incrementing transfer logical clock value.

[0216] When writing an order synchronization message to the message table, the data synchronization and transfer module 103 writes the incremented transfer logic clock value along with the complete set of associated customer identifiers and the target person in charge identifier into the order synchronization message.

[0217] Therefore, each order synchronization message written in the message table carries a transfer logical clock value that represents the order of the transfer operation in the customer subject dimension. The order synchronization message corresponding to the earlier transfer operation carries a smaller transfer logical clock value, and the order synchronization message corresponding to the later transfer operation carries a larger transfer logical clock value.

[0218] On the order microservice node side, in addition to maintaining the target associated order records, the order microservice node also maintains a transfer clock water level field for each associated customer identifier. The transfer clock water level field is persistently stored in the data storage managed by the order microservice node.

[0219] After receiving a remote call request or retry request, the order microservice node processes it as follows:

[0220] Extract the transfer logical clock value from the order synchronization message carried by the request; in the data storage managed by the order microservice node, read the current value of the transfer clock water level field using the associated customer identifier corresponding to the order synchronization message as the index; compare the extracted transfer logical clock value with the current value of the read transfer clock water level field.

[0221] If the extracted transfer logic clock value is significantly greater than the current value of the transfer clock watermark field, the order microservice node determines that the order synchronization message conforms to the true causal sequence of the customer subject dimension, updates the responsible person field of the target associated order record to the target responsible person identifier carried in the order synchronization message, and pushes the transfer clock watermark field up to the extracted transfer logic clock value.

[0222] The operations of updating the responsible person field and pushing up the transfer clock water level field are completed in the same local database transaction on the order microservice node side. The transfer clock water level field record corresponding to the associated customer identifier is read and pushed up while holding a row-level lock, thereby avoiding competition between reading and pushing up the transfer clock water level field when processing multiple order synchronization messages of the same associated customer identifier concurrently.

[0223] If the extracted transfer logic clock value is less than or equal to the current value of the transfer clock water level field, the order microservice node determines that the order synchronization message is an expired message that occurred earlier in the customer subject dimension but was delayed due to network retransmission or out-of-order arrival. The order microservice node does not perform any update on the responsible person field of the target associated order record and directly returns a success response.

[0224] After the order microservice node returns a successful response, the distributed consistency guarantee module 105 updates the status of the corresponding order synchronization message in the message table to the completed status, so that it will no longer retry the order synchronization message.

[0225] Through the above embodiments, in the aforementioned application scenario where customers are continuously transferred, the transfer logic clock value carried by the first order synchronization message is less than the transfer logic clock value carried by the second order synchronization message. Even if the second order synchronization message arrives at the order microservice node first and the first order synchronization message arrives later, when processing the first-arriving second order synchronization message, the order microservice node will update it because its transfer logic clock value is greater than the current transfer clock watermark field, and push the transfer clock watermark field up to the transfer logic clock value of the second order synchronization message; when the late first order synchronization message arrives, because its transfer logic clock value is less than the already pushed-up transfer clock watermark field, the order microservice node will discard it as an expired message and return a success response, and will no longer revert the responsible person field of the target associated order record to the first target responsible person identifier.

[0226] Therefore, the responsible person field of the target associated order record is ultimately kept as the second target responsible person identifier, consistent with the responsible person field of the target customer record, avoiding the rollback of the order responsible person field caused by late messages arriving out of order.

[0227] To ensure that the transfer logic clock field continues to monotonically increase even when a customer record is deleted and then restored, this embodiment further stipulates the following processing rules.

[0228] When a customer record is moved to the recycle bin by the customer relationship data processing system, the transfer logic clock field of the customer record is retained along with other fields of the customer record. When the customer record is restored, the customer relationship data processing system reads the transfer logic clock value retained before the customer record was moved to the recycle bin, and uses a value not less than the retained transfer logic clock value as the value of the transfer logic clock field of the restored customer record. This ensures that the transfer logic clock value corresponding to subsequent transfer operations of the restored customer record is still greater than the transfer logic clock value corresponding to the transfer operations that occurred before the customer record was deleted.

[0229] This avoids the transfer logic clock field returning to zero after restoration, and thus prevents the restored order synchronization message from being mistakenly judged as an expired message by the order microservice node because it carries a small transfer logic clock value.

[0230] It should be noted that in this embodiment, the preset step size for incrementing the transfer logic clock field can be 1 or other positive integers greater than 1, as long as the transfer logic clock value corresponding to each transfer of the person in charge is strictly greater than the transfer logic clock value corresponding to the previous transfer of the person in charge of the customer record.

[0231] In this embodiment, the transfer clock water level field can be stored either in the relational database managed by the order microservice node or in other persistent data storage managed by the order microservice node.

[0232] This invention also provides a customer relationship data processing method for the customer relationship data processing system described in the foregoing embodiments. This method is executed collaboratively by the various software modules of the aforementioned customer relationship data processing system.

[0233] The method is described in detail below. The meanings of the nouns and technical terms used in this embodiment, such as customer records, customer identifiers, responsible person fields, key person identifier fields, responsible person identifiers, target responsible person identifiers, associated data models, order records, target associated order records, and business databases, are the same as those defined in the specific implementation of the aforementioned customer relationship data processing system, and will not be repeated here.

[0234] like Figure 3 As shown, the method includes the following steps:

[0235] S201, in response to a customer data transfer request, retrieve the key person identification field of the customer record.

[0236] The customer data transfer request includes the identifier of the customer to be transferred and the identifier of the target person in charge.

[0237] In some implementations, this step is carried out in conjunction with the request receiving module and the association building module. When the operator selects one or more customers to be transferred and designates a receiving person on the front-end interface, the front-end interface sends a Hypertext Transfer Protocol request carrying a data transmission object to the server. The request receiving module receives the request and parses the data transmission object carried in the request into a customer identifier to be transferred and a target responsible person identifier. The customer identifier to be transferred is the customer identifier of one or more customers selected by the operator, and the target responsible person identifier is the responsible person identifier of the receiving person designated by the operator.

[0238] After receiving the customer identifier to be transferred, the relationship building module initiates a query to the business database through the data access interface, reads a set of customer records, and extracts the customer identifier and key person identifier fields of each customer record for use in subsequent steps to build the relationship data model.

[0239] S202, Construct a relational data model reflecting the relationships between customers based on the key person identification field.

[0240] In some implementations, this step is performed by the relationship building module. The relationship building module creates a mapping table in the server's memory as the relationship data model. For each customer record read in step S201, the relationship building module first places an empty list in the mapping table with the customer identifier of that customer record as the key.

[0241] After the placeholder is completed, the relationship building module iterates through the read customer records again. For customer records where the key person identifier field is not empty and the customer identifier recorded in the key person identifier field falls within the range of customer identifiers to be transferred, the customer identifier of the customer record is added to the list corresponding to the key person identifier field as the key. At the same time, the customer identifier recorded in the key person identifier field is added to the list corresponding to the customer identifier of the customer record as the key. In this way, a two-way relationship is established between the customer identifiers of two customer records that have a relationship, and finally a relationship data model is formed.

[0242] S203, starting with the customer identifier to be transferred, traverse the associated data model to obtain a complete set of associated customer identifiers.

[0243] In some implementations, this step is performed by the association building module. The association building module creates a list of associated customer identifiers and a tag table for marking processed customer identifiers. The customer identifiers to be transferred are first added to the list of associated customer identifiers and then marked in the tag table.

[0244] Subsequently, the relationship building module retrieves customer identifiers one by one from the beginning of the list of associated customer identifiers. For each retrieved customer identifier, it searches the list of customer identifiers associated with that customer identifier in the relationship data model. For each associated customer identifier in the list of customer identifiers, the relationship building module queries the tag table to see if the associated customer identifier has been tagged. If it has not been tagged, it adds the associated customer identifier to the list of associated customer identifiers and tags it in the tag table. If it has been tagged, it skips the associated customer identifier.

[0245] Since newly added associated customer identifiers will also be traversed subsequently, the traversal process will continue until there are no more unprocessed customer identifiers in the associated customer identifier list.

[0246] The list of associated customer identifiers obtained after the traversal is the complete set of associated customer identifiers. This complete set of associated customer identifiers includes the customer identifier to be transferred itself and all customer identifiers directly or indirectly associated with it.

[0247] S204: Using the identifiers in the complete set of associated customer identifiers as the retrieval index, extract the corresponding target customer records from the preset business database.

[0248] In some implementations, this step is performed by the data synchronization and transfer module. The data synchronization and transfer module receives the complete set of associated customer identifiers output by the association relationship building module as a method parameter, and uses the customer identifiers in the complete set of associated customer identifiers as a retrieval index to retrieve customer records in the business database whose customer identifiers match the complete set of associated customer identifiers through the data access interface, thereby obtaining the target customer record.

[0249] S205, update the responsible person field of the target customer record to the target responsible person identifier.

[0250] In some implementations, this step is performed by the data synchronization and transfer module. The data synchronization and transfer module takes all customer identifiers in the complete associated customer identifier set and the target manager identifier as parameters, and calls a batch update statement that uses the customer identifier set as the filtering condition and the manager field as the update content. The business database then updates the manager field of all target customer records matched by the search index to the target manager identifier in one go.

[0251] S206, Retrieve the target associated order record associated with the complete set of associated customer identifiers.

[0252] In some implementations, this step is performed by the data synchronization and transfer module. The data synchronization and transfer module encapsulates the complete set of associated customer identifiers into an order transfer data transmission object, and retrieves the order record in the business database whose association field matches any customer identifier in the complete set of associated customer identifiers, thereby obtaining the target associated order record.

[0253] S207 updates the responsible person field of the target associated order record to the target responsible person identifier, so that the related customers and their orders belong to the same responsible person.

[0254] In some implementations, this step is performed by the data synchronization and transfer module. The data synchronization and transfer module uses the target associated order record retrieved in step S206 and the target responsible person identifier together as parameters, and updates the responsible person field of the target associated order record to the target responsible person identifier through a batch update operation. After steps S205 and S207, the responsible person fields of all target customer records corresponding to the complete set of associated customer identifiers and the responsible person fields of all target associated order records are synchronously updated to the same target responsible person identifier, ensuring that related customers and their orders belong to the same responsible person.

[0255] It should be noted that the labels of steps S201 to S207 are only used to clearly describe the implementation process of each step and do not constitute a restriction on the execution order of each step. Without violating the processing logic of this method, the execution order of some steps can be adjusted. For example, there is no necessary sequential relationship between step S206 (obtaining the target associated order record) and steps S204 to S205 (processing the target customer record).

[0256] Provided that the functions of responding to customer data transfer requests, constructing and traversing the associated data model to obtain a complete set of associated customer identifiers, and synchronously updating the responsible person fields of the target customer record and the target associated order record are realized, the adjustment of the above steps does not constitute a limitation on the scope of protection of this invention.

[0257] The following describes an exemplary customer relationship data processing system provided by an embodiment of the present invention. Figure 4 This is a schematic diagram of an exemplary hardware architecture of the customer relationship data processing system provided in an embodiment of the present invention.

[0258] In some embodiments, the customer relationship data processing system may be an electronic device, or the customer relationship data processing system may include an electronic device. The electronic device includes a processor, memory, and a network interface connected via a system bus. The processor of the electronic device provides computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores an operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The database of the electronic device stores data. The network interface of the electronic device is used to communicate with other external terminals or servers via a network connection. In some embodiments, the network interface may be a wired network interface; in some embodiments, the network interface may also be a wireless network interface. When the computer program is executed by the processor, it implements the methods in the embodiments of the present invention.

[0259] Those skilled in the art will understand that Figure 4 The architecture shown is merely a block diagram of a portion of the architecture related to the present invention and does not constitute a limitation on the electronic device to which the present invention is applied. Specific electronic devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0260] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

[0261] As used in the above embodiments, depending on the context, the term "when..." can be interpreted as meaning "if...", "after...", "in response to determining...", or "in response to detecting...". Similarly, depending on the context, the phrase "when determining..." or "if (the stated condition or event) is interpreted as meaning "if determining...", "in response to determining...", "when (the stated condition or event) is detected", or "in response to detecting (the stated condition or event)".

[0262] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on an electronic device, all or part of the processes or functions described in the embodiments of the present invention are generated. The electronic device may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive), etc.

[0263] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A customer relationship data processing system, characterized in that, include: The request receiving module is configured to receive customer data transfer requests, wherein the customer data transfer request includes the identifier of the customer to be transferred and the identifier of the target person in charge. The relationship building module is connected to the request receiving module and is configured to extract the key person identifier field of the customer record, build a relationship data model reflecting the relationship between customers based on the key person identifier field, and traverse the relationship data model starting from the identifier of the customer to be transferred to obtain a complete set of related customer identifiers. The data synchronization and transfer module is connected to both the request receiving module and the association construction module, and is configured as follows: Using the identifiers in the complete set of associated customer identifiers as the retrieval index, the corresponding target customer record is extracted from the preset business database, and the responsible person field of the target customer record is updated to the target responsible person identifier; Retrieve the target associated order record associated with the complete set of associated customer identifiers; Update the responsible person field of the target associated order record to the target responsible person identifier, so that the related customers and their orders belong to the same responsible person.

2. The system according to claim 1, characterized in that, The specific configuration of the association construction module is as follows: Based on the customer identifier to be transferred, query the corresponding original person in charge identifier in the business database; Using the customer identifier to be transferred as a query clue, iteratively obtain multiple related customer records under the original person in charge's identifier; Extract the first customer identifier and the key person identifier fields from each of the associated customer records; A bidirectional mapping is established between the first customer identifier and the second customer identifier recorded in the key person identifier field to generate the associated data model; Starting with the customer identifier to be transferred, iterate through the associated data model, store the associated customer identifiers that are matched in the traversal into the set to be processed, and after the traversal is completed, perform deduplication processing on the set to be processed to output the complete set of associated customer identifiers.

3. The system according to claim 2, characterized in that, When traversing the associated data model, the relationship building module is also configured to perform the following operations: The customer identifier to be transferred is used as the starting point of the breadth-first traversal, and the diffusion depth value of the customer identifier to be transferred is set to zero. During the iterative traversal of the associated data model layer by layer, the diffusion depth value of the next-hop customer identifier is determined. The diffusion depth value of the next-hop customer identifier is one more than the diffusion depth value of the associated customer identifier of the previous level. The diffusion depth value of the next-hop customer identifier is compared with the preset relationship diffusion threshold; If the diffusion depth value is not greater than the relationship diffusion threshold, then the next-hop customer identifier is stored in the set to be processed; If the diffusion depth value is greater than the relationship diffusion threshold, then the next-hop customer identifier is refused to be stored in the pending set, and the traversal of the next-hop customer identifier to the next level is truncated.

4. The system according to claim 1, characterized in that, The data synchronization and transfer module is also configured to: Based on the complete set of associated customer identifiers, retrieve the corresponding target group association records from the business database; Delete the target group association record to remove the group affiliation relationship between the customer corresponding to the complete set of associated customer identifiers and the original person in charge.

5. The system according to claim 1, characterized in that, It also includes a concurrent deduplication control module, which is connected between the association construction module and the data synchronization and transfer module; When the customer data transfer request is a public sea customer allocation request, the concurrent deduplication control module is configured as follows: Query the current responsible person field for each customer record; Extract the customer identifiers whose current responsible person field is not empty into a set of customer identifiers that are already in use; The set of customer identifiers to be allocated is obtained by removing the already occupied customer identifier set from the complete set of associated customer identifiers. The set of customer identifiers to be assigned is input as a valid execution parameter to the data synchronization and transfer module, so that the data synchronization and transfer module updates the responsible person field of the records corresponding to the set of customer identifiers to be assigned, with the responsible person field being empty as a database condition. Output the set of occupied customer identifiers as the result of the concurrent conflict failure.

6. The system according to claim 1, characterized in that, The data synchronization and transfer module is also configured to: Obtain the information on changes in responsible persons before and after the target customer record update; Based on the complete set of associated customer identifiers and the change information of the person in charge, a data transfer history record is generated and saved to the log storage space.

7. The system according to any one of claims 1-6, characterized in that, When updating the responsible person field of the target associated order record, the data synchronization and transfer module achieves this by sending a remote call request to an independent order microservice node; The system also includes a distributed consistency guarantee module connected to the data synchronization and transfer module; The data synchronization and transfer module is specifically configured as follows: In the business database, update the responsible person field of the target customer record, and synchronously write the order synchronization message in the pending state to the message table in the business database; Upon receiving a successful response to the remote call request, the status of the order synchronization message is updated to "completed". The distributed consistency guarantee module is configured as follows: Listen for order synchronization messages that are in a pending state in the message table, and initiate a retry request to the order microservice node based on the order synchronization message until a successful response is received; When the order microservice node receives the retry request, if it verifies that the current person in charge field of the target associated order record is not equal to the target person in charge identifier, it will perform an operation to update the target person in charge identifier.

8. A customer relationship data processing method, characterized in that, The method, used in the system according to any one of claims 1-7, comprises: In response to a customer data transfer request, the key person identification field of the customer record is obtained, wherein the customer data transfer request includes the identifier of the customer to be transferred and the identifier of the target person in charge; Based on the key person identification field, a relational data model reflecting the relationships between customers is constructed; Starting with the customer identifier to be transferred, traverse the associated data model to obtain a complete set of associated customer identifiers; Using the identifiers in the complete set of associated customer identifiers as the retrieval index, the corresponding target customer records are extracted from the preset business database; Update the responsible person field of the target customer record to the target responsible person identifier; Retrieve the target associated order record associated with the complete set of associated customer identifiers; Update the responsible person field of the target associated order record to the target responsible person identifier, so that the related customers and their orders belong to the same responsible person.

9. A customer relationship data processing system, characterized in that, Includes memory and one or more processors; The memory is coupled to the one or more processors, the memory being used to store computer program code, the computer program code including computer instructions, the one or more processors invoking the computer instructions to cause the customer relationship data processing system to perform the method as described in claim 8.

10. A computer-readable storage medium storing computer instructions, characterized in that, When the computer instructions are executed on the customer relationship data processing system, the customer relationship data processing system performs the method as described in claim 8.

Images