JP2011232900A - Insurance contract support system for agency - Google Patents

Abstract

【Task】
When providing products (services) to be traded, it has been difficult to grasp customer needs. In particular, when selling a plurality of insurances in combination or combining a plurality of special contracts, it becomes difficult to adapt to customer needs.
[Solution]
In the present invention, a chart related to a product is created in an interactive format, and at that time, a history of conversation or the like is stored in association with the chart. In addition, the present invention compares the information indicating the magnitude of needs for each item (property, aspect) of the product with the information indicating the needs for each item of the product subject to the transaction, etc. It also includes extracting those having a large. In this comparison, for the specified items, items having large customer needs may be extracted, or items having a large sum of the items may be extracted. At this time, the extracted information may be output to the terminal.
[Selection] FIG.

Description

  The present invention relates to a technique for supporting a contract or transaction by recording a history related to the contract or transaction. In particular, insurance consultations and contracts at insurance agencies.

  In dealings and contracts with insurance agents, etc., sufficient explanation of the goods (services) is required from the viewpoint of preventing legal obligations and claims after contracts. In addition, since various products are available for insurance, etc., it is also important to explain products that meet customer needs. A system that supports transactions and contracts based on these assumptions has been proposed.

  For example, in Patent Document 1, as a technology that can suppress the generation of paper documents in relation to insurance sales business and can actually improve the efficiency of each insurance company and agency business, a center server and a center server A plurality of insurance company servers and a plurality of agency terminals connected to each other, and the center server stores storage means for storing information on insurance products transmitted from each insurance company server, and each agency terminal Means for sending information on insurance products, and means for sending an application form for the insurance products and prompting for the input of necessary customer information when a request for joining a specific insurance product is sent from the agency terminal The application information transmitted from the agency terminal is transferred to the insurance company server, the means for inquiring whether insurance application is possible, and the result information transmitted from the insurance company server. Insurance business support system and a means to be transferred to the agency terminal, is provided.

JP 2005-100208 A

In recent years, banks and other companies that were not traditional insurance agents have become insurance agents and can sell insurance. In that case, insurance products are not necessarily sold by a person who specializes in insurance sales. Therefore, the insurance product knowledge of the contact person may be limited. As described above, when the contact person has only limited insurance product knowledge, there is a problem that the insurance recommended to the customer by the contact person does not necessarily match the customer needs. In particular, when selling a plurality of insurances in combination or combining a plurality of special contracts, it becomes difficult to adapt to customer needs.

  In response to these issues, an intention confirmation document is currently being introduced in insurance sales as an institutional solution. The intention confirmation document is a document in which the customer finally confirms whether the insurance product to be purchased conforms to the customer's needs before the contract is concluded. However, it is of course desirable that the insurance that the contact person recommends to the customer from the beginning matches the customer's needs. It is also desirable to be able to support what type of insurance meets the customer's needs if it does not meet the customer's needs at the time of final confirmation.

The system for supporting an insurance contract in an insurance agent disclosed in Patent Document 1 is mainly aimed at improving the efficiency of business in the insurance agent, and the above-described problems remain.
An object of the present invention is to provide a technique capable of solving the above-described problems.

  In order to achieve this object, in the present invention, a chart relating to a product is created in an interactive format, and at that time, a history of conversation or the like is stored in association with the chart. In addition, the present invention compares the information indicating the magnitude of needs for each item (property, aspect) of the product with the information indicating the needs for each item of the product subject to the transaction, etc. It also includes extracting those having a large. In this comparison, for the specified items, items having large customer needs may be extracted, or items having a large sum of the items may be extracted. At this time, the extracted information may be output to the terminal.

