System and method for automated customer service with contingent live interaction

Abstract

A balance between customer satisfaction and cost to providing customer care can be achieved based on the use of online interaction classification techniques. Such techniques can use measurements such as a log likelihood ratio to determine if an interaction should be removed from automation to live support if it appears necessary.

Description

BACKGROUND

Automating customer care through self-service solutions (e.g., Interactive Voice Response (IVR), web-based self-care, etc.) results in substantial cost savings and operational efficiencies. However, due to several factors, such automated systems are unable to provide customers with a quality experience. Such factors include the highly constrained nature of automated interactions, poor error recovery in automated interactions, and poor context handling in automated interactions. The present invention addresses some of the deficiencies experienced with presently existing automated care systems.

One challenge in providing automated customer service (e.g., through an interactive voice response system) is a tradeoff between cost and customer satisfaction. While customer interactions which take place using an automated system (e.g., an interactive voice response system) are generally less expensive than interactions which take place between a customer and a human being, automated interactions are also likely to lead to lower customer satisfaction. One technique for addressing this problem is to provide customer service wherein an interaction initially takes place between a customer and an automated system, and, if the interaction seems to be approaching a negative outcome (i.e., “going bad”), transferring the interaction from an automated to a live interaction. However, an obstacle to the successful use of this technique is the problem of determining when an interaction is “going bad.” If an algorithm for determining when an interaction is “going bad” is oversensitive, then too few interactions will be completed using automation, resulting in unnecessary cost. If an algorithm for determining when an interaction is “going bad” is under-sensitive, then too few interactions will be transferred to a live interaction, resulting in lower customer satisfaction and, ultimately, a lost customer and lost business. Further, even creating an algorithm for determining whether an interaction is “going bad” can be a difficult task. The teachings of this application can be used to address some of these deficiencies in the state of the art for systems and methods used in customer interactions.

SUMMARY

In an embodiment, there is a computerized method for determining when to transfer a user from an automated service to a live agent comprising (a) classifying a set of historical interactions offline; (b) after said classifying step, training a set of classification models using said set of classified historical interactions to perform real-time classification of an interaction; (c) after said training step, determining a log likelihood ratio, using said classification models, to trigger whether to transfer said user, from an automated interaction to a live interaction, by computing a log of a prediction that an interaction is good over a prediction that an interaction is bad.

For the purpose of clarity, certain terms used in this application should be understood to have particular specialized meanings. For example, a “set of computer executable instructions” should be understood to include any combination of one or more computer instructions regardless of how organized, whether into one or more modules, one or more programs, a distributed system or any other organization. Also, as used in this application, “computer memory” should be understood to include any device or medium, or combination of devices and media, which is capable of storing computer readable and/or executable instructions and/or data. As used in this application, the term “model” should be understood to refer to a representation or a pattern for a thing. One example of a “model” is a classification model, such as an n-gram language model, which acts as a pattern for certain types of customer interactions.

A “customer interaction” (also, an interaction) should be understood to refer to a communication or set of communications through which information is obtained by a customer. Examples of automated interactions include dialog interactions where a customer is presented with prompts, and then responds to those prompts, and web page interactions, where a customer obtains information by following hyperlinks and providing input (i.e., through forms) on a web page. A live interaction takes place with a human being. Additionally, the term “monitor,” in the context of “monitoring the processing of a customer interaction” should be understood to refer to the act of observing, obtaining data about, or measuring the processing of the customer interaction.

An Interactive Voice Response (IVR) is an automated telephony system that interacts with callers, gathers information and routes calls to the appropriate recipient. An IVR system (IVR) accepts a combination of voice telephone input and touch-tone keypad selection and provides appropriate responses in the form of voice, fax, callback, e-mail and perhaps other media. An IVR system consists of telephony equipment, software applications, a database and a supporting infrastructure.

Classifying shall refer to arranging or organizing by classes or assigning a classification to information. Transferring shall refer to conveying or causing to pass from one place, person, or thing to another.

Interaction refers to an exchange between a user and either the automated system or a live agent. Training shall refer to coaching in or accustoming to a mode of behavior or performance; making proficient with specialized instruction and practice. A live agent generally refers to a human customer service representative.

