JP2017146633A - Proposal assistance method, proposal assistance system, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a proposal assistance method for presenting a user with proposal content that is highly likely to succeed based on a past proposal history.SOLUTION: A proposal history registered in a proposal assistance DB 3 is analyzed to generate an index of proposals with a success record as candidates for the next proposal by proposal history analysis means S107. When the proposal history is registered by proposal history registration means S102, the candidates for the next proposal are extracted by proposal candidate extraction means S103 using the proposal history and the index, and are displayed on a display unit by a proposal candidate display means S104. A proposal selected by a user from the displayed proposal candidates is registered in the proposal assistance DB 3 as a next proposal by next proposal registration means S106.SELECTED DRAWING: Figure 3

Description

  The present invention relates to a proposal support method, a proposal support system, and a program, and more specifically, a proposal support method and a proposal for presenting a proposal content with a high success rate to a user based on a past proposal history based on a proposal result. The present invention relates to a support system and a program.

  Conventionally, for example, a sales support system disclosed in Patent Document 1 is known as an information system for causing a computer to support sales activities. This sales support system assists in performing an appropriate price setting based on the type of proposal contents when an order is placed for the proposal contents.

  Further, a ToDo recommendation device disclosed in Patent Literature 2 is known as a device that manages the actions to be performed by a user and ToDo. This ToDo recommendation device reduces the operation burden on the user by recording the ToDo items to be presented in the ToDo recommendation table in a hierarchical manner and presenting the hierarchical ToDo items to the user sequentially from the upper layer. is there. Such ToDo management is also widely used in sales activities, and is used in combination with an information system such as the above-described sales support system as appropriate.

JP 2001-52058 A JP 2009-99116 A

  In the above-described conventional technology, the user's action is supported based on information set in advance to support the user. That is, in the ToDo recommendation device of Patent Document 2 described above, the ToDo items to be recommended are limited to those recorded in a hierarchical manner in the ToDo recommendation table, and the order of operations and actions is like a specific workflow. It is effective for those that are fixed.

  On the other hand, when a product or service is proposed in a sales activity, what kind of proposal should be made to a certain customer cannot be handled by a previously fixed workflow as in the prior art described above. There was a problem.

  In view of the above problems, the present invention provides a proposal support method, a proposal support system, and a program for presenting a proposal content with a high success rate to a user based on a past proposal history based on a result of a proposal. That is the purpose.

  The present invention, which has been made for the purpose of solving the above-mentioned problems, is a proposal support method for presenting to a user candidates for content to be proposed to a customer using a computer, wherein the computer performs the above operation on the customer. Proposal history registration means for registering the contents and results of proposals in the database as a proposal history, and analyzing the proposal history to create an index for extracting candidate candidates to be proposed next time in the database. Proposal history analyzing means to be registered, proposal candidate extracting means for extracting candidates for the next proposal based on the registered proposal history and the index, and proposal candidates for displaying a list of the extracted proposal candidates on a display device Display means and a proposal candidate selected by the user from the displayed proposal candidates are stored in the database as a proposal to be performed next time. It is characterized by and a next proposal registration means for recording.

  In the proposal support method according to the present invention, it is preferable that the proposal history analysis unit creates an index for extracting the proposal that has been successfully performed the next time after the proposal, It is desirable to create an index for extracting the proposals made at the same time as the proposal and having a successful track record.

  In the proposal support method according to the present invention, the next proposal registration means may further register the selection contents by the user in the database for each of the displayed proposal candidates. However, you may make it show either that the said proposal candidate was employ | adopted as a next proposal, the fact that it was not employ | adopted as a next proposal, or the rejection of all the proposal candidates displayed on the said list. In the suggestion support method according to the present invention, the suggestion history analysis unit may be executed as a batch process for each predetermined period.

  According to the present invention, the contents and results of the proposal made by the user to the customer by the proposal history registration means are registered in the database as the proposal history, and the registered proposal history is analyzed by the proposal history analysis means and performed next time. Create an index to extract proposal candidates. As a result, the proposal candidate extraction means can extract the next proposal candidate based on the past results accumulated in the database, so that the proposal content with a high success rate can be presented to the user based on the past proposal history. Can do.

