Operation server for supporting insurance product counseling based on user emotion analysis and operation method thereof

Abstract

An operating server and a method of operation for supporting consultation on insurance products based on user sentiment analysis are disclosed. The method of operation of the present invention includes the steps of: receiving consultation data generated while a consultation service for designing an insurance product is provided; monitoring the consultation status using the consultation data; collecting a situation data set when a failure event indicating failure in the further progress of the consultation procedure occurs; determining each candidate cause item of the situation data set; normalizing indicators corresponding to the candidate cause items to generate a cause evaluation characteristic vector and calculating a cause matching index for each candidate cause item; determining the candidate cause item having the highest value among the cause matching indices as the failure cause item of the consultation procedure; and generating improvement plan data that supports a reduction in the cause matching index corresponding to the failure cause item and providing it to an expert terminal.

Description

Technology Field

[0001] The present invention relates to an operating server and a method of operation that support consultation on insurance products based on user emotion analysis, and more specifically, to an operating server and a method of operation that identify the state of the consultation process related to insurance products and reflect the user's emotional signals to support successful subscription. Background Technology

[0002] Generally, the insurance subscription journey consists of a multi-stage process that follows the sequence of consultation (identifying needs), design (plan calculation), underwriting, Know Your Customer (KYC), payment, and subscription completion. During this process, data such as user input, consultation logs, design proposals, underwriting regulations, payment attempts and errors, and document submissions are generated across multiple systems and channels (face-to-face, call centers, mobile, web, etc.). Traditionally, operational staff have relied on partial data retrieval or post-hoc statistics; however, there has been a lack of systems capable of detecting signs of failure in real time, analyzing their causes in a multi-dimensional manner, and making immediate corrections.

[0003] In particular, when insurance consultations or enrollment procedures result in failure, it is difficult to clearly analyze whether the failure is simply due to violations of underwriting regulations, behavioral issues such as input errors, waiting delays, or repeated cancellations, or emotional factors of the user (e.g., anxiety, fatigue, or lack of concentration). Current systems are primarily capable of capturing only objective factors, such as regulatory inconsistencies or system errors, and are highly limited in their ability to consider how changes in the user's emotional state during the consultation process contributed to procedural failure. Therefore, even if failures occur repeatedly within the same procedure, there is a limitation in that the cause cannot be systematically distinguished or explained as being due to regulatory issues, consultation interface problems, or the user's emotional reactions.

[0004] Moreover, as the proportion of non-face-to-face consultations increases, qualitative factors such as screen transition delays, UX confusion, and accumulated tension, indifference, and fatigue have a significant impact on failure rates; however, existing consultation support systems fail to effectively reflect these factors. Consequently, counselors and designers are forced to rely on their personal experiences and make speculative responses, leading to unclear causes of failure, reduced customer experience, and increased rework costs.

[0005] Meanwhile, recent advancements have been made in sentiment analysis technologies based on conversation logs, voice, text, and interaction data; time-series analysis of user behavior sequences; and outcome prediction technologies through condition changes. However, many solutions remain limited to rule-based or simple recommendations, and systems capable of simultaneously considering the causes of consultation failures from a complex perspective involving rules, behavior, emotions, and condition changes, while immediately linking these findings to improvement measures, have not yet been sufficiently implemented. Consequently, there is a demand for methods or systems capable of quantitatively analyzing the causes of failures that occur during insurance product consultations and enrollment procedures, and providing explanations and responses that specifically reflect the user's emotional factors. The problem to be solved

[0006] The objective of the present invention, which aims to solve the aforementioned problems, is to provide an operating server and a method of operation thereof that identify the status of the consultation process related to insurance products and reflect the user's emotional signals to support successful subscription. means of solving the problem

[0007] One aspect of the present invention for achieving the above objective provides an operating server that supports consultation on insurance products based on user emotion analysis and a method of operation thereof.

[0008] The above method of operation is a method of operation performed on an operating server that supports consultation for insurance products based on user sentiment analysis, comprising the steps of: receiving consultation data including user input data, consultation log data, insurance design proposal data, underwriting regulation data, payment transaction data, and document submission data generated while a consultation service for designing insurance products is provided; using the consultation data, determining the current state of the user's consultation process as one of a consultation start procedure, design completion procedure, underwriting review procedure, identity verification procedure, payment procedure, and subscription success procedure according to a plurality of pre-set procedures that distinguish the consultation process, and monitoring the consultation status; monitoring the occurrence of a failure event indicating failure regarding further progress of the consultation process, and, if the failure event occurs, collecting consultation data, underwriting regulation data, payment transaction logs, and user reaction signals included in a pre-set time interval based on the time of occurrence of the failure event as a situational data set; analyzing virtual input data generated through condition changes of the situational data set and the insurance data included in the situational data set to determine, respectively, regulation-based cause candidate items, behavior-based cause candidate items, sentiment-based cause candidate items, and condition change-based cause candidate items; and the regulation A step of generating a cause evaluation characteristic vector by normalizing indicators corresponding to the cause candidate items based on the basis, behavior-based cause candidate items, emotion-based cause candidate items, and condition change-based cause candidate items, and calculating a cause matching index for each cause candidate item by applying pre-set weights to the cause evaluation characteristic vector, and determining the cause candidate item having the highest value among the cause matching indices as the cause item of failure in the counseling procedure.It includes the step of generating improvement plan data that supports a reduction in the cause matching index corresponding to the above failure cause items and providing it to an expert terminal.

[0009] The step of receiving the consultation data further includes: receiving user input data including personal information input values ​​collected through the input interface of the user terminal, health-related question response values, and subscription purpose selection values; receiving consultation log data including conversation logs, consultation elapsed time, consultation screen movement history, and event occurrence logs occurring during a consultation session of the consultation service; receiving insurance design plan data including premium calculation values, coverage items, special rider combinations, payment cycle setting values, and estimated refund calculation results; extracting underwriting regulation data from a database including age requirements, occupation classification, health status criteria, risk grade calculation criteria, and subscription limit values; receiving payment transaction data including payment attempt history, payment approval status, payment method type, and payment error code; and receiving data on the submission of documents such as the user's identification card image, income verification documents, health checkup forms, and other documents to satisfy subscription requirements.

[0010] The step of monitoring the consultation status further includes: a step of extracting a consultation procedure definition rule that defines a plurality of procedures including a consultation start procedure, a design completion procedure, an underwriting review procedure, an identity verification procedure, a payment procedure, and a subscription success procedure; a step of determining the current consultation procedure status as one of a consultation start procedure, a design completion procedure, an underwriting review procedure, an identity verification procedure, a payment procedure, and a subscription success procedure by correlating the event tags, timestamps, and screen transition history of real-time consultation log data with the consultation procedure definition rule; and a step of generating a status transition history by accumulating and storing changes in the determined consultation procedure status in chronological order, and monitoring the consultation status based on the status transition history.

[0011] The step of collecting the above-mentioned situational data set further comprises: extracting a time stamp at a point in time when the consultation status is designated as a failure event and calculating a preset time interval before and after based on the time stamp; collecting a consultation log that includes user input values, consultation conversation logs, insurance plan attribute values, and payment attempt history included in the time interval before and after; extracting a regulation log that includes underwriting regulation attribute values ​​and attribute-specific reference values ​​defined in the underwriting regulation data included in the time interval before and after; collecting a payment log that includes payment approval logs, error codes, and payment method attributes included in the time interval before and after; collecting a user response signal that includes voice signals, text input, and user interaction data collected during the time interval; and collecting the consultation log, the regulation log, the payment log, and the user response signal as a situational data set based on the consultation log, the regulation log, the payment log, and the user response signal.

[0012] The step of determining each of the above-mentioned candidate cause items further comprises: a step of determining unsatisfied items as regulation-based candidate cause items by comparing the attribute values ​​of consultation data included in the situation data set with the standard values ​​defined in the underwriting regulation data using a condition matching operation; a step of determining behavior-based candidate cause items by normalizing consultation logs and user interaction data included in the situation data set in chronological order to quantify the number of input errors, waiting time, number of cancellations, and deviation of dwell time, and comparing each quantified value with the procedure progress history data of the set of successful subscribers using a sorting-based comparison operation; a step of calculating an emotional state index and an emotion-based failure risk using feature vectors extracted from voice signals, text inputs, and user interaction data included in the situation data set, and determining emotion-based candidate cause items based on the calculation results; and a step of calculating success rate fluctuation values ​​by inputting virtual input data generated by changing the premium level, coverage and special clause configuration, payment cycle, and payment method included in the consultation data into a pre-trained AI-based prediction model, and determining elements where the fluctuation value is above a threshold as condition change-based candidate cause items.

