Event-driven customer relationship management method and customer relationship management system

Abstract

The invention provides an event-driven customer relationship management method and a customer relationship management system. The method is applied to a scheduling engine in a customer relationship management system, a process manager maintains at least one LTC process model which is completely arranged, and the method comprises the following steps: determining a target LTC process model of a to-be-propelled process from the at least one LTC process model; advancing the progress of the target LTC process according to the process structure; wherein for each domain node in the N domain nodes, under the condition that the current progress of the target LTC flow is in the domain node, generating a node task of the domain node according to the service logic corresponding to the domain node and the task description information of the domain node, and triggering a corresponding executor to execute the node task; and in response to the field event published after the execution is monitored, propelling the current progress to flow to the next field node under the condition that a process propelling condition is met, or ending propelling the target LTC process under the condition that a process ending condition is met.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of customer management technology, and in particular to an event-driven customer relationship management method and customer relationship management system. Background Technology

[0002] Customer Relationship Management (CRM) systems are essential tools for businesses to manage sales, customer service, and marketing activities. These systems typically support interactions between businesses and customers through integrated task and process design. For example, specific tasks related to a particular customer are coded into established business processes to ensure that all operations conform to the company's business logic and relevant requirements. In processing sales orders, for instance, a series of steps—from quoting, placing an order, shipping, to receiving payment—are tightly linked, forming a continuous and inseparable overall process.

[0003] However, while such CRM systems can ensure the consistency and integrity of business processes, they also result in insufficient system flexibility, making it difficult to quickly adapt to market changes or meet the personalized needs of different customers. For example, if a company needs to adjust its business processes to respond to new market demands, it often needs to reconfigure the entire process or even write new code. This is not only time-consuming and labor-intensive, but also prone to errors and urgently needs improvement. Summary of the Invention

[0004] In view of the above, one or more embodiments of this specification provide the following technical solutions:

[0005] According to a first aspect of one or more embodiments of this specification, an event-driven customer relationship management method is proposed for use in a customer relationship management system including a scheduling engine and a process manager, the process manager maintaining at least one orchestrated lead-to-cash (LTC) process model, the method comprising:

[0006] The scheduling engine determines the target LTC process model for the process to be advanced from the at least one LTC process model. The process structure of the target LTC process model is composed of N domain nodes connected in sequence, wherein each domain node is used to represent a business stage in the target LTC process and is associated with corresponding business logic. The configuration information of the target LTC process model includes the task description information of each domain node, where N is an integer greater than 1.

[0007] The scheduling engine advances the target LTC process according to the process structure; wherein, for each of the N domain nodes:

[0008] When the current progress of the target LTC process is at the domain node, the scheduling engine generates the node task of the domain node according to the business logic corresponding to the domain node and the task description information of the domain node, and triggers the corresponding executor to execute the node task.

[0009] The scheduling engine responds to the domain event published after the node task is completed by listening to it. If the process advancement conditions between the domain node and its next domain node are met, the current progress is advanced to the next domain node, or the process termination conditions corresponding to the domain node are met, and the advancement of the target LTC process is terminated.

[0010] According to a second aspect of one or more embodiments of this specification, a customer relationship management system is proposed, the system comprising a scheduling engine and a process manager, the process manager maintaining at least one orchestrated lead-to-cash (LTC) process model, the scheduling engine being used for:

[0011] From the at least one LTC process model, a target LTC process model for the process to be advanced is determined. The process structure of the target LTC process model consists of N domain nodes connected in sequence, wherein each domain node is used to represent the business logic of a business stage in the target LTC process. The configuration information of the target LTC process model includes the task description information of each domain node, where N is an integer greater than 1.

[0012] The target LTC process is advanced according to the described process structure; wherein, for each of the N domain nodes:

[0013] When the current progress of the target LTC process is at this domain node, generate the node task of the domain node according to the business logic and task description information of the domain node, and trigger the corresponding executor to execute the node task;

[0014] In response to a domain event published after the node task is completed, the current progress is advanced to the next domain node if the process advancement conditions between the domain node and its next domain node are met, or the advancement of the target LTC process is terminated if the process termination conditions corresponding to the domain node are met.

[0015] According to a fourth aspect of one or more embodiments of this specification, an electronic device is provided, comprising: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in the second or third aspect by executing the executable instructions.

[0016] According to a fifth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions thereon, which, when executed by a processor, implement the steps of the method as described in the second or third aspect.

[0017] According to a sixth aspect of one or more embodiments of this specification, a computer program product is provided, comprising a computer program / instructions that, when executed by a processor, implement the steps of the method as described in the second or third aspect.

[0018] As can be seen from the above embodiments, the process manager in the customer relationship management system described in this specification maintains at least one orchestrated LTC process model. The system's scheduling engine first determines the target LTC process model from this model, which includes the corresponding process structure and configuration information (i.e., the metadata configured for the model). The process structure consists of N domain nodes connected sequentially, where each domain node represents a business stage in the target LTC process and is associated with corresponding business logic. The configuration information includes task description information for each domain node. Based on this, the scheduling engine can advance the progress of the target LTC process according to the process structure, that is, advance the process progress sequentially between the nodes according to the connection order between the N domain nodes. For each domain node: when the current progress of the target LTC process is at that domain node, a node task for that domain node can be generated according to the business logic and task description information of that domain node, and the corresponding executor can be triggered to execute the node task; then, in response to the domain event released after the node task is completed, the current progress can be advanced to the next domain node if the process advancement conditions between that domain node and its next domain node are met, or the advancement of the target LTC process can be terminated if the process termination conditions corresponding to that domain node are met.