It is the figure which showed an example of the system configuration | structure of embodiment which concerns on this invention. It is the ER figure which showed the structural example of the database in the same embodiment. It is the flowchart which showed the flow of the process in the same embodiment.

  Hereinafter, an example of an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a configuration diagram of a proposal support system 1 that executes a proposal support method according to the present invention. As shown in FIG. 1, the proposal support system 1 is an information system in which a proposal support server 2, a proposal support DB 3, and a user terminal 4 are connected to be communicable via a network. The proposal support system 1 according to the present embodiment is an information system that supports product / service proposals at automobile dealerships.

  The proposal support server 2 is a server device that receives various requests from the user terminal 4 to be described later and executes processing in response to the received requests. In the present embodiment, the proposal support server 2 is a computer in which a CPU, a memory, an input / output device, a recording device, and the like are connected by a bus. The proposal support server 2 is a known computer that can be used for server purposes. be able to.

  In addition, the recording device of the proposal support server 2 records a program for executing each process described later. The program is loaded into a memory, and runs as the proposal support server 2 when the CPU executes it. The computer used for the proposal support server 2 may be a known computer as described above, but it is necessary to include a network communication device for communicating with the proposal support DB 3 and the user terminal 4 via the network. .

  The proposal support DB 3 is a database that adds, updates, deletes information necessary for the proposal support system 1 to perform processing. As the database, a well-known relational database management system (RDBMS) may be used, or another database system may be used. Furthermore, a known data store means other than the database may be used.

  The user terminal 4 communicates with the proposal support server 2 via the network, causes the proposal support server 2 to execute various processes according to operations from the user, or receives the results of the processes executed by the proposal support server 2. It is a computer that displays. As a hardware configuration, a well-known computer in which a CPU, a memory, an input / output device, a recording device, and the like are connected by a bus as in the proposal support server 2 may be used. Although it is necessary to have an input device and a display device, it is necessary to have a network communication device in order to perform network communication with the proposal support server 2. The recording device of the user terminal 4 stores a program for executing each process described later. The program is loaded into the memory and is executed as the user terminal 4 by being executed by the CPU. The user terminal 4 may be a well-known desktop computer or a portable terminal such as a smartphone or a tablet PC.

  The proposal support system 1 of the present embodiment includes the proposal support server 2 and the user terminal 4 as described above, and is an information system called a so-called server / client model. The user terminal 4 is a client in the server / client model, that is, a computer in charge of requesting processing to the server. is there. Further, the proposal support system 1 may be configured as a so-called rich client method in which the user terminal 4 executes a dedicated program and directly processes values acquired from the proposal support server 2 or the proposal support DB 3, and is well known. Like the WEB application, the user terminal 4 may execute a request for processing and display of the processing result by a program such as a WEB browser, and a so-called thin client method in which the actual processing is executed by the proposal support server 2.

  The proposal support system 1 according to the present embodiment is an information system based on a server / client model including the proposal support server 2 and the user terminal 4 as described above, but the proposal support method according to the present invention is a stand-alone configuration with a single computer. It may be executed by. In addition, the proposal support DB 3 of the present embodiment has a hardware configuration independent of the proposal support server 2. However, the proposal support server 2 may also serve as a hardware configuration, and conversely, the proposal support server 2 and the proposal support DB 3. The load may be distributed to a plurality of computers. Further, for example, a part of the proposal support DB may use a part of another information system, and further, when using a part of the other information system as a part of the proposal support DB, the proposal support server It is good also as a structure which 2 does not access this directly but accesses via the front-end server in the said other information system.

  FIG. 2 is an ER diagram (entity relationship diagram) showing a logical configuration of main entities and their main items in the proposal support DB 3. The proposal support system 1 of the present embodiment is an information system that supports proposal activities for products and services in an automobile dealer, and the proposal support DB 3 is also configured based on the business of the automobile dealer. In FIG. 2, (pk) indicates a primary key, that is, an item that identifies an entity, and (fk) indicates an external key, that is, an item that identifies another entity referenced by the item.

  The employee entity E101 is an entity representing a user who uses the proposal support system 1, such as an employee of an automobile dealer.

  A customer entity E201 is an entity that represents a customer of an automobile dealer, and is an entity that includes customer personal information as an item. The owned vehicle entity E301 is an entity that represents a vehicle owned by a customer, and includes various items related to the individual vehicle such as travel distance, purchase date, and first year registration date. The possessed vehicle option entity E302 linked to the possessed vehicle entity E301 in a one-to-many relationship includes various information related to individual optional products added to the owned vehicle, such as manufacturer options and dealer options, such as serial numbers of products, It is an entity that represents the purchase date. The possessed vehicle entity E301 does not include information on the vehicle type itself as an item, and the information is managed by a vehicle type entity E401 described later, and is referred to by the vehicle type ID of the owned vehicle entity E301. Similarly, information on the option product itself is not provided as an item in the possessed vehicle option entity E402, and the vehicle type option entity E402 described later is referred to by the vehicle type option ID.

  The vehicle type entity E401 and the vehicle type option entity E402 are entities representing vehicle types and optional products handled by the automobile dealer. As described above, the owned vehicle entity E301 and the owned vehicle option entity E302 are configured to refer to information on the owned vehicle and the optional product itself by the vehicle type ID and the vehicle type option ID. That is, the owned vehicle entity E301 can be used as a so-called intersection entity that associates the customer entity E201 and the vehicle type entity E401, and similarly, the owned vehicle option entity E302 is an intersection entity that associates the owned vehicle entity E201 and the vehicle type option entity E402. Can be used.

  The proposal content entity E501 is an entity representing the content of the proposal to the customer. The proposal support system 1 according to the present embodiment is an information system that supports product / service proposals at an automobile dealer, and the content of the proposal is set in advance according to the model of the vehicle owned by the customer. In this embodiment, the proposal content entity E501 and the vehicle type entity E401 are associated with each other by a vehicle type-proposed content entity E502 that is an intersection entity in order to represent which proposal content relates to which vehicle type.

  The proposal index entity E503 is an entity that represents an index for analyzing a proposal history entity E506, which will be described later, and extracting candidates for a proposal to be performed next time. The proposal index entity E503 includes items of a proposal content ID, a proposal success / failure, and a next proposal content ID as primary keys, and the proposal content ID and the next proposal content ID refer to the proposal content ID that is the primary key of the proposal content entity E501. It is an item to be. The proposal success / failure item is an item indicating success or failure of the proposal content indicated by the proposal content ID.

