The present application claims priority from Japanese application serial no. JP2013-110485, filed on May 27, 2013, the content of which is hereby incorporated by reference into this application.
The present invention relates to a technology for the allocation of an appropriate service provider in the provision of various services from an organization to a user (for example, from a company to a consumer).
Currently, when companies or other organizations provide their services to users, a service provider who is the person in charge is allocated to each user. For example, in an insurance company, a service provider such as a salesperson is allocated to a subscriber (or prospective customer) to provide consultation on payment, update, subscription, and the like. There are many service providers and their abilities, or in particular, specialties vary as well. Further, there are many users with different needs, and in addition, the needs often vary over time. In this case, the problem is that which of the service providers should be allocated.
By way of background of the art, there is U.S. Pat. No. 8,126,135. In this publication, it is described that: “At least one service providing route is established for each service resource. A service router can receive multiple service provision requests through multiple communication channels. Each service provision request is analyzed based on the feature value of the service provision request. The feature value of the service provision request is compared with the routing rule. Each service provision request is automatically transferred to the selected service resource, at least partially based on the comparison result. The value of the routing rule is dynamically changed based on feedback.”
In U.S. Pat. No. 8,126,135, the ability score of each service provider (service resource) is calculated, and each time a service provision request arrives, the service provider with the highest ability score is allocated to the particular provision request. However, there is a problem that if no service provider with high ability score is left unallocated, it is difficult to allocate a person with high ability upon request for an important service provision request (in the case where the customer is an important one, or other cases).
In order to solve the above problem, according to the present invention, the allocation process of a service provider to a target case, which is performed for each case unit, is performed by calculating the grace period for extending the allocation process, and by controlling the allocation to cases including the target case, according to the state relating to the other case allocation while reflecting the service request level including the compatibility between the other service providers and the user in the particular grace period.
Further, in the control of the allocation, the allocation process is performed (a) by placing the allocation of the target case in a suspended state when a case with a higher service request level than the target case continues in the grace period, (b) by performing the allocation process, including the target case, when it is detected that the case with a higher service request level than the target case does not continue in the grace period, and (c) when any of the cases reaches the allocation due time.
As a more specific configuration of the present invention, for example, the configuration described in the claims is adopted. The present application includes multiple sections that solve the above problem. To cite an example, there is “a system service provider allocation system including:
According to the present invention, it is possible to allocate a service provider to a user who receives service provision more appropriately.
Hereinafter, an embodiment of the present invention will be described with reference to the accompanying drawings. In the embodiment, the sales activities in the life insurance sector will be described as an example. However, the present invention is also applicable to other services.
Many of the sales activities in the life insurance sector are “hard sell”. In other words, this is a method that sales staff or sales representatives, called life-insurance ladies, approach customers to make insurance sales, instead of selling insurance products after a customer refers to the life insurance company. The present embodiment assumes a scenario that the life insurance company detects the life events of the customer to make a “business chance”. For example, it is assumed that the life insurance company has information on the family structure of the customer, and understands that the child of the customer will enter elementary school next April. This is a “business chance” from the point of view that it can lead to an educational insurance proposal. As another example, it is assumed that the life insurance company can detect that the salary of the customer would be reduced from next April due to the poor business performance of the company at which the customer works. The life insurance company assumes a risk that the customer may cancel the insurance to move to an inexpensive insurance company soon. Thus, the life insurance company proposes the customer to review the insurance ahead of this risk, thereby allowing the customer to continue to use the company's own service. This is also a “business chance”, although not having a positive meaning.
As described above, when the salesperson launches sales activities to the customer, the life insurance company understands the situation of the customer in advance. In the above example, “the child will enter elementary school next April” and “there is high possibility that the salary of the customer would be reduced from next April” are the situation of the customer. When the need to launch sales activities occurs due to the understanding of such a situation, each of the sales activities will be hereinafter referred to as a “case”. In the life insurance company, a case occurs from time to time and, in general, multiple cases exist in parallel. The problem for the life insurance company is to who is allocated to each case from a limited number of salespersons.
As shown in
The lower part of
The following describes the concept of the sales staff allocation which is performed as described above. In
Given this perspective, it is rational to monitor whether the case 406 is not completed, without allocating any salesperson to the case 404 as long as it does not reach the allocation due time. The monitoring period corresponds to the period 408. The same concept can be applied to the case 405. The service request level of the case 405 is the third highest of the four cases. However, if there is a completion report of the case 406, it is possible to have the salesperson A with the second highest ability score. Further, if the case 404 is also completed, it is possible to have the salesperson C with the highest ability score. Thus, it is rational to monitor whether the case 406 or 404 is not completed, without allocating any salesperson as long as the particular case does not reach the allocation due time. The monitoring period corresponds to the period 409. The case 404 continues to be monitored during the period 408 and the case 405 continues to be monitored during the period 409. As a result, the case 406 reaches the allocation grace start time 413. At this time, the case 406 is the case with the highest service request level, so that it is possible to have the salesperson C with the highest ability score. Further, the case 407 does not reach the allocation grace start time at this time. However, the service request level of the case 407 is the lowest of the other cases, so that the allocation result of the salesperson to the cases 404 and 405 is not affected by the case 407. Thus, the case 404 with the second highest service request level can have the salesperson A with the second highest ability score. The case 405 with the third highest service request level can have the salesperson B with the third highest ability score. In other words, the batch allocation is performed at the time 411 to allocate the salespersons A, B, C to the cases 404, 405, and 406, respectively. At the time when the case 407 finally reaches the allocation grace start time 415, there is no other case present (unless a new case occurs halfway through), so that the real time allocation is performed. At this time, only the salesperson D is unallocated. Thus, the salesperson D is allocated to the case 407.
In the example of
Note that when the process 504 or 505 is performed, the allocation calculation function 601 sorts the values of the “service request level” and the total ability scores (described below) of the unallocated sales staff, in descending order, to match each of the values from the largest value to the smallest value (namely, in the sorted order). The allocation calculation function 601 obtains the value of the “service request level” of the case from a case management table 701. In other words, the allocation calculation function 601 extracts the “sales staff ID” with the “status” unallocated in the service provider management table 900, and extracts the ability score (described below) of the particular “sales staff ID” from the service provider management table 900. Then, the allocation calculation function 601 extracts the “compatibility point” by substituting the information of the “customer ID” and the “sales staff ID” into a compatibility table 802. Then, the allocation calculation function 601 adds the ability score and the “compatibility point” to obtain the total score of the “sales staff ID”. Note that, for example, if the “case type” of the case is a medical insurance proposal, the ability score corresponds to the value of the “medical insurance knowledge level” of the service provider management table 900.
The case management table 701 includes the following data items. That is, “case ID” that identifies the case, “case type” that identifies the type of case such as insurance reconsideration proposal, death insurance proposal, medial insurance proposal, or educational insurance proposal, “customer ID” that identifies the customer, “service request level” that is converted into a number, “sales staff ID” that identifies the salesperson, “current allocation state” for determining whether each case is currently in the allocation grace period or in the non-allocation period, “next allocation grace start time”, “next allocation due time”, “nearest neighbor allocation due time?” for determining whether the case is the one to which the nearest neighbor allocation due time is given, “affiliation set” for giving a set to which each case belongs, and “degree of progress (%)” representing the progress in each case (0% for immediately after starting, 100% for completion). These data items are determined by the following mechanism. The “case ID” is set by a service provision request receiving device 615 with a number greater than the ID of the last case by one after receiving the case. The “case type” is set by the service provision request receiving device 615 with one of the case types in the period definition table 705, which is the closest to the case content.
The “customer ID” is set by the service provision request receiving device 615 with the “customer ID” corresponding to the “name” of the customer management table 800 by extracting the customer name from the case content. The “service request level” is set by the service provision request receiving device 615 with a value obtained by extracting the “case type” of the case management table 701, the “degree of difficulty” of the difficulty definition table 702, the “customer ID” of the case management table 701, and the “customer rank” of the customer management table 800, and by substituting the “degree of difficulty” and the “customer rank” into the service request level definition table 704. With respect to the “sales staff ID”, the allocation calculation function process 601 sets a combination of the “case ID” and the “sales staff ID”, which is the result of the batch allocation of the process 504 or 505, to the case management table 701. The “current allocation state”, the “next allocation grace start time”, the “next allocation due time”, the “nearest neighbor allocation due time”, the “affiliation set”, and the “degree of progress” are set by a case information editing function 1006, described below, with values.
The difficulty definition table 702 includes the following data items. That is, “case type” described in the case management table 701, and “degree of difficulty” showing the difficulty in completing each case type.
The service request level definition table 704 includes “degree of difficulty”, “customer rank”, and “service request level” that is determined by the two items. The meanings of the former two items are the same as the “degree of difficulty” of the difficulty definition table 702 and the “customer rank” of the customer management table 800.
The period definition table 705 includes the following data items. That is, “case type” described in the difficulty definition table 702, “standard allocation grace period” which is the parameter required for the determination of the allocation grace period shown in
Non-Allocation Period=Standard Non-Allocation Period*(1−Degree of Progress/100) (Equation 1)
Allocation Grace Period=Non-Allocation Period*(Standard Allocation Grace Period/Standard Non-Allocation Period) (Equation 2)
The “degree of progress” is the same as the “degree of progress” of the case management table 701. However, the above equations are examples for calculating the allocation grace period and the non-allocation period, and other formulas may be used.
The customer management table 800 includes the following data items. That is, “customer ID” that identifies the customer, “name” indicating the name of the customer, “customer rank” indicating that the larger the number the more important the customer, and “negotiation ID” that identifies all the past sales activities (negotiation history) that have been performed by each salesperson to the same customer. The “customer ID” is set by the service provision request receiving device 615 with a new number when the customer name is not found in the customer management table 800. The value of the “customer rank” is set by either of the following two methods. The system administrator manually sets a value, or the customer management device automatically sets a value that is proportional to the sales contribution from the particular customer (which is calculated based on the “sales results” of the negotiation history table 801). The “negotiation ID” is set by the allocation calculation function 601 with a new value each time a salesperson is allocated to each case. Note that only the “name” is included in the customer management table 800 as the information indicating the customer attribute. However, other attributes such as address, telephone number, and age may be included in the table, or may be managed in another table.
The negotiation history table 801 includes the following data items. That is, “negotiation ID” described in the customer management table 800, “sales staff ID” that identifies the salesperson, “negotiation date” that indicates the date and time when the negotiation occurs, “sales results” that indicates the business outcomes (results) obtained through the particular negotiation, and “feedback point” which is the evaluation point of the salesperson. The determination method of the “negotiation ID” is the same as that described in the customer management table 800. The “sales staff ID” is set by the allocation calculation function 601 with the value of the “sales staff ID” of the case management table 701. The value of the “sales results” is set by the salesperson with the result value. The value of the “feedback point” is set by either of the following two methods. The particular salesperson inputs the evaluation results obtained from the customer (for example, asked to “continuously provide advice on other insurance products” by the customer, etc.), or the other salesperson inputs the results of the questionnaire conducted on the customer (the degree of customer satisfaction, etc.).
The compatibility table 802 includes the following data items. That is, “customer ID” described in the customer management table 800, “sales staff ID” described in the negotiation history table 801, and “compatibility point” that indicates the height of the compatibility between the customer and the salesperson. The “customer ID” is set by the service provision request receiving device 615 with the same value as the customer management table 800. The “sales staff ID” is set by the allocation calculation function 601 with the “sales staff ID” allocated to the case. As shown in the figure, when multiple salespersons have handled a particular customer in the past, multiple values of the “sales staff ID” correspond to the value of the same “customer ID”. The “compatibility point” is set by the customer management device 609 with a weighted sum of the total value of the “sales results” and the total value of the “feedback point” in the negotiation history table 801. In other words, the customer management device 609 extracts the “negotiation ID” list from the customer management table 800 with the value of the “customer ID” as the key, and extracts the values of the “sales results” and the “feedback point” from the negotiation history table 801 with the “negotiation ID” and the “sales staff ID” as the key. Then, the customer management device 609 counts the “sales results” and the “feedback point” with respect to one pair of the “customer ID” and the “sales staff ID”. Note that the weighted value is set by the system administrator to the customer management device 609 in advance.
The service provider management table 900 includes the following data items. That is, “sales staff ID” that identifies the salesperson, “status” indicating whether the particular salesperson has been allocated to a certain case, “service years” indicating the number of years the salesperson has worked, “available languages” which is the list of languages the salesperson can speak, “death insurance knowledge level” indicating how much the salesperson knows about death insurance products, “medical insurance knowledge level” indicating how much the salesperson knows about medial insurance products, and other multiple parameter items indicating the ability score of each salesperson. The “sales staff ID” is set by the system administrator with a new number each time a new salesperson joins the company. The “status” is set by the allocation execution device 600 with a value “allocated” after the allocation is performed, and set by the allocation management device 608 with a value “unallocated” immediately after the completion of the case. With respect to the “service years”, the service provider management device 607 automatically updates the value from the employment continuously. The “death insurance knowledge level”, the “medial insurance knowledge level”, and the parameter group indicating the knowledge level of the other insurance products are set and updated by the system administrator based on the result such as an internal test.
The control unit 1001 includes the following functions. That is, an allocation execution instruction function 1010 that instructs the allocation calculation function 601 to start allocation execution calculation, a case management table management function 1014 for managing the case management table 701 stored in a case management table storage part 1008, and a case parameter management function 1012 for managing the case parameters stored in a case parameter storage part 1009.
The storage unit 1002 includes the following functions. That is, the case management table storage part 1008 for storing the case management table 701, and the case parameter storage part 1009 for storing the case parameters.
The case management table management function 1014 includes the following functions. That is, as described below, a nearest neighbor end time determination function 1004 for determining whether the nearest neighbor end time matches the current time, a case information editing function 1006 for editing all data items of the case management table 701, and a process flow condition determination function 1005 for determining the conditional branch 503 and the conditional branch 504.
The details of each function will be described below. Note that each function is realized by a program, which is read by each device realized as a computer, and according to which information processing is performed.
The nearest neighbor end time determination function 1004 includes a small storage area 1015 for storing the nearest neighbor end time, and a timer 1016 for storing and updating the current time in real-time. The nearest neighbor end time shows the time closest to the current time, of the end time of the allocation grace period in the case present in the phase thereof and the end time of the non-allocation period in the case present in the phase thereof, with respect to all cases. The nearest neighbor end time determination function 1004 obtains the current time from the timer 1016, and the nearest neighbor end time from the small storage area 1015. Then, the nearest neighbor end time determination function 1004 determines whether the two values match in the control unit 1001 sequentially in real-time. The nearest neighbor end time determination function 1004 does not perform if the two values do not match. When the two values match, the nearest neighbor end time determination function 1004 activates the case information editing function 1006.
The case information editing function 1006 is the function that accesses the case management table storage part 1008 to edit all data items of the case management table 701. Further, this function has a GUI function for the service provider 604 to edit the case management table 701. The case information editing function 1006 updates the information of all the cases, when receiving a new case from the service provision request receiving function 615 (case addition), or receiving a case completion notification from the service provider 604 (case deletion), or receiving a start notification from the nearest neighbor end time determination function 1004 (arrival the nearest neighbor end time determination time), or when the service provider 604 edits a part of the case management table 701. Then, the case information editing function 1006 passes all information of the cases belonging to L(t) of the case management table 701 to the process flow condition determination function 1005. After that, the case information editing function 1006 updates the value of the nearest neighbor end time of the small storage area 1015.
The process flow condition determination function 1005 is the function that determines the conditional branch 502 and the conditional branch 103 shown in
The case parameter management function 1012 is the function that accesses the case parameter storage part 1009 to edit the difficulty definition table 702, or the service request level definition table 704, or the period definition table 705. Further this function has a GUI function for the service provider 604 to edit these tables.
Number | Date | Country | Kind |
---|---|---|---|
2013-110485 | May 2013 | JP | national |