Life insurance customer operation method and device based on distributed service architecture

Abstract

The invention discloses a life insurance customer operation method and device based on a distributed service architecture, computer equipment and a computer readable storage medium, and relates to the technical field of insurance customer management systems.The method comprises the steps that the distributed service architecture is constructed, the whole customer operation process is disassembled into a plurality of independent service modules, and the independent service modules are connected with the distributed service architecture; service modular deployment is realized; based on a message queue and an event-driven mechanism, client behavior data and demand information among the service modules are synchronized in real time; a dynamic resource scheduling algorithm is utilized to intelligently allocate service resources and adjust module operation instances according to service loads and geographic position parameters; and dynamically combining service modules through an intelligent service routing engine in combination with the client willingness label and the behavior track to generate a personalized service process. According to the data processing method provided by the embodiment of the invention, the response speed, the expansibility and the service efficiency of a life insurance customer operation system can be remarkably improved, and efficient management and precise marketing of the customer in the whole life cycle are realized.

Description

Technical Field

[0001] This invention relates to the field of insurance customer management system technology, and in particular to a method and apparatus for managing life insurance customers based on a distributed service architecture. Background Technology

[0002] As a core support for the digital transformation of the insurance industry, life insurance customer management systems are widely used in the field of customer lifecycle management. With the continuous expansion of the life insurance customer base and the increasing complexity of business needs, traditional centralized architectures are no longer sufficient to meet industry demands. Existing systems typically adopt a monolithic application model, constructing a basic customer management system through the interconnected operation of modules such as customer screening, task allocation, and service execution. Specifically, this system covers the entire process from customer tag creation to service process tracking, including key aspects such as customer list generation, agent allocation, service personnel scheduling, and online-offline service collaboration. Among these, the customer tag system construction methodology and multi-channel communication interface integration solutions constitute the system's basic capability framework.

[0003] However, existing centralized architectures have significant limitations in practical applications. Specifically, when the number of customers exceeds ten million, the system's response latency in high-concurrency scenarios can reach over 300ms, resulting in a customer timeout rate as high as 25%. Consequently, the development cycle for adding 20+ new features annually by business departments averages over 6 months, with a single system expansion costing up to 3 million yuan. Furthermore, a 30-minute delay in customer data updates directly impacts the real-time nature of marketing decisions. These shortcomings not only cause hundreds of millions of yuan in customer churn annually but also result in system maintenance costs accounting for 40% of the IT budget, severely hindering the speed of business innovation. In particular, the coupled design of service modules leads to insufficient fault isolation; a single module failure can trigger system-wide service interruptions, while the static resource allocation mechanism struggles to adapt to dynamic business needs, creating an industry-wide technical bottleneck. Summary of the Invention

[0004] The main objective of this invention is to provide a method for managing life insurance customers based on a distributed service architecture.

[0005] Another objective of this invention is to propose a life insurance customer management device based on a distributed service architecture.

[0006] The third objective of this invention is to provide a computer device.

[0007] A fourth objective of this invention is to provide a non-transitory computer-readable storage medium.

[0008] To achieve the above objectives, a first aspect of the present invention proposes a life insurance customer management method based on a distributed service architecture, comprising: S1, build a distributed service architecture, break down the entire customer operation process into multiple independent service modules, and realize modular service deployment; S2, based on message queues and event-driven mechanisms, synchronizes customer behavior data and demand information between various service modules in real time; S3 uses a dynamic resource scheduling algorithm to intelligently allocate service resources and adjust module running instances based on business load and geographical location parameters; S4 uses an intelligent service routing engine to combine customer preference tags and behavioral patterns to dynamically combine service modules to generate personalized service processes.

[0009] Optionally, a distributed service architecture can be built, breaking down the entire customer management process into multiple independent service modules to achieve modular service deployment, including: S11 breaks down the customer management process into six core service modules: customer screening service, task allocation service, service execution service, data reporting service, complaint handling service, and behavior tracking service. S12 uses containerization technology to deploy each service module independently, and uses a Kubernetes cluster to achieve dynamic scaling of the service modules.

[0010] Optionally, based on message queues and event-driven mechanisms, customer behavior data and demand information between various service modules can be synchronized in real time, including: S21 uses Apache Kafka to build an event-driven architecture, achieving second-level synchronization of customer behavior data through the producer-consumer pattern; S22 classifies and processes synchronized data into three types of data streams: customer tag update events, service status change events, and requirement change events.

[0011] Optionally, a dynamic resource scheduling algorithm can be used to intelligently allocate service resources and adjust module running instances based on business load and geographical location parameters, including: S31, calculate the service resource allocation weights based on the load balancing algorithm, the weight formula is as follows: ,in The weight of the i-th service instance. This is the business load factor. For geographic location matching; S32 dynamically adjusts the number of running instances based on real-time resource utilization. When CPU utilization exceeds a threshold... Automatic expansion is triggered at certain times.

[0012] Optionally, a smart service routing engine can be used to dynamically combine service modules with customer preference tags and behavioral patterns to generate a personalized service process, including: S41 uses a rule engine to prioritize customer intention tags and generate a service process decision tree; S42 uses a machine learning model to predict customer behavior patterns, and the model output is a probability matrix of service module combinations. ,in This represents the probability that the i-th customer triggers the j-th service module.

[0013] Optionally, it also includes: S5, which performs customer behavior tracking and remarketing push steps, specifically including: S51 uses the Flink streaming framework to analyze customers' browsing history and click behavior on websites, apps and other online channels in real time. S52 generates customer behavior tags based on the analysis results and determines the tag matching degree. Calculate the priority of recommended products, where The matching score between the customer and the i-th product. This represents the maximum matching score.

[0014] To achieve the above objectives, a second aspect of the present invention provides a life insurance customer management device based on a distributed service architecture, comprising: The distributed service architecture building module is used to build a distributed service architecture, decompose the entire customer operation process into multiple independent service modules, and realize modular deployment of services; The message queue and event-driven synchronization module is used to synchronize customer behavior data and demand information between various service modules in real time based on message queues and event-driven mechanisms. The dynamic resource scheduling and instance adjustment module is used to intelligently allocate service resources and adjust the running instances of the module based on business load and geographical location parameters using a dynamic resource scheduling algorithm. The intelligent service routing and process generation module is used to dynamically combine service modules to generate personalized service processes by combining customer intention tags and behavioral trajectories through the intelligent service routing engine.

[0015] To achieve the above objectives, a third aspect of this application provides a computer device, including a processor and a memory; wherein the processor runs a program corresponding to the executable program code stored in the memory, in order to implement the life insurance customer management method based on a distributed service architecture as described in the first aspect embodiment.

[0016] To achieve the above objectives, a fourth aspect of this application provides a non-transitory computer-readable storage medium storing a computer program that, when executed by a processor, implements the life insurance customer management method based on a distributed service architecture as described in the first aspect embodiment.