[0013] The step of calculating the above-mentioned cause matching index further includes the step of generating a cause evaluation characteristic vector by normalizing the indicator value corresponding to each of the rule-based, behavior-based, emotion-based, and condition change-based cause candidate items to a range of 0 to 1, and the step of calculating the cause matching index of each cause candidate item by applying a pre-set weight vector to the cause evaluation characteristic vector generated by normalization.

[0014] The step of generating and providing the improvement plan data to an expert terminal further includes: verifying the cause matching index calculated for each candidate cause item and determining the candidate cause item having the largest cause matching index as the failure cause item of the consultation procedure; extracting failure cause data from the consultation data and situation data sets, the failure cause data including the cause item identifier, time of occurrence, related procedure status history, attribute values ​​associated with the failure cause item, and cause matching index of the failure cause item; and generating improvement plan data by applying a predefined generation rule for improvement plan data based on the type of failure cause item included in the failure cause data, and transmitting the generated improvement plan data to the expert terminal.

[0015] The above-mentioned predefined rules for generating improvement plan data are defined such that, in the case of regulation-based cause items, supplementary document items for meeting underwriting regulations and design / input modification instructions are generated as improvement plan data; in the case of behavior-based cause items, procedural instructions such as input validation, retry control, waiting time mitigation, and callback suggestions are generated as improvement plan data; in the case of sentiment-based cause items, consultation conversation scenarios including conversation tone, guidance phrases, pauses, and reconnection timing are generated as improvement plan data; and in the case of condition change-based cause items, adjustment plans are generated as improvement plan data by selecting the combination with the maximum prediction success rate among parameter combinations within the acceptable range using a pre-trained prediction model. Effects of the invention

[0016] The operating server according to the present invention, as described above, can provide the effect of quantitatively identifying the causes of procedural failure in terms of regulatory, behavioral, emotional, and conditional change aspects by integrally analyzing consultation data, underwriting regulation data, payment logs, and user response signals. In addition, the operating server according to the present invention can provide the effect of consistently determining the causes of procedural failure by normalizing indicators corresponding to candidate cause items and applying weights to calculate a cause matching index. Accordingly, the causes of failure can be identified based on objective criteria derived from data, without relying on the subjective experience of experts.

[0017] Furthermore, the operating server according to the present invention can provide the effect of supporting experts in taking immediately actionable measures by automatically generating improvement plan data corresponding to the determined cause of failure and providing it to an expert terminal. This increases the success rate of retries in the consultation process, reduces unnecessary repetitive tasks, and improves consultation efficiency. Moreover, since the operating server according to the present invention can include supporting indicators and estimates of success rate improvement in the improvement plan data, it can provide the effect of enabling experts to make rational and reliable decisions. Accordingly, the effect of simultaneously improving consultation quality and customer satisfaction can be expected. Brief explanation of the drawing

[0018] FIG. 1 is a schematic diagram showing an environment in which an operation method of an operating server that supports consultation on insurance products based on user emotion analysis according to one embodiment is performed. FIG. 2 is a diagram illustrating an exemplary configuration of hardware for an operating server that supports consultation on insurance products based on user emotion analysis according to one embodiment. FIG. 3 is a flowchart illustrating an operation method performed on an operating server that supports consultation on insurance products based on user emotion analysis according to one embodiment. FIG. 4 is a flowchart illustrating a method of receiving consultation data from an operating server that supports consultation on an insurance product based on user sentiment analysis according to one embodiment. FIG. 5 is a flowchart illustrating a method for monitoring the consultation status in an operating server that supports consultation on an insurance product based on user sentiment analysis according to one embodiment. FIG. 6 is a flowchart illustrating a method for collecting a situational data set in an operating server that supports consultation on an insurance product based on user sentiment analysis according to one embodiment. FIG. 7 is a flowchart illustrating a method for determining candidate cause items in an operating server that supports consultation on insurance products based on user sentiment analysis according to one embodiment. FIG. 8 is a flowchart illustrating a method for calculating a cause matching index in an operating server that supports consultation on insurance products based on user sentiment analysis according to one embodiment. FIG. 9 is a flowchart illustrating a method of transmitting improvement plan data from an operating server that supports consultation on insurance products based on user sentiment analysis according to one embodiment. Specific details for implementing the invention

[0019] The present invention is susceptible to various modifications and may have various embodiments; specific embodiments are illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the invention to specific embodiments, and it should be understood that the invention includes all modifications, equivalents, and substitutions that fall within the spirit and scope of the invention. Similar reference numerals have been used for similar components in the description of each drawing.

[0020] Terms such as first, second, A, B, etc., may be used to describe various components, but said components shall not be limited by said terms. These terms are used solely for the purpose of distinguishing one component from another. For example, without departing from the scope of the present invention, the first component may be named the second component, and similarly, the second component may be named the first component. The terms "and" and "or" include a combination of a plurality of related described items or any of a plurality of related described items.

[0021] When it is stated that one component is "connected" or "connected" to another component, it should be understood that while it may be directly connected or connected to that other component, there may also be other components in between. On the other hand, when it is stated that one component is "directly connected" or "directly connected" to another component, it should be understood that there are no other components in between.

[0022] The terms used in this application are used merely to describe specific embodiments and are not intended to limit the invention. The singular expression includes the plural expression unless the context clearly indicates otherwise. In this application, terms such as "comprising" or "having" are intended to specify the presence of the features, numbers, steps, actions, components, parts, or combinations thereof described in the specification, and should be understood as not precluding the existence or addition of one or more other features, numbers, steps, actions, components, parts, or combinations thereof.

[0023] Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as generally understood by those skilled in the art to which the present invention pertains. Terms such as those defined in commonly used dictionaries should be interpreted as having a meaning consistent with their meaning in the context of the relevant technology, and should not be interpreted in an ideal or overly formal sense unless explicitly defined in this application.

[0024] Hereinafter, the "previous and post-period interval" used in the present invention refers to a predefined time range before and after the point in time when a failure event of the consultation procedure occurs, and consultation logs, regulation logs, payment logs, and user response signals generated within said time range may be collected. The "condition matching operation" used in the present invention may refer to an operation that determines whether a specific attribute value included in the consultation data satisfies a regulation by comparing it with a reference value defined in the underwriting regulation data.

[0025] The "sort-based comparison operation" used in the present invention may refer to an operation that evaluates similarity or deviation by normalizing consultation logs and user interaction data according to chronological order and comparing indicators such as the number of input errors, waiting time, number of cancellations, and deviation in dwell time with the procedure progress history data of a set of successful subscribers. The "virtual input data" used in the present invention is data generated by modifying actual user input data or changing attribute values ​​such as premium levels, coverage and special clause configurations, payment cycles, and payment methods, and can be input into a pre-trained artificial intelligence-based prediction model to be utilized as simulation data for evaluating fluctuations in the success rate of the consultation process.

[0026] The "emotional state index" used in the present invention is a quantitative indicator calculated by inputting feature vectors extracted from voice signals, text inputs, and user interaction data collected during the counseling process into a neural network-based model pre-trained with artificial intelligence, and can represent the user's emotional state as categories such as positive, neutral, and negative, or as a continuous numerical value.

[0027] Hereinafter, preferred embodiments according to the present invention will be described in detail with reference to the attached drawings.

[0029] FIG. 1 is a schematic diagram showing an environment in which an operation method of an operating server that supports consultation on insurance products based on user emotion analysis according to one embodiment of the present invention is performed.

[0030] Referring to FIG. 1, the operation method of an operating server that supports consultation on an insurance product based on user sentiment analysis of one embodiment can be performed by an operating server (10), a user terminal (20), and an expert terminal (30), and more specifically, can be performed based on the leading operation of the operating server (10).

