Patent ID: 12192410

DETAILED DESCRIPTION

In the following detailed description, reference is made to the accompanying drawings which depict non-limiting, illustrative embodiments of the present disclosure. Other embodiments may be utilized and logical variations, e.g., structural and/or mechanical, may be implemented without departing from the scope of the present disclosure. To avoid unnecessary detail, certain information, items, or details known to those skilled in the art may be omitted from the following.

Contact routing at an inbound contact center can be structured in numerous ways. An individual employed by the contact center to interact with callers is referred to in the present disclosure as an “agent.” Contact routing can be structured to connect callers to agents that have been idle for the longest period of time. In the case of an inbound caller where only one agent may be available, that agent is generally selected for the caller without further analysis. In another example of routing an inbound call, if there are eight agents at a contact center, and seven are occupied with callers, the switch will generally route the inbound caller to the one agent that is available. If all eight agents are occupied with contacts, the switch will typically put the caller on hold and then route the caller to the next agent that becomes available. More generally, the contact center will set up a queue of inbound callers and preferentially route the longest-waiting callers to the agents that become available over time. A pattern of routing callers to either the first available agent or the longest-waiting agent is sometimes referred to as “round-robin” caller routing.

In general, when a caller is placed in a call queue, the caller's queue position is dependent upon the receipt time of the call at the vendor location. No consideration is given to the identity of the caller or the potential value of the call. While this is a democratic way to handle inbound calls, it may not be good for business. For instance, a large number of low business value calls may be in a queue when a high business value call is received. As a result, the high business value call is subjected to a long wait while the low business value calls are answered—with attendant dissatisfaction on the part of the high business value caller. When call centers have an inadequate number of skilled agents to handle all callers, such as at times of peak call volume, challenges of effectively handling high-value callers can be especially severe. The method and system of the present disclosure are intended to alleviate these problems.

Call center operations include various types of call queues. For example, an inbound caller may be put on hold and placed on an answering queue or hold list, to be routed to a live agent when the caller has moved up to the first position in the call queue. In another example, if call centers are unable to route inbound callers to a live agent within a reasonable period of time, an inbound caller may be placed on a call back list, to receive a call back from a live agent when the caller has moved up to the first position on the call back list. In some embodiments, an inbound caller is assigned to one of a plurality of call queues (e.g., two queues) respectively associated with a plurality of pools of agents. In an illustrative embodiment, a first inbound caller is assigned to a first call queue to be routed to live agent in a first pool of agents who are skilled in sales and who are authorized to close a sale with the first caller, while a second inbound caller is assigned to a second call queue to be routed to live agent in a second pool of agents who are unskilled in sales and who are not authorized to close a sale with the second caller. As used in the present application, a “call queue assignment” means assignment of an inbound call from an identified customer to a call queue for connection to a call center agent. In various embodiments, the call queue assignment may include a given queue position and/or may include assignment to a call queue selected from a plurality of call queues.

Methods and systems described herein can automatically assign an inbound call from a customer to a call queue assignment based on predicted value of the inbound telephone call. The present system and method identifies an inbound caller with data from an internal customer database of an enterprise, e.g., sponsoring organization or client of the contact center. Upon identifying the customer, the process retrieves customer demographic data associated with the identified customer. The method selects a selected predictive model from a plurality of predictive models based upon enterprise customer data stored by the customer database for the identified customer. The selected predictive model determines a value prediction signal for the identified customer. Based on the value prediction signal determined, the predictive model classifies the identified customer into one of a first value group and a second value group. When the predictive model classifies the identified customer into the first value group, the call management system assigns the call received from identified customer to a first call queue assignment. When the predictive model classifies the identified customer to the second value group, the call management system assigns the call received from the identified customer to a second call queue assignment.

In an embodiment, the first value group comprises customers having a first set of modeled values, and the second value group comprises customers having a second set of modeled values, wherein modeled values in the first set of modeled values are higher than modeled values in the second set of modeled values. In an embodiment, the modeled values are modeled lifetime values. In an embodiment, when the predictive model classifies the identified customer into the first value group having higher modeled values, the call management system assigns the identified customer to a priority queue assignment; when the predictive model classifies the identified customer into the second value group having lower modeled values the call management system assigns the identified customer to a subordinate queue assignment. As used in the present disclosure, a priority queue assignment and subordinate queue assignment are relative terms, in which a priority queue assignment is more favorable than a subordinate queue assignment. In an embodiment, a priority queue assignment is a more advanced position within a given call queue than a subordinate queue assignment. In another embodiment, a priority queue assignment is an assignment to a more favorable call queue among a plurality of call queues (e.g., a queue for live connection to an agent from a pool of skilled agents) than a subordinate queue assignment (e.g., a queue for live connection to an agent from a pool of unskilled agents).

In other embodiments disclosed herein, an inbound caller is routed to one of a plurality of groups of call center agents (e.g., two groups), respectively associated with a plurality of call queues. Each group of agents is assigned to implement one or more predetermined function or goal of the call center; in the present disclosure a given goal or function of the call center is called a “customer care interaction.” Customer care interactions may be broad in scope, such as generating customer leads, closing sales of products of a sponsoring enterprise of the call center, and customer service interactions with existing customers or purchasers (individuals who previously purchased a product of the sponsoring enterprise). Customer care interactions also can be more specific in scope, such as promoting a given product as part of a marketing campaign. The systems and methods of the present disclosure improve the routing of inbound calls of identified customers to groups of agents that handle customer care interactions appropriate to the callers.

Embodiments described herein can automatically assign an inbound call from a customer to a call queue position for connection to one of a plurality of groups of call center agents, wherein the call queue position is based on predicted value of the inbound telephone call. Upon receiving an inbound call, a call management system retrieves a set of enterprise customer data associated with an identified customer from a customer database. The system retrieves customer demographic data associated with the identified customer. In an embodiment, the system selects a group of agents from a plurality of groups of agents of the call center, wherein the selected group of agents implements a predetermined customer care interaction of the call center. The group of agents is selected based upon consistency of the predetermined customer care interaction with the set of enterprise customer data for the identified customer.

The customer database tracks individuals who are customers of a sponsoring organization or client of the call center, or other enterprise served by the call center, associating these individuals with one or more groups representing general types of customers. In an embodiment, these customer groups include prospects, leads, new business, and purchasers (also herein called sales). The customer database joins these four groups to better evaluate marketing activities and customer service activities of the call center. Data from the customer database is used in building stronger predictive models used for routing inbound calls; in the present disclosure, customer database data is sometimes called “enterprise customer data,” denoting data relating to customers of the sponsoring enterprise. Enterprise customer data retrieved for an identified customer is used in selecting a suitable predictive model from a plurality of predictive models, based upon consistency of the selected predictive model as a modeling target with the set of enterprise customer data for the identified customer. Enterprise customer data is associated with one or more enterprise customer record identifying a given customer tracked by the customer data. Enterprise customer data includes data identified with one or more customer groups (also herein called customer event data), activity event data, and attributions data, among other types of data.

Methods and systems described herein can employ a pre-sale predictive model relating to offer for sale of one or more product offered or supplied by a sponsoring organization of an inbound contact center. In various embodiments, the products offered or supplied by a sponsoring organization require payments by the customer for a period following closing the sale, such as premiums to maintain in force an insurance policy or other financial product, or installment plans for product purchase. In various embodiments, the pre-sale predictive model incorporates information on a minimum period of time of customer payments required to achieve a beneficial transaction for the sponsoring organization, wherein failure of the customer to make payments over at least this minimum time period is sometimes referred to herein as “lapse.” The presale predictive model forecasts customer behavior to improve the probability of closing a sale of an offered product to an inbound customer, and to reduce the probability that the customer will lapse in payment for the purchased product.

The predictive model can classify inbound callers into two or more groups. In an embodiment, two value groups are modeled to model higher predicted value and lower predicted value, respectively, to the sponsoring organization. In various embodiments, this classification governs value-based routing of inbound telephone calls for response by agents to allocate limited resources of the inbound contact center. An individual employed by the contact center to interact with callers is referred to herein as an “agent.”

The inbound contact center is sometimes called simply a contact center or a call center. The individuals that interact with the contact center using a telecommunication device are referred to herein as callers, and alternatively are referred to as inbound callers, as customers, or as any of the general types of customer. As used in the present disclosure, a “customer” may be an existing customer or a prospective customer of the sponsoring organization, including any of the general groups of customer tracked in the customer database. In an embodiment, a customer is associated with the one or more of the groups: prospects, leads, new business, and sales (also herein called purchasers). A given individual may be associated with multiple such groups over different stages of customer acquisition. For example, a purchaser may have previously been one or more of a prospect, a lead, or a new business applicant.

In an embodiment of the customer groups in the customer database, “prospects” are individuals that have contacted the enterprise. Inbound prospects may or may not be customers in the customer databases. In an embodiment, if an inbound caller is not identified with an individual in the customer database, the database opens a new record for that caller in the prospects group. “Leads” are individuals who have expressed interest in one or more products of the enterprise; as used herein, products may include goods or services sold by the enterprise, or a combination of these. A lead may have previously been a prospect, or may not have been a prospect (e.g., an individual that searches for products or services of the enterprise online). “New Business” (also herein called new business applicants) identifies applicants to purchase one or more product of the enterprise, where such purchase requires underwriting. These applicants may have been prospects, leads, or both. “Purchasers” (also herein called “sales”) generally are individuals that own a product of the enterprise. Purchasers may have been prospects, leads, new business applicants, or any combination of these groups.

Methods and systems described herein can employ a predictive model relating to offering for sale one or more products offered or supplied by a sponsoring organization of an inbound contact center. In various embodiments, the products offered or supplied by a sponsoring organization require payments by the customer for a period following closing the sale, such as premiums to maintain in force an insurance policy or other financial product, or installment plans for product purchase. A pre-sale prediction model can incorporate information on a minimum period of time of customer payments required to achieve a beneficial transaction for the sponsoring organization and uses this information in determining conditions for “lapse.” The pre-sale predictive model forecasts customer behavior to improve the probability of closing a sale of an offered product to an inbound customer, and to reduce the probability that the customer will lapse in payment for the purchased product.