A logarithm is an exponent used in mathematical calculations to depict the perceived levels of variable quantities. Suppose three real numbers a, x, and y are related according to the following equation: x=a^y. Then y is defined as the base-a logarithm of x. This is written as follows: log_a x=y. As an example, consider the expression 100=10². This is equivalent to saying that the base-10 logarithm of 100 is 2; that is, log₁₀ 100=2. Note also that 1000=10³; thus log₁₀ 1000=3. (With base-10 logarithms, the subscript 10 is often omitted, so we could write log 100=2 and log 1000=3). When the base-10 logarithm of a quantity increases by 1, the quantity itself increases by a factor of 10. A 10-to-1 change in the size of a quantity, resulting in a logarithmic increase or decrease of 1, is called an order of magnitude. Thus, 1000 is one order of magnitude larger than 100.

In an embodiment the log likelihood ratio may be computed using the formula log(P(x|LM_good)/P(x|LM_bad)).

In an embodiment, the log likelihood ratio is compared against a threshold value to determine whether said interaction is bad. A threshold value is the point that must be exceeded to begin producing a given effect or result or to elicit a response.

In an embodiment, threshold value may be dynamically reset based on external factors. In computer terminology, dynamic usually means capable of action and/or change, while static means fixed. Both terms can be applied to a number of different types of things, such as programming languages (or components of programming languages), Web pages, and application programs. External factors refer to factors situated or being outside something; acting or coming from without (e.g., external influences). In an embodiment, an example of a dynamic factor may be how successful the dialog has been up to that point—if a caller has proffered a large number (appropriately determined by business rules) of inputs during that interaction and the system has successfully recognized and a ‘dialog success’ metric has been reached, then the caller might be immediately transferred to an agent with appropriate data and thereby shorten that subsequent agent interaction. If a caller has given few or no input and is in need of agent intervention, they may be transferred to a normal queue or escalated into a more verbose dialog.

In an embodiment, the threshold value may be dynamically reset based on a lifetime value associated with said user. For discussion of lifetime value, please see co-pending patent application U.S. application Ser. No. 11/686,812, SYSTEM AND METHOD FOR CUSTOMER VALUE REALIZATION, which was filed on Mar. 15, 2007 (and which is incorporated by reference into this application).

In an embodiment, the models are based on a boostexter classification. For a discussion of boostexter classification, please see “Boostexter: A boosting-based system for text categorization.” By R. E. Schapire and Y. Singer appearing in Machine Learning, vol. 39, no 2/3, pp. 135-168, 2000; incorporated herein by reference.

In an embodiment, the boostexter classification is derived using Bayes' rule. Bayes' rule is a result in probability theory, which relates the conditional and marginal probability distributions of random variables. In some interpretations of probability, Bayes' theorem tells how to update or revise beliefs in light of new evidence a posteriori.

In an embodiment, the classification models are based on an N-gram based language model. An n-gram is a sub-sequence of n items from a given sequence. N-grams are used in various areas of statistical natural language processing and genetic sequence analysis. The items in question can be letters, words or base pairs according to the application. N-grams constitute a novel approach to developing classification models because there is some “dependence” or “memory” associated with present and past dialog states that has an immediate impact on the success of the current dialog. Dialogs may be designed based on a higher-level knowledge of the interaction and the business logic and processes that drive them and the recognition that there dependence on prior states exists (e.g., if you are ready to pay with a credit card, then it is reasonable to assume that you have gone through several dialog states such as login, product selection, etc.). Also, the deeper the dialog (and the longer the call, in general), the more dependence there is between present and prior dialog states. N-grams can allow the classification models to predict dialog success/failure more reliably.

In an embodiment, the log likelihood ratio is re-calculated for each turn in said interaction. A turn refers to a single exchange within an interaction between a user and the automated system and/or the live agent. This allows detection rather than mere prediction of when a call is going bad. Furthermore, this allows detection to be performed at any point during the call (after any number of turn exchanges).

In an embodiment computer-executable instructions encoded on a computer-readable medium for determining when to transfer a user from an automated service to a live agent comprising a) predicting whether an interaction is good, based on a classification model, using P(x|LM_good); b) predicting whether an interaction is bad, based on a classification model, using P(x|LM_bad); c) calculating a log likelihood ratio using log(P(x|LM_good)/P(x|LM_bad)); d) setting a threshold value for said log likelihood ratio; e) if said log likelihood ratio falls below said threshold value, executing instructions to transfer said user from automation to said live agent. Calculating refers to making a computation or forming an estimate. Setting refers to assigning a value to a variable.

In an embodiment, said classification model is based on a boostexter classification. The boostexter classification may be derived using Bayes' rule. The classification model may also be based on an N-gram-based language model. In an embodiment the threshold value may be dynamically modified based on external factors. In an embodiment the threshold value may be dynamically reset based on a lifetime value associated with said user. In an embodiment, the computer-executable instructions recalculate the log likelihood ratio for each turn in said interaction.