[0031] First, the operating server (10) may refer to a device such as a server for supporting consultation on insurance products based on user emotion analysis, and may refer to a server of a business operator selling insurance products.

[0032] The operation server (10) receives consultation data generated or collected during the insurance product consultation process and monitors the status of the consultation process. When a failure event occurs during the consultation process, it can perform the function of analyzing the cause of the failure and generating improvement plan data by configuring a set of situational data at that time. In this regard, the operation server (10) can be linked with a consultation-related database, an underwriting regulation repository, a payment log repository, etc., and can derive candidate cause items based on regulations, behavior, sentiment, and condition change through an AI-based analysis module that includes a pre-trained AI-based analysis model. Additionally, the operation server (10) may include a transmission interface for providing results to an expert terminal (30), authentication and authorization management functions, and record storage functions.

[0033] The user terminal (20) may refer to an electronic device that can be used and communicated with by a user participating in the consultation service, and may be implemented in various forms such as a smartphone, tablet, laptop, or desktop. The user terminal (20) performs consultation interactions such as inputting personal information, responding to health-related questions, selecting coverage and special clauses, requesting insurance premium calculation, verifying identity, attempting payment, and submitting documents, and can transmit input values, conversation logs, screen movement history, payment attempt history and error codes, document submission data, and reaction signals such as voice, text, and clicks generated during the process to the operating server (10).

[0034] The expert terminal (30) is an electronic device that can be used and communicated with by an expert supporting the consultation, and can receive consultation status, failure events, cause analysis results, and improvement plan data from the operation server (10) and utilize them in the consultation process. The expert terminal (30) can check improvement plans such as alternative product recommendations, document supplementation guidance, and consultation conversation scenarios provided by the operation server (10), and can supplement the consultation with the user or adjust the procedure based on this.

[0035] In addition, to perform the operation method in the present invention, the operating server (10) may receive consultation data and user response signals from the user terminal (20), and may obtain underwriting regulation data and payment logs from an internal or external storage or database. Subsequently, the operating server (10) may determine the current consultation procedure status as one of the consultation start, design completion, underwriting review, identity verification, payment, or successful subscription procedures by interpreting the event tags, timestamps, and screen transition history of the consultation logs according to the consultation procedure definition rules, and may monitor the consultation status by accumulating these in chronological order.

[0036] When a consultation procedure is identified as a failure event, the operation server (10) can construct a situation data set by extracting consultation logs, underwriting regulation logs, payment logs, and user response signals that fall within a preset time interval based on that point in time. Subsequently, the operation server (10) can analyze the constructed situation data set by an artificial intelligence-based analysis module to derive regulation-based cause candidate items based on condition matching results with underwriting regulations, behavior-based cause candidate items based on comparison results with successful user history, emotion-based cause candidate items based on the emotion state index and emotion-based failure risk calculation results, and condition change-based cause candidate items based on the success rate fluctuation value due to condition changes in the consultation data.

[0037] The operating server (10) can calculate a cause matching index by normalizing the indicators corresponding to the candidate cause items derived in this way and applying weights, and can determine the item with the highest cause matching index as the cause of failure in the consultation process. Finally, the operating server (10) can generate improvement plan data corresponding to the determined cause of failure and provide it to the expert terminal (30) so that the expert can immediately use the data in the consultation.

[0039] FIG. 2 is a diagram illustrating an exemplary configuration of hardware for an operating server that supports consultation on insurance products based on user emotion analysis according to one embodiment.

[0040] Referring to FIG. 2, in one embodiment, an operating server (100) that supports consultation on insurance products based on user sentiment analysis may include at least one processor (110) and a memory (120) that stores instructions that instruct at least one processor (110) to perform at least one operation.

[0041] Here, at least one processor (110) may mean a central processing unit (CPU), a graphics processing unit (GPU), or a dedicated processor on which methods according to embodiments of the present invention are performed.

[0042] The memory (120) may be composed of at least one of a volatile storage medium and a non-volatile storage medium. For example, the memory (120) may be one of read-only memory (ROM) and random access memory (RAM).

[0043] An operating server (100) that supports consultation on insurance products based on user sentiment analysis may further include a storage device (160) for storing input data, intermediate processing temporary data, output data, etc. for performing at least one operation. For example, the storage device (160) may be a flash memory, a hard disk drive (HDD), a solid-state drive (SSD), or various memory cards (e.g., a micro SD card).

[0044] Additionally, the operating server (100) supporting consultation on insurance products may include a transceiver (130) that performs communication via a wireless network. Additionally, the operating server (100) supporting consultation on insurance products based on user sentiment analysis may further include an input interface device (140), an output interface device (150), a storage device (160), etc. Each component included in the operating server (100) supporting consultation on insurance products based on user sentiment analysis can communicate with each other by being connected by a bus (170).

[0045] Examples of operating servers (100) that support consultation on insurance products based on user emotion analysis may include a desktop computer, laptop computer, notebook, smartphone, tablet PC, mobile phone, smart watch, smart glass, e-book reader, PMP (portable multimedia player), portable game console, navigation device, digital camera, DMB (digital multimedia broadcasting) player, digital audio recorder, digital audio player, digital video recorder, digital video player, PDA (Personal Digital Assistant), etc.

[0047] FIG. 3 is a flowchart illustrating an operation method performed on an operating server that supports consultation on insurance products based on user emotion analysis according to one embodiment.

[0048] FIG. 4 is a flowchart illustrating a method of receiving consultation data in an operating server that supports consultation of an insurance product based on user emotion analysis according to one embodiment, and FIG. 5 is a flowchart illustrating a method of monitoring the consultation status in an operating server that supports consultation of an insurance product based on user emotion analysis according to one embodiment.

[0049] FIG. 6 is a flowchart illustrating a method for collecting a situational data set in an operating server that supports consultation on an insurance product based on user sentiment analysis according to one embodiment, and FIG. 7 is a flowchart illustrating a method for determining a candidate cause item in an operating server that supports consultation on an insurance product based on user sentiment analysis according to one embodiment.

[0050] FIG. 8 is a flowchart illustrating a method for calculating a cause matching index in an operating server that supports consultation on insurance products based on user sentiment analysis according to one embodiment, and FIG. 9 is a flowchart illustrating a method for transmitting improvement plan data in an operating server that supports consultation on insurance products based on user sentiment analysis according to one embodiment.

[0052] First, referring to FIG. 3, an operating server according to one embodiment can receive consultation data for consultation on an insurance product based on user sentiment analysis (S100).

[0053] At this time, the operating server may receive consultation data including user input data, consultation log data, insurance design proposal data, underwriting regulation data, payment transaction data, and document submission data generated while the consultation service for designing insurance products is provided. In this regard, the specific process of receiving consultation data on the operating server may be described in more detail below with reference to FIG. 4.

[0054] Referring to FIG. 4, the operating server can receive user input data, which means data entered through a user terminal (S110).

[0055] Specifically, the operating server may receive user input data including personal information input values, health-related question response values, and subscription purpose selection values ​​collected through the input interface of a user terminal. For example, personal information input values ​​may refer to basic personal information such as name, date of birth, gender, and contact information, and may be obtained as values ​​directly entered by the user on the interface of the user terminal. Additionally, health-related question response values ​​may refer to results selected or entered by the user in response to questions regarding health status, such as smoking status, drinking habits, or the presence of pre-existing diseases, and subscription purpose selection values ​​may refer to results where the user specifies the purpose of insurance subscription (e.g., savings, coverage, investment, etc.) from among the options.

[0056] Afterwards, the operating server can receive consultation log data related to the consultation service provided to the user through the user terminal (S120).

[0057] Specifically, the operation server may receive consultation log data including conversation logs, consultation elapsed time, consultation screen navigation history, and event occurrence logs that occur during a consultation session of the consultation service. For example, conversation logs may refer to data recording text input and response between a user terminal and an expert terminal, and consultation elapsed time may refer to the cumulative time from the start of the consultation to the end of the consultation.