The following more detailed aspects are also included in the present invention.
An agent counter terminal operated by a contact person at the insurance agent, and
A product data server operated by an insurance company or its agent,
A contract server operated by an insurance company or its agent,
Connected by network,
In the product database connected to the product data server by a network or the like, an insurance needs table expressing numerically the needs that the insurance product satisfies is stored,
In response to a request from the contact person, generate a customer insurance need that expresses the customer's needs numerically in the memory or secondary storage device provided in the agency contact terminal,
The agency window terminal creates a needs table that records the needs of each item of insurance to be contracted from the insurance needs table,
As a result of comparing the customer insurance needs with the needs table of the insurance to be contracted, if the customer insurance needs are larger than the needs table of the insurance to be contracted, the fact is displayed.

  According to the present invention, it is possible to present to the contact person the reference information as to whether or not the product recommended to the customer by the contact person is suitable for the customer needs. Reduce the situation of not meeting customer needs.

It is a figure which illustrates the outline | summary of the system to which one Embodiment of this invention is applied. It is a figure which shows an example of the internal structure of a general PC It is a flowchart which shows the outline of a process of the insurance agency contract assistance system of embodiment of this invention. It is a flowchart which shows the outline of the needs grasping | ascertainment support process of embodiment of this invention. It is a flowchart which shows the outline of the insurance design assistance process of embodiment of this invention. It is a flowchart which shows the outline of the needs satisfaction determination process of the design insurance of embodiment of this invention. It is a flowchart which shows the outline of the simple intention confirmation process of embodiment of this invention. It is a flowchart which shows the outline of the detailed intention confirmation process of embodiment of this invention. It is a flowchart which shows the outline of the insurance contract support process of embodiment of this invention. It is the figure which illustrated the insurance needs table It is the figure which illustrated customer insurance needs, insurance satisfaction needs, insurance shortage needs It is the figure which showed an example of the screen in needs grasping support processing It is the figure which showed an example of the screen in insurance design support processing It is the figure which showed an example of the screen in a simple intention confirmation process It is the figure which showed an example of the screen in a detailed intention confirmation process It is the figure which showed an example of the screen in an insurance contract support process

Hereinafter, embodiments for carrying out the invention will be described with reference to the drawings.
FIG. 1 is a diagram illustrating an overview of a system.
In this figure, reference numeral 101 is an agency window terminal, reference numeral 102 is customer insurance needs, reference numeral 103 is insurance satisfaction needs, reference numeral 104 is insurance shortage needs, reference numeral 105 is a network, reference numeral 106 is a product data server, reference numeral 107 is a product DB. (Database), 108 is an insurance needs table, and 109 is a contract server.

  The agency window terminal 101 is installed in the vicinity of the agency window, and is a terminal that supports insurance explanation and contract work by the window staff when operated by the staff in charge of the window, and is connected to the network 105. As will be described later, the agency window terminal 101 is provided with a memory. As will be described later, the customer insurance needs 102, the insurance satisfaction needs 103, and the insurance shortage needs 104 are generated in the memory by the operation of the person in charge of the window. Customer insurance needs 102 are data representing customer insurance needs. Insurance satisfaction needs 103 are needs covered by the proposed insurance. The insurance shortage needs 104 is data representing the difference between the customer's insurance needs and the needs covered by the proposed insurance. The network 105 is a network including a local area network (LAN) and a line connecting the agency and the insurance company, and is connected to the agency window terminal 101, the product data server 106, and the contract server 109. The product data server 106 is installed in the premises of an insurance company or its agent, and accesses the product DB 107 in which insurance product data is stored in response to a request from the agent contact terminal 101, and stores data related to the product at the agent contact A server having a function of returning to the terminal 101 and connected to the network 105 and the product DB 107. The product DB 107 is a DB that stores data related to insurance products, and includes an insurance needs table 108 and is connected to the product data server 106. The insurance needs table 108 is a table for storing insurance needs. The contract server 109 is installed in the insurance company and is a server that receives contract data in response to a request from the agency window terminal 101 and is connected to the network 105.

  The agency window terminal 101, the product data server 106, the product DB 107, and the contract server 109 can be realized by a general PC (Personal Computer). The agency window terminal 101 can be realized by executing a program for performing processing as described later on a general PC. The merchandise data server 106 can be realized by executing a general server program that accepts a connection from the agency window terminal 101 on a general PC. The product DB 107 can be realized by executing a general database program on a general PC. The contract server can be realized by executing a general server program on a general PC.