In an embodiment, a computerized system for determining when to transfer a user from an automated service to a live agent comprises a) an interactive voice response system (IVR) and b) a monitoring module. The user interacts with said IVR. The monitoring module evaluates, after each turn in said IVR, a probability that said user's interaction with the IVR is good and a probability that said user's interaction with the IVR is bad. The monitoring module signals an alarm to bring in a human agent if a log of the ratio of said probabilities is below a predetermined threshold. A monitoring module is a computer with instructions encoded thereon to receive data regarding an interaction and calculate the probabilities associated therewith. An alarm may comprise computer-executable instructions to take a particular action. In an embodiment, the monitoring module evaluates said probabilities based on an N-gram based language model built on partial inputs. Partial inputs may comprise any subsection of an interaction. In an embodiment, the monitoring module evaluates said probabilities based on a boostexter classifier in an iterative algorithm. In an embodiment, the threshold may be dynamically reset based on a lifetime value associated with said user.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts an experimentally observed relationship between a log likelihood ratio and turn progression for “good” and “bad” interactions between a caller and an interactive voice response system.

FIG. 2 depicts an experimentally observed relationship between transfer thresholds based on log likelihood ratio and accuracy of transfer for interactions between a caller and an interactive voice response system.

FIGS. 3a-b depict a representation of a call flow for an interactive voice response system in the form of a state machine.

FIG. 4 depicts a flow diagram of an interaction involving a caller, an IVR, and an agent using an assisted automation (AA) GUI.

DETAILED DESCRIPTION

Some embodiments might make use of transaction information and use it to learn, which might be accomplished with the help of machine learning software agents. This might allow the automated self-care system to improve its performance in the area of user interface, speech, language and classification models, application logic, and/or other areas relevant to customer and/or agent interactions.

For ease of comprehension, this application is structured in the following manner. First, the application describes techniques for offline classification of interactions. Second, the application discusses how data regarding interactions classified offline can be used to train models used for online classification. Third, the application will describe how those models can be used to detect when an interaction should be transferred from an automated interaction to a live interaction (e.g., when the interaction is “going bad”). To make concrete examples possible, the discussion below will be set forth in the context of interactive voice response system technology. However, upon reviewing this application, one of ordinary skill in the art will be able to apply the teachings of this application in contexts and for uses beyond those explicitly set forth herein including a variety of modalities (e.g., web-based interactions). Thus, this application should be understood as illustrative only, and not limiting on any claims included in patent applications which claim the benefit of this application.

To facilitate the discussion of offline classification of interactions, the following assumptions should be made. First, it should be assumed that there is provided a corpus of data representing interactions which can be classified. Such a data corpus can be generated during the normal operation of an interactive voice response system, as most such systems are designed to automatically monitor calls, and create records of calls for quality assurance purposes. Second, it should be assumed that the records in the data corpus representing individual interactions preserve all information regarding the interaction. Examples of such information include prompts provided by the interactive voice response system, transcriptions of statements by a caller derived from an automatic speech recognizer, meanings ascribed to statements made by the caller, confidence scores for the transcriptions and/or meanings, and other relevant information which can be used to represent or describe an interaction. Of course, it should be understood that these assumptions are made for the sake of clarity only, and that they are not intended to be limiting on the scope of any claims included in applications claiming the benefit of this disclosure.

Agent assisted support may be triggered by a variety of mechanisms including, but not limited, to dialog quality or a specific call path. In some embodiments, a voice dialog (or some other type of interaction, such as a self care web site) might be defined in terms of specific states and transition between states. Referring to FIG. 3b, an IVR application that automates tracking and shipping of a package may contain a number of states.