[0058] Additionally, screen navigation history may refer to the history of page transitions performed by the user on the consultation screen provided via the user terminal interface, and event occurrence logs may refer to detailed events that occurred during the consultation process, such as button clicks, input cancellations, and error message generation. Such consultation log data may be recorded on the user terminal and transmitted to the operation server. In this case, if the user provides consultation services through an expert and an expert terminal rather than the user terminal, the consultation log data collected through the expert terminal may also be transmitted to the operation server.

[0059] Afterwards, the operating server can receive insurance design plan data related to the insurance product that is the subject of the consultation service (S130).

[0060] Specifically, the operating server may receive insurance plan data including calculated premium values, coverage items, combinations of special riders, payment cycle settings, and estimated refund calculation results. For example, the calculated premium value may refer to an amount calculated based on an expert's rate system according to input values ​​such as the user's age, gender, occupation, and health status, while the coverage items may refer to the scope of coverage selected by the user. The combination of special riders may refer to a combination of selected additional coverage options. Additionally, the payment cycle setting may refer to a payment method specified by the user, such as monthly or annual payments, and the estimated refund calculation result is an estimated refund amount calculated based on the contract period and paid premiums, which may be automatically calculated by a design program or a calculation engine of an expert terminal and transmitted to the operating server.

[0061] Afterwards, the operation server can extract underwriting regulation data related to the regulations of the insurance product from the database (S140).

[0062] Specifically, the operations server can extract underwriting regulation data from the database, including age requirements, occupation classifications, health status criteria, risk rating criteria, and coverage limit values ​​related to insurance products. For example, underwriting regulation data may refer to criteria for determining eligibility for insurance and may include age requirements, occupation classifications, health status criteria, risk rating criteria, and coverage limit values. Age requirements may refer to the minimum and maximum age values ​​for which insurance enrollment is permitted, and occupation classifications may refer to occupational groups subject to enrollment restrictions or those assigned risk coefficients. Health status criteria may refer to standards for eligibility based on a history of specific diseases or physical condition, and risk rating criteria may refer to a method of quantifying the level of risk by combining various attribute values ​​(e.g., age, gender, presence of disease). Additionally, coverage limit values ​​may refer to the maximum coverage amount or upper limit of premium payments that can be set by the user. Such underwriting regulation data can be extracted from the database of the operations server.

[0063] Afterwards, the operation server can receive payment transaction data related to the payment of the insurance product (S150).

[0064] Specifically, the operating server may receive payment transaction data including payment attempt history, payment approval status, payment method type, and payment error code. For example, payment attempt history may refer to the time and amount information when a user executes a payment through a user terminal, and payment approval status may refer to whether a payment request generated by the user terminal has been approved. Additionally, the payment method type may refer to the means or method used for payment on the user terminal, such as credit cards, debit cards, bank transfers, or simplified payments, and the payment error code may refer to a code value specifying the reason for the error returned when a payment fails.

[0065] Afterwards, the operating server can receive document submission data, which refers to data related to the user (S160).

[0066] Specifically, the operating server may receive images of the user's identification documents, proof of income documents, health checkup forms, and other data submitted to meet enrollment requirements. For example, the identification image may refer to image files such as a resident registration card or driver's license for verifying the user's identity, and proof of income documents may refer to documents verifying income levels, such as certificates of employment, pay stubs, or certificates of income. Additionally, the health checkup form may refer to materials issued by medical institutions to prove the user's health status, and other documents meeting requirements may refer to confirmation forms or consent forms for subscribing to additional coverage items. Such document submission data may be transmitted to the operating server via image uploads through user terminals or expert terminals.

[0068] Referring again to FIG. 3, an operating server according to one embodiment can monitor a consultation procedure based on received consultation data (S200).

[0069] At this time, the operation server can monitor the consultation status by using consultation data to determine the current user's consultation process status as one of the consultation start process, design completion process, underwriting review process, identity verification process, payment process, and subscription success process according to multiple pre-configured procedures that distinguish consultation processes. In this regard, the specific process of monitoring the consultation process on the operation server can be explained in more detail below with reference to FIG. 5.

[0070] Referring to FIG. 5, the operating server can extract a consultation procedure definition rule to monitor the consultation procedure (S210).

[0071] Specifically, the operation server can extract consultation procedure definition rules that define multiple procedures, including a consultation start procedure, a design completion procedure, an underwriting review procedure, an identity verification procedure, a payment procedure, and a successful subscription procedure. For example, the consultation procedure definition rules may include entry and exit conditions for each procedure, transition conditions between procedures, priority when multiple signals occur simultaneously, and dwell time criteria for each procedure, and may be defined for the consultation start procedure, design completion procedure, underwriting review procedure, identity verification procedure, payment procedure, and successful subscription procedure.

[0072] The consultation start procedure may refer to the procedures of initial interactions performed when the consultation service is initiated, such as session creation, entry to the first screen, and initial agreement to the terms and conditions. The design completion procedure may refer to a state where the design proposal is validly finalized after the selection of coverage and special riders is finished and the premium calculation is complete; at this point, signals such as a transition to the design summary screen or a premium calculation completion event may be combined to satisfy the entry conditions.

[0073] The underwriting review process may refer to a state in which user input data and design proposal information are submitted to the underwriting engine of the operating server and are awaiting or processing the review results, and entry into the process may be supported by the recording of review request events, transmission logs to the underwriting engine of the operating server, and the reception of a response awaiting review. The identity verification process may refer to a state in which the KYC module is performed for identity verification, and entry into the process may be indicated by the reception of an identity verification start signal, a transition to the identity verification screen, and the continuous occurrence of identity verification progress events.

[0074] The payment process may refer to the entire sequence leading from payment method registration, payment authentication, waiting for approval, and receiving the approval result, and the progress of this process may be defined by a payment start event, a payment screen transition, and the arrival of a payment gateway callback. The subscription success process may refer to a final completion state where payment is approved, a contract number is assigned, and a certificate issuance or subscription completion screen is displayed, and the transition to this process may be confirmed by a combination of the contract issuance log, a certificate issuance event, and a subscription completion screen transition.

[0075] The operation server can maintain signal mappings and transition conditions for each procedure defined in this way as rules, and in a subsequent step, can determine the current procedure status by matching these rules to real-time consultation log data.

[0076] Afterwards, the operating server can determine the status of the consultation procedure for the ongoing consultation service based on the extracted consultation procedure definition rules (S220).

[0077] Specifically, the operation server can determine the current consultation procedure status as one of the consultation start procedure, design completion procedure, underwriting review procedure, identity verification procedure, payment procedure, and subscription success procedure by matching the event tags, timestamps, and screen transition history of real-time consultation log data with consultation procedure definition rules.

[0078] Here, event tags in consultation log data may refer to codes identifying events occurring during the consultation process, and can be categorized, for example, as 'session start', 'premium calculation completed', 'underwriting request', 'identity verification start', 'payment approval completed', etc. Timestamps may refer to the time when the corresponding event occurred. Screen transition history may refer to the transition flow of the consultation screen or service stage where the user is currently located.

[0079] In other words, the operation server can determine the transition to a specific procedure state if a specific event tag and screen transition history are simultaneously satisfied, based on the entry and exit conditions of each procedure in the consultation procedure definition rules. For example, if the 'Premium Calculation Complete' event tag is confirmed and subsequently transitions to the 'Design Summary Screen,' the operation server can determine the consultation procedure state as the Design Completion procedure. As another example, if the 'Underwriting Review Request' event occurs and a data transmission log to the underwriting engine is confirmed, the operation server can determine the state as the Underwriting Review procedure. Similarly, the operation server can determine the state as the Identity Verification procedure if the 'Identity Verification Start' event and identity verification screen transition log are confirmed; as the Payment procedure if the 'Payment Attempt' event and payment screen entry log are recorded; and finally as the Enrollment Success procedure if the Payment Approval Complete event and contract issuance log occur.

[0080] Afterwards, the operation server can monitor the consultation status based on changes in the determined consultation procedure status (S230).

[0081] Specifically, the operation server can generate a state transition history by accumulating and storing changes in the determined consultation procedure state in chronological order, and can monitor the consultation status based on the state transition history. The state transition history may refer to a data structure that records, in chronological order, the process of the consultation procedure state progressing from the consultation start procedure to the design completion procedure, underwriting review procedure, identity verification procedure, payment procedure, and subscription success procedure, or the process of repeated delays at specific procedures.