[0019] It is understandable that the above embodiments actually propose a novel event-driven CRM solution: in the process orchestration phase (i.e., the model configuration phase), by configuring the task description information, the upper-level business logic associated with each domain node is decoupled and separated from the lower-level node tasks that need to be executed during the actual process. This allows users to flexibly orchestrate the upper-level business logic according to actual business needs without having to worry about how the lower-level node tasks are implemented, helping users to flexibly respond to actual business needs (such as the personalized needs of specific customers) through efficient orchestration. Simultaneously, this solution uses an event-driven approach to ensure that the decoupled lower-level node tasks can still be effectively executed asynchronously according to the upper-level business logic. That is, after the node task is executed, the corresponding domain event is generated and published, and the scheduling engine, after listening to the domain event, determines whether the corresponding process advancement or process termination conditions are met, and then decides how to advance the target LTC process to continue or directly terminate the process. Therefore, this solution not only achieves effective decoupling of business logic and node tasks, but also further ensures that the decoupled node tasks can be executed asynchronously through an event-driven approach. Thus, it not only allows users to flexibly orchestrate business processes to meet actual business needs, but also helps to improve the overall process advancement efficiency of the system, resulting in significant improvements. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the architecture of a customer relationship management system provided in an exemplary embodiment.

[0021] Figure 2 This is a schematic diagram of a process orchestration and advancement provided in an exemplary embodiment.

[0022] Figure 3 This is a flowchart of an event-driven customer relationship management method provided in an exemplary embodiment.

[0023] Figure 4 This is a schematic diagram of the structure of a device provided in an exemplary embodiment.

[0024] Figure 5 This is a block diagram of an event-driven customer relationship management device provided in an exemplary embodiment. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0026] Customer Relationship Management (CRM) systems are essential tools for businesses managing sales, customer service, and marketing activities. These systems typically support customer interactions through integrated task and process design. For example, specific tasks related to a particular customer are coded into established business processes to ensure that all operations conform to the company's business logic and relevant requirements. In processing sales orders, for instance, a series of steps—from quoting, order placement, and shipment to payment collection—are tightly linked, forming a continuous and inseparable overall process.

[0027] However, while such CRM systems can ensure the consistency and integrity of business processes, they also result in insufficient system flexibility, making it difficult to quickly adapt to market changes or meet the personalized needs of different customers. For example, if a company needs to adjust its business processes to respond to new market demands, it often needs to reconfigure the entire process or even write new code. This is not only time-consuming and labor-intensive, but also prone to errors and urgently needs improvement.

[0028] The inventors discovered that the reason why traditional CRM systems have the above problems is that there is a strong coupling between the upper-level business processes and the lower-level node tasks in such systems. That is, the various lower-level node tasks involved in the advancement of the upper-level business processes are written into the business processes during the process orchestration stage. Therefore, the degree of dependence between the driving methods of tasks and processes is too high.

[0029] To address this issue, this specification proposes a novel event-driven CRM solution that decouples upper-layer business logic from lower-layer node tasks. By using event-driven mechanisms, it ensures that the decoupled node tasks can be executed asynchronously. This not only allows users to flexibly orchestrate business processes to meet actual business needs but also helps improve the overall process efficiency of the system. The specific implementation of this solution is described below with reference to the accompanying drawings and embodiments.

[0030] Figure 1 This is a schematic diagram of the architecture of a customer relationship management system provided in an exemplary embodiment. For example... Figure 1 As shown, the customer relationship management system includes a server 11, a network 10, and several electronic devices, such as a PC (Personal Computer) 12, a mobile phone 13, etc.

[0031] Server 11 can be a physical server containing an independent host, or it can be a virtual server hosted in a host cluster. During operation, server 11 can run server-side programs for a certain application to implement the relevant functions of that application. For example, when server 11 runs a CRM service program, it can be implemented as a corresponding CRM service platform.

[0032] PC 12 and mobile phone 13 are just some of the types of electronic devices that users can use. In reality, users can obviously also use electronic devices such as tablets, laptops, PDAs (Personal Digital Assistants), wearable devices (such as smart glasses, smartwatches, etc.), etc., and one or more embodiments in this specification do not limit this. During operation, the electronic device can run a client-side program of an application to achieve the relevant functions of that application. For example, when the electronic device runs a CRM service program, it can act as a client for that CRM service. The aforementioned CRM service client application can be launched and run on the electronic device. This client-side program can be a native application installed on the electronic device, or it can be a mini-program, quick app, or other similar form. Of course, when using web technologies such as HTML5 or similar, the relevant functions can be achieved through a page displayed by a browser. This browser can be a standalone browser application or a browser module embedded in some applications.

[0033] As for the network 10 that enables interaction between electronic devices such as PC 12 and mobile phone 13 and server 11, the communication can be implemented using either wired or wireless networks based on the communication methods supported by the respective electronic devices. This specification does not impose any restrictions on this. For example, PC 12 can support both wired and wireless communication, so it can use either wired or wireless networks as needed. Mobile phone 13 typically only supports wireless communication, so it can use a wireless network for communication.

[0034] It should be noted that, Figure 1 The diagram illustrates the hardware architecture of a Customer Relationship Management System (CRM). From a software perspective, the CRM system may include a CRM server and a CRM client. The scheduling engine (used to schedule and advance the progress of the LTC process) and the process manager (used to manage the orchestrated LTC process models), as described in the embodiments below, can be functional modules deployed in the CRM server. In addition, the CRM server may also deploy functional modules such as a process orchestration engine (used to provide process orchestration services to users), a task manager (used to manage node tasks generated by the scheduling engine during the LTC process), and an event manager (used to manage domain events published after node tasks are completed). The specific functions of these modules are described in the embodiments below and will not be elaborated upon here.