[0017] The embodiments of the present invention have the following beneficial effects: the methods, apparatus, electronic devices and computer-readable storage media of the present invention, by adopting a distributed service architecture and modular design, significantly improve the response speed, scalability and service efficiency of the life insurance customer management system, effectively reduce maintenance costs and support rapid business iteration. Attached Figure Description

[0018] The above and / or additional aspects and advantages of the present invention will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 A flowchart illustrating a life insurance customer management method based on a distributed service architecture, provided as an embodiment of the present invention; Figure 2 A flowchart illustrating another life insurance customer management method based on a distributed service architecture provided in this embodiment of the invention; Figure 3 A structural diagram of a life insurance customer management device based on a distributed service architecture provided in an embodiment of the present invention; Detailed Implementation It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

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

[0020] The following description, with reference to the accompanying drawings, outlines a life insurance customer management method and apparatus based on a distributed service architecture, according to embodiments of the present invention.

[0021] Example 1 This embodiment provides a method for managing life insurance customers based on a distributed service architecture. For example... Figure 1 As shown, the method includes the following steps: S1 constructs a distributed service architecture, breaking down the entire customer operation process into multiple independent service modules to achieve modular service deployment.

[0022] Specifically, in some implementations, building a distributed service architecture is one of the core technical steps of this invention. This technology is based on the microservice architecture design concept, combined with containerized deployment and service registration and discovery mechanisms. The entire life insurance customer management process is decomposed into multiple functionally independent and single-responsibility service modules, achieving modular deployment and operation of services. Specifically, the system uses the Spring Cloud framework as the microservice governance platform, combined with Nacos or Eureka as the service registry center, to achieve dynamic service discovery and load balancing. Each service module (such as customer tag management service, task allocation service, telephone call record service, policy processing service, etc.) is encapsulated as an independent Spring Boot application, communicating with other services through RESTful APIs or gRPC protocols, ensuring decoupling and high cohesion between modules.

[0023] In this embodiment, the system supports elastic scaling of service instances, dynamically adjusting the number of service nodes based on business load. For example, during peak customer call periods, the number of service instances assigned to operators can be increased from the default 3 to more than 10 to ensure concurrent processing capabilities. Service communication uses OpenFeign or Ribbon to implement client load balancing, and the response timeout is set to... milliseconds, number of retries Secondly, this ensures the stability of service calls. Furthermore, data interaction between services is routed and authenticated through a unified API gateway, supporting OAuth2.0 or JWT authentication mechanisms to guarantee system security.

[0024] In this embodiment, the distributed architecture is widely used in business processes such as life insurance customer screening, call allocation, service follow-up, and data report generation. For example, in the customer screening stage, the CRM system uses the tag service module to access customer profile data to accurately identify target customer groups; in the task allocation stage, the system dynamically allocates tasks based on the real-time workload of agents through the task scheduling service, improving resource utilization. This architecture also supports multi-regional deployment, meeting the needs of life insurance companies to provide localized services to customers nationwide.

[0025] The technical benefits of this step are a significant improvement in system response speed, scalability, and service efficiency. Through modular design, each service can be developed, tested, and deployed independently, reducing system coupling and improving development iteration efficiency. Simultaneously, the distributed architecture supports horizontal scaling, capable of handling high-concurrency customer requests and meeting the rapid growth demands of the life insurance business. Furthermore, the high availability design of the services (such as service circuit breaking and degradation mechanisms) ensures stable system operation under abnormal conditions, thereby improving customer service quality and enterprise operational efficiency.

[0026] Furthermore, S1 includes: S11 breaks down the customer management process into six core service modules: customer screening service, task assignment service, service execution service, data reporting service, complaint handling service, and behavior tracking service.

[0027] Specifically, in some implementations, this invention breaks down the life insurance customer management process into six core service modules, including customer screening service, task allocation service, service execution service, data reporting service, complaint handling service, and behavior tracking service. This step is based on the design concept of a distributed service architecture, aiming to achieve decoupling of system modules and high cohesion of services, thereby improving the system's response speed, scalability, and maintenance efficiency. Specifically, the customer screening service uses a preset tagging system (such as customer age, policy type, risk preference, etc.) in the CRM system or customer management platform to accurately segment customer groups. Its screening logic can be implemented based on SQL queries or full-text search engines such as Elasticsearch, supporting both real-time updates and batch processing modes, with processing latency controlled within 500ms, meeting the rapid response requirements of large-scale customer data.

[0028] The task allocation service uses load balancing algorithms (such as round-robin and weighted least connections) to dynamically distribute the customer list to different agents or service personnel. Allocation strategies can be optimized based on personnel performance indicators (such as connection rate, conversion rate, and service duration) to ensure efficient resource utilization. The service execution service covers operations such as phone calls, face-to-face visits, and meeting invitations, supporting multi-channel access (such as phone, WeChat, and APP). It also features service process recording and customer preference tag generation capabilities. Tag generation algorithms can be implemented based on rule engines or lightweight machine learning models (such as decision trees and Naive Bayes), with a tag accuracy rate of no less than 85%.

[0029] The data reporting service periodically extracts data from various modules through an ETL process and uses an OLAP engine for multidimensional analysis to generate visual reports. It supports statistics at daily, weekly, and monthly granularities, and the report refresh frequency can be configured to be hourly or in real-time mode. The complaint handling service receives complaint events through a message queue (such as Kafka), automatically routes them to the corresponding processing department, and controls the processing time to within 24 hours to ensure timely response to customer issues. The behavior tracking service records customer behavior within the system using event tracking technologies (such as front-end SDKs and API logs), including page visits, click events, and dwell time. The data collection frequency is over 1000 records per second, meeting the behavior analysis needs in high-concurrency scenarios.

[0030] This step plays a core role in process deconstruction and service modularization within the entire system. By breaking down complex processes into independent service units, it not only improves the maintainability and scalability of the system, but also provides a structured data foundation for subsequent precision marketing, service quality monitoring, and customer profile building, demonstrating significant engineering value and business support capabilities.

[0031] S12 uses containerization technology to deploy each service module independently, and uses a Kubernetes cluster to achieve dynamic scaling of the service modules.

[0032] Specifically, in some implementations, this invention employs containerization technology to deploy each service module independently and uses a Kubernetes cluster to dynamically scale the service modules, thereby improving the system's elasticity, maintainability, and resource utilization. Containerization deployment is based on Docker technology, encapsulating each service module (such as customer screening, telephone call management, service allocation, and data report generation) into an independent container image, ensuring isolation and decoupling between services. Each container contains all the dependencies and configurations required to run the service, enabling the service to be quickly deployed and migrated in any environment that supports container operation.

[0033] In a Kubernetes cluster, each service container runs as a Pod and is managed through Deployment and Service objects. The system achieves dynamic scaling through the HPA (Horizontal Pod Autoscaler) mechanism, which relies on CPU utilization, memory usage, or custom metrics (such as request queue length, task processing latency, etc.). For example, when the CPU utilization of a service module exceeds a preset threshold (e.g., 80%), Kubernetes will automatically increase the number of Pod replicas based on the load; when the load drops below the threshold (e.g., 30%), the system will reduce the number of replicas to optimize resource consumption. Optionally, the system supports metric collection and alerting mechanisms based on the Prometheus monitoring platform, enabling fine-grained resource scheduling and fault warnings.