The predictive model can classify inbound callers into two or more value groups. In an embodiment, two value groups are modeled to model higher predicted value and lower predicted value, respectively, to the sponsoring organization. In various embodiments, this classification governs value-based routing of inbound telephone calls for response by agents, to allocate limited resources of the inbound contact center. An individual employed by the contact center to interact with callers is sometimes referred to herein as an “agent.”

A key metric for value-based classification of a customer who has purchased a product is called a “lifetime value” of the product sale to that customer. In various embodiments, lifetime value includes the sum of all associated costs over product lifetime, netted against revenue for the product sale. The lifetime value for the product (insurance policy) sold to that customer is the net value of all premiums paid, over the sum of all such associated costs during that policy life.

In an illustrative embodiment involving sale of an insurance policy, associated costs over product lifetime include various sales acquisition costs, including marketing costs distributed across inbound calls, cost of operating the inbound contact center distributed across inbound calls, and commission at the time of sale. In this example, additional associated costs include cost of providing the insurance policy, and claims or death benefit. In various embodiments, total costs for a customer are modeled based on the customer's age, gender, policy face amount, and whether the policy is lapsed, and by applying formulas based on amortization of total marketing costs and operations costs. In an illustrative embodiment involving sale of an insurance policy, total revenue for a customer is modeled based on the customer's age, gender, policy face amount, and whether the policy is lapsed (if so, when). The model calculates expected total premium payments based on age and gender via lookup of mortality statistics.

Methods and systems described herein can identify lapse (e.g., for a given product or class of products) with a pre-determined period of time following sale of the product and define lapse as failure of the customer to make payments for the product over at least this period of time. In various embodiments, this predetermined period of time is based upon modeling a minimum period of time for achieving a positive lifetime value for the product sale. This model compares total payments received with associated costs over different product lifetimes to determine the predetermined period. In one embodiment, product lifetime represents a period of time over in which the customer has continued to make purchase payments for the product, such as premiums or installment payments. In another embodiment, lifetime value is measured during the full term or life of an insurance policy or other financial instrument until all claims and death benefits have been paid, even if all premiums or other customer payments had been paid prior to this time.

FIG.1shows a system architecture for a customer management system100, according to an illustrative embodiment. In the present disclosure, the customer management system100is sometimes called an inbound call center or inbound contact center, referring to its primary function of receiving inbound customer calls. Customer management system100includes an inbound queue management system102, also called an inbound call management system. Inbound queue management system102manages assignment of inbound telephone calls for response by agents to multiple queues (e.g., two queues) based on predicted value of the inbound telephone call. Inbound queue management system102includes an analytical engine104containing a call evaluation sub-module108, and a predictive modeling module110including a regression model114and a tree-based model118.

Inbound call management system102is interfaced with one or more internal databases120of the inbound contact center, such as call history database124and account information database128. In an embodiment, analytical engine104interacts with external services, applications, and databases, such as third party databases130, through one or more application programmable interfaces, an RSS feed, or some other structured format, via communication network135. In the embodiment ofFIG.1, inbound queue management system102retrieves data from one or more third party databases130, including a consumer demographic database132and a directory service database134.

Predictive modeling module110builds one or more models that model behaviors of customers such as likelihood that a caller will purchase a product offered by the call center, and likelihood that the caller will lapse in payments for a purchased product. The predictive modeling module analyzes each inbound customer call using data associated with a customer identifier for the inbound caller. This customer identifier may be obtained from various sources by the call evaluation sub-module108. Input data used in predictive modeling includes data retrieved from one or more of internal databases120, and third party databases130. This input data also may include data derived from the retrieved data that has been transformed by analytical engine104in order to facilitate predictive modeling, as described herein.

Databases120are organized collections of data, stored in non-transitory machine-readable storage. In an embodiment, the databases may execute or may be managed by database management systems (DBMS), which may be computer software applications that interact with users, other applications, and the database itself, to capture (e.g., store data, update data) and analyze data (e.g., query data, execute data analysis algorithms). In some cases, the DBMS may execute or facilitate the definition, creation, querying, updating, and/or administration of databases. The databases may conform to a well-known structural representational model, such as relational databases, object-oriented databases, and network databases. Database management systems may include MySQL, PostgreSQL, SQLite, Microsoft SQL Server, Microsoft Access, Oracle, SAP, dBASE, FoxPro, IBM DB2, LibreOffice Base, or FileMaker Pro.

Analytical engine104can be executed by a server, one or more server computers, authorized client computing devices, smartphones, desktop computers, laptop computers, tablet computers, PDAs and other types of processor-controlled devices that receive, process, and/or transmit digital data. Analytical engine104can be implemented using a single-processor system including one processor, or a multi-processor system including any number of suitable processors that may be employed to provide for parallel and/or sequential execution of one or more portions of the techniques described herein. Analytical engine104performs these operations as a result of central processing unit executing software instructions contained within a computer-readable medium, such as within memory. In one embodiment, the software instructions of the system are read into memory associated with the analytical engine104from another memory location, such as from a storage device or from another computing device via communication interface. In this embodiment, the software instructions contained within memory instruct the analytical engine104to perform processes described below. Alternatively, hardwired circuitry may be used in place of or in combination with software instructions to implement the processes described herein. Thus, implementations described herein are not limited to any specific combinations of hardware circuitry and software.

Predictive modeling module110generates a value prediction signal representative of one or more of the following customer behaviors: (a) likelihood that the customer will accept an offer to purchase a product, (b) likelihood that the customer will lapse in payments for a purchased product, and (c) likelihood that the customer will accept an offer to purchase the product and will not lapse in payments for the purchased product. In certain embodiments, the predictive modeling module can predict more than one of these customer behaviors. For example, the predictive model may first determine the customer behavior (a) likelihood that the customer will accept an offer to purchase a product, followed by determining the customer behavior (b) likelihood that the customer will lapse in payments for a purchased product, in order to determine a value prediction signal. Based on this value prediction signal, the analytical module, in conjunction with the predictive modeling module, classifies each customer call into one of two, or more, value groups. Depending on the value group determined for each customer call, analytical engine104directs routing of the customer call to one of two or more answering queues150to await connection to an agent of the call center. InFIG.1, two call queues154and158are shown. Value-based classification of inbound calls by inbound call management system102represents a significant improvement over traditional methods of routing callers, such as “round-robin” caller routing.

Inbound call management system102interfaces with an inbound telephone call receiving system140. In customer management system100, inbound call management system102and call receiving system140may be integrated in a single computing platform. Alternatively these systems may be based on separate computing platforms. In certain embodiments, the computing platform(s) are interfaced with computer-telephone integration (“CTI”) middleware. In an embodiment, inbound telephone call receiving system140includes a telephony device that accepts inbound telephone calls through a telephony interface141, such as conventional T1 or fiber interfaces. Inbound telephone call receiving system140accepts inbound telephone calls through interface141and obtains caller information associated with the inbound calls, such as Automatic Number Identification (“ANI”) and Dialed Number Identification Service (“DNIS”) information145. ANI is a signaling system feature in which a series of digits, either analog or digital, are included in the call identifying the source telephone number of the calling device. DNIS is a telephone function that sends the dialed telephone number to an answering service. The DNIS need not be a telephone number associated with any physical location.

Inbound telephone call receiving system140may include an Automatic Call Distributor (“ACD”) system142; a Voice Response Unit (“VRU”) system144; a private branch exchange (“PBX”) switch146; a Voice over Internet Protocol (“VOIP”) server148; or any combination of such devices. In an embodiment, intrasite telephony access within the call center may be managed by a private branch exchange (PBX) switch146. In an embodiment, PBX switch146operates in coordination with ACD142to distribute inbound calls customer service stations locally networked call center agents, such agents in first pool160and second pool170. In further embodiments, inbound inquiries may include e-mail or instant messages that provide inquiry information based on login ID, e-mail address, IP, or instant message address. In such an embodiment, the call center can gather additional information by an automated e-mail or instant message survey response, which can be used to request various types of customer identifier data.

An identified customer can be an inbound caller for which the customer management system100has obtained reliable identifying data. This data is used by inbound queue management system102to retrieve or identify data associated with that customer. In an embodiment, an identified customer is a customer for which the system100has reliably identified at least two of name, address, and zip code. In an embodiment, Voice Response Unit (“VRU”) system144collects customer identifier data, such as name, address, and zip code, through automated interaction with the customer. In the present disclosure, this VRU data collection is sometimes called a telegreeter. For instance, VRU144may query an inbound caller to collect customer identifier information when ANI is not operative, e.g., when caller-ID is blocked. In an embodiment, inbound call management system102communicates with a third party directory service134. Directory service134can provide additional caller identification information, such as name and address information, for inbound callers that are initially identified only by a telephone number. For an inbound caller that is a new lead of the enterprise, this additional caller identification information can be stored in Account Info database128as profile data for that lead.

Inbound telephone calls received through interface141are distributed to answering queues150for response by agents operating telephony devices. In the embodiment ofFIG.1, answering queues150include a first call queue154for response by one of the agents in a first pool160of call center agents, and a second call queue158for response by one of the agents in a second pool of agents170. AlthoughFIG.1depicts an embodiment of the present invention that orders inbound telephone calls, alternative embodiments apply inbound queue management to schedule other types of inbound inquiries, such as e-mail or instant message inquiries. In an embodiment, call center agents in agent pools160and170are groups of customer service representatives or agents deployed at workstations or agent devices communicatively coupled to call management system100.

The agents are associated with a sponsoring organization that sells or supplies products with the assistance of the call center. In an embodiment, the organization generates sales of one or more product through advertisements that give a phone number to prospective customers, and the prospective customers call into the call center using this phone number. In various embodiments, the agents in first pool160are authorized to offer an advertised product to a prospective customer (inbound caller), while the agents in second pool170are not authorized to offer the advertised product. In the present disclosure, for an agent to be authorized to offer a product to a prospective customer or lead means that the agent is authorized to pursue a sale of the product to the lead.