In addition, as items for storing the history analysis results, there are provided success and failure results of the next proposal, and related accuracy calculated from these items. In the present embodiment, the related accuracy is the success rate of the next proposal calculated from the results of the proposal history entity E506 described later.

  The proposal candidate entity E504 is an entity that represents candidates for the next proposal that the user makes to the customer based on the proposal index entity E503 described above. The proposal candidate entity E504 includes a proposal history ID, a proposal content ID, an employee ID, and a possessed vehicle ID as external key items. E301 is associated with the proposal content entity E501 (the association with the employee entity E101, the customer entity E201, and the owned vehicle entity E301 is not shown). Further, the proposal candidate entity E504 includes a priority order and a selection type as items. In this embodiment, a proposal entity E505 and a proposal history entity E506, which will be described later, are provided as proposal-related entities in addition to the proposal candidate entity E504. For example, these entities E504 to E506 are set as one entity, and It is also possible to determine which state the entity represents by providing items indicating different states of proposal candidates, proposals, and proposal histories as items.

  The proposal entity E505 is an entity that represents a proposal that the user will make to the customer. The proposal entity E505 includes an employee ID, a customer ID, a possessed vehicle ID, a proposal content ID, and a proposal candidate ID as external key items. The employee entity E101, the customer entity E201, the possessed vehicle entity E301, and the proposal content entity are provided according to the ID items. E501 is associated with the candidate entity E504 (the association with the employee entity E101, the customer entity E201, and the owned vehicle entity E301 is not shown).

  The proposal history entity E506 is an entity representing the contents and results of a proposal that has already been made. As with the proposed entity E505, the employee key, employee ID, owned vehicle ID, proposed content ID, proposed candidate ID are provided as external key items, and the employee entity E101, customer entity E201, owned vehicle entity E301, proposed content entity E501, proposed candidate. It is associated with entity E504 (association with employee entity E101, customer entity E201, and owned vehicle entity E301 is not shown). The proposal history entity E506 is an entity that represents a proposal that has already been made, whereas the proposal entity E505 is an entity that represents a proposal to be made in the future, and includes a proposal result (success / failure) and a proposal execution date as items. The proposal result (success / failure) is an item indicating that the proposal indicated by the entity has succeeded or failed.

  The ER diagram shown in FIG. 2 is a diagram showing the main logical configuration of the proposal support DB 3 in this embodiment, but the database configuration can be changed as appropriate depending on the characteristics of the database used, the configuration of the existing system, and the like. Good. For example, the entities E101 to E506 are roughly classified as follows: an entity relating to an employee (E101), an entity relating to a customer (E201), an entity relating to a owned vehicle (E301, E302), an entity relating to a vehicle type (E401, E402), an entity relating to a proposal 5) is configured in one proposal support DB 3, but a separate database may be configured for each entity type to configure an information system including a plurality of database groups. Also, the ER diagram shown in FIG. 2 shows the logical configuration of the proposal support DB 3, and the physical configuration does not have to match this. For example, the items shown as external keys in FIG. Does not require foreign key constraints in physical design.

  FIG. 3 is a flowchart showing the flow of processing in the proposal support system 1 of the present embodiment from when the user registers the result of the proposal to selecting and registering an arbitrary proposal from the next proposal candidate. As shown in FIG. 1, when the user operates the user terminal 4 and inputs the content and result proposed by the proposal history input unit S <b> 101 to the user terminal 4, the proposed content and result are transmitted to the proposal support server 2. . As described above, the proposal history entity E506 in the proposal support DB 3 of this embodiment includes an employee ID for identifying a user, a customer ID for identifying a customer who has made a proposal, and a owned vehicle ID for identifying a customer's own vehicle. In the proposal history input means S101, the above information is transmitted in addition to the contents and results of the proposal.

  When the proposal support server 2 receives the transmitted proposal contents, results, and the like, the proposal history registration unit S102 registers the proposal contents and results in the proposal support DB 3 as a proposal history. In the proposal support DB 3, the proposal history is managed as a proposal history entity E506, and the received proposal content and result are recorded as a proposal content ID item and a proposal result (success / failure) item of the proposal history entity E506. The proposal history entity E506 is used when the proposal index entity E503 is created by the proposal history analysis means S106 described later.