[0034] Furthermore, this invention utilizes Kubernetes' ConfigMap and Secret objects to achieve dynamic injection of service configurations and management of sensitive information, ensuring service consistency and security across different environments (such as development, testing, and production). Communication between services employs gRPC or RESTful APIs, and a unified entry point for external access is managed through an Ingress controller.

[0035] This step plays a crucial role in the entire system, and its technical effects are reflected in: significantly improving the system's responsiveness in high-concurrency scenarios, reducing resource idle rate, and enhancing the independent deployment and rapid iteration capabilities of service modules, thereby meeting the stringent requirements of life insurance customers for high availability, high scalability, and low maintenance costs in the course of their business operations.

[0036] S2, based on message queues and event-driven mechanisms, synchronizes customer behavior data and demand information between various service modules in real time.

[0037] Specifically, the step of "real-time synchronization of customer behavior data and demand information between service modules based on message queues and event-driven mechanisms" in this invention is an important technical means to achieve efficient collaboration and data consistency in customer management systems under a distributed service architecture. Its technical implementation principle is based on the combination of Event-Driven Architecture (EDA) and Message Queue, achieving loosely coupled, high-concurrency, and low-latency data interaction between service modules through an asynchronous communication mechanism.

[0038] In one embodiment of the present invention, the system employs mature message queue middleware such as Kafka, RabbitMQ, or RocketMQ to construct a unified event bus. When each service module performs critical operations (such as customer phone calls, tag updates, task generation, etc.), it publishes corresponding events to the message queue. Events are typically encapsulated in JSON format, including the event type (e.g., customer_behavior_updated), event timestamp, customer unique identifier (customer_id), action description, and additional parameters (e.g., tag_list, service_status, etc.). Consumer services in the message queue subscribe to relevant events and trigger subsequent processing logic based on the event content, such as updating customer tags, assigning service personnel, and generating task reminders.

[0039] In this embodiment, the message queue needs to support high throughput and low latency, typically requiring message processing latency of less than 100ms and throughput of no less than 10,000 messages per second. Event formats must adhere to unified data exchange standards, such as ISO 8601 time format, UTF-8 encoding, and JSON Schema validation, to ensure cross-service data compatibility and consistency.

[0040] In this embodiment, the mechanism is widely used in real-time updates of customer willingness tags after a phone call, instant assignment of service personnel tasks, and synchronous analysis of online behavioral data. For example, when a call center agent completes a phone call and submits customer feedback, the system will issue a `customer_feedback_received` event, triggering the customer tag service module to update the customer willingness tag, and simultaneously notifying the task management module to generate a new service task and push a reminder.

[0041] In this embodiment, this step effectively solves the problems of high data synchronization latency, high service coupling, and poor scalability in traditional centralized systems. Through an event-driven mechanism, the system achieves decoupling and asynchronous processing between modules, improving overall response speed and service reliability. This provides real-time and accurate data support for subsequent precision marketing, task scheduling, and data analysis, and is one of the core technologies of this invention for achieving efficient customer management.

[0042] Furthermore, S2 includes: S21 uses Apache Kafka to build an event-driven architecture, achieving second-level synchronization of customer behavior data through a producer-consumer pattern.

[0043] Specifically, in some implementations, this invention uses Apache Kafka to build an event-driven architecture, achieving second-level synchronization of customer behavior data through a producer-consumer pattern. Its technical implementation is based on Kafka's high throughput, low latency, and scalable publish-subscribe message queue mechanism. Specifically, when a customer action occurs, each functional module in the system (such as online service preparation, customer behavior tracking, and call center agent interviews) acts as a Kafka producer, encapsulating the event data in JSON format and publishing it to the corresponding Kafka Topic. Event data typically includes fields such as customer ID, behavior type (e.g., click, browse, questionnaire submission), behavior timestamp (ISO 8601 format), and behavior parameters (e.g., page path, product ID, feedback content), ensuring the data's structure and parsability.

[0044] On the consumer side, the system deploys multiple asynchronous processing services, each subscribing to different topics to achieve real-time event consumption and processing. For example, the customer behavior analysis module subscribes to the "customer_behavior" topic, retrieves event streams via the Kafka Consumer API, and performs streaming processing based on Flink or Spark Streaming to generate customer tags or update customer profiles. This process supports millisecond-level latency, meeting the real-time response requirements in life insurance customer management.

[0045] In this embodiment, the Kafka cluster typically sets the replication factor (replication.factor) to 3 to ensure high data availability. The producer is configured with acks=all to ensure that a message is considered successfully sent only after all replicas have acknowledged it. The consumer uses automatic offset commit (enable.auto.commit=true) and sets a maximum pull interval (max.poll.interval.ms=300000) to accommodate business scenarios with long processing times. Furthermore, the number of partitions (num.partitions) in a Kafka Topic is dynamically adjusted based on business throughput, typically set to 8-16 partitions to achieve load balancing and parallel processing.

[0046] This step plays a crucial role in data flow and real-time response throughout the system, especially in modules such as customer behavior tracking, precision marketing, and online service preparation. It ensures the timely collection and processing of customer data, providing a reliable data foundation for subsequent tag generation, task allocation, and report statistics. Through an event-driven architecture, the system achieves module decoupling, asynchronous processing, and elastic scaling, significantly improving the response efficiency and data consistency of the customer management system.

[0047] S22 classifies and processes synchronized data into three types of data streams: customer tag update events, service status change events, and requirement change events.

[0048] Specifically, in some implementations, classifying and processing synchronized data is one of the key steps in achieving efficient customer management within the distributed service architecture of this invention. The core of this step lies in dividing synchronized data streams from different business modules into three categories: customer tag update events, service status change events, and demand change events, thereby enabling refined data processing and precise triggering of subsequent service processes.

[0049] In this embodiment, the classification process is implemented based on an event-driven architecture (EDA) and message queue mechanisms (such as Kafka, RabbitMQ, etc.). The system listens for data change events from CRM, telephone interview modules, service modules, etc., and matches the event types with preset classification rules. For example, when customer information (such as occupation, income, risk preference, etc.) is updated, the system identifies it as a customer tag update event; when a service personnel completes a service operation (such as face-to-face interview, complaint handling, etc.), the system generates a service status change event; and when a customer makes a new insurance, policy maintenance, or claims request, it is classified as a request change event. Each type of event is transmitted asynchronously through a message queue to ensure the system's high concurrency processing capability and low latency response.

[0050] In this embodiment, the system supports custom event classification rules, including but not limited to field change thresholds (e.g., tag updates require at least three key field changes), event priorities (e.g., requirement change events have priority P1, service status change events have priority P2), and event processing timeouts (e.g., a default of 300 seconds). Furthermore, the system supports event type encoding standards, such as using ISO 8601 standard timestamps to identify event occurrence times and employing JSON Schema to define event structures, ensuring data format consistency and parsability.