FIG. 2 is a diagram illustrating an example of an internal configuration of a general PC, that is, the agency window terminal 101 or the like.
In this figure, reference numeral 201 is a CPU, reference numeral 202 is a memory, reference numeral 203 is a network interface, reference numeral 204 is a keyboard, reference numeral 205 is a clock, reference numeral 206 is a speaker, reference numeral 207 is a display, reference numeral 208 is a microphone, reference numeral 209 is a video camera Reference numeral 210 denotes a hard disk, and reference numeral 211 denotes an interface.

  The CPU 201 is a central processing unit, and executes a program recorded in the memory 202 or a program read from the hard disk 210 to the memory 202. Note that the program may be installed on a removable storage medium that can be used by a PC as needed. In this case, a device for reading the storage medium is connected to the interface 211. As such a storage medium and an apparatus for reading the storage medium, those using an optical disk are generally known and can be used.

  Further, the program may be introduced into the PC via the communication medium (communication line or carrier wave on the communication line) by the network interface 203 as necessary. The memory 202 is a device for temporarily recording programs and data executed by the CPU 201. The network interface 203 is a device for communicating with a device outside the PC, such as another PC. The keyboard 204 is a device that is operated by an operator of the PC in order to input commands and data to the PC. The clock 205 is a device for the CPU 201 to know the current approximate time. The speaker 206 is a device that reproduces a signal as sound. A display 207 is a device for displaying processing results and the like. The microphone 208 is a device that inputs sound as a signal into the PC. The moving image camera 209 is a device that inputs a moving image as a signal into the PC. The hard disk 210 is a device that stores programs and data, and can be configured by, for example, a nonvolatile memory. In this case, the program and data stored in the hard disk 210 are normally held even when the program and data are turned on after the power is turned off. Note that an operating system may be installed in the hard disk 210 in advance. This makes it possible to specify a program using a file name. Here, the operating system is basic software of the computer, and generally known operating systems can be used. The interface 211 is for connecting devices in the PC. The CPU 201, the network interface 203, the keyboard 204, the clock 205, the speaker 206, the display 207, the microphone 208, the video camera 209, and the hard disk 210 are connected via the interface 211. Has been. The CPU 201 and the memory 202 are directly connected without using the normal interface 211, but may be connected through the interface 211.

Next, an outline of the processing of the insurance agent contract support system according to the embodiment of the present invention will be described using a flowchart.
FIG. 3 is a flowchart showing an outline of processing of the insurance agent contract support system. In FIG. 3, first, in step 301, needs grasp support is performed. Details of this processing will be described later with reference to the diagram showing the needs grasping support processing flow of FIG.
Next, in step 302, insurance design support is performed. The details of this process will be described later with reference to the diagram showing the insurance design support process flow of FIG.

  Next, in step 303, it is checked whether the needs are satisfied. If the needs are satisfied, the process proceeds to step 304. If the needs are not satisfied, the process proceeds to step 305. Details of this process will be described later with reference to the diagram showing the design satisfaction needs determination process flow of FIG.

Step 304 is a process for confirming a simple intention. Details of this process will be described later with reference to the flowchart of the simple intention confirmation process flow of FIG.
Step 305 is a process for confirming the detailed intention. Details of this processing will be described later with reference to the flowchart showing the detailed intention confirmation processing flow of FIG.

  After step 304 or step 305, the process proceeds to step 306. In step 306, it is checked whether customer consent has been obtained in the processing of step 304 or step 305. If customer consent cannot be obtained, the process returns to step 302. If customer consent is obtained, the process proceeds to step 307.

Step 307 is processing for supporting insurance contract processing. Details of this process will be described later with reference to the flowchart of the insurance contract support process in FIG.
The above steps outline the processing of the insurance agent contract support system.