[0082] The state transition history generated in this manner may include a timestamp at the time the procedure transition occurred, the procedure status before and after the transition, the event tag that triggered the transition, screen transition information, and result codes received from external devices (e.g., underwriting, identity verification, payment modules, etc.). For example, if a 'design complete' event and a design summary screen transition are recorded in the consultation log, the operation server may record that point in time in the history as the entry point for the design complete procedure, and subsequently, when an underwriting request signal is received, the transition point to the underwriting review procedure may be stored separately.

[0084] Referring again to FIG. 3, an operating server according to one embodiment can collect a set of situation data based on whether there is a failure to proceed further with the consultation procedure (S300).

[0085] At this time, the operation server can monitor the occurrence of failure events indicating failure to proceed further with the consultation process. For example, failure events may refer to states such as underwriting rejection, identity verification failure, payment approval refusal, timeout due to inactivity exceeding a specified time, session termination after repeated cancellation, or inability to proceed due to non-submission of required documents, and each event may be detected by a predefined event code or condition (e.g., inactivity time ≥ threshold, error code set matching, etc.).

[0086] Subsequently, when a failure event occurs, the operation server may collect consultation data, underwriting regulation data, payment transaction logs, and user response signals included in a preset time interval based on the time of occurrence of the failure event as a context data set. In this regard, the specific process of collecting the context data set by the operation server can be described in more detail below with reference to FIG. 6.

[0087] Referring to FIG. 6, the operation server can determine a time interval for collecting a set of situational data (S310).

[0088] Specifically, the operations server can extract a timestamp at the point in time when the consultation status is designated as a failure event and calculate a pre-set time interval before and after based on the timestamp. Here, the time interval before and after refers to an analysis range intended to consider data both before and after the event to analyze the cause of the failure, and it can be set differently depending on the type of failure event.

[0089] For example, in the case of an underwriting rejection event, since there is a high probability that the user's input data and the attributes of the insurance plan conflict with regulations, a relatively long prior time interval may be predefined to allow for sufficient analysis of the input and design processes prior to the rejection. Conversely, in the case of a payment approval rejection event, since it is necessary to examine the user's retry behavior or error response process immediately after the rejection, a relatively long subsequent time interval may be set. Additionally, for an identity verification failure event, since both the authentication input patterns and system responses before and after the identity verification process must be considered, the prior and subsequent intervals may be set in a balanced manner. Meanwhile, for an inactivity timeout event, since it is important to identify the user's behavioral patterns immediately before the consultation process is interrupted, the prior time interval may be set with emphasis.

[0090] Afterwards, the operation server can collect consultation logs for the determined time interval before and after (S320).

[0091] Specifically, the operation server may collect consultation logs that include user input values, consultation conversation logs, insurance plan attribute values, and payment attempt history within the preceding and succeeding time intervals. Here, user input values ​​may include input field values ​​(e.g., amount, period, coverage selection, etc.) captured at each event point in time, and each value may be obtained through the interface of the user terminal; for each value, a field identifier, input time, and validation results may be recorded together. Additionally, consultation conversation logs may include the content of conversations exchanged between the user and the consultation system (e.g., inquiries about insurance premiums, requests for condition changes, guidance messages, etc.), and for each utterance, the speaker, the time of utterance, and conversation tags may be recorded.

[0092] Additionally, the attribute values ​​of the insurance plan may include coverage items, special rider combinations, payment cycles, premium calculation results, and estimated refunds derived during the consultation process; each attribute value may be generated by the insurance design module of the operating server, and the time of calculation and the identifier of the referenced rate table may be recorded together. The payment attempt history may include events in which the user attempted payment (e.g., entering the payment screen, selecting the payment button, etc.), and for each attempt history, the time of the event, the type of payment method selected, and the payment attempt result code may be recorded.

[0093] Afterwards, the operation server can extract regulation logs for the determined time interval before and after (S330).

[0094] Specifically, the operation server can extract regulation logs that include underwriting regulation attribute values ​​included in the preceding and succeeding time intervals and attribute-specific standard values ​​defined in the underwriting regulation data.

[0095] Here, the underwriting regulation attribute values ​​serve as criteria defining eligibility or restrictions for insurance enrollment. For example, age requirements may refer to the age at which a specific insurance product can be purchased (e.g., 20 years of age or older, 65 years of age or younger, etc.), and occupation classification may be a code value used to distinguish between high-risk and general occupations. Additionally, health status criteria may include BMI, the presence of pre-existing conditions, smoking status, etc., while risk grade calculation criteria may correspond to risk grade values ​​calculated based on occupation, age, and health status. The coverage limit value may refer to the maximum coverage amount or maximum payable amount for a specific insurance product. Along with these underwriting regulation attribute values, the operation server can construct a regulation log by extracting reference values ​​corresponding to each attribute. Reference values ​​may refer to reference indicators used to determine whether attributes are met, such as "smokers cannot enroll in the standard type" or "coverage limits for specific high-risk occupations are restricted by 50%."

[0096] Afterwards, the operation server can collect payment logs for the determined time interval before and after (S340).

[0097] Specifically, the operation server can collect payment approval logs included in the preceding and succeeding time intervals, as well as payment logs that include error codes and payment method attributes.

[0098] Here, payment logs refer to the transaction history generated during the insurance premium payment process, and payment approval status may be a value indicating whether the payment attempted by the user was successful or failed. Error codes are values ​​used to classify the cause of payment failure; for example, "E101" indicates exceeding the card limit, "E205" indicates account authentication failure, and "E310" indicates a network failure, with the reason displayed as a code. Payment method attributes may refer to information regarding the payment method selected by the user, such as card payment, bank transfer, simplified payment, or automatic transfer; some payment methods may include additional identifiers such as bank codes or card company codes. These logs can serve as a basis for analyzing the reasons why the consultation process was interrupted at the payment stage or whether errors repeatedly occur with specific payment methods.

[0099] Afterwards, the operation server can collect user response signals for the determined time interval before and after (S350).

[0100] Specifically, the operating server can collect user response signals, including voice signals, text input, and user interaction data collected during a determined time interval before and after.

[0101] First, the voice signal refers to voice data spoken by the user during a determined time interval before and after, and may include measurable values ​​such as frequency band, speech duration, average voice volume (dB), speech rate (syllables / second), and intonation curve. Text input may include phrases entered by the user on the consultation screen of a user terminal or expert terminal, and items such as the length of the phrase (number of characters), the frequency of specific keywords (e.g., "expensive", "cancel"), the number of input error corrections, and the time taken to complete the input may be recorded.

[0102] User interaction data can quantify and record actions occurring on the consultation screen. For example, user interaction data may include the number of screen transitions, button clicks, input field cancellations, time spent on a specific screen (seconds), and the duration of unresponsive periods (seconds). Additionally, user interaction data may include further detailed metrics, such as repetitive input patterns or the number of consecutive clicks on the same button.

[0103] Afterwards, the operation server can collect each item for the determined time interval as a situation data set (S360).

[0104] Specifically, the operation server can collect a context data set based on consultation logs, regulation logs, payment logs, and user response signals for a determined time interval.

[0105] For example, the operations server can organize consultation logs, regulation logs, payment logs, and user reaction signals extracted from before and after time intervals into a single-structured context data set by aligning them on a common time axis. To this end, the operations server can arrange all data into an integrated sequence based on the timestamps assigned to each log and signal item, and if multiple events exist within the same time slot, they can be merged by applying priority rules (e.g., payment error > regulation violation > user input error > emotional reaction). The context data set thus constructed can be represented as a multidimensional attribute vector and can be defined in the form of, for example, D{d1, d2, dn}.

[0106] Here, di may refer to a bundle of consultation log events, qualifying attribute values, payment processing status, and user response signals collected within a specific time interval unit (e.g., 1 second, 5 seconds). Each di may include consultation event codes (e.g., conversation start, screen transition, input submission), underwriting qualifying values ​​and flags indicating whether criteria are met, payment approval / rejection codes and error codes, and user response signals (e.g., voice waveform characteristics, text input strings, number of button clicks, number of screen transitions, etc.).