A sponsoring organization for customer management system100is an insurance company or other financial services company, and the agents may include insurance agents. In some cases, an insurance agent may be associated with only a single insurance provider (sometimes referred to as a “captive” insurance agent). In other cases, an “independent” insurance agent may be associated with several different insurance providers. In an embodiment, the agents in the first pool160are licensed to sell insurance. In some cases, the producers may be licensed to sell different types of insurance products, might have different areas of expertise, needs, etc. In some embodiments, agents in the first pool160are selected for performance metrics related to sales. Agent sales performance may be measured by aggregate sales productivity metrics, as well as distributed performance metrics such as sales metrics by product types, etc.

While the agents in second pool170are not authorized to offer the product(s) to the inbound caller (prospective customer or lead), these agents perform an important role in lead nurturing. Forwarding an inbound inquiry to a live agent with little or no wait time, sometimes referred to herein as a “warm transfer,” has been observed to significantly increase probability of a successful sale to that customer in a later interaction. In some embodiments, agents in the second pool170are selected for skills related to agent-customer communications, which can be measured in indicators of customer satisfaction such as feedback on customer experiences.

FIG.2is a flowchart of a call management process200for automatically routing an inbound call from a customer to one of a plurality of call queue assignments based on predicted value of the inbound telephone call. The method retrieves from a customer database a set of enterprise customer data associated with an identified customer in a customer call. The customer database stores enterprise customer data associated with prospects, leads, and purchasers of an enterprise. In certain embodiments, the customer database also stores enterprise customer data associated with new business applicants of the customer enterprise. The process then retrieves customer demographic data associated with the identified customer.

The method200selects a predictive model from a plurality of predictive model, by selecting a predictive model for which the set of enterprise customer data has the highest expected impact on likelihood of a respective business outcome associated with that predictive model. The selected predictive model, including a logistic regression model operating in conjunction with a tree-based model, determines a value prediction signal for the identified customer. Based on the value prediction signal determined, the predictive model classifies the identified customer into one of a first value group and a second value group. When the predictive model classifies the identified customer into the first value group, the call management system routes the call received from identified customer to a first call queue assignment, i.e., first queue position and/or first call queue. When the predictive model classifies the identified customer into the second value group, the call management system routes the call received from identified customer to a second call queue assignment, i.e., second queue position and/or second call queue.

The steps of process200may be performed by one or more computing devices or processors in the customer management system ofFIG.1. In an embodiment, the plurality of steps included in process200may be performed by an inbound queue management system102of a customer management system100of a call center, in operative communication with an inbound call receiving system140that receives a customer call of the identified customer.

The call management process200is initiated at step202in response to the customer management system100receiving an incoming customer call, by retrieving from a customer database enterprise customer data associated with an identified customer in the customer call. The customer database stores enterprise customer data associated with prospects, leads, and purchasers of an enterprise. In various embodiments, the enterprise customer data used in selecting the selected predictive model comprises one or more of customer event data, activity event data, and attributions data. In certain embodiments, the customer database also stores enterprise customer data associated with new business applicants of the enterprise.

At step204, the call management process retrieves customer demographic data associated with the identified customer. In an embodiment, the process retrieves the customer demographic data from a third party database. In an embodiment, the third party customer demographic data is associated with identified customer by matching the data to one or more enterprise customer identifier stored by the customer database. In an embodiment, the call management process builds a simplified data file from the set of enterprise customer data and the retrieved third party demographic data as input to further steps of the process.

At step206, the call management process selects a predictive model from a plurality of predictive models stored by the customer management system. Each of the plurality of predictive model is configured to predict likelihood of a respective business outcome comprising one or more of likelihood and accepting an offer to purchase a product, likelihood of not lapsing in payments for a purchased product, and likelihood of accepting an offer to purchase a product and not lapsing in payments for the purchased products. Step206selects the one of the plurality of predictive models for which the set of enterprise customer data has the highest expected impact on likelihood of the respective business outcome. In an embodiment, the predictive model is selected based on highest expected likelihood of achieving one or more business outcome associated with that predictive model. In various embodiments of step206, the predictive model is selected based upon enterprise customer data for the inbound caller including one or more of customer event data, activity event data, and attributions data.

In an embodiment of step206, the respective business outcome comprises one or more of the following general buy/lapse behaviors: accepting an offer to purchase a product, not lapsing in payments for a purchased product, and accepting an offer to purchase a product and not lapsing in payments for the purchased products. In an embodiment, the respective business outcome comprises a more specific business outcome, such as a business outcome representing an instance of one of these general buy/lapses behaviors. In an illustrative embodiment, the respective business outcome is likelihood of purchase of a given product of the enterprise. In another illustrative embodiment, the respective business outcome is likelihood of lapse, targeted to new business applicants of the enterprise.

In an embodiment of step206, the respective business outcome of the selected business model targets one or more of the prospects, leads, and purchasers of the enterprise, and the enterprise customer data comprises customer event data associated with the one or more prospects, leads, and/or purchasers of the enterprise targeted by the respective business outcome. In an example, based on enterprise customer data associated with a prospect, step206selects a predictive model targeted at prospects in which the respective business outcome includes likelihood of generating customer leads. In another example, based upon enterprise customer data associated with a purchaser, step206selects a predictive model targeted at purchasers for which the respective business outcome includes likelihood of cross selling an additional product to the purchaser.

In another embodiment of step206, the set of enterprise customer data includes activity event data, and the predictive model is selected based upon the one of the plurality of predictive models for which the activity event data has the highest expected impact on the likelihood of the respective business outcome. In an example, the predictive model is selected based on enterprise customer data for a sale of an insurance product, including activity event data indicating failure to pay first year premiums. The selected predictive model models the likelihood that the identified customer will lapse in payments for a purchased product.

At step208, the call management process executes the selected predictive model to determine a value prediction signal. In an embodiment, the selected predictive model applies a logistic regression model in conjunction with a tree-based model to the set of the enterprise customer data and the retrieved customer demographic data. In an embodiment, the call management process executes the selected predictive model to determine the value prediction signal in real time. By determining the value prediction signal in real time, the present method automatically routes incoming customer calls to a call queue assignment expeditiously.

In various embodiments of step208, the value prediction signal includes one or more of a first signal representative of a likelihood that the identified customer will accept an offer to purchase a product, a second signal representative of a likelihood that the identified customer will lapse in payments for a purchased product, and a third signal representative of a likelihood that the identified customer will accept an offer to purchase the product and will not lapse in payments for the purchased product.

In various embodiments of step208, the value prediction signal determines a likelihood that the identified customer will lapse in payments for a purchased product by determining a likelihood that the identified customer will fail to make a payment for the purchased product during a predetermined time period following purchase of the purchased product. In an embodiment, the predetermined time period was previously determined by modeling lifetime value over varying durations of the time period following purchase of the purchased product.

In various embodiments of step208, the regression model employs l1regularization. In various embodiments, the logistic regression model employs l2regularization. In various embodiments, the tree-based model is a random forests ensemble learning method for classification.

At step210, the call management process classifies the customer call for the identified customer into either a first value group or a second value group, based on the value prediction signal determined at step208. In an embodiment of step210, the first value group includes customers having a first set of modeled lifetime values, and the second value group includes customers having a second set of modeled lifetime values. The modeled lifetime values in the first set of modeled lifetime values are higher than modeled lifetime values in the second set of modeled lifetime values.

When step210classifies the identified customer into the first value group, at step212the call management process routes the identified customer to a first call queue assignment. When step210classifies the identified customer into the second value group, at step214the call management process routes the identified customer to a second call queue assignment.

In various embodiments of steps212and214, the first call queue assignment comprises a first queue position in a call queue, and the second call queue assignment comprises a second queue position in a call queue. In one embodiment, the call queue is a hold list for callers on hold. In another embodiment, the call queue is a call back queue.

In another embodiment of steps212and214, the first call queue assignment is a first call queue for connection to an agent from a first pool of call center agents. The second call queue assignment is a second call queue for connection to an agent from a second pool of call center agents.

In various embodiments, the agents to which customers are routed at steps212and214are associated with a sponsoring organization that sells or supplies products with the assistance of the call center. In an embodiment, the organization generates sales of one or more product through advertisements that give a phone number to potential or prospective customers, and the potential customers call into the call center using this phone number. In embodiments of step210in which the first value group includes customers having modeled lifetime values that are higher than modeled lifetime values of customers in the second value group, steps212and214prioritize call center resources to pursue sale of offered product(s) to the higher-value group of customers.

In certain embodiments of steps210,212, and214, in which calls received from an identified customer are routed to one of a first call queue and a second call queue, the routing process can permit adjustments to take into account matching of call center resources (agents) to customers at a given time, herein referred to as resource matching adjustments. As seen in the schematic diagram of a customer queue arrangement300atFIG.3, first call queue302consists of a queue of length M (last queue position306), to be connected to agents310in a first pool of agents who are authorized to present an offer to purchase the product. Second call queue304consists of a queue of length N (last queue position308), to be connected to agents312in a second pool of agents who are not authorized to present an offer to purchase the product.

In various embodiments, resource matching adjustments can including adjustments to the binary classification model that classifies customers into first and second value groups. For example, if there are a disproportionately high number of agents in the first pool310compared to the second pool312, the threshold for the first value group can be reduced to permit routing of additional customers to the first pool of agents. In another example, if there are a disproportionately low number of agents in the first pool310compared to the second pool312, the threshold for the first value group can be raised to permit routing of fewer customers to the first pool of agents.

In various embodiments, resource matching adjustments can include adjustments to the first queue of customers and second queue of customers. Such adjustments may take into account the total population of customers awaiting connection to call center agents, i.e., the customers in both queues302and304at a given time. At certain times there may be an unusual distribution of customers between the first and second queues, e.g., a disproportionately high number of customers in the first queue (M is unusually high relative to N) or a disproportionately low number of customers in the first queue (M is unusually low relative to N). To address these unusual distributions, one or more customer may be shifted from the first queue302to the second queue304, or one or more customer may be shifted from the second queue304to the first queue302.

Both types of resource matching adjustment, i.e., adjustment of the classification model, and direct adjustment of the call queues, may be combined.