Next, details of the processing of the insurance agent contract support system will be described.
First, needs grasp support processing will be described with reference to FIGS. FIG. 4 is a flowchart showing an outline of the needs grasping support process, in which the process performed in step 301 is described in detail. FIG. 12 is a view showing an example of a screen in the needs grasping support process.

  First, FIG. 12 will be described. In this figure, reference numeral 1201 is a click area (current health), reference numeral 1202 is a click area (future health), reference numeral 1203 is a click area (in case of emergency), reference numeral 1204 is a click area (life after retirement), reference numeral Reference numeral 1205 denotes an end button, and reference numeral 1206 denotes a pointer.

  A click area (current health) 1201 is a button for increasing security needs regarding current health. A click area (future health) 1202 is a button for increasing security needs related to future health. A click area (in the case of an emergency) 1203 is a button for increasing the security needs in case of an emergency, that is, death. A click area (life after retirement) 1204 is a button for increasing security needs related to life after retirement. An end button 1205 is a button that is clicked when the needs grasp support is ended. A pointer 1206 is a pointer that determines an object to be clicked.

Next, needs grasp support processing will be described with reference to FIG.
Step 401 is a process for initializing the click counter. Here, the click counter is a counter for measuring how many times a click area such as the click area (current health) 1201 has been clicked, and is equivalent to the number of click areas. In the example of FIG. 12, there are 4 click counters (current health), 6 click counters (future health), 15 click counters (in case of emergency), and 15 click counters (life after retirement). Nine. The click counter may be displayed near or in the corresponding click area as shown in FIG.
Step 402 is processing for displaying keywords. By this processing, a screen as shown in FIG. 12 is displayed.
Steps 403 to 405 are repeated until the end button 1205 in FIG. 12 is pressed.

  Step 403 is a process for checking whether or not the end button has been clicked. If the end button is clicked, the process proceeds to step 406. Otherwise, go to step 404.

  Step 404 is a process of accepting a click. A screen as shown in FIG. 12 is displayed, and it waits for a click area such as the click area (current health) 1201 to be clicked. The contact person asks what kind of anxiety the customer feels and what kind of insurance they want to get. Then, during or immediately after the hearing, the user clicks on a click area where a keyword related to the anxiety or insurance he / she wants to enter is displayed. This step 404 accepts this click.

  Step 405 is a process of adding 1 to the click counter of the clicked keyword. After this processing, the process returns to step 403.

  Step 406 is a process of normalizing each click counter and registering it in the memory as customer insurance needs. Here, normalization is to increase / decrease the value of each click counter so that the maximum value is 50, for example. As an example, as shown in FIG. 12, the click counter (current health) is 3, the click counter (future health) is 6, the click counter (in case of emergency) is 15, and the click counter (life after retirement) is 9. It is assumed that the end button 1205 is clicked at a certain time. Since the maximum value of the click counter is a click counter (in the unlikely event), in order to make this 50, each click counter is multiplied by 50/15. Then, the click counter (current health) is 10, the click counter (future health) is 20, the click counter (in case of emergency) is 50, and the click counter (life after retirement) is 30. This is registered in the memory as customer insurance needs.

FIG. 11 shows customer insurance needs. This is a diagram illustrating the need for insurance satisfaction and the need for insurance shortage, which will be described later.
In this figure, reference numeral 1101 is current health, reference numeral 1102 is future health, reference numeral 1103 is emergency, reference numeral 1104 is life after retirement, reference numeral 102 is customer insurance needs, reference numeral 103 is insurance satisfaction needs, reference numeral 104 is This is a lack of insurance needs.
The current health 1101 is a field indicating the height of security needs related to the current health. The future health 1102 is a field representing the level of security needs related to future health. In the unlikely event, 1103 is a field that indicates the height of security needs related to death. The life after retirement 1104 is a field representing the high level of security needs related to life after retirement. Thus, the customer insurance needs are recorded in the memory 202 of the agency window terminal in a format associated with each field. The customer insurance needs may be recorded on the hard disk 210 of the agency window terminal. In this case, when using customer insurance needs, customer insurance needs are read from the hard disk 210 to the memory 202 as appropriate.

  Next, regarding the details of the insurance design support process of the insurance agent contract support system, a flowchart showing an outline of the insurance design support process of FIG. 5 and a diagram showing a diagram showing the insurance design support process screen of FIG. It explains using. This process is performed in step 302.