[0051] In this embodiment, this step is widely applied to the entire process management of life insurance customer operations. For example, after a customer telephone interview, the system automatically generates a customer preference tag (such as "interested in pension insurance") based on the feedback content and processes it as a customer tag update event; after the service personnel complete the in-person interview, the system records the service status and triggers a service status change event to update the customer file and service progress; when a customer submits a claim application through the APP, the system identifies it as a demand change event and automatically assigns it to the claims processing module.

[0052] The technical advantage of this step lies in the fact that, through the event classification mechanism, the system can achieve efficient distribution and processing of data streams, avoiding processing delays and resource waste caused by data mixing in centralized systems. Simultaneously, classification processing provides a structured and traceable data foundation for subsequent precision marketing, service scheduling, and data analysis, significantly improving the intelligence level and response efficiency of customer management systems.

[0053] S3 uses a dynamic resource scheduling algorithm to intelligently allocate service resources and adjust module running instances based on business load and geographical location parameters.

[0054] Specifically, in this invention, "intelligently allocating service resources and adjusting module running instances based on business load and geographical location parameters using a dynamic resource scheduling algorithm" is one of the core technical steps for achieving efficient system operation and optimized resource configuration. This step, based on a distributed service architecture and combined with real-time business load monitoring and geographical information analysis, uses a dynamic resource scheduling algorithm to achieve elastic allocation of service resources and intelligent adjustment of module instances, thereby improving system response speed, resource utilization, and service quality.

[0055] In one embodiment of the present invention, the dynamic resource scheduling algorithm employs a hybrid scheduling strategy based on load balancing and geographic awareness. The system collects real-time business load metrics, including but not limited to CPU utilization, memory usage, request response time, and concurrent request count, through monitoring modules deployed on each node. Simultaneously, it combines customer geographic location information (such as latitude and longitude, region, and service radius) to construct a multi-dimensional resource allocation model. When the scheduling algorithm receives a new customer request or task allocation instruction, it first assesses the current load status of each service node and calculates its resource load index. ,in and They represent the first CPU and memory usage per node and This represents the maximum resource capacity of the node. Subsequently, the algorithm incorporates geographical location parameters. (Representing the distance between the customer and the service node), using a weighted scoring mechanism. ,in and These are preset weighting coefficients used to balance the effects of load and distance.

[0056] Furthermore, the system supports dynamic scaling of module instances. When the request volume of a certain module (such as the telephone call module or the service allocation module) exceeds a preset threshold... When the load drops to a safe level, the scheduler automatically triggers an instance scaling mechanism, dynamically increasing the number of running instances of the module through container orchestration platforms such as Kubernetes or Docker Swarm to ensure high availability and low latency of the service. Conversely, when the load decreases to a safe level... When needed, the system can automatically reduce instances, thereby reducing resource consumption and operational costs.

[0057] This step is widely applicable in practical scenarios such as life insurance customer phone calls, service allocation, and task management. For example, during high-concurrency marketing campaigns, the system can intelligently allocate customer lists based on real-time agent load and customer location, preventing overload in a particular area or among a single agent, while improving service response efficiency. In cases of uneven geographical distribution, the system can prioritize assigning customers to service personnel who are closer and have lower loads, reducing response latency and improving customer experience.

[0058] The innovation of this technical solution lies in integrating business load and geographical parameters into the resource scheduling model, achieving spatiotemporal optimization of service resources. Its technical effects are reflected in significantly reduced service response time, improved resource utilization, and enhanced system elasticity and scalability, thereby providing efficient, intelligent, and scalable technical support for life insurance customer operations.

[0059] Furthermore, S3 includes: S31, calculate the service resource allocation weights based on the load balancing algorithm, the weight formula is as follows: ,in The weight of the i-th service instance. This is the business load factor. For geographic location matching degree.

[0060] Specifically, in a distributed service architecture, the rational allocation of service resources is a key aspect of ensuring efficient system operation and high-quality customer service. The load balancing algorithm used in this invention calculates the allocation weights of service instances. This enables dynamic scheduling of service resources. Among them, Indicates the first The overall weight of each service instance, This represents the service load factor for this instance. For geographic location matching, and These are configurable weighting coefficients used to adjust the relative importance of load and geographic location factors in the weighting calculation.

[0061] In this embodiment, the service load factor Typically, metrics such as CPU utilization, memory usage, request queue length, and response latency of the current service instance are collected in real time by the system monitoring module. For example, Can be defined as ,in For the first Length of the request queue for each instance The average response time, and The upper limit of the threshold set for the system. Geographic location matching degree. The quantification is based on the distance or network latency between the customer's location and the service instance deployment location. Latitude and longitude information can be obtained using GIS systems or IP positioning technology, and normalized using Euclidean distance or network latency indicators.

[0062] In this embodiment, the weight calculation step is integrated into the service scheduling engine to dynamically select the optimal service instance from modules such as customer phone calls, service allocation, and task reminders. This can be achieved through proper configuration. and The value (e.g.) , The system can achieve a balance between load balancing and geographic location optimization, thereby improving customer response efficiency and satisfaction. This step effectively supports the core objective of this invention to achieve intelligent resource scheduling in a distributed environment, enhancing the system's scalability and service quality.

[0063] S32 dynamically adjusts the number of running instances based on real-time resource utilization. When CPU utilization exceeds a threshold... Automatic expansion is triggered at certain times.

[0064] Specifically, in some implementations, the step of dynamically adjusting the number of running instances based on real-time resource utilization is one of the key mechanisms in the distributed service architecture of this invention for ensuring system stability and response efficiency. This step involves monitoring the CPU utilization of running instances and adjusting the number of instances when it exceeds a preset threshold. Automatic scaling is triggered in real time to achieve elastic resource scheduling. Specifically, the system uses distributed monitoring components (such as Prometheus, Zabbix, or a self-developed monitoring module) to collect CPU utilization data of each running instance in real time. The collection frequency is usually set to once every 30 seconds to 1 minute to ensure a balance between real-time monitoring and system overhead.

[0065] When the CPU utilization of a certain instance Meet the conditions At this time, the system will trigger the expansion logic. Among them, This is a dynamic threshold set by the system administrator based on business load characteristics, typically ranging from 60% to 85%. The specific value can be optimized based on historical load data and business response SLAs (Service Level Agreements). Scaling up is executed by a scheduling center (such as the Kubernetes scheduler or a custom scheduling module). Based on the current load and resource pool status, it dynamically creates new running instances and migrates some request traffic to the new instances to alleviate the pressure on the original instances.

[0066] Furthermore, this step supports multi-dimensional resource monitoring and collaborative scaling strategies, such as combining metrics like memory usage, network throughput, and request queue length for comprehensive judgment. In practical applications, this mechanism is widely deployed in high-concurrency modules such as customer phone calls, service allocation, and data report generation, ensuring that the system maintains low latency and high availability even when the number of customers surges or service requests spike. Through this step, the system achieves on-demand resource allocation and dynamic scaling, effectively improving service elasticity and resource utilization in a distributed architecture, reducing operational costs, and enhancing customer experience.