[0108] Referring again to FIG. 3, an operating server according to one embodiment can determine candidate causes related to the failure of the consultation procedure based on situation data (S400).

[0109] At this time, the operation server can analyze virtual input data generated through condition changes of the situation data set and the insurance data included in the situation data set, and thereby determine rule-based candidate cause items, behavior-based candidate cause items, emotion-based candidate cause items, and condition change-based candidate cause items, respectively. Here, "candidate cause items" may refer to specific attributes or factors that may have a causal relationship with the failure of the consultation process, and whether they are actual causes of failure can be evaluated through the calculation of a cause conformity index in a subsequent step. In this regard, the specific process of determining each candidate cause item by the operation server can be explained in more detail below with reference to Fig. 7.

[0110] Referring to Fig. 7, the operating server can determine each candidate cause item based on a preset method for each candidate cause item.

[0111] First, the operation server can determine rule-based cause candidate items based on condition matching operations on the situation data set (S410).

[0112] Specifically, the operation server can determine items that are not satisfied as regulation-based cause candidate items by comparing the attribute values ​​of consultation data included in the situation data set with the standard values ​​defined in the underwriting regulation data using a condition matching operation. Here, the operation server can determine whether there is a regulation violation by comparing the attribute values ​​of consultation data included in the situation data set with the standard values ​​defined in the underwriting regulation data using a condition matching operation. For example, if the user's age (attribute value) extracted from the consultation data exceeds or falls short of the age requirement (standard value) defined in the underwriting regulation data, the operation server can determine that the attribute is a regulation violation. Additionally, the operation server can determine a regulation-based cause candidate item if the job classification code is determined to be an unacceptable risky occupation group, or if the health status indicator appears to be below the standard value. In this regard, the condition matching operation can be expressed as a discrepancy determination formula as shown in Mathematical Formula 1 below.

[0113]

[0115] In mathematical formula 1, M i can mean the value of the condition matching operation for the i attribute value, and v i can mean the value of attribute i, and R i may mean the allowable range defined in the underwriting regulation data.

[0116] In addition, the operation server can determine behavior-based cause candidate items based on consultation logs and user interaction data for a situation data set (S420).

[0117] Specifically, the operations server can quantify the number of input errors, waiting time, number of cancellations, and deviations in dwell time by normalizing consultation logs and user interaction data included in the situational data set in chronological order. Subsequently, the operations server can determine behavior-based candidate causes by comparing each quantified value with the procedure progress history data of a set of successful sign-ups using a sort-based comparison operation.

[0118] For example, the operations server can sort consultation logs and user interaction data included in the context data set in chronological order and calculate metrics representing user behavior. Here, the metrics representing user behavior may include the number of input errors (the number of occurrences of validation failure events for the same input field), average waiting time (the average value of time intervals between consecutive events), number of cancellations / returns (the number of occurrences of cancellation or return-to-previous-step events within the same procedure), and variance of dwell time per screen (the variance or standard deviation of dwell time per screen).

[0119] The operations server can determine deviations by comparing each calculated metric with a pre-calculated threshold value or threshold range from a set of successful users. For example, if the number of input errors exceeds a preset threshold, the average waiting time exceeds a preset threshold, the number of cancellations / returns exceeds a preset threshold, or the variance of time spent per screen falls outside a preset threshold range, the behavior corresponding to that metric can be determined to be outside the normal range. In other words, based on the judgment result, the operations server can determine labels such as "excessive input errors," "waiting time delay," "repeated cancellations / returns," and "time spent imbalance" as behavior-based cause candidate items.

[0120] In addition, the operation server can determine emotion-based cause candidate items based on feature vectors for the situation data set (S430).

[0121] Specifically, the operation server can calculate an emotion state index and an emotion-based failure risk using feature vectors extracted from voice signals, text inputs, and user interaction data included in the situational data set. Subsequently, the operation server can determine emotion-based candidate cause items based on the calculation results. In this regard, the operation server can construct feature vectors by extracting predefined item-specific feature values ​​from voice signals, text inputs, and user interaction data included in the situational data set.

[0122] For example, in speech signals, quantitative values ​​such as speech rate (syllables or words per second), statistical values ​​of fundamental frequency (pitch) (mean and standard deviation), non-utterance rate (ratio of silent periods to the total duration), and short-term energy fluctuations (the range of energy fluctuation per frame) can be extracted as feature values. Additionally, in text input, the frequency of occurrence of keywords related to negation, concern, or refusal (based on a predefined vocabulary dictionary), the frequency of interrogative or hesitant expressions (e.g., "is that right?", "whether it will be okay", "another method"), output symbol usage patterns (number of question marks and exclamation marks), and the number of corrections / deletions (number of modification actions within the same sentence) can be extracted as feature values. Furthermore, in interaction data, time- and frequency-based indicators such as response latency (time elapsed from system presentation to the first input), consecutive click count (number of multiple clicks at short intervals), number of returns to previous steps or cancellations, number of re-edits of the same input field, and time spent on a specific screen can be extracted as feature values.

[0123] Subsequently, the operating server can input a feature vector consisting of feature values ​​into a neural network-based model pre-trained with artificial intelligence to calculate an emotional state index and an emotion-based failure risk. The emotional state index may refer to an indicator that normalizes the intensity of negative emotional components, such as anxiety, confusion, and antipathy, into a single value in the range of 0 to 1, and may indicate that the negative emotion is stronger the higher the value. The emotion-based failure risk may refer to a value calculated in the range of 0 to 1 representing the probability of procedure failure estimated solely by emotional factors based on the feature vector and the emotional state index.

[0124] Here, a neural network-based model pre-trained by artificial intelligence can be supervised learning using past consultation logs (e.g., voice, text, interaction) and the success / failure results of the corresponding session, and can be trained to internally estimate probabilities by emotion category for input feature vectors and to output an emotion state index and an emotion-based failure risk by synthesizing the results.

[0125] Subsequently, the operations server can determine candidate cause items based on sentiment by evaluating two indicators (sentiment state index and sentiment-based failure risk) based on pre-set threshold values. For example, if the sentiment state index and sentiment-based failure risk each exceed the threshold values, the operations server can label them as "impedance of procedure progress due to sentiment factors" and determine them as candidate cause items based on sentiment. In this case, the top contributing feature values ​​that served as the basis for the decision (e.g., increased non-utterance rate, increased frequency of negative keywords, increased response latency) can be stored together and utilized in subsequent steps (calculation of cause match index, generation of improvement plan data).

[0126] In addition, the operation server can input consultation data into an AI-based prediction model to determine candidate causes based on condition change (S440).

[0127] Specifically, the operation server can calculate the success rate fluctuation value by inputting virtual input data, generated by changing the premium level, coverage and special rider configuration, payment cycle, and payment method included in the consultation data, into a pre-trained AI-based prediction model. Subsequently, the operation server can determine elements whose success rate fluctuation value exceeds a preset threshold as candidate causes based on condition changes. Here, insurance design-related attributes can be defined as premium levels, coverage and special rider configurations, payment cycles, and payment methods, and multiple virtual input data can be generated by changing each of these attributes individually or in combination. For example, scenarios such as adjusting the premium level within a ±10% range under the same coverage conditions or changing the existing payment cycle from monthly to annual payments can serve as examples of virtual input data.

[0128] The operation server can input virtual input data into a neural network-based prediction model pre-trained by artificial intelligence. This prediction model may refer to a model trained to output the success rate of the consultation process for specific attribute combinations by learning from multiple past consultation logs and their success / failure results. The output value of the prediction model can be calculated as a predicted success rate corresponding to each virtual input data, and the operation server can calculate the success rate fluctuation value by comparing this with the reference success rate for existing consultation data.

[0129] Subsequently, if the success rate fluctuation value increases above a preset threshold, the operation server may determine that the corresponding attribute change is a factor that contributes to failure avoidance or success rate improvement. For example, if the success rate increases by 15% or more compared to the baseline when the premium level is slightly lowered or the payment cycle is adjusted, the operation server may determine this as a candidate cause item based on condition change. On the other hand, if the success rate fluctuation value is below the threshold or decreases, the operation server may exclude the corresponding change from candidate cause items.