Given such a data corpus, the step of offline classification of interactions can be performed using a variety of techniques. For example, a live individual could review the records of individual interactions and classify the interactions “by hand.” Alternatively, a live individual could classify some of the interactions, and then those interactions could be used as training data for an automated system (e.g., a neural network) which would classify the remaining interactions. As another alternative, rules or logic functions could be developed and used to classify the interactions (e.g., IF a caller hung up THEN classify the interaction as “bad” ELSE classify the interaction as “good”). As yet another alternative, a finite state machine such as is depicted in FIG. 3 could be made based on the call flow for the interactive voice response system. Using this technique, calls which are accepted by the finite state machine (for example, because the call flow reaches a desired “final” state) can be classified as “good,” while calls which are not accepted by the finite state machine (for example, because no “final” state is reached due to caller disconnection or due to network or server problem, or because an undesirable “final” state, such as the caller opting out of automation is reached) could be classified as “bad.” Of course, it is also possible that combined methods of classification could be used. For example, classification could be based on a finite state machine, but additionally, calls which exhibit some identifiable characteristics (e.g., repeated “yes/no” confirmations, which generally happen only when an automatic speech recognizer is unsure of a transcription of customer speech) could also be classified as “bad.” Additional combinations, variations and alternative techniques could also be used in classification. Thus, the discussion above should be understood as illustrative only, and not limiting on the scope of any claims in applications claiming the benefit of this disclosure.

A state-transition model may be used to illustrate certain methods of tracking dialog quality which might be used in some embodiments. As will be known to one of ordinary skill in the art, tracking dialog quality as discussed below, is not limited to embodiments which utilize the state-transition model. One method which some embodiments might use to measure dialog quality comprises rules. For example, a transition from state 1 to state 2 might have a set of rules such as: no more than two loopbacks from state 2 to state 1, and no more than 10 seconds time should be spent in state 1 (e.g., the system might time out if the caller does not speak or takes too long to respond).

In a rule-based dialog quality system, the relevant dialog events might be logged and sent to a dialog quality monitor for each call. A set of decision rules might then be applied to those events and a dialog quality rating might be generated by the decision agent. This decision can be produced for every state transition. Such a rule generated dialog quality rating might then be used to measure the quality of a customer interaction.

Another type of method which some embodiments might use to measure dialog quality comprises an analysis of probabilities. In some such probability analysis methods, each state might have a probability associated with it, which might be based on the likelihood of a caller reaching that state. The transitions between states might also have probabilities associated with them (or such probabilities associated with transitions might be the only probabilities measured). In some probability based methods, the probabilities might be trained based on heuristics and/or data from real deployments of the application. In some probability based dialog quality models, with every transition, an overall probability measure might be determined. Such a measure might be defined as how likely a particular dialog flow is in relation to the general population or to a target user group, though other types of probability measures, such as a measure of how likely a particular transition was relative to the general population or a particular user group might also be utilized. Regardless, once a probability measure has been made, one way to use such measure to determine dialog quality is to compare the probability measure to values corresponding to dialog quality states. For example, probability measures between 0 and 30% might be defined as poor dialog quality, probability measures between 31 and 70% might be defined as acceptable dialog quality, while probability measures between 71 and 99% might be defined as good dialog quality.

In some embodiments, if the probability measurement falls too low, or if it indicates a high probability of a negative outcome from the interaction, some action might be taken, such as automatically transferring the interaction to an agent. When a caller is transferred to an agent, they might have access to the dialog quality measure and a description of how it was arrived at, i.e., what caused the interaction to deteriorate.

In some embodiments, specific events associated with a dialog can be obtained by mining call logs from existing or new applications in real-time to generate events of interest. One approach which might be taken is to list the desired events in a configuration file that the IVR application can use to generate events in real-time.

It should be noted that, while the assumption that the records in the data corpus preserve all information regarding the interaction could allow for a high degree of flexibility in techniques used in offline classification, such complete data preservation is not necessary for all offline classification. For example, when classification is performed using a finite state machine, the classification could be based on some subset of the information stored for the interactions (e.g., the meanings assigned to statements by the caller), while the remaining information (e.g., confidence in transcriptions of caller statements) could be discarded, or could be maintained for some other purpose. Similarly, using a logic function in offline classification, it is possible to only use a subset of the information regarding individual interactions in the logic functions, while the remaining information could be discarded, or could be maintained for some other purpose. Thus, in some implementations, it is possible that offline classification could be performed even if some subset of information regarding an interaction is not preserved in the records of the data corpus. Additional variations on this approach could be implemented by those of ordinary skill in the art without undue experimentation. Therefore, it should be understood that the variations presented herein are intended to be illustrative only, and not limiting on the scope of any claims included in applications claiming the benefit of this disclosure.