[0067] S4 uses an intelligent service routing engine to combine customer preference tags and behavioral patterns to dynamically combine service modules to generate personalized service processes.

[0068] Specifically, the step in this invention of "dynamically combining service modules to generate personalized service processes by integrating customer intention tags and behavioral trajectories through an intelligent service routing engine" is the core mechanism for achieving precise service and efficient operation for life insurance customers. This step, based on a distributed service architecture, drives the dynamic generation and optimization of service processes through the fusion analysis of customer tagging systems and behavioral data, thereby improving customer experience and business conversion efficiency.

[0069] In this embodiment, the intelligent service routing engine combines a rule engine with a machine learning model to analyze customer intent tags (such as insurance intent, policy maintenance needs, and claims concerns) and behavioral patterns (such as app click paths, page dwell time, and telephone response rates) in real time. The system uses a preset tag weight matrix... Combined with customer behavior sequences Calculate the customer's service preference vector ,in Indicates the first The trigger status (0 or 1) of each intention tag. These are the weighting coefficients for the behavioral trajectory. This vector is used to match the combination strategy of service modules, thereby generating a personalized service flow.

[0070] In this embodiment, the system supports dynamic adjustment of tag weights, with weight values ​​ranging from [value missing]. ,and To ensure the interpretability and configurability of the tagging system, the collection frequency of behavioral trajectories can be set to once every 5 minutes. Data storage adopts a distributed log system (such as Kafka + HDFS), supporting high concurrency and real-time processing. The composition logic of service modules is based on a service orchestration engine (such as Camunda or Activiti), supporting parallel, serial, and conditional branch configurations of service nodes.

[0071] This step is widely used in practical applications such as customer lifecycle management, marketing campaign triggering, and service process optimization. For example, after a customer submits a security protection request, the system can automatically identify their historical behavior and intention tags, combine them to create a personalized process of "security protection consultation → face-to-face appointment → document submission → service completion", and intelligently allocate services based on the customer's geographical location and the service personnel's workload.

[0072] In this embodiment, this step enables dynamic adaptation and personalized recommendations of the service process, significantly improving the accuracy of customer response and service efficiency. Through the fusion modeling of tags and behaviors, the system can improve customer service matching accuracy to over 90%, while reducing the proportion of manual intervention and improving the overall level of operational automation.

[0073] The data processing method of this invention, by adopting a distributed service architecture, achieves efficient response, flexible expansion, and comprehensive management of the entire process of the life insurance customer management system, significantly improving customer service quality and marketing accuracy.

[0074] Furthermore, S4 includes: S41 uses a rule engine to prioritize customer intention tags and generate a service process decision tree.

[0075] Specifically, in some implementations, the step of "prioritizing customer intention tags using a rule engine to generate a service process decision tree" in this invention is based on an intelligent customer intention recognition and service path planning mechanism under a distributed service architecture. This step, by integrating a rule engine and a tag system, enables dynamic evaluation of customer intention tags and automatic generation of service processes, thereby improving customer response efficiency and service accuracy.

[0076] In this embodiment, this step first relies on the construction and updating of customer intention tags. Customer intention tags are entered by call center agents during telephone interviews or automatically generated by the system based on customer behavior (such as app clicks, questionnaire feedback, complaint content, etc.). The tag system typically includes dimensions such as insurance intention, policy maintenance needs, claims consultation, and product preferences, with each tag potentially having a weighted coefficient. This reflects the priority of rules within the service flow. The rule engine employs an implementation based on Drools or a similar rule processing framework, supporting dynamic loading and real-time execution of rules. The rule base pre-defines several service path decision rules, such as:

[0077] in, This indicates the customer's rating on the insurance intention tag. and The preset threshold parameter is usually set to 0. , This is to distinguish between high-priority and low-priority requirements.

[0078] In this embodiment, the system supports configuration of tag weights, rule priorities, service path matching degrees, etc. For example, tag weights... The rule priority can be adjusted within the range of [0,1]. Integers are used, ranging from [1, 100], with higher values ​​indicating higher priority for the rule. Furthermore, the system supports a tag conflict handling mechanism; when multiple tags simultaneously satisfy different rules, a weighted scoring model is used for comprehensive ranking.

[0079] in, Indicates that the customer is at the The overall score across each service path This represents the total number of tags.

[0080] In this embodiment, this step is widely used in service allocation and marketing path planning for life insurance customers. For example, after a customer makes a phone call, the system automatically generates a service process decision tree based on their preference tags, recommending whether to arrange a face-to-face visit, whether to push products, and whether to transfer the case for complaint handling. This mechanism can be deployed in a distributed microservice architecture, supporting high concurrency and low latency customer response.

[0081] In this embodiment, this step enables the structured processing of customer intentions and the automated generation of service paths, significantly improving the intelligence level and response efficiency of the service process. Through the flexible configuration of the rule engine, the system can adapt to service strategy adjustments under different business scenarios, enhancing the personalization and precision of customer management.

[0082] S42 uses a machine learning model to predict customer behavior patterns, and the model output is a probability matrix of service module combinations. ,in This represents the probability that the i-th customer triggers the j-th service module.

[0083] Specifically, in some implementations, predicting customer behavior patterns using machine learning models is one of the core steps in achieving precision marketing and personalized services within the distributed service architecture of this invention. This step constructs a service module combination probability matrix based on multi-dimensional features such as historical customer behavior data, telephone records, and intent tags. ,in Indicates the first The customer triggered the first The model calculates the probability of each service module. It typically employs supervised learning methods, such as logistic regression, random forest, or deep neural networks (DNNs), taking a sequence of customer behavior as input and outputting its trigger probability on different service modules.

[0084] In this embodiment, feature vectors need to be constructed during the model training phase. This includes basic customer attributes (such as age, gender, and occupation), policy information (such as coverage amount and type of insurance), historical service records (such as number of phone calls and frequency of complaints), and behavioral tags (such as "interested in pension insurance" and "have policy maintenance needs"). Target variable Indicates whether the customer has triggered the first... Each service module. The model is trained by maximizing the likelihood function or minimizing the cross-entropy loss function, and finally outputs a probability matrix. ,in The output function of the model. Used to map the output to a probability distribution.

[0085] In this application embodiment, the model's prediction accuracy is typically evaluated using AUC (Area Under Curve) and F1-score, requiring AUC ≥ 0.85 and F1-score ≥ 0.75. The division of service modules must conform to business logic, generally including telephone outreach, policy maintenance, claims services, product recommendations, etc., with a total number of modules... The number of parameters should typically be kept between 10 and 20 to ensure model interpretability and computational efficiency. Furthermore, a model update frequency of once a week is recommended to adapt to dynamic changes in customer behavior.