[0130] Furthermore, in the process of determining candidate causes based on condition changes, the operations server may assess not only whether the success rate has increased but also whether the change falls within a practically applicable range. For example, collateral combinations not permitted by underwriting regulations or changes to payment methods not supported by the operations server may be excluded from the candidate causes. Consequently, the finally determined candidate causes based on condition changes may be limited to attribute changes that satisfy regulatory and system constraints while the change in success rate exceeds a certain threshold.

[0132] Referring again to FIG. 3, an operating server according to one embodiment can calculate a cause matching index for each cause candidate item (S500).

[0133] At this time, the operation server can generate a cause evaluation characteristic vector by normalizing indicators corresponding to rule-based cause candidate items, behavior-based cause candidate items, emotion-based cause candidate items, and condition change-based cause candidate items. Subsequently, the operation server can apply pre-set weights to the cause evaluation characteristic vector and calculate the cause matching index for each cause candidate item. In this regard, the specific process of calculating the cause matching index by the operation server can be explained in more detail below with reference to Fig. 8.

[0134] Referring to FIG. 8, the operating server can generate a cause evaluation characteristic vector to calculate the cause matching index (S510).

[0135] Specifically, the operating server can generate a cause evaluation characteristic vector by normalizing the indicator values ​​corresponding to each of the rule-based, behavior-based, emotion-based, and condition change-based cause candidate items to a range of 0 to 1.

[0136] For example, as indicator values ​​included in the cause evaluation characteristic vector, in the case of regulation-based systems, indicators directly related to underwriting regulations, such as the number of violation items, the severity of violations, and the number of missing documents, may be included; in the case of behavior-based systems, indicators quantifying user consultation behavior, such as the input error rate, the average waiting time deviation, and the cancellation rate during consultation, may be included. Additionally, as indicator values ​​included in the cause evaluation characteristic vector, in the case of emotion-based systems, indicators reflecting the user's emotional state, such as the voice tone change rate, text sentiment score, and interaction response speed, may be included; and in the case of condition change-based systems, indicators of success rate fluctuations calculated when premiums, combinations of coverage and special clauses, payment cycles, and payment methods are changed may be included. The operation server normalizes all such calculated indicator values ​​to a range of 0 to 1 to create independent cause evaluation characteristic vectors F for each item type. reg , F beh , F emo , F alt It can generate.

[0137] Afterwards, the operation server can calculate the cause matching index using each generated cause evaluation characteristic vector (S520).

[0138] Specifically, the operation server can calculate the cause matching index of each cause candidate item by applying a pre-set weight vector to the cause evaluation feature vector generated through normalization processing.

[0139] For example, rule-based cause conformity index C reg is a rule-based feature vector F reg The weight vector W corresponding to reg It can be calculated by multiplying, and in the same way, the behavior-based, emotion-based, and condition change-based causal matching index C beh , C emo , C altEach can be calculated independently, and this can be expressed as mathematical formula 2 below.

[0140]

[0142] In mathematical formula 2, C k can mean the causal match index for candidate cause item k, and f k,i can mean the normalized i-th index value, and w k,i can mean a pre-set weight value for the corresponding indicator, and n k can mean the number of indicators of the corresponding item type.

[0144] Referring again to FIG. 3, an operating server according to one embodiment can provide improvement plan data for failure cause items determined based on a cause matching index to an expert terminal (S600).

[0145] At this time, the operating server can determine the candidate cause item having the highest value among the cause matching indices as the failure cause item of the consultation procedure, and can generate improvement plan data that supports the reduction of the cause matching index corresponding to the failure cause item and provide it to the expert terminal. In this regard, the specific process of generating and providing improvement plan data by the operating server can be explained in more detail below with reference to FIG. 9.

[0146] Referring to FIG. 9, the operation server can determine the cause of failure based on the cause matching index of the cause candidate items (S610).

[0147] Specifically, the operation server can check the calculated cause matching index for each candidate cause item and determine the candidate cause item with the largest cause matching index as the cause item of failure in the counseling process. For example, if the cause matching index of a rule-based candidate cause item is calculated as 0.72, the cause matching index of a behavior-based candidate cause item is calculated as 0.65, the cause matching index of an emotion-based candidate cause item is calculated as 0.48, and the cause matching index of a condition change-based candidate cause item is calculated as 0.58, the operation server can determine the rule-based candidate cause item as the cause item of failure.

[0148] Afterwards, the operation server can extract failure cause data, which is data related to the failure cause item (S620).

[0149] Specifically, the operation server can extract failure cause data from consultation data and situation data sets, including the cause item identifier of the failure cause item, the time of occurrence, the history of the related procedure status, attribute values ​​associated with the failure cause item, and the cause matching index.

[0150] That is, the operation server can extract detailed information related to determined failure cause items from consultation data and situation data sets and organize this into failure cause data as a single data structure. Here, the failure cause data may include a cause item identifier assigned to identify the failure cause items, and this identifier may be defined to distinguish between rule-based, behavior-based, emotion-based, and condition change-based types and their sub-items.

[0151] Furthermore, the failure cause data may include the exact time at which the consultation process was determined to have failed; this time can be calculated by synchronizing the timestamps in the consultation log data with the occurrence times of external events, such as payment approval logs or underwriting judgment logs. In addition, the failure cause data may include the status history of the consultation process immediately before and after the point of failure.

[0152] Furthermore, the operations server can extract attribute values ​​associated with failure cause items. For example, in the case of rule-based items, the discrepancy between the age threshold defined in underwriting regulation data and the actual user input age value can be extracted as an attribute value; for behavior-based items, this may include the number of repeated cancellations or the exceedance of waiting times. Additionally, for emotion-based items, the operations server can include whether an emotion state index calculated from voice signals and text input exceeds a specific range as an attribute value, and for condition change-based items, the fluctuation value of the success rate calculated by a predictive model applying virtual input data can be included as an attribute value. Moreover, the operations server includes the cause conformity index calculated for each cause item, allowing the extracted failure cause data to be provided alongside quantitative evaluation values ​​rather than remaining merely as record information.

[0153] Afterwards, the operation server can transmit the generated improvement plan data to the expert terminal by applying the rules for generating improvement dialect data to the failure cause data (S630).

[0154] Specifically, the operations server can generate improvement plan data by applying predefined generation rules based on the types of failure cause items included in the failure cause data, and can transmit the generated improvement plan data to an expert terminal. For example, the operations server can identify the types of failure cause items included in the extracted failure cause data and generate improvement plan data by applying predefined generation rules to the corresponding types. Here, the generation rules can be defined by converting attribute values ​​and procedural instructions corresponding to each cause type and mapping them to items of the improvement plan data.

[0155] Here, the predefined rules for generating improvement plan data may be defined to generate supplementary documentation items for meeting underwriting regulations and design / input modification instructions as improvement plan data when the type of failure cause item is a rule-based cause item. Additionally, the rules for generating improvement plan data may be defined to generate procedural instructions such as input validation, retry control, wait time mitigation, and callback suggestions as improvement plan data when the type of failure cause item is a behavior-based cause item.

[0156] Additionally, the generation rule for improvement plan data may be defined to generate a consultation conversation scenario, including conversation tone, guidance phrases, pauses, and reconnection timing, as improvement plan data when the type of failure cause item is an emotion-based cause item. Furthermore, the generation rule for improvement plan data may be defined to generate an adjustment plan as improvement plan data by using a pre-trained prediction model to select the combination with the maximum prediction success rate among parameter combinations within an acceptable range when the type of failure cause item is a condition change-based cause item.

[0157] In other words, if a failure cause item is determined to be a regulation-based item, the operations server can refer to the attribute value where the regulation was not met within the consultation data to automatically specify the supplementary document items required to satisfy underwriting regulations, generate instruction data guiding the submission procedure for such documents, and additionally include instructions for modifying user input fields. Furthermore, if it is determined to be a behavior-based item, the operations server analyzes the number of input errors or timeout values ​​recorded in the consultation log to generate data containing specific procedural instructions, such as enhanced input validation procedures, retry limits, and callback consultation suggestions.