After the offline classification has taken place, the classified interaction data can be used to train models which can be used to perform classification in an online manner. As was the case with the offline classification, a variety of techniques can be used for the training of models. For example, it is possible that the classified models can be used to train models such as N-gram based language models, or that the records could be used to train iterative models, such as the boostexter classification models described in R. E. Shapire and Y. Singer, “Boostexter: A boosting-based system for text categorization.” Machine Learning, vol. 39, no. 2/3, pp. 135-168, 2000, the teachings of which are hereby incorporated by reference. Thus, concretely, in an example in which the records were classified as “good” or “bad” using a finite state machine based on the meanings of responses given by a caller, a class conditional language model LM_c can be built by taking the caller's response sequence as a word sequence. Using this technique, a prior, given test input x consisting of response sequences (x=r₁, r₂, . . . r_n) can be classified by estimating the likelihood of the sequence from each LM_c:

$\hat{c}=\underset{c\in C}{\arg \max }P\left(x|{\mathrm{LM}}_c\right)$ where C={good, bad}.

Similarly, using a Boostexter classifier on an input x of responses as described above, the confidence that x is in a class c can be determined by using the following formula:P(c−x)=(1+exp(−2*f(x)))⁻¹ where

$f\left(x\right)=\sum _{t=1}^T{\alpha }_t{h}_t\left(x\right),$ h_t(x) is a base classifier at t, and α_t is its weight, as in M.

Karahan, D. Hakkani-Tür, G. Riccardi, and G. Tur, “Combining classifiers for spoken language understanding” Proc. of ASRU, Virgin Islands, USA, November 2003, pp. 589-594, the teachings of which are hereby incorporated by reference in their entirety.

Of course, additional variations could be implemented by those of ordinary skill in the art without undue experimentation in light of this disclosure. For example, while it is possible that models could be trained based on complete series' of responses from a caller (i.e., for an interaction in which the caller made n responses, the input x would be (r₁, r₂, . . . r_n), it is also possible to use partial sequences, in order to more closely approximate online classification during training. This could be accomplished by chopping the individual records into turns, then feed turn sequence prefixes (up to each particular turn) to the classifier being trained. Still further variations could also be implemented. Thus, the discussion herein of training models for online classification should be understood as being illustrative only, and not limiting.

Once a model for online classification has been trained, that model can actually be used to determine whether to transfer a call from an automated interaction to a live interaction. As was the case with the steps of offline interaction classification and model training described above, a variety of techniques can be used in this step as well. For example, it is possible that a classification model could be used directly to predict whether an interaction is “good” and therefore should continue in automation or “bad” and therefore should be transferred to a live individual (e.g., using a language model as described above, the interaction could be transferred to a live individual if P(x|LM_good) falls below a set threshold, or if P(x|LM_bad) rises above a set threshold).

Alternatively, it is also possible that models such as described above could be used as inputs to other functions which could be used for determining whether an interaction should be transferred. For example, a log likelihood ratio (LLR) could be used based on the good/bad classification (e.g., using a language model as described previously, the measurement log(P(x|LM_good)/P(x|LM_bad)) to determine whether to transfer an interaction out of automation). Other variations, such as a log likelihood ratio for a Boostexter classifier derived using Bayes' rule could be used as well. In any case, the function or models could then be applied to actual interactions, and, in real time, determine whether an interaction should be transferred out of automation, thereby increasing customer satisfaction, by transferring interactions before they “go bad,” and at the same time reducing costs, by avoiding unnecessary transfers. A good call never hits the threshold. The LLR is compared against the threshold value to determine when to bring in a human agent. The use of logs allows an easier and more accurate determination of the best threshold value because taking log dynamically scales particular numbers within certain ranges. The invention achieves this by taking the log of the prediction that a call is good over the prediction that a call is bad. By taking the log of the ratio of each of the probabilities, the system more accurately distinguishes between a single bad turn triggering a live operator (particularly if it would be possible for the IVR to recover from the error), and when the system is not able to recover (e.g., by a continuous series of really bad turns). The log operation helps by providing a uniform ‘range’ of values to work with in determining the optimal thresholds across a large number of turns and variations.

Further variations on the theme of online classification of interactions are also possible. For example, various systems for online classification implemented according to this disclosure could vary from one another based on whether a transfer out of automation is triggered based on static or dynamic factors. To help clarify the nature of this variation, consider that it is possible to use the classified data for testing as well as for training (e.g., by chopping up the records into individual turns, as was described previously in the context of training in a manner similar to online classification). Using this data it is possible to empirically measure the likely behavior of different methods for online classification of interactions as “good” or “bad.” For example, given a set of training data with an average log likelihood ratio as shown in FIG. 1, it is possible to test different log likelihood ratios as potential triggers for transfer out of automation, an exemplary set of data which could be obtained from such a test being shown in FIG. 2. Then, to create a static trigger, the test data could be used to determine the log likelihood ratio which results in the greatest accuracy (negative 1.1, in the case of the test data for FIG. 2) which would be set as the threshold for transfer of an interaction into automation. Similarly, to create a dynamic trigger, the test data could be used to determine potential thresholds for transfer of interactions which could later be varied based on external factors (e.g., if a larger number of agents is available, the threshold could be set to transfer more calls, so as to avoid excess capacity, while if a smaller number of agents is available, the threshold could be set to transfer fewer calls, to avoid callers being placed in a hold queue).