[0086] In this embodiment, this step is widely used in service allocation after a customer phone call, online marketing material delivery, task reminders, and resource scheduling. For example, after a customer completes a phone call, the system... Based on the prediction results, customers are automatically assigned to the module most likely to generate a service response, such as "security service" or "product recommendation", thereby improving service efficiency and customer conversion rate.

[0087] The technical effect of this step is that by quantifying the potential connections between customers and service modules, it enables intelligent scheduling and personalized recommendations for service processes, significantly improving customer response rates and service satisfaction, and providing key support for resource optimization and precision marketing in distributed systems.

[0088] The data processing method of this invention, by adopting a distributed service architecture, achieves efficient response, flexible expansion, and comprehensive management of the entire process of the life insurance customer management system, significantly improving customer service quality and marketing accuracy.

[0089] S5 involves executing customer behavior tracking and remarketing push steps, specifically including: Specifically, in the customer behavior tracking and remarketing push process, the system uses multi-dimensional data collection and behavioral modeling to track the real-time behavior of life insurance customers across various online channels (such as apps, websites, and WeChat official accounts), and delivers precise remarketing information based on customer preference tags and behavioral characteristics. This step is technically implemented using a distributed service architecture, combining user behavior log collection, tag matching algorithms, and message push mechanisms to ensure the system has high concurrency processing capabilities and low latency response characteristics.

[0090] In this embodiment, the system employs a behavior analysis service module within a microservice architecture. It collects behavioral data at various online touchpoints during customer visits (such as page clicks, dwell time, product browsing, and questionnaire completion) using event tracking technology. The collected data is encapsulated in JSON format and transmitted asynchronously via a Kafka message queue, ensuring data real-time performance and decoupling from the system. The behavioral data is indexed and stored in Elasticsearch, supporting rapid retrieval and tag matching. The system uses a pre-defined tag rule engine (such as rule-based decision trees or regular expression matching) to categorize customer behavior and generate intention tags such as "concerned about pension insurance" and "needs long-term care."

[0091] In this embodiment, the system is configured to collect behavior logs at a frequency of no less than 5,000 per second, with the tag matching algorithm response time controlled within 200ms and the message push latency not exceeding 500ms. Push content is dynamically generated using a template engine, supporting personalized field replacements such as customer name, product name, and promotional information.

[0092] In this embodiment, this step is widely used in the precision marketing activities of life insurance companies. For example, after a customer browses a health insurance product, the system can push relevant product introductions or promotional information within 24 hours to improve customer conversion rates. In addition, it can also be used in scenarios such as customer churn warning and product recommendation optimization.

[0093] The technical benefits of this step are that, through behavioral data-driven remarketing strategies, it significantly improves customer response rates and marketing conversion efficiency, while reducing the cost of manual screening and push notifications, and enhancing customer loyalty and satisfaction.

[0094] S51 uses the Flink streaming framework to analyze customers' browsing history and click behavior on websites, apps, and other online channels in real time.

[0095] Specifically, in some implementations, analyzing customers' browsing history and click behavior on websites, apps, and other online channels in real time using the Flink streaming framework is one of the core technical implementation methods of the "Online Service Preparation" module in this invention. This step builds a real-time data processing pipeline based on Apache Flink and uses an event-driven architecture to perform low-latency, high-throughput streaming processing of customer behavior data, thereby realizing the dynamic generation of customer behavior tags and the immediate response of service strategies.

[0096] In this embodiment, the system acquires clickstream data of customers accessing the life insurance company's online platform through data collection techniques (such as front-end SDK or back-end log collection). This data includes page access timestamps, clicked element IDs, dwell time, and navigation paths. This data is then fed into the Flink stream processing engine in real-time via Kafka or Flink's Source API in JSON format. Flink uses a window mechanism (such as sliding or scrolling windows) to aggregate and analyze customer behavior, calculating metrics such as average dwell time on specific pages, click frequency, and access path depth. Simultaneously, the system introduces a state management mechanism to maintain customer session state and behavioral context, ensuring accurate identification of behavioral patterns even after multiple customer visits.

[0097] In this embodiment, the parallelism of the Flink job is typically set to 16-32 to accommodate data processing needs in high-concurrency scenarios. The window size can be configured as a 1-minute sliding window. To ensure a balance between real-time performance and data integrity, an event time processing mechanism is enabled to address the impact of network latency or out-of-order events. Furthermore, the system supports tag matching of customer behavior based on rule engines (such as Drools or Flink SQL). For example, if a customer clicks on a "pension insurance" related page more than three times consecutively, the system automatically tags them with the intention to "pay attention to pension insurance".

[0098] In this embodiment, this step is widely applied to the analysis of life insurance customers' behavior on apps or official websites, such as browsing product detail pages, clicking on marketing pop-ups, and submitting insurance intentions. Through real-time analysis, the system can immediately trigger personalized service processes when customers exhibit potential needs, such as pushing product recommendations, assigning call center agents to follow up, or generating task reminders. This technology is particularly suitable for customer interaction scenarios with high concurrency and high real-time requirements, such as key marketing nodes like holiday promotions and new product launches.

[0099] The technical advantage of this step lies in the fact that, through Flink's streaming processing capabilities, the system can achieve millisecond-level customer behavior responses, significantly improving the timeliness and accuracy of customer tag generation, thereby providing reliable data support for subsequent targeted marketing and service recommendations. At the same time, this technical solution has good scalability, capable of supporting the real-time processing of tens of millions of customer behavior data points, meeting the long-term development needs of the life insurance business.

[0100] S52 generates customer behavior tags based on the analysis results and determines the tag matching degree. Calculate the priority of recommended products, where The matching score between the customer and the i-th product. This represents the maximum matching score.

[0101] Specifically, this step involves generating customer behavior tags based on customer behavior analysis results, and then applying a tag matching formula. Calculating the priority of recommended products is one of the core implementation methods of this invention in the precision marketing and personalized service module. Its technical principle is based on feature extraction and tagging of customer behavior data, combined with the normalized calculation of product matching scores, to achieve dynamic ranking of customer-recommended content.

[0102] In this embodiment, the system first collects customer interaction data from online channels such as apps, websites, and WeChat through a customer behavior tracking module. This data includes page browsing time, click frequency, product interest records, and questionnaire completion information. After preprocessing, this data is input into a tag generation engine. This engine classifies and tags customer behavior based on a rule engine and machine learning models (such as decision trees, random forests, or LightGBM), generating behavioral tags such as "interested in pension insurance," "preferring long-term care," and "high-net-worth client." Each tag corresponds to a set of feature vectors for subsequent matching calculations.

[0103] Match In the calculation, This represents the matching score between the customer and the i-th product. This score is calculated from the similarity between the multidimensional feature vector and the product attributes, usually using methods such as cosine similarity or weighted Euclidean distance. The maximum matching score between the current customer and all candidate products is used for normalization to ensure the matching degree is within the range of [0, 1]. This formula can be applied to the Top-K ranking algorithm in recommendation systems, dynamically adjusting the recommendation priority based on the matching degree between customer tags and product tags.