FIG.4shows a system architecture for a customer management system400of a contact center, also herein called a call center, according to an illustrative embodiment. In the present disclosure, the call center is sometimes called an inbound call center or inbound contact center, referring to its primary function of receiving inbound customer calls. However, it should be understood that communications of the inbound call center on occasion may include outbound calls, or call backs, in response to inbound customer calls. Customer management system400includes an inbound queue management system402, also called an inbound call management system. Inbound queue management system402manages assignment of inbound telephone calls for response by agents based on predicted value of the inbound telephone call. Inbound queue management system402includes an analytical engine404containing a call evaluation sub-module408, and a predictive modeling module410including first and second regression models412and416, and first and second tree-based models414and418.

Inbound call management system402is interfaced with one or more enterprise databases420, which are internal databases of the inbound contact center. Internal databases include customer database422, which tracks individuals who are customers of the sponsoring organization of the call center or other client enterprise. Other internal databases include call history database424and account information database426. In an embodiment, analytical engine404interacts with external services, applications, and databases, such as third party databases430, through one or more application programmable interfaces, an RSS feed, or some other structured format, via communication network435. In the embodiment ofFIG.4, inbound queue management system402retrieves data from one or more third party databases430, including a consumer demographic database432, and a directory service database434.

Predictive modeling module410includes two or more models that model behaviors of customers such as likelihood that a caller will purchase a product offered by the call center, and likelihood that the caller will lapse in payments for a purchased product. The predictive modeling module analyzes each inbound customer call using data associated with a customer identifier for the inbound caller. This customer identifier may be obtained from various sources by the call evaluation sub-module408, including enterprise customer data retrieved from customer database422. Input data used in predictive modeling includes data retrieved from customer database422and may include data from other internal databases420. Additionally, input data used in predictive modeling includes data from third party databases430. This input data also may include data derived from the retrieved data that has been transformed by analytical engine404in order to facilitate predictive modeling, as described herein.

In the system and method of the present disclosure, for each identified customer predictive modeling module410selects among two or more predictive models by selecting a predictive model for which a set of enterprise customer data for the identified customer has the highest expected impact on likelihood of a respective business outcome associated with that predictive model. In an embodiment, each of the plurality of predictive models is configured to determine a business outcome signal representative of one of more of likelihood of accepting an offer to purchase a product, and the selected predictive model is the one of the plurality of predictive models for which the set of enterprise customer data has a highest importance in determining the respective business outcome signal. In an embodiment, analytical engine404analyzes the set of enterprise customer data retrieved and selects either a first predictive model that includes regression model #1412and tree-based model #1414(collectively called predictive model #1), or a second predictive model that includes regression model #2416and tree-based model #2418(collectively called predictive model #2). In other embodiments, predictive modeling module410can include more than two predictive models, and analytical engine404can select combinations of component models (e.g., regression model and tree-based model) other than predetermined pairings of these component models. The selection of predictive models based upon consistency of the selected predictive model as a modeling target with a set of enterprise customer data retrieved for an identified customer improves reliability of value-based classification of identified customer for call routing. In addition, predictive modeling module410may build stronger predictive models using enterprise customer data of the sponsoring organization.

In an embodiment, predictive model #1412and414is configured to determine a first business outcome signal representative of the likelihood of a first business outcome, and predictive model #2416and418is configured to determine a first business outcome signal representative of the likelihood of a second business outcome. In various embodiments, each of the first business outcome and the second business outcome comprises one or more of accepting an offer to purchase a product, not lapsing in payments for a purchased product, and accepting an offer to purchase a product and not lapsing in payments for the purchased products. The analytical engine404retrieves a set of enterprise customer data associated with an identified customer, and selects either predictive model #1 or predictive model #2 to generate a value prediction signal for the identified customer. In an embodiment, analytical engine404selects the predictive model for which the set of enterprise customer data has the higher importance in determining the respective business outcome signal.

In an embodiment, analytical engine404includes logic for selecting a predictive model from a plurality of predictive models for which a set of enterprise customer data retrieved for an identified customer has the highest importance in determining the respective business outcome. In an embodiment, analytical engine404stores lookup tables each of the predictive models within predictive modeling module410with table entries for various enterprise customer data, wherein each table entry includes an expected impact on business value. In an embodiment, analytical engine404applies business logic to forecasting expected impact on business value for given categories of enterprise customer data, and for weighing two or more enterprise customer data as components of overall importance in determining expected impact on likelihood of the respective business outcome. In an embodiment, analytical engine404adjusts the weight of two or more enterprise customer data as components of overall importance in determining expected impact on likelihood of the respective business outcome, depending on circumstances of the call center management system400. For example, in the context of a call center campaign focused on one or more types of customer (prospect, lead, purchaser, new business applicant), analytical engine404may place greater importance on customer event data and attributions data than on activity event data in determining the respective business outcome.

Predictive modeling module410generates a value prediction signal representative of one or more of the following customer behaviors: (a) likelihood that the customer will accept an offer to purchase a product, (b) likelihood that the customer will lapse in payments for a purchased product, and (c) likelihood that the customer will accept an offer to purchase the product and will not lapse in payments for the purchased product. In certain embodiments, the predictive modeling module can predict more than one of these customer behaviors. For example, the predictive model may first determine the customer behavior (a) likelihood that the customer will accept an offer to purchase a product, followed by determining the customer behavior (b) likelihood that the customer will lapse in payments for a purchased product, in order to determine a value prediction signal. Based on this value prediction signal, the analytical module, in conjunction with the predictive modeling module, classifies each customer call into one of two, or more, value groups. Depending on the value group determined for each customer call, analytical engine404directs routing of the customer call to call queue routing module450to await connection to an agent of the call center. Call queue routing module450assigns each inbound caller to one of two or more call assignments based on the value prediction signal for that caller; inFIG.4, two call queue assignments—first call queue assignment460and second call queue assignment470—are shown. Value-based classification of inbound calls by inbound call management system402represents a significant improvement over traditional methods of routing callers, such as “round-robin” caller routing.

Inbound call management system402interfaces with an inbound telephone call receiving system440. In customer management system400, inbound call management system402and call receiving system440may be integrated in a single computing platform. Alternatively, these systems may be based on separate computing platforms. In certain embodiments, the computing platform(s) are interfaced with computer-telephone integration (“CTI”) middleware. In an embodiment, inbound telephone call receiving system440includes a telephony device that accepts inbound telephone calls through a telephony interface441, such as conventional T1 or fiber interfaces. Inbound telephone call receiving system440accepts inbound telephone calls through interface441and obtains caller information associated with the inbound calls, such as Automatic Number Identification (“ANI”) and Dialed Number Identification Service (“DNIS”) information445. Reference may be had to the description of inbound telephone call receiving system140(FIG.1), for a description of corresponding components of inbound telephone call receiving system440. These components include Automatic Number Identification (“ANI”)441; Dialed Number Identification Service (“DNIS”) information445; Automatic Call Distributor (“ACD”) system442; Voice Response Unit (“VRU”) system444; private branch exchange (“PBX”) switch446; Voice over Internet Protocol (“VOIP”) server448; and combinations of such devices.

An identified customer can be an inbound caller for which the customer management system400has obtained reliable identifying data, including enterprise customer data retrieved from customer database422. This data can be used by inbound queue management system402to retrieve or identify additional data associated with that customer. In an embodiment, an identified customer is a customer for which the system400has reliably identified at least one customer group associated with the customer in customer database422, and at least two of name, address, and zip code. In embodiments in which the customer has been associated over time with two or more customer groups, customer identifying data may include attributions (also herein called attributions data) retrieved by customer database422, as further described below.

In an embodiment, inbound call management system402communicates with a third party directory service434such as the WhitePages® online directory service, as described above for inbound telephone call receiving system140. For an inbound caller that is a new prospect of the enterprise, this additional caller identification information can be stored in customer database422as profile data for that prospect.

Inbound telephone calls received through interface441are distributed to call queue(s) routing module450for response by agents operating telephony devices. In the inbound telephone call receiving system540of customer management system500shown inFIG.5, answering queues550control routing of inbound callers on hold to live agents. Answering queues module550includes a first call queue (hold list)554and a second call queue (hold list)558. First call queue (hold list)554routes calls on hold for response by one of the agents in a first pool560of call center agents, while second call queue (hold list)558routes calls on hold for response by one of the agents in a second pool570of call center agents. In an embodiment, call center agents in agent pools560and570are groups of customer service representatives or agents deployed at workstations or agent devices communicatively coupled to customer management system500.

In the inbound telephone call receiving system640of customer management system600shown inFIG.6, call back queue routing module650controls call backs to customers by agents of the call center. Call back queue routing module650includes a call back queue654for controlling call back to the customer by a live agent. Call back queue routing module650assigns different customers to different call back queue positions, such as first queue position660and second queue position670. AlthoughFIGS.5and6depict embodiments of the present invention that order inbound telephone calls, alternative embodiments apply inbound queue management to schedule other types of inbound inquiries, such as e-mail or instant message inquiries.

In an embodiment, agents are associated with a sponsoring organization that sells or supplies products with the assistance of the call center. In an embodiment, the organization generates sales of one or more product through advertisements that give a phone number to prospective customers, and the prospective customers call into the call center using this phone number. In an embodiment of the answering queues system shown inFIG.5, the agents in first pool560are authorized to offer an advertised product to a prospective customer (inbound caller), while the agents in second pool570are not authorized to offer the advertised product. In the present disclosure, for an agent to be authorized to offer a product to a prospective customer or lead means that the agent is authorized to pursue a sale of the product to the lead. In this embodiment, placing an inbound caller in the first call queue554may be considered a priority queue assignment, while placing the inbound caller in the second call queue558may be considered a subordinate queue assignment.

In an embodiment, a sponsoring organization for customer management system400is an insurance company or other financial services company, and the agents may include insurance agents. In some cases, an insurance agent may be associated with only a single insurance provider (sometimes referred to as a “captive” insurance agent). In other cases, an “independent” insurance agent may be associated with several different insurance providers. In an embodiment of the system500, the agents in the first pool560are licensed to sell insurance. In some cases, the producers may be licensed to sell different types of insurance products, might have different areas of expertise, needs, etc. In some embodiments, agents in the first pool560are selected for performance metrics related to sales. Agent sales performance may be measured by aggregate sales productivity metrics, as well as distributed performance metrics such as sales metrics by product types, etc.