[0035] Furthermore, given that users of a customer relationship management system may have multiple roles, the CRM client can include various types so that users with different roles can use different types of CRM clients; or the CRM client can support multiple process-related functions / services so that different users can use the functions / services provided by the client. For example, the CRM client running on PC 12 can provide process orchestration services to a first user (such as process orchestrators, pre-sales service personnel, etc.), allowing the first user to orchestrate business-related processes (i.e., workflows) through visual operations based on this service, obtaining the corresponding LTC process model. The CRM client running on mobile phone 13 can provide task execution services to a second user (such as liaisons and managers from both sides of the business), allowing the second user to execute node tasks generated during the process that are related to their own responsibilities, such as liaisons performing contract creation and signing tasks, and managers performing contract approval tasks.

[0036] The user / enterprise information (including but not limited to user device information, user personal information, enterprise internal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this manual are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals shall be provided for users to choose to authorize or refuse.

[0037] Figure 2 This is a schematic diagram illustrating a process orchestration and execution as provided in an exemplary embodiment. For example... Figure 2 As shown, the complete process consists of two phases: the arrangement phase and the implementation phase.

[0038] The Customer Relationship Management System described in this specification operates based on the concepts of a Domain Model. A Domain Model is an abstract representation of key concepts and their relationships within the CRM-related problem domain. In traditional Domain-Driven Design (DDD), the Domain Model includes not only traditional elements such as Entities and Value Objects, but may also involve Services and Events. These elements work together to describe business processes.

[0039] Before orchestrating the process, it's necessary to predefine some CRM primary domains, such as leads, customers, opportunities, quotes, contracts, and orders. These domains are the top-level classifications of business data, representing the core business entities of the enterprise. Then, business entities within each primary domain (such as opportunities and contracts) can be mapped to corresponding LTC process models, binding business scenarios with process templates. When a business entity (such as an "opportunity") is created or modified, the system automatically matches the corresponding LTC process based on its attributes. For example, when an "opportunity" enters the system, it triggers the LTC process of "Sales Opportunity → Quote → Contract → Order"; this step is a "prerequisite for process initiation," determining "which path to take next" based on actual business needs. LTC rules define "who does what under what conditions," but they are not directly executed. Instead, the process management module is responsible for transforming these rules into actual "flowcharts" or "workflows." Next, during the "process node orchestration" stage, the aforementioned first user can dynamically adjust the node order, conditional branches, approval steps, etc., according to actual business needs. This step determines the domain nodes and their connections in the LTC process model and meets the personalized needs of actual business. For example, a "quotation approval process" may include multiple approvers and judgment logic for different amount thresholds. In addition, the first user also needs to configure corresponding metadata for each domain node according to actual business needs, such as configuring task description information to indicate how to generate node tasks, and configuring event description information to indicate how to publish domain events, etc.

[0040] Finally, during the actual implementation of the orchestrated LTC process model, when the process progresses to a domain node (such as "quotation review"), the scheduling engine will create / generate the corresponding "node task (i.e., task instance)" and assign it to various executors for execution through "task outreach" (such as pushing it to the sales manager for approval); "task listening" means that the scheduling engine continuously monitors the task status (completed / timed out / pending) by listening to events; and when it hears that a task has been completed, it pushes the process to the next stage.

[0041] like Figure 2 As shown, the "Domain Creation" below and the "Domain-Driven Events" above embody the closed-loop mechanism of "event-driven + domain flow," reflecting the intelligent process management concept of moving from "passive response" to "proactive advancement," as well as the system design philosophy of this solution: "triggered by events, gradually advancing, and ultimately completing the domain closed loop."

[0042] Figure 3This is a flowchart illustrating an event-driven customer relationship management method provided in an exemplary embodiment. The method is applied to a customer relationship management system, which includes a scheduling engine and a process manager. The scheduling engine (also known as a workflow engine) is a functional module within the system specifically designed to define, execute, and monitor business processes. It can automatically advance the development of process instances according to preset rules (i.e., advance the progress of the target LTC process according to the process structure defined in the target LTC process model). The process manager maintains at least one orchestrated LTC (Lead to Cash, L2C) process model.

[0043] It should be noted that the LTC process (or LTC workflow) described in this solution is commonly used by enterprises, institutions, organizations, and groups. The following explanation uses an enterprise as an example. The LTC process is an end-to-end customer value realization process for enterprises (such as B2B companies). Its core objective is to efficiently, systematically, and traceably convert a potential customer (lead) into actual revenue (cash / payment). In other words, the LTC workflow is a standardized operational process for an enterprise "from customer discovery to payment collection," which can be implemented across marketing, sales, delivery, and finance stages. Each stage has clear responsibilities and seamless connections, ensuring fast customer conversion, low risk, and stable payment collection.

[0044] The LTC process model orchestrated (i.e., created / generated) by the user is a collection of data / information used to record the aforementioned LTC process. Intuitively, this model can be viewed as a flowchart and necessary configuration information. Each orchestrated LTC process model includes a process structure and configuration information (i.e., metadata configured for the model). The process structure consists of N domain nodes connected sequentially, where each domain node represents a business stage in the corresponding LTC process and is associated with corresponding business logic. The configuration information includes task description information for each domain node. Here, N is an integer greater than 1, meaning that the process structure of any LTC process model contains multiple domain nodes.

[0045] In one embodiment, the customer relationship management system further includes a process orchestration engine, which provides process orchestration services to a first user. Based on this, when generating any LTC process model, the process orchestration engine can display alternative process components in the process orchestration interface, such as visual components corresponding to each of the aforementioned primary domains, like squares, diamonds, arrows, and connecting lines. Based on this, the first user can select the appropriate component (i.e., the target process component below) for orchestration according to actual business needs. Correspondingly, the process orchestration engine can generate any LTC process model containing the target process component based on the visual orchestration operations performed by the first user on the target process component in the process orchestration interface.

[0046] For example, suppose a courier company needs to configure a high-priority customer contract signing process for a large e-commerce platform. This customer has specific requirements: insurance service, contract signing within 48 hours, and the first order must be fulfilled by a dedicated operations team. Traditional CRM process orchestration would require the courier company's employees (operations configuration staff) to write code according to these requirements. This solution, however, can achieve this quickly through visual orchestration. When the operations configuration staff (i.e., the aforementioned first user) opens the process orchestration interface, the system automatically displays a library of visual components corresponding to the CRM primary domain, such as a square-shaped lead registration component (representing business opportunity entry), a square-shaped customer qualification verification component (for verifying customer business licenses and credit ratings), a diamond-shaped high-value customer judgment component (for determining if a customer is high-value), a square-shaped electronic contract signing component (integrated with an electronic signature platform), and a circular first-order fulfillment initiation component (for triggering WMS system pickup), etc. Additionally, the interface's toolbar can display arrows indicating flow direction, connecting lines for linking components, and start / end icons to identify the starting and ending points. Operations configuration personnel can perform drag-and-drop operations on the canvas based on the above-mentioned special needs to place and connect various target process components. Finally, by clicking "Save", the process orchestration engine can automatically generate the orchestration result of the process structure, that is, transform the orchestration result into a structured LTC process model.

[0047] Understandably, this approach provides a visual orchestration service for the first user, allowing them to select the appropriate target process components from the available alternatives displayed on the interface to complete the orchestration. Clearly, this solution only requires the first user to select the target process components and perform the visual orchestration operation to achieve process orchestration, eliminating the need for user coding. Therefore, through its high degree of visualization and ease of operation, it not only reduces the difficulty and operational threshold of orchestration work but also flexibly supports various differentiated scenarios, making the solution more adaptable. It is evident that the customer relationship management system described in this solution provides users with powerful visual modeling capabilities, enabling non-technical personnel to participate in the process design process.

[0048] Furthermore, in addition to drawing the process structure of the LTC process model as described above, the first user can also perform metadata configuration operations on the target process component and / or any LTC process model in the process orchestration interface. Correspondingly, the process orchestration engine can respond to the metadata configuration operations and determine the configuration information of any LTC process model, such as task description information and event description information corresponding to each domain node. Specifically, the task description information of any domain node can be used to record the type of task to be executed at that node, the execution method, and the execution subject (i.e., which tasks are included, task dependencies, how each task is executed, and who executes it, etc.); the event description information of any domain node can be used to record upstream events listened to at that node and downstream events that need to be published after the domain nodes in that node have completed execution. In this way, the first user can configure the configuration information (i.e., the metadata) corresponding to each domain node separately, in addition to drawing the process structure of the LTC process model, thereby achieving decoupling between the upper-layer business logic and the lower-layer node tasks in the user operation during the process orchestration stage.

[0049] When the process orchestration engine provides alternative process components and generates any LTC process model, it can be implemented based on third-party BPMN (Business Process Model and Notation, an international standard graphical modeling language) tools or low-code platforms. This specification does not limit this implementation.

[0050] The LTC process model generated in the above manner consists of N domain nodes connected sequentially. The connection method between these domain nodes reflects their dependencies, which in turn determine the subsequent execution order of each domain node. The connection method is determined by the first user during the orchestration phase based on actual business needs (such as the specific needs of the e-commerce platform mentioned above), and this embodiment does not impose any limitations on it.

[0051] The event-driven customer relationship management method specifically involves a scheduling engine advancing the progress of a target LTC process model within at least one LTC process model managed by the process manager. For example... Figure 3 As shown, steps 302-304 are included:

[0052] Step 302: The scheduling engine determines the target LTC process model of the process to be promoted from the at least one LTC process model. The process structure of the target LTC process model is composed of N domain nodes connected in sequence, wherein each domain node is used to represent a business stage in the target LTC process and is associated with corresponding business logic. The configuration information of the target LTC process model includes the task description information of each domain node, where N is an integer greater than 1.

[0053] In one embodiment, the scheduling engine first needs to determine the target LTC process model for the process to be promoted from the at least one LTC process model. For example, if the customer relationship management system also includes a CRM client, the user can specify the target LTC process model. Specifically, a second user can initiate a business flow request for any LTC process model through the CRM client based on the business they are handling; correspondingly, the scheduling engine can respond to the request and determine any LTC process model as the target LTC process model to be promoted. The second user can be an employee of the company, who needs to follow a preset process when interacting with other companies. In this case, they can specify a model as the target LTC process model from the at least one LTC process model maintained by the process manager as needed. This method allows users to specify the target LTC process model according to their actual business needs, helping to ensure that the model better meets the user's actual business requirements.

[0054] For example, the scheduling engine can also listen for preset external events and, in response to these events, identify the corresponding LTC process model as the target LTC process model to be initiated. In this approach, the external event is the key starting point for the entire event-driven LTC process initiation mechanism; specifically, it refers to a business signal from outside the customer relationship management system that can trigger the start of the LTC process. For instance, the external event can be an event initiated by a third-party system or other business modules, an event where IoT / sensors detect specific data, or a special marketing activity. The external event can be listened to by the scheduling engine through message queues, API callbacks, event buses, etc., thereby triggering the advancement of the target LTC process model. In this way, the customer relationship management system can automatically listen for external events and begin advancing specific target LTC process models, helping to ensure that the customer relationship management system responds accurately and promptly to the triggering of external events.

[0055] In one embodiment, when the scheduling engine begins to advance the target LTC process model, it needs to create a target LTC process instance according to the model and sequentially advance the progress of the instance between various domain nodes.

[0056] Step 304: The scheduling engine advances the progress of the target LTC process according to the process structure.

[0057] After determining the target LTC process model for the process to be advanced, the scheduling engine can advance the progress of the corresponding target LTC process according to the process structure in the model. That is, it needs to advance each domain node sequentially according to the connection relationship of each domain node. Specifically, when advancing each domain node, steps 3042 and 3044 can be followed.

[0058] Step 3042: When the current progress of the target LTC process is at the domain node, the scheduling engine generates the node task of the domain node according to the business logic corresponding to the domain node and the task description information of the domain node, and triggers the corresponding executor to execute the node task.

[0059] In one embodiment, this solution can break down the complete business requirements into three-level processes according to the target LTC process model:

[0060] The first-level process corresponds to the stage advancement of "cross-domain nodes", that is, it is used to advance the progress between various domain nodes. For example, if the model includes five domain nodes: "lead → opportunity → quotation → contract → payment", the first-level process is used to advance the process progress between these nodes in the order indicated by the arrows.

[0061] The secondary process corresponds to the lifecycle within a "single domain node," meaning it's used to advance the progress between the various sub-nodes within that single node. For example, in the "business opportunity" domain node, which includes four sub-nodes: "create → evaluate → advance → close," the secondary process is used to advance the process progress sequentially between these sub-nodes according to the order indicated by the arrows.

[0062] The third-level process corresponds to the "specific node tasks (operational tasks)" for each domain node, that is, it is used to advance the execution of the node tasks corresponding to the domain node. For example, in the case of the "quotation" node corresponding to the two tasks of "sending a quotation email" and "initiating an approval", the third-level process is used to advance the execution of these two tasks in sequence.

[0063] Corresponding to the above-mentioned secondary process, when generating node tasks for each domain node, the scheduling engine can generate tasks corresponding to each sub-node. For example, when generating node tasks for a domain node, if the domain node contains multiple sub-nodes, the scheduling engine can determine the task type corresponding to each sub-node and the dependency relationship between each sub-node matching the business logic based on the task description information, and generate node tasks conforming to the corresponding business type for each sub-node based on the dependency relationship. For example, corresponding to the aforementioned sub-nodes such as "Create → Evaluate → Promote → Close", tasks such as "Generate Product Consultation Record" corresponding to the "Create" sub-node, "Initiate Business Opportunity Evaluation Meeting", "Generate Meeting Minutes", and "Copy Meeting Minutes to Process Personnel" corresponding to the "Evaluate" sub-node can be generated, which will not be elaborated further. In this way, the scheduling engine can accurately generate node tasks of different types corresponding to each sub-node during the process of advancing the target LTC process model, which helps to advance each sub-node and any of the domain nodes.

[0064] Each node task generated by the scheduling engine when it advances to any domain node needs to be executed by its corresponding executor. The scheduling engine can query the executor of each node task from the aforementioned task description information of that domain node.

[0065] In one embodiment, the scheduling engine can trigger the corresponding executor to execute the node task in various ways. For example, if the executor includes a preset service, the preset service can be invoked to execute the node task. The invocation method and required parameters (such as service identifier, access interface, etc.) of the preset service can be queried from the aforementioned task description information. The preset service can be a local service provided by the customer relationship management system itself, or it can be a third-party service; this embodiment does not impose any limitations on this. In this way, the customer relationship management system can invoke the preset service to automatically execute the node tasks generated by the scheduling engine, typically with high execution efficiency.

[0066] For example, when the executor includes pre-defined personnel, the scheduling engine can send task prompts for the node task through the communication method associated with the pre-defined personnel, prompting them to execute the node task. For instance, this could involve notifying a leader to approve a contract, or notifying an employee to attend a meeting and compile meeting minutes. The communication method associated with the pre-defined personnel can be determined based on the aforementioned task description information. For example, the communication method could include sending in-app messages to a CRM client, sending SMS messages, sending emails, and / or making phone calls, etc. This embodiment of the specification does not limit this. In this way, when the executor includes pre-defined personnel (i.e., natural persons), they can be promptly and accurately notified to execute relevant tasks as soon as possible to avoid losses due to task delays or omissions.

[0067] The aforementioned task management (such as task data maintenance and task status updates) can be handled by the task manager in the customer relationship management system. For example, after generating any node task, the scheduling engine can send its relevant data to the task manager for maintenance, which will not be elaborated further.

[0068] Step 3044: In response to the domain event published after the node task is completed, the scheduling engine advances the current progress flow to the next domain node if the process advancement conditions between the domain node and its next domain node are met, or terminates the advancement of the target LTC process if the process termination conditions corresponding to the domain node are met.

[0069] After the aforementioned executor completes its node task, relevant parties can generate and publish corresponding domain events to advance the target LTC process. These domain events represent significant changes occurring within the domain. This solution uses domain events to trigger actions in the next step or to notify other interested components (i.e., the scheduling engine). This method uses domain events to transmit task execution success messages, promoting loosely coupled inter-service communication and supporting asynchronous processing mechanisms. During the advancement of the target LTC process, the scheduling engine can continuously monitor events for the node tasks corresponding to that process. Upon detecting an event, it determines whether the corresponding process advancement or termination conditions are met, and then decides how to advance the process.

[0070] In one embodiment, the configuration information of the target LTC process model may further include event description information for each domain node. Based on this, when the process manager and / or the scheduling engine determines that the node task has been completed, it can publish the domain event corresponding to the node task according to the event description information corresponding to the domain node. This method can ensure that the message of task completion is promptly and accurately communicated to downstream stakeholders (or event subscribers, consumers) through event publishing.

[0071] For example, suppose a courier company is finalizing a cooperation agreement with an e-commerce platform client: In the LTC process, the current progress has reached the "Contract Signing" domain node. The task of this node is for the client to sign an electronic contract online. When the scheduling engine detects that the LTC process has entered the "Contract" domain node, it can generate a "Contract Signing" task (e.g., calling the task service to create a task instance) based on the task description information of this node (e.g., task type "electronic signing," executor "client," timeout of 48 hours) and send it to the client via email. The client clicks the link in the email to enter the electronic signature platform, reads the contract content, and enters the verification code and name information to complete the signing. The electronic signature platform verifies the signature validity and sends the result back to the courier company's contract service. At this point, the process manager (or the contract service) can, if the callback result indicates that the contract status has been marked as "signed," generate a "Contract Signed" domain event based on the event description information (e.g., constructing a standardized domain event object) and publish the event through an event bus (e.g., Kafka, RabbitMQ, or the system's internal Event Bus). Correspondingly, after the scheduling engine detects the event, it can check whether the process advancement conditions or process termination conditions corresponding to the "contract" domain node are met.