When the proposal history is registered in the proposal support DB 3, the proposal support server 2 then extracts from the proposal support DB 3 a candidate for the next proposal of the registered proposal by the proposal candidate extraction unit S 103 and transmits it to the user terminal 4. . As described above, the proposal index entity E503 includes the proposal content ID, the proposal success / failure, and the next proposal content ID as items, and the proposal content ID and the proposal result (success / failure) of the registered proposal history entity E506 are stored in the proposal index entity E503. The next proposal content ID of the proposal index entity E503 searched as a proposal content ID and a proposal success / failure condition is an ID item indicating the proposal content entity E501 that is a candidate for a proposal to be performed next time by the user. The proposal candidate extraction unit S103 generates a proposal candidate entity E504 based on the content of the proposal index entity E503 acquired as a result of the search and registers it in the proposal support DB 3, and then uses the content of the entity E504 as a candidate for the next proposal. 4 to send. Note that the proposal candidate entity E504 is configured to refer to the content of the proposal content entity E501 such as the content of the proposal content entity E501 by an ID item, and the next proposal to be transmitted to the user terminal 4 The candidate is obtained by adding necessary information such as the name and details of the proposal content from the ID item to the content of the proposal candidate entity E504.
There may be a plurality of proposal index entities E503 that match the search conditions, and there may also be a plurality of proposal candidate entities E504 generated and registered from the search results and proposal candidates transmitted to the user terminal 4. In the present embodiment, the display order of the plurality of proposal candidates that may exist is determined based on the related accuracy of the proposal index entity E504. The related accuracy, which is an item of the proposal index entity E503, is the success rate of the next proposal calculated from the past history. In this embodiment, the proposal candidate entities E504 are ordered so that the success rate is displayed in descending order. The ordering is recorded as a priority item of the proposal candidate entity E504.

  Upon receiving the transmitted next proposal candidate, the user terminal 4 displays it on the display device of the user terminal 4 by the proposal candidate display means S104. As described above, the proposal candidates are ordered according to the priority order of the proposal candidate entities E504 recorded based on the related accuracy of the proposal index entity E503, that is, the past success rate of the proposal contents. A list of proposal candidates is displayed in descending order of the rate. In the present embodiment, the related accuracy is used as information for determining the display order in the proposal candidate means S104. However, this may be used as a search condition in the proposal candidate extraction means S103. For example, an arbitrary threshold value may be set in advance, and only those exceeding the threshold value may be searched as proposal candidates.

  Proposal candidates displayed as a list on the display device are selected as a proposal for executing next one or two or more proposal candidates by the next proposal selecting means S105 of the user terminal 4 or rejecting all proposal candidates. The contents of the selection are transmitted to the proposal support server 2. In this embodiment, the user inputs the next proposal date at the time of the selection, and other information such as the next proposal date, the content of the selection, and an employee ID necessary for execution of the next proposal registration means S106 described later. Sent with.