While the agents in second pool570are not authorized to offer the product(s) to the inbound caller (prospective customer or lead), these agents perform an important role in lead nurturing. Forwarding an inbound inquiry to a live agent with little or no wait time, sometimes referred to herein as a “warm transfer,” has been observed to significantly increase probability of a successful sale to that customer in a later interaction. In some embodiments, agents in the second pool570are selected for skills related to agent-customer communications, which can be measured in indicators of customer satisfaction such as feedback on customer experiences.

FIG.7is a flowchart of a call management process700for automatically routing an inbound call from a customer to one of a plurality of queues (e.g., two queues) based on predicted value of the inbound telephone call. Upon identifying the customer, the process retrieves customer demographic data associated with a customer identifier for the identified customer. A predictive model, including a logistic regression model operating in conjunction with a tree-based model, determines a value prediction signal for the identified customer. Based on the value prediction signal determined, the predictive model classifies the identified customer into one of a first value group and a second value group. In the event the predictive model classifies the identified customer into the first value group, the call management system routes the identified customer to a first call queue for connection to one of a first pool of call center agents who are authorized to present the offer to purchase the product. In the event the predictive model classifies the identified customer into the second value group, the call management system routes the identified customer to a second call queue for connection to one of a second pool of call center agents who are not authorized to present the offer to purchase the product.

The plurality of steps included in process700may be performed by one or more computing devices or processors in the customer management system ofFIG.4. In an embodiment, the plurality of steps included in process700may be performed by an inbound queue management system402of a customer management system400of a call center, in operative communication with an inbound call receiving system440that receives a customer call of the identified customer.

The call management process700is initiated at step702in response to the customer management system400receiving an incoming customer call associated with a customer identifier. Customers may dial into the system via a public switched telephone network or via intrasite telephony. Additionally, inbound calls may be transmitted via the Internet using Web-enabled browsers, personal digital assistants or other network-enabled devices; via mobile cellular telephones (not shown), which may be Web-enabled, or connected via a mobile switching center.

In an embodiment, the customer identifier includes two or more of name of the identified customer, address of the identified customer, and zip code of the identified customer. In an embodiment, the customer management system obtains a customer identifier for the received customer call from caller information associated with the inbound calls, such as Automatic Number Identification (“ANI”) and Dialed Number Identification Service (“DNIS”) information. In an embodiment, the customer management system obtains a customer identifier for the received customer call via an automated telegreeter of a Voice Response Unit (“VRU”) system. In an embodiment, the customer management system obtains a customer identifier for the received customer call from a third party directory service.

In an embodiment of step702, the call management process retrieves the third party customer demographic data. In an embodiment, the third party customer demographic data is associated with the customer identifier contained in a third party demographic database. In an embodiment, the call management process builds a simplified data file from the third party demographic data indexed to the customer identifier as input to further steps of the process.

A step704, the call management process determine via a value prediction signal via a predictive model that includes a logistic regression model and a tree-based model. In various embodiments, the value prediction signal includes one or more of a first signal representative of a likelihood that the identified customer will accept an offer to purchase a product, a second signal representative of a likelihood that the identified customer will lapse in payments for a purchased product, and a third signal representative of a likelihood that the identified customer will accept an offer to purchase the product and will not lapse in payments for the purchased product. In various embodiments, the value prediction signal is a buy-only signal, a lapse-only signal, a buy-don't-lapse signal, or a combination of these signals.

In various embodiments of step704, the value prediction signal determines a likelihood that the identified customer will lapse in payments for a purchased product by determining a likelihood that the identified customer will fail to make a payment for the purchased product during a predetermined time period following purchase of the purchased product. In an embodiment, the predetermined time period was previously determined by modeling lifetime value over varying durations of the time period following purchase of the purchased product.

In various embodiments of step704, the regression model employs l1regularization. In various embodiments, the logistic regression model employs l2regularization. In various embodiments, the tree-based model is a random forests ensemble learning method for classification.

In an embodiment, the call management process retrieves customer demographic data from a third party demographic database at step702, and the logistic regression model of step704is trained on a full set of features of the third party demographic database.

At step706, the call management process classifies the customer call (lead) into either a first value group or a second value group, based on the value prediction signal determined at step704. In an embodiment of step706, the first value group includes customers having a first set of modeled lifetime values, and the second value group includes customers having a second set of modeled lifetime values. The modeled lifetime values in the first set of modeled lifetime values are higher than modeled lifetime values in the second set of modeled lifetime values.

In the event step706classifies the identified customer into the first value group, at step708the call management process routes the identified customer to a first call queue for connection to one of a first pool of call center agents who are authorized to present the offer to purchase the product. In the event step706classifies the identified customer into the second value group, at step710the call management process routes the identified customer to a second call queue for connection to one of a second pool of call center agents who are not authorized to present the offer to purchase the product.

In various embodiments, the agents to which customers are routed at steps708,710are associated with a sponsoring organization that sells or supplies products with the assistance of the call center. In an embodiment, the organization generates sales of one or more product through advertisements that give a phone number to potential or prospective customers, and the potential customers call into the call center using this phone number. In embodiments of step706in which the first value group includes leads having modeled lifetime values that are higher than modeled lifetime values of leads in the second value group, steps708and710prioritize call center resources to pursue sale of offered product(s) to the higher-value group of leads.

In certain embodiments of steps706,708, and710, the classification of leads and routing of leads to the first call queue and second call queue, can permit adjustments to take into account matching of call center resources (agents) to leads at a given time, herein referred to as resource matching adjustments. As seen in the schematic diagram of a customer queue arrangement300atFIG.3, first call queue302consists of a queue of length M (last queue position306), to be connected to agents310in a first pool of agents who are authorized to present an offer to purchase the product. Second call queue304consists of a queue of length N (last queue position308), to be connected to agents312in a second pool of agents who are not authorized to present an offer to purchase the product.

In various embodiments, resource matching adjustments can including adjustments to the binary classification model that classifies leads into first and second value groups. For example, if there are a disproportionately high number of agents in the first pool310compared to the second pool312, the threshold for the first value group can be reduced to permit routing of additional leads to the first pool of agents. In another example, if there are a disproportionately low number of agents in the first pool310compared to the second pool312, the threshold for the first value group can be raised to permit routing of fewer leads to the first pool of agents.

In various embodiments, resource matching adjustments can include adjustments to the first queue of leads and second queue of leads. Such adjustments may take into account the total population of leads awaiting connection to call center agents, i.e., the leads in both queues302and304at a given time. At certain times there may be an unusual distribution of leads between the first and second queues, e.g., a disproportionately high number of leads in the first queue (M is unusually high relative to N) or a disproportionately low number of leads in the first queue (M is unusually low relative to N). To address these unusual distributions, one or more customer may be shifted from the first queue302to the second queue304, or one or more customer may be shifted from the second queue304to the first queue302.

Both types of resource matching adjustment, i.e., adjustment of the binary classification model, and direct adjustment of the call queues, may be combined.

FIG.8shows a system architecture for a customer management system800of a contact center, also herein called a call center, according to an illustrative embodiment. In the present disclosure, the call center is sometimes called an inbound call center or inbound contact center, referring to its primary function of receiving inbound customer calls. The components and functions of customer management system800are generally similar to those of customer management system ofFIG.4, and reference should be had to discussion of the system400above for a description of corresponding components and functions. Customer management system800includes an inbound queue management system802, also called an inbound call management system. The inbound queue management system802may be hosted on one or more computers (or servers), and the at least one computer may include or be communicatively coupled to one or more databases. Inbound queue management system802manages assignment of inbound telephone calls for response by agents in a queue position of a call queue for connection to a group of call center agents selected from a plurality of groups of call center agents. The group of call center agents is selected based on enterprise customer data for the caller (identified customer), while the queue position is selected based on predicted value of the inbound telephone call.

Predictive modeling module810models behaviors of customers such as likelihood that a caller will purchase a product offered by the call center and likelihood that the caller will lapse in payments for a purchased product. The predictive modeling module analyzes each inbound customer call using data associated with a customer identifier for the inbound caller. This customer identifier may be obtained from various sources by the call evaluation sub-module808, including enterprise customer data retrieved from customer database822. Input data used in predictive modeling includes data retrieved from customer database822and may include data from other internal databases820. Additionally, input data used in predictive modeling includes data from third-party databases830. This input data also may include data derived from the retrieved data that has been transformed by analytical engine804in order to facilitate predictive modeling, as described herein.

Analytical engine804stores customer care interaction data representing attributes of one or more predetermined customer care interactions implemented by each group of agents within a plurality of groups860and870of call center agents. Attributes of customer care interactions may include, for example, general areas of responsibility, specific areas of responsibility, primary agent skills, secondary agent skills, target customer groups, associated products, associated marketing campaigns, etc. As part of the process for routing a given inbound caller (identified customer) to call center agents, analytical engine804compares the stored customer care data with a set of enterprise customer data retrieved for that customer. Analytical engine804selects one of the plurality of groups of agents860and870based upon consistency of the predetermined customer care interaction for the selected group of agents with the set of enterprise customer data retrieved for the identified customer.

Predictive modeling module810generates a value prediction signal representative of one or more of the following customer behaviors: (a) likelihood that the customer will accept an offer to purchase a product, (b) likelihood that the customer will lapse in payments for a purchased product, and (c) likelihood that the customer will accept an offer to purchase the product and will not lapse in payments for the purchased product. In certain embodiments, the predictive modeling module can predict more than one of these customer behaviors. For example, the predictive model may first determine the customer behavior (a) likelihood that the customer will accept an offer to purchase a product, followed by determining the customer behavior (b) likelihood that the customer will lapse in payments for a purchased product, in order to determine a value prediction signal. Based on this value prediction signal, the analytical module, in conjunction with the predictive modeling module, classifies each customer call into one of two, or more, value groups.