[0072] Steps 3042 and 3044 need to be executed separately for each domain node in the target LTC process model. As mentioned earlier, a domain node may contain multiple child nodes. In this scenario, if the domain node is not the Nth domain node (i.e., the domain node is one of the first N-1 nodes in the process structure, meaning the target LTC process progress has not yet reached the last domain node), then the process advancement condition may include the completion of the node tasks corresponding to each of the multiple child nodes. That is, if the target LTC process progress has not yet reached the last domain node, the process progress will advance to the next domain node only after the node tasks corresponding to each of the child nodes in the domain node have been completed (see the aforementioned first-level and second-level processes for details). Alternatively, if the domain node is the Nth domain node (i.e., the target LTC process progress has reached the last domain node), the process termination condition may include the completion of the node tasks corresponding to each of the multiple child nodes. That is, if the target LTC process progress has reached the last domain node, the process can be terminated only after the node tasks corresponding to each of the child nodes in the domain node have been completed.

[0073] Similar to the Task Manager, the aforementioned event management (such as event-related data maintenance, event status updates, etc.) can be handled by the aforementioned Event Manager in the Customer Relationship Management System. For example, after generating any event, the generator can publish it to the Event Manager, or instruct the Event Manager to publish the domain event, which will not be elaborated further.

[0074] In one embodiment, when the domain node is the Nth domain node (i.e., the target LTC process progress has reached the last domain node), the scheduling engine can also generate the business flow result corresponding to the target LTC process based on the execution result of the node task and / or the domain event. Clearly, this business flow result is the final execution result after the target LTC process model progress is completed. Furthermore, the scheduling engine can also send the business flow result to the relevant parties of the target LTC process, which will not be elaborated further.