First, the insurance design support processing screen will be described using the screen example shown in FIG.
In this figure, reference numeral 1301 is a contractor information field, reference numeral 1302 is a current plan field, reference numeral 1303 is an insurance need display field, reference numeral 1304 is a recommended insurance display field, reference numeral 1305 is an insurance design field, reference numeral 1306 is an update button, reference numeral 1307 Is an end button.

  The contractor information column 1301 is a column for inputting and confirming contractor information. The current plan column 1302 is a column in which an outline of the contents of the insurance plan that is currently being applied is displayed. The insurance needs display column 1303 is a column for displaying customer insurance needs and insurance satisfaction needs in the insurance plan up to now. The recommended insurance display column 1304 is a column for displaying recommended insurance. The insurance design column 1305 is a column for designing a new insurance to be added to the insurance plan. An update button 1306 is a button that is clicked when a newly designed insurance is added to the insurance plan up to now. An end button 1307 is a button that is clicked when the insurance design support process is ended.

Next, an outline of the insurance design support process will be described with reference to FIG.
Step 501 is processing for substituting customer insurance needs for insurance shortage needs. The insurance shortage needs are data having the same fields as the customer insurance needs 102 as shown by the insurance shortage needs 104 in FIG. First, as an initialization process, each field of insurance shortage needs is made the same as each field of customer insurance needs.

  Next, in step 502, insurance satisfaction needs are initialized. The insurance satisfaction needs are data having the same fields as the customer insurance needs 102 as indicated by the insurance satisfaction needs 103 in FIG. First, as an initialization process, each field of insurance satisfaction needs is set to 0.

Next, steps 503 to 507 are repeated until an end instruction is issued by clicking on the end button 1307.
Step 503 is a process for examining whether or not an end instruction has been received (whether or not an end instruction has been received). If there is an end instruction, the process proceeds to step 508. Otherwise, the process proceeds to step 504, and the processes from step 504 to step 507 are repeated.

Step 504 is a process of accessing the product data server 106, referring to the insurance needs table 108, and displaying the insurance whose value of insurance needs is high in the field where the value is high in the insurance shortage needs 104. In the example of FIG. 11, an insurance with a high value of this insurance need is displayed in the recommended insurance display field 1304. In addition, other screen elements as shown in FIG. 11 are also displayed in this step.
For example, the insurance needs display field 1303 includes portions for displaying the customer insurance needs 102 and the insurance satisfaction needs 103, which are respectively displayed. Also, a contractor information column 1301 and a current plan column 1302 are displayed. If no data has been input yet, it may be left blank.

  Step 505 is a process for accepting inputs such as insurance type and insurance amount, and designing insurance. The person in charge of the window or the customer uses the keyboard 204 of the agency window 101 to enter the insurance design field 1305 and the contractor information field 1301. When the update button 1306 is pressed after the input, the input data is accepted. Information input in the contractor information column 1301 is recorded in the memory 202 of the agency window terminal 101 or the hard disk 210 as contractor information. The information input in the insurance design column 1305 is added to the current plan and recorded in the memory 202 or the hard disk 210 of the agency window terminal 101. The insurance added in the current plan column 1302 is displayed. Although not shown, the insurance in the current plan column 1302 may be corrected. This can be done by clicking on the insurance to be modified currently displayed in the plan field 1302, displaying the insurance in the insurance design field 1305, and subtracting the insurance needs of the insurance from the insurance satisfaction needs 103. The insurance needs are searched by the method described in step 506.

  Step 506 is a process of subtracting each field of the insurance needs of the used insurance from each field of the insurance shortage needs 104. The insurance needs used in step 505, step 506, and step 507 are obtained by accessing the product data server 106 via the network 105 and referring to the product DB 107 based on the insurance name entered in the insurance design field 1305. Can be obtained.

  Step 507 is a process of adding each field of the insurance needs of the used insurance to each field of the insurance satisfaction needs 103. After the processing in step 507, the process returns to step 503.