Depending on the group of agents selected and the value group determined for each customer call, analytical engine804directs routing of the customer call to answering queues module850to await connection to an agent of the call center. Answering queues module850includes a component854that routes the inbound call to a call queue for a given group of agents from a plurality of groups of agents, and a component858that assigns the inbound caller to a selected queue position in the selected call queue for live connection to an agent from the given group of agents. InFIG.8, two groups of call center agents with respective call queues—first agent group/call queue860and second agent group/call queue870—are shown. Routing inbound calls based on analysis of customer care interactions and of call value represents a significant improvement over traditional methods of routing callers, such as “round-robin” caller routing.

An identified customer can be an inbound caller for which the customer management system800has obtained reliable identifying data, including enterprise customer data retrieved from customer database822. This data can be used by inbound queue management system802to retrieve or identify additional data associated with that customer. In an embodiment, an identified customer is a customer for which the system800has reliably identified at least one customer group associated with the customer in customer database822, and at least two of name, address, and zip code. In embodiments in which the customer has been associated over time with two or more customer groups, customer identifying data may include attributions (also herein called attributions data) retrieved by customer database822, as further described below.

In an embodiment, a sponsoring organization for customer management system800is an insurance company or other financial services company, and the agents may include insurance agents. In some cases, an insurance agent may be associated with only a single insurance provider (sometimes referred to as a “captive” insurance agent). In other cases, an “independent” insurance agent may be associated with several different insurance providers. In an embodiment of the system800, the agents in the first group860are licensed to sell insurance. In some cases, the producers may be licensed to sell different types of insurance products, might have different areas of expertise, needs, etc. In some embodiments, agents in the first group860are selected for performance metrics related to sales. Agent sales performance may be measured by aggregate sales productivity metrics, as well as distributed performance metrics such as sales metrics by product types, etc.

In an embodiment the agents in the second group870are not authorized to offer the product(s) to the inbound caller (prospective customer or lead), but these agents are authorized to screen leads for prospective customers. Such agents perform an important role in lead nurturing. Forwarding an inbound inquiry to a live agent with little or no wait time, sometimes referred to herein as a “warm transfer,” has been observed to significantly increase probability of a successful sale to that customer in a later interaction. In some embodiments, agents in the second group870are selected for skills related to agent-customer communications, which can be measured in indicators of customer satisfaction such as feedback on customer experiences.

FIG.9is a flowchart of a call management process900for automatically routing an inbound call from an identified customer to a queue position within a call queue to be connected to a one of a plurality of call center agents. The selected group of agents implements a predetermined customer care interaction and is selected based upon consistency of the predetermined customer care interaction with enterprise data pertaining to the identified customer. The inbound call's queue position within the call queue for connection to the selected group of call center agents is based on a predicted value of the inbound telephone call.

The method900retrieves from a customer database a set of enterprise customer data associated with an identified customer in a customer call. The customer database stores enterprise customer data associated with prospects, leads, and purchasers of an enterprise. In certain embodiments, the customer database also stores enterprise customer data associated with new business applicants of the customer enterprise. The method additionally retrieves customer demographic data associated with the identified customer.

The method900selects a group of agents from a plurality of groups of agents of the call center, wherein the selected group of agents implements a predetermined customer care interaction of the call center. The group of agents is selected based upon consistency of the predetermined customer care interaction with the set of enterprise customer data for the identified customer.

A predictive model, including a logistic regression model operating in conjunction with a tree-based model, determines a value prediction signal for the identified customer. Based on the value prediction signal determined, the predictive model classifies the identified customer into one of a first value group, and a second value group. When the predictive model classifies the identified customer into the first value group, the call management system routes the customer call for the identified customer to a first call queue position for connection to an agent from the selected group of agents. When the predictive model classifies the identified customer into the second value group, the call management system routes the customer call for the identified customer to a second call queue position for connection to an agent from the selected group of agents.

The steps of process900may be performed by one or more computing devices or processors in the customer management system ofFIG.8. In an embodiment, the plurality of steps included in process900may be performed by an inbound queue management system802of a customer management system800of a call center, in operative communication with an inbound call-receiving system840that receives a customer call of the identified customer.

The call management process900is initiated at step902in response to the customer management system800receiving an incoming customer call, by retrieving from a customer database enterprise customer data associated with an identified customer in the customer call. The customer database stores enterprise customer data associated with prospects, leads, and purchasers of an enterprise. In various embodiments, the enterprise customer data used in selecting the selected predictive model comprises one or more of customer event data, activity event data, and attributions data. In certain embodiments, the customer database also stores enterprise customer data associated with new business applicants of the enterprise.

At step904, the call management process retrieves customer demographic data associated with the identified customer. In an embodiment, the process retrieves the customer demographic data from a third-party database. In an embodiment, the third-party customer demographic data is associated with identified customer by matching the data to one or more enterprise customer identifiers stored by the customer database. In an embodiment, the call management process builds a simplified data file from the retrieved third-party demographic data as input to further steps of the process.

At step906, the method selects a group of agents from a plurality of groups of agents of the call center, wherein the selected group of agents implements a predetermined customer care interaction of the call center. The group of agents is selected based upon consistency of the predetermined customer care interaction with the set of enterprise customer data retrieved from the customer database at step902.

In an embodiment of step906, a first predictive model from the plurality of predictive models is selected if the enterprise customer data satisfies predetermined model selection criteria, and a second predictive model from the plurality of predictive models is selected if the enterprise customer data does not satisfy the predetermined model selection criteria. In another embodiment of step906, the selected predictive model is selected from three or more predictive models.

In various embodiments of step906, the group of agents is selected based upon enterprise customer data for the inbound caller including one or more of customer event data, activity event data, and attributions data. In an embodiment, the group of agents is selected to increase the likelihood of achieving one or more predetermined customer care interaction based upon consistency with the enterprise customer data for that group of agents.

In an illustrative embodiment of step906, the predetermined customer care interaction is customer development of leads, and the set of enterprise customer data includes customer event data associated with a prospect. In another example, the predetermined customer care interaction is cross-selling of products, and the set of enterprise customer data includes customer event data associated with a purchaser, and activity event data indicating likelihood of an additional purchase. In another example, the predetermined customer care interaction is promoting a given product, and the set of enterprise customer data includes activity event data indicating customer interest in a marketing campaign for the given product. In a further example, the predetermined customer care interaction is closing product sales, and the set of enterprise customer data includes one or more of customer event data associated with a prospect, customer event data associated with a new business applicant, and attributions data associated with a prospect and a new business applicant.

At step908, the call management process executes a predictive model to determine a value prediction signal. In an embodiment, the predictive model applies a logistic regression model in conjunction with a tree-based model to the retrieved customer demographic data. In an embodiment, the call management process executes the predictive model to determine the value prediction signal in real time. By determining the value prediction signal in real time, the present method expeditiously routes an incoming customer call to a call queue for connection to an agent from a selected group of call center agents.

In various embodiments of step908, the value prediction signal includes one or more of a first signal representative of a likelihood that the identified customer will accept an offer to purchase a product, a second signal representative of a likelihood that the identified customer will lapse in payments for a purchased product, and a third signal representative of a likelihood that the identified customer will accept an offer to purchase the product and will not lapse in payments for the purchased product.

In various embodiments of step908, the value prediction signal determines a likelihood that the identified customer will lapse in payments for a purchased product by determining a likelihood that the identified customer will fail to make a payment for the purchased product during a predetermined time period following purchase of the purchased product. In an embodiment, the predetermined time period was previously determined by modeling lifetime value over varying durations of the time period following purchase of the purchased product.

In various embodiments of step908, the regression model employs l1regularization. In various embodiments, the logistic regression model employs l2regularization. In various embodiments, the tree-based model is a random forests ensemble learning method for classification.

At step910, the call management process classifies the customer call for the identified customer into either a first value group or a second value group, based on the value prediction signal determined at step908. In an embodiment of step910, the first value group includes customers having a first set of modeled lifetime values, and the second value group includes customers having a second set of modeled lifetime values. The modeled lifetime values in the first set of modeled lifetime values are higher than modeled lifetime values in the second set of modeled lifetime values.

When step910classifies the identified customer into the first value group, at step912the call management process routes the customer call for the identified customer to a first call queue position for connection to an agent from the selected group of agents. When step910classifies the identified customer into the second value group, at step914the call management process routes the customer call for the identified customer to a second call queue position for connection to an agent from the selected group of agents.

In an embodiment of steps912,914, the call queues are hold lists for callers on hold. In another embodiment, the call queues are call-back queues.

In embodiments of step910in which the first value group includes customers having modeled lifetime values that are higher than modeled lifetime values of customers in the second value group, steps912and914prioritize call center resources to the higher-value group of customers.

As seen in the schematic diagram of a customer queue arrangement300atFIG.3, first call queue302consists of a queue of length M (last queue position306), to be connected to agents310in a first group of agents who are assigned to implement a first predetermined customer care interaction. Second call queue304consists of a queue of length N (last queue position308), to be connected to agents312in a second group of agents who are assigned to implement a second predetermined customer care interaction

In an embodiment, steps912and914provide normal (FIFO) queuing for callers within a given value group, and assign priority queue positions to one value group and subordinate queue positions to another value group. In various embodiments, the first queue position is located behind other callers who were previously assigned a first queue position in that call queue, and the second queue position is located behind the queue position of other callers who were previously assigned a second queue position in that call queue. For example, in first call queue302, if the most recent prior assignment of a first queue position was to queue position M, the current assignment of a first queue position could be to a new queue position M+1 (not shown). If the most recent prior assignment of a second queue position was to queue position3, the current assignment of a second queue position could be to insert the current inbound caller into queue position4, and to adjust the prior caller at queue position4to queue position5, adjust the prior caller at queue position5to queue position6, etc.

In an embodiment of steps912,914, the longest-waiting callers on hold in the subordinate value group may have a more advanced position in the queue than the shortest-waiting callers on hold in the priority value group. In an example of this arrangement, the first queue position is the subordinate queue position and the second queue position is the priority queue position. At step914, the method assigns a second queue position to a current inbound caller that is behind the most recently assigned second queue position, and is behind any callers previously assigned a first queue position who have waited more than a predetermined period of time for connection to an agent.