[0104] In this embodiment, this step is widely used in scenarios such as customer profiling, product recommendation, and marketing material delivery. For example, when a customer is about to retire, the system can automatically identify their "retirement needs" tag and prioritize recommending retirement insurance products with higher matching scores based on a matching formula. This method significantly improves the accuracy and response efficiency of the recommendation system, providing data support for subsequent customer follow-up and service arrangements.

[0105] In summary, this step, through the intelligent generation of behavioral tags and the quantitative calculation of matching degree, achieves accurate matching between customers and products, which is an important technical support for this invention in improving customer satisfaction and conversion rate.

[0106] The data processing method of this invention improves the real-time performance of customer behavior response and the accuracy of personalized recommendations by introducing the Flink streaming processing framework to analyze customer online behavior in real time and generate recommended product priorities based on dynamic matching algorithms, thereby enhancing remarketing effectiveness and customer conversion rates.

[0107] Example 2 This invention relates to a life insurance customer management system based on a distributed service architecture, such as... Figure 2 As shown: System modules: Create customer groups and customer lists.

[0108] Function: In a CRM or customer management system, filter and create customer groups based on preset tags to generate a customer list.

[0109] Explanation: This is the foundation of the project, used to identify the target customer group. Through pre-set tags, the system can accurately filter customers who meet specific criteria, providing accurate data support for subsequent marketing and services.

[0110] Assigned to a call center operator.

[0111] Function: Assign the filtered customer list to different operators for telephone calls.

[0112] Explanation: The system enables the rational allocation of customers, ensuring that each call center agent receives a suitable customer base and improving work efficiency. Simultaneously, the system can dynamically adjust resource allocation based on agent workload and performance.

[0113] Customer details and telephone interview with operators.

[0114] Function: Operators can view customer details (such as gender, age, policy details, etc., displayed in an anonymized manner) in the system and conduct telephone interviews.

[0115] Explanation: The system provides detailed customer information, helping agents better understand customer needs and conduct targeted marketing. It also records customer feedback and requests during the call process, providing a basis for subsequent services.

[0116] Assign service personnel.

[0117] Function: Based on the results of the telephone interview or customer needs, assign service personnel (such as policy service personnel) to follow up.

[0118] Explanation: To ensure customer issues are resolved promptly and improve customer satisfaction. The system can intelligently allocate service personnel based on factors such as customer service needs and geographical location, thereby improving service efficiency and quality.

[0119] Offline service arrangements.

[0120] Functions: The system arranges offline services based on the allocation of service personnel, including task assignment, contacting customers, scheduling face-to-face visits, and inviting participants to meetings.

[0121] Explanation: Through systematic management, the smooth operation of offline services is ensured. The system can also track service progress and results in real time, providing customers with a more convenient and efficient service experience.

[0122] Online service preparation.

[0123] Function: Call center agents interact with customers and provide online services through online channels (such as websites, apps, etc.).

[0124] Explanation: Expand service channels and improve service convenience. The online service system can generate customer behavior tags based on customers' online behavior and then make corresponding service recommendations and targeted marketing.

[0125] Data report generation.

[0126] Function: The system regularly generates data reports to display information such as customer behavior, service status, and tag distribution.

[0127] Explanation: Provides administrators with comprehensive data analysis support, helping them understand customer business operations and develop corresponding marketing strategies and service plans.

[0128] Task assignment and reminders.

[0129] Function: Generate tasks to be done in the system, such as face-to-face visits and invitations to attend meetings, and remind relevant personnel to handle them in a timely manner.

[0130] Explanation: Through systematic management, tasks are ensured to be executed in an orderly manner. The system can also intelligently sort and remind users of tasks based on their urgency and priority, thereby improving work efficiency.

[0131] Customer preference tagging service.

[0132] Function: Based on customer feedback and needs, assign relevant intention tags to customers (such as willingness to purchase insurance, policy maintenance needs, etc.).

[0133] Explanation: Facilitates follow-up and targeted marketing. The system can automatically recommend relevant products and services based on customer preference tags, improving marketing effectiveness and customer satisfaction.

[0134] Contact the customer.

[0135] Function: Provides multiple contact methods (such as telephone, WeChat, etc.) to facilitate communication between service personnel and customers.

[0136] Explanation: To enhance customer loyalty and improve service quality.

[0137] Schedule in-person visits and invite participants to the conference.

[0138] Function: Based on customer needs, schedule face-to-face meetings or invite customers to participate in relevant activities (such as product presentations).

[0139] Explanation: By communicating face-to-face, we can gain a deeper understanding of customer needs and improve conversion rates.

[0140] Orders are processed.

[0141] Function: Complete the policy issuance process within the system, including entry of insurance information, underwriting, and issuance of the policy.

[0142] Explanation: To digitize insurance policies and improve work efficiency.

[0143] Individual / team activities.

[0144] Function: Records and tracks the activity volume of an individual or team, such as the number of phone calls and face-to-face visits.

[0145] Explanation: Through data analysis, evaluate work effectiveness and optimize sales strategies.

[0146] Call center agents add customers through online channels.

[0147] Function: Call center agents can add customers as friends through online channels (such as WeChat) to conduct online communication and provide services.

[0148] Explanation: This further expands service channels and enhances customer loyalty. Online communication is more flexible and convenient, helping to build closer customer relationships.

[0149] Insurance needs, policy maintenance needs, and claims needs.

[0150] Function: Record and process customer needs such as insurance application, policy maintenance, and claims.

[0151] Explanation: To ensure that customer needs are responded to and processed in a timely manner. The system can automatically assign requests to the appropriate departments or personnel, improving processing efficiency and quality.

[0152] Greetings, questionnaires, complaint handling, and complaint transfer.

[0153] Functions: Provide greeting services, send questionnaires to collect customer feedback, handle customer complaints and transfer them to relevant departments.

[0154] Explanation: To improve customer satisfaction, collect market information, and optimize service processes. The system can automatically record customer feedback and complaints, and generate corresponding processing reports and data analysis results.

[0155] Mass distribution of promotional materials and products.

[0156] Function: Send marketing materials and product information to customers via the system.

[0157] Explanation: To increase brand exposure and product sales.

[0158] Customer behavior tracking.

[0159] Function: Send marketing materials and product information to customers via the system.

[0160] Explanation: Increase brand exposure and product sales. The system can automatically match relevant marketing materials and product information based on customer tags and needs, achieving precise marketing.

[0161] System data flow: Creating customer groups and customer lists: First, filter and create key customer groups based on tags in the CRM or customer management system to generate a customer list.

[0162] Assign to agents: Assign the customer list to different agents for telephone calls.

[0163] Customer Details and Call Center Contacts: Call center agents can view customer details in the system and conduct calls, recording customer needs and feedback. Customer preference tags are also generated.

[0164] Service personnel assignment: Based on the results of the telephone interview or customer needs, service personnel are assigned to follow up.