Step 508 is a process of recording the insurance shortage needs 104 and the insurance satisfaction needs 103 in the memory 202 or the hard disk 210 so that they can be used after the insurance design support process.
This is the end of the outline of the insurance design support processing flow.

  Next, an overview of the design insurance needs satisfaction determination process in step 303 will be described with reference to the design insurance needs satisfaction determination processing flow of FIG.

  Step 601 is a process of checking whether there is a field exceeding the threshold in each field of the insurance shortage needs 104. If there is a field exceeding the threshold value in each field of the insurance shortage needs 104, the process proceeds to step 602.

  If there is no field exceeding the threshold value in each field of the insurance shortage needs 104, the process proceeds to step 603. Here, the threshold value is determined in advance and should be stored in the memory 202 of the agency window terminal 101 or the hard disk 210. For example, an arbitrary numerical value from 10 to 50 is a typical example, but 0 or another positive numerical value may be taken. This numerical value may be stored in the memory 202 or the hard disk 210 of the product data server 106 and stored in the memory 202 or the hard disk 210 of the agency window terminal 101 through the network 105 before executing step 303.

  Step 602 is processing for determining that the needs are not satisfied. That is, in step 601, when the threshold is smaller, it is determined that the needs are not satisfied. This determination result is stored in the memory 202 or the hard disk 210 of the agency window terminal 101 so that it can be referred to in the processing after step 303. As described in FIG. 3, after this processing, the process proceeds to step 305.

  Step 603 is a process of checking whether the field that gives the maximum value in the insurance satisfaction needs 103 is different from the field that gives the maximum value in the customer insurance needs 102. If the field giving the maximum value in the insurance satisfaction needs 103 is different from the field giving the maximum value in the customer insurance needs 102, the process proceeds to step 604. If the field giving the maximum value in the insurance satisfaction needs 103 is the same as the field giving the maximum value in the customer insurance needs 102, the process proceeds to step 605.

  Step 604 is processing for determining that the needs may not be satisfied because there is a possibility that the request is different. That is, in step 603, if the fields are different, it is determined that the needs are not satisfied. This determination result is stored in the memory 202 or the hard disk 210 of the agency window terminal 101 so that it can be referred to in the processing after step 303. As described in FIG. 3, after this processing, the process proceeds to step 305.

Step 605 is processing for determining that the needs are satisfied. That is, in step 603, if the fields match, it is determined that the needs are satisfied. This determination result is stored in the memory 202 or the hard disk 210 of the agency window terminal 101 so that it can be referred to in the processing after step 303. As described in FIG. 3, after this processing, the process proceeds to step 304.
Thus, the design insurance needs satisfaction determination process in step 303 is roughly completed.

  Next, an outline of the simple intention confirmation processing in step 304 will be described with reference to a diagram showing a simple intention confirmation processing flow in FIG. 7 and a diagram showing a simple intention confirmation processing screen in FIG. First, the simple intention confirmation processing screen of FIG. 14 will be described.

FIG. 14 is a diagram showing an example of a screen in the simple intention confirmation process.
In this figure, reference numeral 1401 is a contractor information column, reference numeral 1402 is an insurance needs display column, reference numeral 1403 is an insurance design column, reference numeral 1404 is a redo button, and reference numeral 1405 is a confirmation button.

  The contractor information column 1401 is a column for displaying contractor information and insured person information. The insurance needs display column 1402 is a column for displaying the customer insurance needs 102 and the insurance satisfaction needs 103. The insurance design column 1403 is a column for designing a new insurance to be added to the insurance plan. The redo button 1404 is a button for the operator to instruct (click) this redo when redoing the insurance design. A confirmation button 1405 is a button for the operator to instruct the end of the confirmation process by clicking.

  Next, an outline of the simple intention confirmation process according to the embodiment of the present invention will be described with reference to the flowchart shown in FIG.

  Step 701 is a process for displaying an intention confirmation screen. The intention confirmation screen is, for example, as shown in FIG. While looking at this screen, the contact person and the customer can confirm that the insurance that they are currently trying to meet meets their needs.