Additional variations are possible as well. For example, while a log likelihood ratio measurement based on a language model based classification with a transfer threshold of −1.1 has been found to have an accuracy of 0.830, a precision of 0.831, a recall of 0.834 and an F-score of 0.830, different methods for determining transfer could be used to achieve different results (e.g., a log likelihood ratio using a boostexter classification and transfer threshold of −1.1 has been found to have an accuracy of 0.733, a precision of 0.797, a recall of 0.708, and a F-score of 0.702). Further, while the discussion of model creation above focused on the meanings ascribed to statements by a caller, it is also possible that other features of an interaction (e.g., confidence levels in transcriptions by an automatic speech recognizer) could be used. Additionally, learning might take place, rather than being based on classified data, through the use of unsupervised learning techniques (e.g., outlier detection).

In addition to, or as an alternative to, the interfaces described above, certain embodiments might comprise a method for measuring the quality of interactions, and/or a method of implementing assisted automation over existing care applications. FIG. 4 depicts the integration of certain products, services, service channels, data sources and agent contexts which might be implemented in some embodiments of the invention.

An IVR might be configured to present a dialog organized into specific states. In some embodiments, those states might be designed so that, at a high level, they correspond to business processes. In some embodiments, either in addition to, or as an alternative to, high level correspondence with business processes, the states might correspond to specific interaction points (such as a single system prompt and a corresponding caller response) at a low level. Further, in some embodiments, states might be defined in terms of the current state and context, the previous state, the next state, and the possible transitions between states. For coordination between an IVR and an assisted automation enabled application, one or more of the states might have an integration definition for a corresponding assisted automation application.

An illustrative example of an interaction between a caller, an agent, and assisted automation enabled application is set forth below:

Assume that the caller speaks the tracking number (say, a 16 character alpha-digit string) and the IVR/speech recognizer has been unable to find a match, and has asked the caller to repeat the tracking number multiple times. In some embodiments, this might trigger intervention by an agent, who might be given access to context information related to the customer's interaction. The agent might then enter the tracking number (which he or she might have heard from the caller's prior recording) into a GUI interface to the IVR, which might then proceed to the next state in the voice dialog. The agent might be given a choice to provide input (tracking #) in a surreptitious mode (without the caller's knowledge) or in a direct mode. In some embodiments, the agent might be instructed to directly interact with a caller if the caller has repeatedly been unable to reach a desired state using the IVR. In some embodiments, after the agent has provided the correct tracking number, the agent might have the option of placing the interaction back into automation, which might free the agent to process one or more additional transactions.

Further variations could also be practiced by those of ordinary skill in the art without undue experimentation. Thus, the disclosure set forth herein should be understood as illustrative only, and not limiting.

Claims

1. A computerized system for determining when to transfer a user from an automated service to a live agent comprising: a) a self-service solution (SSS); andb) a monitoring module;whereini) said user interacts with said SSS;ii) said monitoring module evaluates, after each turn in said SSS, a probability that said user's interaction with the SSS is good and probability that said user's interaction with the SSS is bad;iii) said monitoring module signals an alarm to bring in a human agent if a log of the ratio of said good probability over said bad probability is below predetermined threshold.

2. The computerized system as claimed in claim 1 wherein: a) said monitoring module evaluates the probability that the user's interaction with the SSS is good using P(x|LMgood);b) the monitoring module evaluates the probability that the user's interaction with the SSS is bad using P(x|LMbad);c) x=r1, r2, . . . rn;d) each r is a response made by the user in the user's interaction with SSS;e) LMgood is a first classification model trained using records of one or more previous interactions classified as good; andf) LMbad is a second classification model trained using records of one or more previous interactions classified as bad.

3. The computerized system as claimed in claim 1 wherein said monitoring module evaluates said probabilities based on a boostexter classifier in an iterative algorithm.

4. The computerized system as claimed in claim 1 wherein said threshold may be dynamically reset based on a lifetime value of a relationship with said user.