[0165] Offline service arrangements: The system arranges offline services based on the allocation of service personnel, including task completion, contacting clients, scheduling face-to-face visits, and inviting participants to meetings. During the offline service process, new client tags and needs information may be generated. Service progress and results are tracked in real time.

[0166] Online service preparation: Call center agents interact with customers through online channels (such as websites, apps, etc.). The online service system generates customer behavior tags based on customer online behavior and provides corresponding services. Customer behavior is tracked.

[0167] Data Report Generation: The system regularly generates data reports, displaying information such as customer behavior, service status, and tag distribution. Administrators can view and analyze these data reports to make corresponding management decisions.

[0168] Task assignment and reminders: Generate tasks to be assigned in the system, such as scheduling face-to-face visits and inviting people to meetings, and remind relevant personnel to handle them in a timely manner.

[0169] Contacting customers: Service personnel maintain communication with customers through the contact information provided by the system.

[0170] Schedule in-person visits and invite clients to events: Schedule in-person visits or invite clients to relevant events based on their needs.

[0171] Individual / team activities: Record and track the amount of activity of individuals or teams.

[0172] Customer Intention Tagging Service: Based on customer feedback and needs, we tag customers with relevant intention tags to facilitate follow-up and targeted marketing.

[0173] Call center agents add customers through online channels: Call center agents add customers as friends through online channels to communicate and provide services online.

[0174] Insurance needs, policy maintenance needs, and claims needs: Record and process various customer needs.

[0175] Greetings and Questionnaires: Provide greeting services and send out questionnaires to collect customer feedback.

[0176] Bulk Marketing Materials and Products: Send marketing materials and product information to customers through the system to increase brand exposure and product sales.

[0177] Complaint Handling: If a customer submits a complaint through online or offline channels, the system will transfer the complaint to the appropriate department. After the complaint is resolved, the relevant information will be recorded and updated in the customer's file.

[0178] Order issuance and service completion: After the offline service is completed, the system will record the order information. Once all services are completed, the relevant information will be archived and updated in the customer's file.

[0179] Customer behavior tracking: Tracking customer behavior within the system to understand customer interests and provide a basis for precision marketing.

[0180] Example 3 This invention also provides a life insurance customer management device based on a distributed service architecture, such as... Figure 3 As shown, the device includes: Distributed service architecture building module 100 is used to build a distributed service architecture, decompose the entire customer operation process into multiple independent service modules, and realize modular deployment of services; The message queue and event-driven synchronization module 200 is used to synchronize customer behavior data and demand information between various service modules in real time based on message queues and event-driven mechanisms. The dynamic resource scheduling and instance adjustment module 300 is used to intelligently allocate service resources and adjust the running instances of the module based on business load and geographical location parameters using a dynamic resource scheduling algorithm. The intelligent service routing and process generation module 400 is used to dynamically combine service modules to generate personalized service processes by combining customer intention tags and behavior trajectories through the intelligent service routing engine.

[0181] Example 4 To implement the methods of the above embodiments, the present invention also provides a computer device, which includes a memory and a processor; wherein the processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the various steps of the methods described above.

[0182] Example 5 To implement the above embodiments, this application also proposes a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described in the foregoing embodiments.

[0183] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0184] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0185] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this invention, "a plurality of" means at least two, such as two, three, etc., unless otherwise explicitly specified.

Claims

1. A method for managing life insurance customers based on a distributed service architecture, characterized in that, include: S1, build a distributed service architecture, break down the entire customer operation process into multiple independent service modules, and realize modular service deployment; S2, based on message queues and event-driven mechanisms, synchronizes customer behavior data and demand information between various service modules in real time; S3 uses a dynamic resource scheduling algorithm to intelligently allocate service resources and adjust module running instances based on business load and geographical location parameters; S4 uses an intelligent service routing engine to combine customer preference tags and behavioral patterns to dynamically combine service modules to generate personalized service processes.

2. The method as described in claim 1, characterized in that, The construction of a distributed service architecture, which breaks down the entire customer operation process into multiple independent service modules and enables modular service deployment, also includes: S11 breaks down the customer management process into six core service modules: customer screening service, task allocation service, service execution service, data reporting service, complaint handling service, and behavior tracking service. S12 uses containerization technology to deploy each service module independently, and uses a Kubernetes cluster to achieve dynamic scaling of the service modules.

3. The method as described in claim 1, characterized in that, The real-time synchronization of customer behavior data and demand information between service modules based on message queues and event-driven mechanisms also includes: S21 uses Apache Kafka to build an event-driven architecture, achieving second-level synchronization of customer behavior data through the producer-consumer pattern; S22 classifies and processes synchronized data into three types of data streams: customer tag update events, service status change events, and requirement change events.

4. The method as described in claim 1, characterized in that, The example of using a dynamic resource scheduling algorithm to intelligently allocate service resources and adjust module operation based on business load and geographical location parameters also includes: S31, calculate the service resource allocation weights based on the load balancing algorithm, the weight formula is as follows: ,in The weight of the i-th service instance. This is the business load factor. For geographic location matching; S32 dynamically adjusts the number of running instances based on real-time resource utilization. When CPU utilization exceeds a threshold... Automatic expansion is triggered at certain times.

5. The method as described in claim 1, characterized in that, The method of dynamically combining service modules to generate a personalized service process by combining customer intention tags and behavioral patterns through an intelligent service routing engine also includes: S41 uses a rule engine to prioritize customer intention tags and generate a service process decision tree; S42 uses a machine learning model to predict customer behavior patterns, and the model output is a probability matrix of service module combinations. ,in This represents the probability that the i-th customer triggers the j-th service module.

6. The method as described in claim 1, characterized in that, Also includes: S5 involves executing customer behavior tracking and remarketing push steps, specifically including: S51 uses the Flink streaming framework to analyze customers' browsing history and click behavior on websites, apps and other online channels in real time. S52 generates customer behavior tags based on the analysis results and determines the tag matching degree. Calculate the priority of recommended products, where The matching score between the customer and the i-th product. This represents the maximum matching score.

7. A life insurance customer management device based on a distributed service architecture, characterized in that, include: The distributed service architecture building module is used to build a distributed service architecture, decompose the entire customer operation process into multiple independent service modules, and realize modular deployment of services; The message queue and event-driven synchronization module is used to synchronize customer behavior data and demand information between various service modules in real time based on message queues and event-driven mechanisms. The dynamic resource scheduling and instance adjustment module is used to intelligently allocate service resources and adjust the running instances of the module based on business load and geographical location parameters using a dynamic resource scheduling algorithm. The intelligent service routing and process generation module is used to dynamically combine service modules to generate personalized service processes by combining customer intention tags and behavioral trajectories through the intelligent service routing engine.

8. A computer device, characterized in that, Including processor and memory; The processor reads executable program code stored in the memory to run a program corresponding to the executable program code, so as to implement the life insurance customer management method based on a distributed service architecture as described in any one of claims 1-6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the life insurance customer management method based on a distributed service architecture as described in any one of claims 1-6.

Images