Step 702 is processing for obtaining customer consent. For example, the customer's consent states that the customer confirms the intention with the microphone 208 or the video camera 209 of the agency window terminal 101, for example, the method in which the customer signs the intention confirmation document. It can be obtained by a method of recording or recording, or by connecting a pen pad generally sold in the market to the agency window terminal 101 and receiving the signed content on the pen pad. After confirming the intention, the confirmation button 1405 is clicked to end the simple intention confirmation process. A simple intention confirmation can also be made by having the customer click the confirmation button 1405.
Thus, the simple intention confirmation process is roughly completed.

  Next, the detailed intention confirmation processing in step 305 will be described with reference to the detailed intention confirmation processing flow diagram of FIG. 8 and the detailed intention confirmation processing screen of FIG.

  First, the figure which showed an example of the screen in the detailed intention confirmation process of FIG. 15 is demonstrated. In this figure, reference numeral 1501 is a detailed intention confirmation column. The detailed intention confirmation column 1501 is a column for displaying points to be specifically confirmed based on the customer insurance needs 102 and the insurance satisfaction needs 103. Other reference numerals are the same as those in FIG. 14, and are the same columns as in FIG.

  Next, the outline of the detailed intention confirmation processing according to the embodiment of the present invention will be described with reference to the flowchart of FIG.

  Step 801 is a process for checking whether or not it is determined in step 604 that there is a possibility that it is different from what is desired. If it is determined that there is a possibility that the request is different, the process proceeds to step 802. If it is not determined that there is a possibility that the request is different, the process proceeds to step 803.

Step 802 accesses the product data server, searches the insurance needs table, and finds an insurance policy in which the field that gives the maximum value among the fields of the insurance needs matches the field that gives the maximum value among the fields of the customer insurance needs. This is a process for making a review candidate insurance and recording the insurance needs in a memory. If the reconsideration candidate insurance is already included in the proposed insurance, the reconsideration candidate insurance is emptied.
Step 803 is a process for extracting each field in the field where the insurance shortage needs are positive. If there is an element, go to step 804. After processing for each element, the process proceeds to step 805. Step 804 accesses the product data server, searches the insurance needs table, adds an insurance in which the value of the processing target field is larger than the insurance shortage needs to the reconsideration candidate insurance, This process records the insurance needs in a memory. If the insurance to be added is already included in the proposed insurance, nothing is done.

  Step 805 is processing for displaying customer insurance needs 102, insurance satisfaction needs, insurance to be contracted, and reconsideration candidate insurance. The display screen is as shown in FIG. 15. For example, in the example of FIG. 15, the life after retirement of the customer insurance needs 102 is 30, while the life after retirement of the proposed insurance satisfaction needs 103 is 10 Therefore, a warning is displayed in the insurance needs display field 1402. And it is displayed in the detailed intention confirmation column that there is a possibility that the life needs after retirement may not be satisfied. In the example of FIG. 15, since the maximum value of the customer insurance needs 102 is 50 in the unlikely event, the maximum value of the proposed insurance satisfaction needs 103 is 80 for future health. A warning to that effect is displayed in the detailed intention confirmation column. The contact person and the customer can check whether the customer's needs can be met with the insurance they are proposing.

  Step 806 is processing for determining whether or not a contract continuation intention display is present. If the contract continuation intention display is present, the process proceeds to step 807. If there is no indication of intention to continue the contract, it is terminated.

Step 807 is processing for obtaining customer consent. This can be executed by the same processing as in step 702.
This completes the detailed intention confirmation process.