FIG.10is an architecture of a customer database1000, representing an embodiment of the customer database422ofFIG.4and of the customer database822ofFIG.8. Customer database1000is an internal database of the sponsoring organization of the call center, or other enterprise. Customer database1000stores information on individual customers of the enterprise, associating these customers with one or more of the groups Prospects1002, Leads1004, New Business1006and Purchasers (Sales)1008. In the present disclosure, customer database records that identify individual customers of the enterprise, such as by name and phone number, are sometimes called “enterprise customer records.” Customer database1000includes links between each customer group and each of the other groups. These links between customer groups are sometimes herein called attributions. There are unique keys1012between Purchasers (Sales) and each of the other data stores; a unique key1014between Prospects1002and Leads1004; a unique key1016between Prospects1002and New Business1006; and a unique key1018between Leads1004and New Business1006. In addition, customer database1000tracks event data for customer-related activities, such as promotional activities, customer prospecting activities, and call center CRM activities. Customer database1000joins customer information across these four groups, as well as attributions and events data, in order to better evaluate marketing and call center activities, build stronger models, and generate useful reports.

In the embodiment ofFIGS.4, enterprise customer data from customer database1000is used in conjunction with customer data from third party data sources430, such as customer demographic data432and directory services data434based on phone number, to score incoming customers. This use case may also apply to the embodiments ofFIG.1andFIG.8.

Customer database1000employs attribution processes for tracking customers across events in customer acquisition and marketing. The objective of attribution is to track people across events: i.e., prospects, leads, applications, and sales. Customer database1000uses exact matching of personal details in order to determine which prospects may have become leads, submitted new business applications, and/or bought products; and which leads may have submitted new business applications and/or bought products. In an embodiment, customer database1000additionally employs matching algorithms for matching personal details with leads data retrieved from third party demographic databases.

The flow chart diagram ofFIG.11shows attribution processes for tracking persons across events between the customer groups.FIG.11shows four customer groups, herein sometimes called “customer event” data: prospects1102, leads1104, applications1106, and sales1108. An individual customer can follow several different paths. For example, the customer might be a prospect who goes straight to a sale; might go through the leads pipeline; might submit an application but never buy the product, etc. Events also can include activity events, such as promotional activities, customer prospecting activities, and call center CRM activities. In the present disclosure, customer database data tracking such activity events are sometimes called “activity event” data.

In an embodiment, events tracked by customer database1100include pairs of events consisting of an event that occurs earlier in time (also herein called prior event; e.g., event A) and an event that occurs later in time (also herein called subsequent event; e.g., event B). Attributions, also called “attributions data” in the present disclosure, serve two primary functions. The first function is to trace all instances of a prior event A to see where these instances ended up. An example of this function is: “Find all leads, applications, and sales that resulted from prospecting activity on X date.” The second function is to determine, for any record of a subsequent event B, which instance of event A most likely caused event B. An example of this function is: “Which prospecting activities were responsible for TERM product sales this month?”

Each arrow ofFIG.11represents one of five attribution processes1112,1114,1116,1118, and1120. The illustrated embodiment does not include an attribution between applications and sales, because tracking between them is very simple. In another embodiment, the attributions would include an attribution between applications and sales. Each arrow is numbered (1, 2, 3, 4, or 5), representing the order in which these attribution processes are run. In an embodiment, each attribution process carries out the following steps, in order: (1) Match records between event A and event B, where event B occurs later in time. For example, in the prospect to leads attribution1112, prospect is event A and leads is event B; (2) Filter matches based on a time limit determined by business rules; (3) Determine the best match, i.e., the single record from event A that most likely led to each record from event B; and (4) Load unique best matches to the attribution table, updating the historical table.