When the proposal support server 2 receives the transmitted information, the proposal support server 2 executes next proposal registration means S106. If one or more proposal candidates are selected as the next proposal as the contents of the selection, the next proposal registration unit S106 generates a proposal entity E505 based on the selected candidate, and stores it in the proposal support DB 3. sign up. The registered proposal entity E505 can be used as a target for schedule management or ToDo management in performing a proposal activity.
In this embodiment, the proposal candidate entity E504 is registered in the proposal candidate extraction unit S103, and the proposal entity E505 is generated based on the proposal candidate entity E504. At this time, the proposal candidate ID of the original proposal candidate entity E504 is recorded in the proposal candidate ID of the proposal entity E505.
The next proposal registration means S106 registers the user's selection contents in the proposal support DB 3 based on the received information. Specifically, the contents of the proposal candidate entity E505 are updated, and whether or not the proposal candidates are adopted as the next proposal contents by the user in the selection type that is an item of the proposal candidate entity E505, or a list is displayed. If you reject all candidates, record that fact. In this embodiment, it is possible to make a proposal with a high success rate based on the past history by selecting the content of the next proposal from the candidates for the next proposal presented above. By sequentially selecting candidates for the next proposal presented by this embodiment, the frequency and quantity of proposals can be improved based on the past history. Here, if all candidates listed above are rejected, proposal activities that are not based on the past history will be performed thereafter, so the frequency and quantity of the proposals will decrease, resulting in the success rate of the proposals. It can be predicted that results such as sales will decline. In the present embodiment, by recording whether or not all proposal candidates have been adopted or rejected in the next proposal registration means S106, the influence that the proposal activity not based on the past history specifically has on the result of the proposal. It is possible to accumulate information for investigating, predicting, etc. In this embodiment, since the proposal candidate entity E504 is registered in the proposal candidate extraction unit S103 as described above, the next proposal registration unit S106 only updates the above items, but the next proposal registration unit S106 proposes the proposal. Candidate entity E504 may be registered.

  The above is the flow of processing from the proposal history registration to the next proposal registration in the present embodiment, and the processing is performed by online processing. In addition to this, in the present embodiment, the proposal support server 2 executes the proposal history analysis unit S107 as a batch process every predetermined period.