[0075] It is understandable that the above embodiments actually propose a novel event-driven CRM solution: in the process orchestration phase (i.e., the model configuration phase), by configuring the task description information, the upper-level business logic associated with each domain node is decoupled and separated from the lower-level node tasks that need to be executed during the actual process. This allows users to flexibly orchestrate the upper-level business logic according to actual business needs without having to worry about how the lower-level node tasks are implemented, helping users to flexibly respond to actual business needs (such as the personalized needs of specific customers) through efficient orchestration. Simultaneously, this solution uses an event-driven approach to ensure that the decoupled lower-level node tasks can still be effectively executed asynchronously according to the upper-level business logic. That is, after the node task is executed, the corresponding domain event is generated and published, and the scheduling engine, after listening to the domain event, determines whether the corresponding process advancement or process termination conditions are met, and then decides how to advance the target LTC process to continue or directly terminate the process. Therefore, this solution not only achieves effective decoupling of business logic and node tasks, but also further ensures that the decoupled node tasks can be executed asynchronously through an event-driven approach. Thus, it not only allows users to flexibly orchestrate business processes to meet actual business needs, but also helps to improve the overall process advancement efficiency of the system, resulting in significant improvements.

[0076] Corresponding to the foregoing method embodiments, this specification also proposes a customer relationship management system, which includes a scheduling engine and a process manager. The process manager maintains at least one orchestrated lead-to-cash (LTC) process model, and the scheduling engine is used for:

[0077] From the at least one LTC process model, a target LTC process model for the process to be advanced is determined. The process structure of the target LTC process model consists of N domain nodes connected in sequence, wherein each domain node is used to represent the business logic of a business stage in the target LTC process. The configuration information of the target LTC process model includes the task description information of each domain node, where N is an integer greater than 1.

[0078] The target LTC process is advanced according to the described process structure; wherein, for each of the N domain nodes:

[0079] When the current progress of the target LTC process is at this domain node, generate the node task of the domain node according to the business logic and task description information of the domain node, and trigger the corresponding executor to execute the node task;

[0080] In response to a domain event published after the node task is completed, the current progress is advanced to the next domain node if the process advancement conditions between the domain node and its next domain node are met, or the advancement of the target LTC process is terminated if the process termination conditions corresponding to the domain node are met.

[0081] The specific implementation methods of each functional module in the customer relationship management system can be found in the previous embodiment, and will not be repeated here.

[0082] Figure 4 This is a schematic structural diagram of a device provided in an exemplary embodiment. For example... Figure 4 As shown, device 400 mainly consists of a communication interface 402, a user interface 404, a processor 406, and a data storage 408. These components are interconnected and communicate with each other via a system bus, network, or other connection mechanism 410. The communication interface 402 enables device 400 to communicate with other devices, access networks, and transmission networks via analog or digital modulation. For example, the communication interface 402 may include a chipset and antenna for wireless communication with a radio access network or access point. Furthermore, the communication interface 402 can be a wired interface such as Ethernet, Token Ring, or a USB port, or a wireless interface such as Wi-Fi, Bluetooth, Global Positioning System (GPS), or a wide-area wireless interface (e.g., WiMAX or LTE). Of course, the communication interface 402 can also support other forms of physical layer interfaces and standard or proprietary communication protocols. The communication interface 402 may also include multiple physical communication interfaces, such as Wi-Fi, Bluetooth, and wide-area wireless interfaces.