FIG.12is a schematic diagram of customer database event tables for the customer groups prospect, lead, new business, and sale; and of attribution tables between events. Customer database event tables pool all prospects, leads, applications, and sales across the enterprise into four standardized tables1252,1254,1256,1258. In an embodiment, prospect events data include, e.g., camp_cde (code of the marketing campaign that targeted the prospect) and marketing_date (earliest known date for the prospect). In an embodiment, leads events data include, e.g., lead_creation_date (earliest known date for the lead) and source_key (data that identifies the lead's corresponding prospect, where applicable). In an embodiment, new business events data include, e.g., role (role of the person in the record has on an insurance policy, such as owner, insured, or payer) and fyp (first year premium). In an embodiment, sale events data includes, e.g., policy_date (earliest known date for the policy) and vnb (value of new business).

In an embodiment of the system ofFIG.4, various data in customer database422are also stored in other internal databases420of the enterprise, such as call history database424and account information database426. The latter databases may act as source systems for customer database422. Referring again toFIG.12, customer database records may have values in the columns source_table, source_id_column, and source_id, indicating how to access information in the source system.

Attribution creates attribution tables by applying rules to the customer database event tables. The attribution tables1264,1268,1272,1276, and1282ofFIG.12provide the basic data representing the relationship between each pair of events1252,1254,1256,1258. In addition, the customer database1200can build overall tables that aggregate all the relationships between prospect, lead, new business, and sales. For example, if a prospect is attributed to a lead, which in turn is attributed to a sale, an overall table would represent these relationships in a single row. In various embodiments, customer database builds reports via overall tables that apply analytics to select data using one or more of attribution tables1264,1268,1272,1276, and1282. In various embodiments, the analytics include criteria based on activity events.

In an example, the customer database1200builds a report to answer the question: “What is the response rate for the Term to Perm campaign?” The customer database selects data using the marketing.datamart_prospect_lead_attrib table1264. The customer database applies analytics to focus on the Term to Perm marketing campaign, counting the number of leads generated from the total prospects. In another example, the customer database1200builds a report to answer the question: “What is the conversion rate for the Retirement campaign?” The customer database selects data using the marketing.datamart_prospect_appl_attrib table1268. The customer database applies analytics to focus on the Retirement marketing campaign, counting the percentage of applications generated from the total prospects.

The following discussion refers to customer management system400and its components, but also applies to customer management system100and customer management system800. In an illustrative embodiment, customer management system400utilizes data from both internal and external sources in pre-sale predictive modeling of sale of a financial product (insurance policy). The data includes internal data420of the call center that tracks historical information about leads, customers, and marketing costs of the call center, including historical sales and lapse information. In an embodiment, these internal databases use rmm_analytics schema in data warehouse software. In an embodiment, internal databases420use rmm_analytics schema to generate a table of enterprise customer data. In another embodiment, internal databases420use rmm_analytics schema to generate additional data tables, such as a table of historical lead and customer data, and a table of marketing costs data.

In an embodiment, rmm_analytics schema includes sales and lapse data for current and/or historical leads of the enterprise, which data is used in building predictive models of the present disclosure. In an illustrative embodiment, a paid_flag indicates policy payments and a related field shows the amount of each payment. In the present disclosure, these data are called payment data. In an illustrative embodiment, either a lapse_flag or surrendered_flag indicate that a policy has lapsed. In the present disclosure, these data are referred to as lapse data. In an embodiment, date fields are used for filtering data by date range. In an illustrative embodiment, information about leads, customers, and marketing costs was used to model a pre-determined period of time of payments following the sale of the product that defines lapse. In an illustrative embodiment, for the purpose of pre-sale predictive modeling of sale of an insurance policy, this modeling resulted in defining lapse as failure of the customer to maintain a purchased policy in force for at least 18 months.

In building the predictive models of the present disclosure, model datasets may have populations in the hundreds of thousands or millions of individuals. Model datasets may include training datasets and testing datasets. Filtering techniques can be applied to eliminate false data and for de-duplicating, reducing the number of records but significantly improving quality of model datasets. In an illustrative embodiment, date-filtered data such as payment data and lapse data within an older date range are used for building a training data set, and date-filtered data within a more recent range are used for building a test data set. In an illustrative embodiment, predictive machine-learning models of the present disclosure are continually trained using updated payment data, lapse data, and customer demographic data.

In an embodiment, in building predictive models, rmm_analytics schema are filtered based on the flow of historical leads through the inbound call center routing process. In an embodiment, the data are filtered to select only historical leads that were connected to a live agent; in the present disclosure this flow is sometimes called a “warm transfer.” Applicant has observed that building predictive models based on a population limited to warm transfers can improve performance of models for predicting sales and lapse behaviors.

In the illustrative embodiment, data used in predictive modeling also include data retrieved from the customer demographic database432to obtain information about customers. In an embodiment, customer demographic data includes individual level data on customers. In various embodiments, as a prerequisite to using data in predictive modeling of a given inbound caller (customer), analytical engine404associates the customer demographic data with a customer identifier for the customer. In an illustrative embodiment, customer demographic data used in modeling of a customer requires an exact match of name and address.

In an embodiment, customer demographic data also includes data using zip-level features of the system, which provides a coarser representation in building the predictive model. Such zip-level features employ variables that have resolution at the zip-level for each individual in the zip code. In an illustrative embodiment, zip-level data for individual income is associated with a median value of income for each individual in the zip code. Reasons for using zip-level data in predictive modeling include, for example, lack of a statistically significant difference in model performance as a function of any polymr match score threshold; simplicity of collecting only the name and zip code in the telegreeter process; and privacy considerations as to individual-level data.

In various embodiments embodiment, in predictive modeling of inbound callers, inbound queue management system402uses a fast-lookup tool (e.g., polymr) that analyzes customer identifiers of inbound callers in real time to retrieve customer data, such as customer demographic data, matched to the customer identifiers. In an embodiment, the polymr fast-lookup tool is a lightweight, extensible search engine, or API, implemented in the Python object-oriented programming language, https://www.python.org/. In various embodiments, the polymr tool performs real time matching of data in the customer demographic database432to a customer identifier for a given lead. In various embodiments, as a preliminary to using data in real-time predictive modeling of inbound callers, inbound queue management system402indexes the data by applying the search engine to customer identifiers in customer training data, and stores this index as an internal enterprise database420.

In an embodiment, inbound queue management system402labels each data element in Acxiom as continuous (including interval), binary, ordinal, or nominal (categorical). For use in a logistic regression model414, variables that have lookup fields are converted to integers. Following feature transformation of the variables, the final view outputs each variable with human-readable names (if known), and a tag at the end of the variable name. Illustrative end tags for transformed variable names include:_binary: either 0 or 1_ordinal_to_binary: either 0 or 1, where null values are mapped to 0_flat_binary: mapped from a string field like “01001000” into multiple fields_ordinal: as an integer, with null values left null_interval: as an integer, with null values left null_continuous: as an integer, with null values left null_nominal: as an integer, with null values mapped to an additional integer

By applying the feature transformation rules described above, analytical engine404builds a simplified input data file from data retrieved. This simplified input data file facilitates predictive modeling with a binary target.

Predictive modeling module410builds both a regression model414and a tree-based model418. In an embodiment, the predictive modeling module410trains a logistic regression model414with l1regularization on the full set of features of the Acxiom database. Use of logistic regression for classification problems provides performance advantages over standard linear regression, because application of the logistic function to the raw model score maps the output precisely from 0→1 while providing a smooth decision boundary. In an embodiment, the logistic regression model with l1regularization utilizes LASSO (Least Absolute Shrinkage and Selection Operator), a regression analysis method that performs both variable selection and regularization to enhance prediction accuracy and ease of interpretation of the resulting statistical model.

l1regularization provides the benefit of simplifying the selection of features through the model training process by constraining features with lower correlation to have 0 weight. The general form for a linear model can be indicated as:
ŷ(w,x)=wo+w1x1+ . . . +wpxp
for ŷ to be predicted from data points in the array x by learned coefficients w. The l1regularization is achieved by adding a term to the cost function, as follows:

minw12⁢nsamples⁢Xw-y⁢22+a⁢w1
with regularization weight α. Applicant observed in training a logistic regression model with l1regularization, that run time of training increases rapidly with greater regularization parameters, with best model performance at low values of the regularization parameter α. In an embodiment, the logistic regression model with l1regularization sets the regularization parameter α using cross-validation, with best-performing values typically around 0.005-0.01.

In another embodiment, regression model employs logistic regression with l2regularization, sometimes called ridge regression, according to the formula:

minw12⁢nsamples⁢Xw-y⁢22+a⁢w2

In the l2regularization model, as in the l1regularization model, the regularization weight α is set by cross validation. In an embodiment, a logistic regression model with l2regularization uses a backward feature selection procedure to select an optimal number of features. This feature selection procedure is the RFECV method for recursive feature elimination in Scikit-learn, a software machine-learning library for the Python programming language, available at https://github.com/scikit-learn/scikit-learn.

In various embodiments, both l1and l2regularization models fit a regularization hyperparameter using five folds for cross validation and searching across the seven parameters: [0, 0.001, 0.005, 0.01, 0.1, 0.5, 1]. In repeated iterations of model training, this range is restricted around previously successful settings.

In an embodiment, the tree-based model418is a random forests model. Random forests is a class of ensemble methods used for classification problems. Random forests models work by fitting an ensemble of decision tree classifiers on sub samples of the data. Each tree only sees a portion of the data, drawing samples of equal size with replacement. Each tree can use only a limited number of features. By averaging the output of classification across the ensemble, the random forests model can limit over-fitting that might otherwise occur in a decision tree model.

In an embodiment, the tree-based model418uses the random forests model in Python's scikit-learn. In an illustrative embodiment, the tree-based model418uses the following parameters in the scikit-learn random forests model:Maximum tree depth: 3 or ∞, set with max_depth.Maximum number of features considered when looking for the best split: 3→6, set with max_features.Minimum number of samples required to split a node of the tree: 2→11, set with min_samples_split.Minimum number of samples to be a leaf node: 1→11, set with min_samples_leaf.Number of trees in the forest: 100 or 200, set by n_estimators.Whether to sample with replacement for the data seen by each tree: true or false, set by bootstrap.Function to measure quality of a split: Gini or Entropy (information gain), set as criterion.

In an embodiment, for each customer a pre-sale predictive model generates a value prediction signal indicative of potential value of a sales transaction for that customer. The predictive model can provide various types of value prediction signal including, for example: (a) buy-only signal, representative of the likelihood that the customer will accept the offer to purchase the product; (b) lapse-only signal representative of the likelihood that the customer will lapse in payments for the purchased product; (c) buy-don't-lapse signal representative of the likelihood that the customer will accept the offer to purchase the financial product and will not lapse in payments for the purchased product; as well as predictive models providing combinations of these signals.

Predictive models410effect a degree of feature selection. In various embodiments, predictive models410identify high importance features that have the most pronounced impact on predicted value. Different types of model may identify different features as most important. For example, a model based upon a buy-only signal may identify different leading features than a model based upon a lapse-only signal.

TABLE_1Features from l1buy-don't-lapse modelImportanceFeature−2.7125expectant_parent_nominal−0.3126recent_divorce_nominal_0−0.2634credit_card_new_issue_nominal_0−0.1438gender_input_individual_nominal_00.1117socially_influenced_ordinal0.0890home_length_of_residence_interval−0.0757likely_investors_nominal_0−0.0667vacation_travel_international_would_enjoy_or-dinal_to_binary0.0637total_liquid_investible_assets_fin_ordinal−0.0632new_mover_nominal_0−0.0518single_parent_ordinal_to_binary−0.0517vacation_travel_time_share_have_taken_ordinal_to_binary−0.0455investments_real_estate_ordinal_to_binary0.0438investments_stocks_bonds_ordinal_to_binary0.0429obtain_life_insurance_along_with_loan_mortgage_instal-lment_payments_ordinal

Table 1 shows the top 15 features from an l1buy-don't-lapse model. The most important features are identified by the highest absolute value of the importance coefficient. The most important feature of this target is the expectant_parent_nominal variable, where a 0 corresponds to not expectant. Positive and negative signs of the importance coefficient indicate whether an increase, or a decrease, of the feature increases likelihood of the target. This data indicates that non-expectant parents are less likely to buy and less likely to lapse.

In an embodiment, in building the predictive model410, the call center evaluates performance of prospective models, such as test models, for efficacy in predicting buying behavior and/or lapse behavior. In an embodiment, prospective models are tested for the area under the curve (AUC) of a receiver-operator curve (ROC).FIG.13is an example1300of an ROC curve1330. The receiver-operating characteristic (ROC) curve plots the true positive rate (Sensitivity)1310as a function of the false positive rate (100-Specificity)1320for different cut-off points. Each point on the ROC curve1330represents a sensitivity/specificity pair corresponding to a particular decision threshold. An ROC curve with a higher area under the curve (AUC) generally indicates a higher-performing model. The ROC1300ofFIG.13was obtained in testing a logistic regression model with l1regularization on the lapse-only signal, and has an area under the curve (AUC)1340of 0.574, indicating a high-performing model.

FIG.14is another example of a receiver-operator curve (ROC)1450, obtained by testing a logistic regression model with12regularization on the buy-only signal trained using all leads. (Sensitivity)1460as a function of the false positive rate (100-Specificity)1470for different cut-off points. Each point on the ROC curve1480represents a sensitivity/specificity pair corresponding to a particular decision threshold. ROC1450has an area under the curve (AUC)1490of 0.531.

In an embodiment, prospective predictive models are tested for performance by measuring lift across deciles. Lift is a measure of the degree of improvement of a predictive model over analysis without a model. For a binary classifier model, decile lift is applied to deciles of the target records ranked by predicted probability.FIG.15is a graph of lift across deciles of model scores1500for a logistic regression model with l1regularization on the lapse-only signal, trained on zip-level features. Percent of target values1520across deciles1510show a significant impact of the model on lapse rate.

In an embodiment, prospective predictive models are tested for performance by measuring improvements in buying behavior and/or reductions on lapse rate. In various embodiments, these measurements are carried out with different levels of resource constraint of the call center, measured by call center agent resources in view of inbound call volume. For example, a 70% resource constraint involves agent resources at a 70% level of resources in view of call volume relative to full resources.

In illustrative embodiments, the predictive model incorporated a logistic regression model with l1regularization, for the lapse-only target. In one illustrative embodiment, this model was trained on all customers with individual-level data. In another illustrative embodiment, this model was trained on all customers with zip-level data. At a 70% resource constraint, the model with individual-level data was tested to provide an 11% reduction in lapse rate, while the model with zip-level data was tested to provide an 8% reduction in lapse rate. At a 60% resource constraint, the model with individual-level data was tested to provide a 14% reduction in lapse rate, while the model with zip-level data was tested to provide an 11% reduction in lapse rate.

While various aspects and embodiments have been disclosed, other aspects and embodiments are contemplated. The various aspects and embodiments disclosed are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

The foregoing method descriptions and the interface configuration are provided merely as illustrative examples and are not intended to require or imply that the steps of the various embodiments must be performed in the order presented. As will be appreciated by one of skill in the art the steps in the foregoing embodiments may be performed in any order. Words such as “then,” “next,” etc. are not intended to limit the order of the steps; these words are simply used to guide the reader through the description of the methods. Although process flow diagrams may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or the main function.

The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed here may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

Embodiments implemented in computer software may be implemented in software, firmware, middleware, microcode, hardware description languages, or any combination thereof. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

The actual software code or specialized control hardware used to implement these systems and methods is not limiting of the invention. Thus, the operation and behavior of the systems and methods were described without reference to the specific software code being understood that software and control hardware can be designed to implement the systems and methods based on the description here.

When implemented in software, the functions may be stored as one or more instructions or code on a non-transitory computer-readable or processor-readable storage medium. The steps of a method or algorithm disclosed here may be embodied in a processor-executable software module which may reside on a computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable media includes both computer storage media and tangible storage media that facilitate transfer of a computer program from one place to another. A non-transitory processor-readable storage media may be any available media that may be accessed by a computer. By way of example, and not limitation, such non-transitory processor-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other tangible storage medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer or processor. Disk and disc, as used here, include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and/or instructions on a non-transitory processor-readable medium and/or computer-readable medium, which may be incorporated into a computer program product.