The proposal history analysis unit S107 analyzes the proposal history and creates an index used by the proposal candidate extraction unit S103. As described above, the proposal history entity E506 of the proposal support DB 3 includes, as items, a customer ID, a proposal ID, and a proposal implementation date. The proposal made for a certain customer and the next time the proposal is made. The proposal is represented by a proposal history entity E506 having the same customer ID as the one proposal history entity E506 and having the latest proposal implementation date after the proposal implementation date of the proposal history entity E506. . Similarly, other proposals made simultaneously with a certain proposal are represented by two or more proposal history entities E506 having the same customer ID and proposal implementation date. The proposal history analysis means S107 creates a proposal index entity E503 having the above-mentioned success record as the above relationship, and records it in the proposal support DB 3. Also, the proposal index entity E503 has a success record, a failure record, and a related accuracy as items, and the proposal history analysis unit S107 proposes for each proposal index entity E503 a proposal history entity E506 corresponding to a combination of proposals represented by the entity. The value of the item is generated from the proposed result (success / failure). As described above, the value of the related accuracy item in the present embodiment is a success rate, and a value obtained by dividing the value of the success record by the total number of histories corresponding to the combination is stored.

  The proposal index entity E503, which is the index of the next proposal candidate, is generated from the past proposal history accumulated in the proposal support DB 3 by the proposal history analysis means S107, and the proposal candidate extraction means S103 uses this index to determine the next proposal candidate. Extract. With this configuration, since a successful proposal in the past proposal history is extracted as a proposal candidate, it is possible to present a proposal with a high probability of success as a candidate.

  Although description of this embodiment is above, embodiment of this invention is not restricted to this. For example, as described above, the present embodiment is configured as an information system based on a server / client model, but may be a stand-alone configuration based on a single computer. The configuration of the proposal support DB 3 may be changed as appropriate, and the logical configuration of the present embodiment may be normalized or denormalized.

  Other specific configurations are not limited to the above-described embodiment, and various modifications can be made without departing from the spirit of the present invention.

1 Proposal Support System 2 Proposal Support Server 3 Proposal Support DB
4 User terminals

Claims (9)

A proposal support method for presenting a user with candidate content to be proposed to a customer using a computer,
The computer is
Proposal history registration means for registering the content and result of the proposal made by the user to the customer as a proposal history in a database;
Analyzing the proposal history, creating an index for extracting candidate candidates to be performed next time of the proposal, and recording the proposal history analysis means in the database;
Based on the registered proposal history and the index, proposal candidate extraction means for extracting candidates for a proposal to be performed next time;
Proposal candidate display means for displaying a list of the extracted proposal candidates on a display device;
A next proposal registration means for registering in the database as a proposal to be performed next time, the proposal candidate selected by the user from the displayed proposal candidates;
A suggestion support method characterized by comprising:   The proposal support method according to claim 1, wherein the proposal history analysis unit creates an index for extracting the proposal made next time and having a successful record.   3. The proposal support method according to claim 2, wherein the proposal history analysis means further creates an index for extracting the proposals made at the same time as the proposal and having a successful record. . The proposal support according to any one of claims 1 to 3, wherein the next proposal registration means further registers the contents of selection by the user in the database for each of the displayed proposal candidates. Method. The content of the selection indicates that the proposal candidate has been adopted as a next proposal, that it has not been adopted as a next proposal, or that all the suggested proposals displayed in the list have been rejected. The proposal support method according to claim 4.   The proposal support method according to claim 1, wherein the proposal history analysis unit is executed as a batch process for each predetermined period. A proposal support system for executing the proposal support method according to any one of claims 1 to 6 by a proposal support server and a user terminal,
The proposal support server executes the proposal history registration means, the proposal history analysis means, the proposal candidate extraction means, and the next proposal registration means;
The proposal support system, wherein the user terminal executes the proposal candidate display means.   A program for operating a computer as a proposal support server according to claim 7. The program which operates a computer as a user terminal of Claim 7.