Finally, details of the insurance contract support processing in step 307 will be described using the diagram showing the insurance contract support processing flow in FIG. 9 and the diagram showing the insurance contract support processing screen in FIG. First, an example of the screen in the insurance contract support process of FIG. 16 will be described.
In this figure, reference numeral 1601 is a bank account input field, reference numeral 1602 is a hold button, and reference numeral 1603 is a contract button.
A bank account input field 1601 is a field for inputting a bank account for insurance premium deduction. The hold button 1602 is a button that is clicked when the contract is held and ended. The contract button 1603 is a button that is clicked when a contract is made and contract data is transmitted to the contract server 109.

Next, a flowchart showing an outline of the insurance contract support process of FIG. 9 will be described.
Step 901 is a process for requesting input of the missing part of the contract data. This corresponds to, for example, processing such as inputting a bank account for deduction of insurance premiums in the bank account input field 1601.

Step 902 is processing for accessing the contract server 109 and transmitting the input contract data to the contract server 109 via the network 105. Of course, a final confirmation of the customer is necessary before this, and the confirmation can be performed by the method used in step 702.
This completes the description of the insurance contract support process.

101 ... Agency counter terminal 102 ... Customer insurance needs 103 ... Insurance satisfaction needs 104 ... Insurance shortage needs 105 ... Network 106 ... Product data server 107 ... Product DB
108 ... Insurance needs table 109 ... Contract server 201 ... CPU
202 ... Memory 203 ... Network interface 204 ... Keyboard 205 ... Clock 206 ... Speaker 207 ... Display 208 ... Microphone 209 ... Video camera 210 ... Hard disk 211 ... Interface 1201 ... Click area (current health)
1202 ... Click area (future health)
1203 ... Click area (in case of emergency)
1204 ... Click area (life after retirement)
1205 ... End button 1206 ... Pointer 1301 ... Contractor information column 1302 ... Current plan column 1303 ... Insurance needs display column 1304 ... Recommended insurance display column 1305 ... Insurance design column 1306 ... Update button 1307 ... End button 1401 ... Contractor information column 1402 ... Insurance needs display field 1403 ... Insurance design field 1404 ... Redo button 1405 ... Confirm button 1501 ... Detailed intention confirmation field 1601 ... Bank account input field 1602 ... Hold button 1603 ... Contract button

Claims (6)

An agent counter terminal operated mainly by an insurance agent's contact person at the insurance agent,
A product data server operated by an insurance company or its agent,
A contract server operated by an insurance company or its agent,
In the insurance agency contract support system connected by the network,
In the product database connected to the product data server by a network or the like, an insurance needs table expressing numerically the needs to be satisfied by the insurance products is stored,
In response to a request from the person in charge of the counter, in the memory or secondary storage device provided in the agency window, customer insurance needs that express customer needs numerically are generated,
The agency window terminal creates an insurance needs table to be contracted from the insurance needs table,
When the customer insurance needs are greater than the needs table of the insurance to be contracted as a result of comparing the customer insurance needs with the needs table of the insurance to be contracted, the contract server indicates that An insurance agent contract support system characterized by being transmitted to an agent window terminal. In the contract support method for supporting the contract or transaction by recording the history about the contract or transaction,
For each item indicating the nature of each product subject to the contract or transaction, record the needs information indicating the needs,
Accepts interactive exchanges about the products of interest between the parties involved in the contract or transaction,
From the received exchange, extract the needs information of the prospective purchaser of the product included in the participant,
A transaction support method, wherein the extracted needs information is compared with the recorded needs information to extract a product having a large need of the prospective purchaser. The transaction support method according to claim 2,
A transaction support method, wherein product information of the extracted product is transmitted via a network, and the transmitted terminal device displays the product information. In the transaction support method according to claim 2 or 3,
In the transaction support method, the product is extracted for each designated item that has a greater need for the prospective purchaser. The transaction support method according to any one of claims 2 to 4,
In the transaction support method, the product is extracted by extracting items having a large sum of items. The transaction support method according to any one of claims 2 to 5,
The transaction support method, wherein the product is an insurance product.

Images