[0158] In addition, if the operation server determines that an item is emotion-based, scenario data can be generated by adjusting the tone, guidance phrases, pause timing, and reconnection point of the consultation conversation scenario by referring to the emotion state index calculated from the user response signal. Furthermore, if the operation server determines that an item is condition change-based, it can generate adjustment proposal data by selecting the condition combination with the highest success rate based on the results of reapplying virtual input data—combining premiums, special rider configurations, payment cycles, and payment methods from the consultation data—to a prediction model.

[0159] Improvement plan data generated in this manner may include procedure identifiers and implementation guidelines to which the data will be applied, as well as the expected success rate improvement effect and the indicators serving as the basis for its calculation.

[0161] The methods according to the present invention may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, etc., either alone or in combination. The program instructions recorded on the computer-readable medium may be those specifically designed and configured for the present invention, or they may be those known and available to those skilled in the art of computer software.

[0162] Examples of computer-readable media may include hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, and flash memory. Examples of program instructions may include machine code, such as that generated by a compiler, as well as high-level language code that can be executed by a computer using an interpreter, etc. The aforementioned hardware devices may be configured to operate as at least one software module to perform the operation of the present invention, and vice versa.

[0163] In addition, the above-described method or device may be implemented by combining all or part of its configuration or function, or by implementing it separately.

[0164] Although the present invention has been described above with reference to preferred embodiments, those skilled in the art will understand that various modifications and changes can be made to the invention without departing from the spirit and scope of the invention as described in the following claims. Explanation of the symbols

[0165] 10: Operation Server 20: User Terminal 30: Expert Terminal 100: Operation Server 110: Processor 120: Memory 130: Transmitter / receiver device 140: Input interface device 150: Output interface device 160: Storage device 170: Bus

Claims

Claim 1 A method of operation performed on an operating server that supports consultation for insurance products based on user sentiment analysis, comprising: receiving consultation data including user input data, consultation log data, insurance design proposal data, underwriting regulation data, payment transaction data, and document submission data generated while a consultation service for designing insurance products is provided; using the consultation data, determining the current user's consultation process status as one of a consultation start procedure, design completion procedure, underwriting review procedure, identity verification procedure, payment procedure, and subscription success procedure according to a plurality of pre-set procedures that distinguish the consultation process, and monitoring the consultation status; monitoring the occurrence of a failure event indicating failure regarding further progress of the consultation process, and, if the failure event occurs, collecting consultation data, underwriting regulation data, payment transaction logs, and user reaction signals included in a pre-set time interval based on the time of occurrence of the failure event as a situational data set; analyzing virtual input data generated through condition changes of the situational data set and the insurance data included in the situational data set to determine, respectively, regulation-based cause candidate items, behavior-based cause candidate items, sentiment-based cause candidate items, and condition change-based cause candidate items; and the regulation-based cause candidate items, A step of generating a cause evaluation characteristic vector by normalizing indicators corresponding to behavior-based cause candidate items, emotion-based cause candidate items, and condition change-based cause candidate items, and calculating a cause matching index for each cause candidate item by applying pre-set weights to the cause evaluation characteristic vector; and a step of determining the cause candidate item having the highest value among the cause matching indices as the failure cause item of the counseling procedure, and generating improvement plan data that supports a decrease in the cause matching index corresponding to the failure cause item, and providing it to an expert terminal.The method includes, but is not limited to, the step of receiving consultation data, comprising: receiving user input data including personal information input values ​​collected through the input interface of a user terminal, health-related question response values, and subscription purpose selection values; receiving consultation log data including conversation logs, consultation elapsed time, consultation screen movement history, and event occurrence logs occurring during a consultation session of the consultation service; receiving insurance plan data including premium calculation values, coverage items, special rider combinations, payment cycle setting values, and estimated refund calculation results; extracting underwriting regulation data from a database including age requirements, occupation classification, health status criteria, risk grade calculation criteria, and subscription limit values; receiving payment transaction data including payment attempt history, payment approval status, payment method type, and payment error code; and receiving data on the submission of documents such as the user's identification card image, income verification documents, health examination forms, and other documents to satisfy subscription requirements. The method further includes: a step of monitoring the consultation status, wherein the step of extracting a consultation procedure definition rule that defines a plurality of procedures including a consultation start procedure, a design completion procedure, an underwriting review procedure, an identity verification procedure, a payment procedure, and a subscription success procedure; a step of determining the current consultation procedure status as one of a consultation start procedure, a design completion procedure, an underwriting review procedure, an identity verification procedure, a payment procedure, and a subscription success procedure by correlating the event tags, time stamps, and screen transition history of real-time consultation log data with the consultation procedure definition rule; and a step of generating a status transition history by accumulating and storing changes in the determined consultation procedure status in chronological order, and monitoring the consultation status based on the status transition history; and the step of collecting the situation data set, wherein the step of extracting a time stamp at the point in time when the consultation status is designated as a failure event, and calculating a preset time interval before and after the time stamp.A method of operation of an operating server supporting consultation of an insurance product, further comprising: a step of collecting a consultation log including user input values, consultation conversation logs, insurance plan attribute values, and payment attempt history included in the aforementioned time intervals; a step of extracting a regulation log including underwriting regulation attribute values ​​and attribute-specific standard values ​​defined in the underwriting regulation data included in the aforementioned time intervals; a step of collecting a payment log including payment approval logs, error codes, and payment method attributes included in the aforementioned time intervals; a step of collecting a user response signal including voice signals, text input, and user interaction data collected during the aforementioned time intervals; and a step of collecting a situational data set based on the consultation log, the regulation log, the payment log, and the user response signal. Claim 2 delete Claim 3 ◈Claim 3 was abandoned upon payment of the establishment registration fee.◈ In Claim 1, the step of determining each of the above-mentioned candidate cause items comprises: determining unsatisfied items as regulation-based candidate cause items by comparing the attribute values ​​of consultation data included in the situation data set with reference values ​​defined in the underwriting regulation data using a condition matching operation; normalizing consultation logs and user interaction data included in the situation data set in chronological order to quantify the number of input errors, waiting time, number of cancellations, and deviation of dwell time, and determining behavior-based candidate cause items by comparing each quantified value with the procedure progress history data of the set of successful subscribers using a sorting-based comparison operation; and calculating an emotion state index and an emotion-based failure risk using feature vectors extracted from voice signals, text inputs, and user interaction data included in the situation data set, and determining emotion-based candidate cause items based on the calculation results. The method includes the step of inputting virtual input data generated by changing the premium level, coverage and special clause configuration, payment cycle, and payment method included in the consultation data into a pre-trained AI-based prediction model to calculate a success rate fluctuation value, and determining elements whose fluctuation value is above a threshold as condition change-based cause candidate items; the step of calculating the cause matching index further includes the step of generating a cause evaluation characteristic vector by normalizing indicator values ​​corresponding to each regulation-based, behavior-based, emotion-based, and condition change-based cause candidate item to a range of 0 to 1; and the step of calculating the cause matching index of each cause candidate item by applying a pre-set weight vector to the cause evaluation characteristic vector generated by normalization; and the step of generating improvement plan data and providing it to an expert terminal includes the step of verifying the cause matching index calculated for each cause candidate item and determining the cause candidate item having the largest cause matching index as the failure cause item of the consultation procedure.A step of extracting failure cause data from the above consultation data and situation data sets, the failure cause item identifier, time of occurrence, related procedure status history, attribute values ​​associated with the failure cause item, and cause matching index; and a step of generating improvement plan data by applying a predefined generation rule for improvement plan data based on the type of failure cause item included in the failure cause data, and transmitting the generated improvement plan data to the expert terminal; A method of operation of an operating server supporting consultation on insurance products, wherein the rules for generating the above-mentioned predefined improvement plan data are defined such that, in the case of a regulation-based cause item, supplementary document items for satisfying underwriting regulations and design / input modification instructions are generated as improvement plan data; in the case of a behavior-based cause item, procedural instructions such as input validation, retry control, waiting time mitigation, and callback suggestions are generated as improvement plan data; in the case of an emotion-based cause item, consultation conversation scenarios including conversation tone, guidance phrases, pauses, and reconnection timing are generated as improvement plan data; and in the case of a condition change-based cause item, an adjustment plan is generated as improvement plan data by selecting the combination with the maximum prediction success rate among parameter combinations within an acceptable range using a pre-trained prediction model.

Images