[0083] User interface 404 includes receiving user input and providing output to the user. Therefore, user interface 404 may include input components such as a keypad, keyboard, touch-sensitive or presence-sensitive panel, computer mouse, trackball, joystick, microphone, still camera, and video camera, and output components such as a display screen (which may be combined with a touch-sensitive panel), CRT, LCD, LED, display using DLP technology, printer, and other similar devices known or developed in the future. User interface 404 may also generate auditory output via speakers, speaker jacks, audio output ports, audio output devices, headphones, and other similar devices known or developed in the future. In some embodiments, user interface 404 may include software, circuitry, or other forms of logic capable of transmitting and receiving data from external user input / output devices. Additionally or alternatively, device 400 may support remote access from other devices via communication interface 402 or another physical interface (not shown). User interface 404 may be configured to receive user input, the position and movement of which may be indicated by indicators or cursors described herein. User interface 404 may also be configured as a display device for rendering or displaying text fragments.

[0084] Processor 406 may contain one or more general-purpose processors and / or special-purpose processors.

[0085] Data storage 408 may include one or more volatile and / or non-volatile storage components and may be integrated wholly or partially with processor 406. Data storage 408 may include removable and non-removable components.

[0086] Processor 406 is capable of executing program instructions 418 (e.g., compiled or uncompiled program logic and / or machine code) stored in data storage 408 to perform the various functions described herein. Data storage 408 may contain a non-transitory computer-readable medium on which program instructions are stored, which, when executed by device 400, enable device 400 to perform any methods, processes, or functions disclosed in this specification and / or the accompanying drawings. Processor 406 executing program instructions 418 may result in processor 406 using data 412.

[0087] For example, program instructions 418 may include an operating system 422 (e.g., an operating system kernel, device drivers, and / or other modules) installed on device 400 and one or more applications 420 (e.g., a browser, social application, or game application). Similarly, data 412 may include operating system data 416 and application data 414. Operating system data 416 is primarily accessible to the operating system 422, while application data 414 is primarily accessible to one or more applications 420. Application data 414 may reside in a file system visible or hidden from the user of device 400.

[0088] Application 420 can communicate with operating system 422 through one or more application programming interfaces (APIs). These APIs help application 420 read and / or write application data 414, transmit or receive information via communication interface 402, receive or display information on user interface 404, etc.

[0089] In some terminology, application 420 may be simply referred to as "app". Furthermore, application 420 can be downloaded to device 400 through one or more online app stores or app markets. However, applications can also be installed on device 400 in other ways, such as through a web browser or a physical interface on device 400 (e.g., a USB port).

[0090] Please refer to Figure 5 Event-driven customer relationship management devices can be applied to, for example, Figure 4 The device shown is used to implement the technical solution of this specification. Specifically, the device is applied to a customer relationship management system, which includes a scheduling engine and a process manager. The process manager maintains at least one orchestrated lead-to-cash (LTC) process model. The device includes:

[0091] The target model determination unit 501 is used by the scheduling engine to determine the target LTC process model of the process to be promoted from the at least one LTC process model. The process structure of the target LTC process model is composed of N domain nodes connected in sequence, wherein each domain node is used to represent a business stage in the target LTC process and is associated with corresponding business logic; the configuration information of the target LTC process model includes the task description information of each domain node, and N is an integer greater than 1.

[0092] The target process advancement unit 502 is used by the scheduling engine to advance the progress of the target LTC process according to the process structure; wherein, for each of the N domain nodes, the target process advancement unit 502 is specifically used for:

[0093] When the current progress of the target LTC process is at the domain node, the scheduling engine generates the node task of the domain node according to the business logic corresponding to the domain node and the task description information of the domain node, and triggers the corresponding executor to execute the node task.

[0094] The scheduling engine responds to the domain event published after the node task is completed by listening to it. If the process advancement conditions between the domain node and its next domain node are met, the current progress is advanced to the next domain node, or the process termination conditions corresponding to the domain node are met, and the advancement of the target LTC process is terminated.

[0095] Optionally, the customer relationship management system further includes a process orchestration engine, and the device further includes a model orchestration unit 503, which, when orchestrating any LTC process model, is used to:

[0096] The process orchestration engine displays alternative process components in the process orchestration interface, and generates any LTC process model containing the target process component according to the visual orchestration operation performed by the first user on the target process component in the process orchestration interface.

[0097] Optionally, a configuration information determination unit 504 is also included, for:

[0098] The process orchestration engine responds to the metadata configuration operation performed by the first user in the process orchestration interface for the target process component and / or any LTC process model, and determines the configuration information of any LTC process model.

[0099] Optionally, the target model determination unit 501 is specifically used for:

[0100] When the customer relationship management system also includes a CRM client, the scheduling engine, in response to a business flow request initiated by a second user through the CRM client for any LTC process model, identifies that any LTC process model as the target LTC process model to be implemented; or...

[0101] The scheduling engine responds to a preset external event by identifying the LTC process model corresponding to the external event as the target LTC process model to be promoted.

[0102] Optionally, the target process advancement unit 502 is specifically used for:

[0103] When the domain node contains multiple child nodes, the scheduling engine determines the task type corresponding to each child node and the dependency relationship between each child node that matches the business logic based on the task description information, and generates node tasks that conform to the corresponding business type for each child node based on the dependency relationship.

[0104] Optional,

[0105] If the node in this domain is not the Nth domain node, the process advancement conditions include the completion of the node tasks corresponding to each of the multiple sub-nodes.

[0106] When the domain node is the Nth domain node, the process termination condition includes the completion of the node tasks corresponding to each of the multiple child nodes.

[0107] Optionally, the target process advancement unit 502 is specifically used for:

[0108] If the executor includes a preset service, the preset service is invoked to execute the node task; and / or,

[0109] When the executor includes a preset person, a task prompt message for the node task is sent through the communication method associated with the preset person, so as to prompt the preset person to perform the node task.

[0110] Optionally, the configuration information of the target LTC process model also includes event description information for each domain node, and the device further includes an event publishing unit 505, used for:

[0111] When the process manager and / or the scheduling engine determine that the node task has been completed, they publish the domain event corresponding to the node task based on the event description information corresponding to the domain node.

[0112] Optionally, a result generation unit 506 is also included, for:

[0113] When the domain node is the Nth domain node, the scheduling engine generates the business flow result corresponding to the target LTC process based on the execution result of the node task and / or the domain event.

[0114] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0115] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0116] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0117] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0118] What those skilled in the art will understand is:

[0119] In this specification, the terms "comprising," "including," or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded.

[0120] In this specification, “a,” “an,” and “the” do not specifically refer to the singular, but may also include the plural.

[0121] In this specification, ordinal numbers such as "first," "second," etc., do not necessarily indicate order; they are often used to distinguish between objects. For example, "first server" and "second server" usually refer to two servers. To differentiate between these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0122] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0123] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0124] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0125] Although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is only one of many possible execution orders and does not represent the only execution order. Therefore, when the claims involve method steps, any changes or adjustments to the order of such steps, or the parallelism between steps, are also within the scope of protection of the claims.

Claims

1. An event-driven customer relationship management method, characterized in that, Applied to a customer relationship management system, the system including a scheduling engine and a process manager, the process manager maintaining at least one orchestrated lead-to-cash (LTC) process model, the method includes: The scheduling engine determines the target LTC process model for the process to be advanced from the at least one LTC process model. The process structure of the target LTC process model is composed of N domain nodes connected in sequence, wherein each domain node is used to represent a business stage in the target LTC process and is associated with corresponding business logic. The configuration information of the target LTC process model includes the task description information of each domain node, where N is an integer greater than 1. The scheduling engine advances the target LTC process according to the process structure; wherein, for each of the N domain nodes: When the current progress of the target LTC process is at the domain node, the scheduling engine generates the node task of the domain node according to the business logic corresponding to the domain node and the task description information of the domain node, and triggers the corresponding executor to execute the node task. The scheduling engine responds to the domain event published after the node task is completed by listening to it. If the process advancement conditions between the domain node and its next domain node are met, the current progress is advanced to the next domain node, or the process termination conditions corresponding to the domain node are met, and the advancement of the target LTC process is terminated.

2. The method according to claim 1, characterized in that, The customer relationship management system also includes a process orchestration engine, which orchestrates any LTC process model, including: The process orchestration engine displays alternative process components in the process orchestration interface, and generates any LTC process model containing the target process component according to the visual orchestration operation performed by the first user on the target process component in the process orchestration interface.

3. The method according to claim 2, characterized in that, Also includes: The process orchestration engine responds to the metadata configuration operation performed by the first user in the process orchestration interface for the target process component and / or any LTC process model, and determines the configuration information of any LTC process model.

4. The method according to claim 1, characterized in that, The scheduling engine determines the target LTC process model for the process to be advanced from the at least one LTC process model, including: When the customer relationship management system also includes a CRM client, the scheduling engine, in response to a business flow request initiated by a second user through the CRM client for any LTC process model, identifies that any LTC process model as the target LTC process model to be implemented; or... The scheduling engine responds to a preset external event by identifying the LTC process model corresponding to the external event as the target LTC process model to be promoted.

5. The method according to claim 1, characterized in that, The scheduling engine generates node tasks for the domain node according to the business logic corresponding to the domain node and the task description information of the domain node, including: When the domain node contains multiple child nodes, the scheduling engine determines the task type corresponding to each child node and the dependency relationship between each child node that matches the business logic based on the task description information, and generates node tasks that conform to the corresponding business type for each child node based on the dependency relationship.

6. The method according to claim 5, characterized in that, If the node in this domain is not the Nth domain node, the process advancement conditions include the completion of the node tasks corresponding to each of the multiple sub-nodes. When the domain node is the Nth domain node, the process termination condition includes the completion of the node tasks corresponding to each of the multiple child nodes.

7. The method according to claim 1, characterized in that, The scheduling engine triggers the corresponding executor to execute the node task, including: If the executor includes a preset service, the preset service is invoked to execute the node task; and / or, When the executor includes a preset person, a task prompt message for the node task is sent through the communication method associated with the preset person, so as to prompt the preset person to perform the node task.

8. The method according to claim 1, characterized in that, The configuration information of the target LTC process model also includes event description information for each domain node, and the method further includes: When the process manager and / or the scheduling engine determine that the node task has been completed, they publish the domain event corresponding to the node task based on the event description information corresponding to the domain node.

9. The method according to claim 1, characterized in that, Also includes: When the domain node is the Nth domain node, the scheduling engine generates the business flow result corresponding to the target LTC process based on the execution result of the node task and / or the domain event.

10. A customer relationship management system, characterized in that, The system includes a scheduling engine and a process manager, the process manager maintaining at least one orchestrated lead-to-cash (LTC) process model, and the scheduling engine being used for: From the at least one LTC process model, a target LTC process model for the process to be advanced is determined. The process structure of the target LTC process model consists of N domain nodes connected in sequence, wherein each domain node is used to represent the business logic of a business stage in the target LTC process. The configuration information of the target LTC process model includes the task description information of each domain node, where N is an integer greater than 1. The target LTC process is advanced according to the described process structure; wherein, for each of the N domain nodes: When the current progress of the target LTC process is at this domain node, generate the node task of the domain node according to the business logic and task description information of the domain node, and trigger the corresponding executor to execute the node task; In response to a domain event published after the node task is completed, the current progress is advanced to the next domain node if the process advancement conditions between the domain node and its next domain node are met, or the advancement of the target LTC process is terminated if the process termination conditions corresponding to the domain node are met.

11. An electronic device, characterized in that, include: processor; A memory for storing processor-executable instructions; wherein the processor implements the steps of the method as described in any one of claims 1-9 by executing the executable instructions.

12. A computer-readable storage medium, characterized in that, It stores computer instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-9.

13. A computer program product, characterized in that, Includes a computer program / instructions that, when executed by a processor, implement the steps of the method as described in any one of claims 1-9.

Images