GB2410148A - Call routing - Google Patents

Abstract

Apparatus for routing voice and/or data calls comprises means for detecting a transaction type relating to an incoming call; call routing logic 100 for directing a call to one of several different call handling actions relating to that transaction type; means for deriving a facilities cost for each call in respect of each possible call handling action relating to that call, the facilities cost depending on at least telecommunications charges associated with that call; an operator control for setting a transaction weight associated with each transaction type; means for associating a value with each call / call handling action combination, the value depending on at least the call handling action, the transaction type and the transaction weight; and a memory for storing data representing facilities costs and associated values in respect of currently active calls which has been routed by the call routing logic; the call routing logic being responsive to data stored in the memory to route each call to one of the call handling actions so as to aim towards a desired relationship between the aggregate facilities cost and the aggregate value of that call and other currently active calls which have been routed by the call routing logic. Calls are routed to agents 10 via Automatic call distributors (ACD) 8.

Description

CALL ROUTING

This invention relates to call routing.

It is known for organizations, such as banks, department stores and supermarkets to make use of call centres to handle incoming customer calls. For example, many banks use call centres to allow customers to enquire about the balance of their bank accounts, pay bills, alter overdraft limits and request loans. Some call centres make use of interactive voice response (IVR) units that can provide the customer with pre-recorded information and receive directions from the customer when the customer enters specific values via touch tone telephone input. IVR Grits are able to determine the service required by a customer through a series of option menus. These are controlled by so-called "scripts" - effectively programmed flowcharts showing different paths through the various option menus. Some of these services can be handled without the need of human interaction: a simple balance enquiry for example. Other services require human interaction and the customer's call may be transferred to an agent working on behalf of the organization.

Some organizations make use of a single call centre whilst others make use of multiple call centres that may be linked in a variety of ways. These call centres may be geographically separated, may specialise in particular services and may be operated either by the organization or a third party working on behalf of the organization.

The number of calls entering a call centre or network of call centres can vary over time. Inevitably, this re: ults in there being insufficient agents to handle all of the customer calls at, for example, certain times of the day. Incoming calls are therefore placed in queues, with the call at the head of a queue being transferred to an agent when an agent associated with that queue becomes available.

Whilst incoming calls received by a call centre are best known to be telephone calls, it is also known for call centres to receive calls of other types, such as emails. As an example, a caller could email the call centre with a request for an agent to telephone him back.

Alternatively, there may be some form for "Internet collaboration" in which a caller and an agent work. For example, the agent could lead the caller through the completion of a webpage-based application form.

Complex systems are created when IVRs with complex menu and option scripts are used across multiple call centres that are networked together, especially when there are multiple queues for storing the incoming calls. Routing systems exist for routing incoming calls according to predetermined rules. For example, it is known for routing systems for networked call centres to transfer an incoming call to the call centre that is expected to have an agent available next. father routing systems transfer a call directly to any available agent and only make use of IVR units when all agents are busy. In another system, different call centres specialise in different services and the routing is performed on a skillsbasis, whereby the call is placed in a queue for the agents best equipped to handle the call type.

Various metrics of a call centre are observed by a supervisor of the call centre. Such metrics include the number of calls handled per hour, the number of calls abandoned by customers, the average queue size, etc. In response to these metrics, the supervisor may wish to alter the routing systems and he may instruct the agents to handle the incoming calls lo differently, for example, by omitting any time-consuming cross-selling of products and keeping call times to a minimum.

However, existing systems are limited in terms of their ability to adapt to changing circumstances and their ability to differentiate between different calls. It can be difficult, expensive and tints consuming to alter the hard-coded script of an IVR unit, especially when the IVR unit is being operated by a third party. This may cause problems when a new service is launched and needs to be added to the system. Additionally, it is often difficult to assess the impact of a routing system on both the customers and the organization. Call centre supervisors often make changes to the routing system or the ways in which agents handle calls without a full appreciation of the overall impact on the organization and the call handling system.

There is therefore a need for a call centre supervisor to be able to change how calls are handled in a simple, dynamic and inexpensive manner.

This invention provides apparatus for routing voice and/or data calls, the apparatus comprising: means for detecting a transaction type relating to an incoming call; call routing logic for directing a call to one of several different call handling actions relating to that transaction type; means for deriving a facilities cost for each call in respect of each possible call handling action relating to that call, the facilities cost depending on at least telecommunications charges associated with that call; an operator control for setting a transaction weight associated with each transaction type; means for associating a value with each call / call handling action combination, the value depending on at least the call handling action, the transaction type and the transaction weight; and a memory for storing data representing facilities costs and associated values in respect of currently active calls which have been routed by the call routing logic; the call routing logic being responsive to data stored in the memory to route each call to one of the call handling actions so as to aim towards a desired relationship between the aggregate facilities cost and the aggregate value of that call and other currently active calls which have been routed by the call routing logic.

Embodiments of the invention will now be described by way of example only with reference to the accompanying drawings in which: Figure 1 schematically illustrates a typical call centre; Figure 2 schematically illustrates a group of agents; s Figure 3 is an example workflow of an agent; Figure 4 schematically illustrates an automatic call distributor; Figure 5 schematically illustrates an interactive voice response unit; Figure 6 is an example flow followed by an interactive voice response unit; Figure 7 schematically illustrates a configuration of three call centres; lo Figure 8 schematically illustrates an alternative configuration of three call centres; Figure 9 is an example graph of the cost of an incoming call plotted against call time; Figure 10 is an example graph of customer satisfaction plotted against call time; Figure 11 is an example graph of corporate value plotted against customer satisfaction; Figure 12 schematically illustrates a configuration of three call centres that includes additional call routing apparatus; and Figure 13 schematically illustrates an example workstation used by an agent or a call centre supervisor.

Figure 1 schematically illustrates a typical call centre 2 that is configured to received incoming calls 4. There may be numerous telephone numbers and numerous telephone lines by which the incoming calls 4 can be received by the call centre 2, thereby allowing multiple incoming calls 4 to be received and handled in parallel. An example of there being multiple telephone numbers for the call centre 2 is that the organisation running the call centre 2 wants all of its incoming customer calls 4 to be handled by the call centre 2. The organisation therefore provides one telephone number for new customers, another telephone 2s number for existing customers and yet a further telephone number dedicated to customers that the organisation values highly.

The call centre 2 comprises an optional interactive voice response (IVR) unit 6, an automatic call distributor (ACD) 8 and a group 10 of (human) agents 12. A detailed description of the IN R unit 6, the ACD 8 and groups of agents 10 will be given later. Briefly though, the IVR unit 6 is responsible for rendering audio information to a caller and detecting options that the caller has selected. The IVR unit 6 then routes the incoming calls 4 to the ACD 8 via connections 18. The ACD 8 may hold the incoming calls 4 in various queues before routing them to the agents 12 via connections 20. The agents 12 then handle the incoming calls 4 as appropriate. Information from the group of agents 10 may be fed l back to the IVR unit 6 and the ACD 8 via an IVR feedback channel 14 and an ACD feedback channel 16 respectively.

The call centre 2 may have different values for the number of incoming calls 4 that the IVR unit 6 can simultaneously handle; the number of calls that the ACD 8 can hold in its queues; the number of agents 12 in the group of agents 10; the number of the connections 18 between the IVR unit 6 and the ACD 8; and the number of the connections 20 between the ACD 8 and the group of agents 10.

If the IVR unit 6 is not present in the configuration of the call centre 2 then the incoming calls 4 are received directly by the ACD 8. In this situation, a caller does not have lo any interaction, such as selecting options from menus, with the call centre before the incoming call 4 is handled by the agents 12. Instead, the incoming calls 4 are simply held by the ACD 8 in its queues before being transferred to the agents 12. However, information about the incoming calls 4 may still be collected by the ACD 8, as will be described later.

Figure 2 schematically illustrates the group of agents 10 which receives the incoming calls 4 via the connections 20 from the ACD 8. In Figure 2, the agents 12 within the group of agents 10 are divided into two skill sets 30 and 31, although it will be appreciated that the agents 12 may be split into any number of skill sets, including no skill sets. The skill sets 30 and 31 have one or more agents 32 in common, although it will be appreciated that this is not necessary for all skill sets. As an example, a call centre for a bank may have agents 12 within the first skill set 30 who are responsible for handling mortgage applications. The agents 12 within the second skill set 31 may be responsible for handling credit card enquiries. The agents 32 who lie in the intersection of the skill sets 30 and 31 handle both types of service.

A call centre supervisor 34 oversees the operation of the group of agents 10. The call centre supervisor 34 may, for example, monitor the rate at which the incoming calls 4 are arriving, the speed with which the agents 12 are handling the incoming calls 4 and the type of service of each of the incoming calls 4. The call centre supervisor 34 may respond to changing circumstances by, for example, modifying the arrangement of the agents 12 within the skill sets 30 and 31 so as to better handle the differing types of the incoming calls 4.

Information from ibe group of agents l O can be passed back to the IVR unit 6 via the IVR feedback channel 14. For example, the call centre supervisor 34 may request that the IVR unit 6 uses different option menus. Similarly, information from the group of agents l O can be passed back to the ACD 8 via the ACD feedback channel 16. For example, the ACD 8 can be provided with 'information on the availability of the agents 12 within the group of agents l O so that it can otter route the incoming calls 4.

Figure 3 is an example workflow of one of the agents 12 within the group of agents 10.

At a step S2, the agent 12 logs in to one or more of the skill sets if such skill sets exist within the group of agents 10.

At a step S4, the agent 12 waits for one of the incoming calls 4 to be delivered to him by the ACD 8.

At a step S6, the agent 12 handles the incoming call 4 as appropriate.

At a step S8, the agent 12 wraps-up the incoming call 4. This involves not only the lo termination of the incoming call 4, but also a process of recording any details about the incoming call 4 in, for example, a database.

The agent 12 may then return to the step S4 and wait for another incoming call 4.

Alternatively, the agent 12 may, at a step Sin, decided to indicate that he is unavailable and should therefore not have any of the incoming calls 4 routed to him. At a step S 12, the agent 12 may then indicate that he is now available to receive the incoming calls 4. Workflow then returns to the step S4.

At a step S14, the agent 12 logs out. This may occur (a) after having wrapped-up the incoming call 4 at the step S8; (b) having indicated that he is unavailable at the step S10 or (c) whilst waiting for one of the incoming calls 4 at the step S4.

Figure 4 schematically illustrates the ACD 8, which is arranged to receive the incoming calls 4 via the connections 18 and to route the incoming calls 4 to the group of agents 10 via the connections 20. The ACD 8 has queue assignment logic 40 for assigning the incoming calls to a set of queues 42. In a simple example, the number of queues 42 may be the same as the number of connections 18 and each of the connections 18 has its own dedicated queue 42 for storing the incoming calls 4 arriving at the ACD 8 via that connection 18. In a more complex arrangement, the ACD 8 may have a connection 44 to a caller line identification (CLI) database 46. In such a configuration, the queue assignment logic 40 may be operable to determine from the CLI database 46 whether or not the telephone number of the incoming call 4 is in the CLI database 46. If the telephone number does not exist within the CLI database 46 then the caller is potentially a new customer and the queue assignment logic 40 may place the incoming call 4 in a queue 42 dedicated to new customers; otherwise the queue assignment logic 40 may place the incoming call 4 into a different queue 42 dedicated to existing customers.

The ACD 8 has distribution logic 48 that routes the incoming calls 4 held on the queues 42 to the group of agents 10 via the connections 20. The distribution logic 48 may be configured in several ways. For example, the ACD 8 may be informed by the group of agents 10 via the ACD feedback channel 16 of when one of the agents 12 next becomes available, the distribution logic being operable to route one of the incoming calls 4 to this agent 12. The distribution logic 48 may select which particular incoming call 4 to route to the group of agents 10 in several ways. For example, the distribution logic 48 could select the incoming call 4 at the head of the queue 42 that currently holds the most incoming calls 4; alternatively, one of the queues 42 may be a high priority queue from which the lo distribution logic 48 takes the incoming calls 4 in precedence over all of the other queues 42.

The ACD 8 may additionally have a so-called "universal queue" 43 that may be used for receiving incoming data calls 45 that are not telephone calls. For example, it is known for customers to communicate with the call centre 2 via email. Such an email could contain a request from the customer asking for one of the agents 12 to telephone the customer. As another example, customer may email transactional information to one of the agents 12 in order to complete a previously initiated transaction. The incoming data calls 45 held on the universal queue 43 are also distributed to the group of agents 10 by the distribution logic 48.

Figure 5 schematically illustrates the IVR unit 6, which is arranged to route the incoming calls 4 to the ACD 8 via the connections 18. The IVR unit 6 has IVR logic 50 for handling audio input and delivering audio output for the incoming calls 4. The IVR logic 50 contains an audio rendering unit 52 that receives audio data 54 that has been configured for the IVR unit 6 and renders a selection of the audio data 54 so that the callers of the incoming calls 4 can hear the audio data 54 relevant to their particular incoming call 4. The audio data 54 may be stored, for example, as audio files or as text tiles, in which case the audio rendering unit 52 additionally contains text to speech logic.

The IVR logic 50 may receive input from the incoming calls 4 directly. Alternatively the IVR unit 6 may contain an advanced speech recognition (ASR) unit 56, which is capable of converting the speech input of the incoming calls 4 into a form recognizable by the IVR logic 50. This may be limited, for example, to converting spoken forms of numbers into digital values for use within the IVR logic 50. In preferred embodiments though, the IVR unit 6 contains a tone dial recognition unit 58 that can recognise the telephone buttons pressed by the caller. The IVR unit 6 can therefore receive input from the incoming calls 4 in numerous ways.

The IVR unit 6 may have a connection 44' with a CLI database 46' so that the IVR unit 6 can determine, in a way analogous with the ACD 8, whether or not the incoming calls 4 correspond to telephone numbers of new callers or callers that have called before. With this information, the IVR logic 50 may alter its selection of the audio data 54 to render to the s caller.

The IVR unit 6 is, in general, operable to: (a) render predetermined audio to the caller, (such as a "welcome" script or a menu of caller selectable options); (b) render a mixture of predetermined audio and caller specific audio, (such as a lo "welcome" script particular to that caller or, for calls centres 2 serving a bank say, the balance of the caller's bank account); (c) receive the caller's input, (such as a menu selection or, for call centres 2 serving a bank say, the amount of money a caller wishes to transfer between accounts).

Any caller specific information that the IVR unit 6 is configured to render (such as the balance of a bank account) or to change (for example by paying a bill) is stored on one or more databases (or business systems or transaction systems) 60 and accessed via one or more channels 62.

Figure 6 is an example flow followed by the IVR unit 6.

At a step S20, the IVR unit 6 receives one of the incoming calls 4.

At a step S22, the IVR unit 6 renders a predetermined "welcome" audio message to the caller.

At a step S24, the IVR unit 6 queries the CLI database 46' (if present) to determine whether or not an incoming call 4 with this particular telephone number has been received before. If, at a step S26, the IVR unit 6 determines that such a call has been received before then at a step S28, the IVR unit 6 renders any caller specific audio message as appropriate, such as a "per-caller welcome message".

At a step S30, the IVR unit 6 renders audio data to request the caller to input their customer ID. The IVR unit 6 receives data entered by the caller via, for example, tone dialling input.

At a step S32, the IVR unit 6 renders audio data to request the caller to input their personal identification number (PIN), or a part thereof. The IVR unit 6 receives data entered by the caller via, for example, tone dialling input.

At a step S34, the IVR unit 6 validates the data received from the caller by referencing the database 60. If, at a step S36, the IVR unit 6 determines that the data received from the caller is invalid, the IVR unit proceeds to a step S38 at which it determines whether or not the caller has provided invalid data for the third time in this incoming call 4. If this is the third time in this incoming call 4 that an invalid customer ID or PIN has been entered by the caller, then, at a step S40, the incoming call 4 is routed to one of the inputs of the ACD 8, which will ultimately route the incoming call 4 to one of the agents 12 who will be able to handle the incoming call 4; otherwise the IVR unit 6 proceeds to a step S39 at which the IVR unit 6 renders an audio message to inform the caller of the invalidity of the input before returning to the step S3Q at which the customer ID is requested.

If, at the step 36, the IVR unit 6 determines that the input customer ID and PIN are lo valid then, at a step S42, the IVR unit 6 undertakes automated actions, such as informing the caller of the balance of a bank account.

At a step S44, the IVR unit 6 renders audio options according to a predetermined menu of options.

At a step S46, the IVR unit 6 receives an input from the caller which is validated at a step S48. If it is determined, at a step S50, that the input is invalid then, at a step S52, the IVR unit 6 renders an audio message to inform the caller that the input was invalid; otherwise, at a step S54, the incoming call 4 is routed to one of the inputs of the ACD 8.

Note that this is a simplified flow for the IVR unit 6. In practice, multiple menus may be navigated by the caller who may access several automated services before possibly being routed to one of the agents 12.

Figure 7 schematically illustrates a configuration of three call centres 2a, 2b and 2c with incoming calls 4a, 4b and 4c, IVR units 6a and 6b, ACDs 8a, 8b and 8c and groups of agents lea, lOb and lOc. Note that the third call centre 2c is a call centre that does not support an IVR unit. The three call cenkes 2a, 2b and 2c are linked by connections 70 so that the incoming calls 4a, 4b and 4c may be routed from one call centre to another call centre. Any of the incoming calls 4a, 4b or 4c received by any component of a call centre may be routed to any component of another call centre, where a component is an IVR unit, an ACD or a group of agents.

Figure 8 schematically illustrates an alternative configuration for connecting three call centres 2a, 2b and 2c with ACDs 8a, 8b and 8c and groups of agents lOa, lOb and lOc. The incoming calls 4 are received by a networked interactive voice response (NIVR) unit 80 which comprises an IVR unit 82 and an optional gateway 84 connected to one or more databases (or business systems or transaction systems) 86 via one or more connections 88.

The NIVR unit 80 may I'e serving more than one organization and the gateway 84 handles the security and data handling issues that arise in such circumstances.

After the incoming calls 4 have been handled by the IVR unit 82 of the NIVR unit 80, they are routed to an enterprise router (ER) 90 via a connection 92. The ER 90 has its own queues (not shown) for storing the incoming calls 4, which may be queues of an IVR associated with the ER (not shown) or queues of the telecommunications network. It also has routing logic (not shown) for routing the incoming calls 4 to one of the call centres 2a, 2b and 2c via connections 94a, 94b and 94c. Once the incoming call 4 has been handled by one of the call centres 2a, 2b and 2c, it may be terminated or it may be routed back to the ER lo 90 for further routing to another one of the call centres 2a, 2b and 2c. The routing by the ER may be based on a variety of factors, such as (a) which one of the call centres 2a, 2b and 2c is expected to have an agent available next and (b) which one of the call centres 2a, 2b and 2c is best suited to handle the incoming call 4, in terms of the service required by the caller and the skill sets of the groups of agents 1 Oa, 1 Ob and 1 Oc.

Note that in a configuration of call centres as shown in Figure 8, the call centres 2a, 2b and 2c do not have their own IVR unit. Instead the single IVR unit 82 of the NIVR unit 80 serves all of the call centres 2a, 2b and 2c. However, it is still possible for the call centres 2a, 2b and 2c to have their own IVR unit to handle any interactive voice communication that is not performed by the IVR unit 82 of the NIVR unit 80. For example, the call centres 2a, 2b and 2c may have their own IVR unit to inform the caller of terms and conditions after a sale has been completed.

The rate at which line incoming calls 4 are received by the call centre 2 can vary greatly over time. There exist a number of responses that the call centre supervisor 34 can use to cope with a situation when the rate of receiving the incoming calls 4 is growing large. Such responses are often used in other situations, for example when a new product is launched and an increased proportion of the resources available must be directed to handling the incoming calls 4 concerning the new product. These responses include: (a) paying the agents 12 for working overtime; (b) allowing a proportion of the incoming calls 4 to be abandoned by the caller; (c) employing temporary staff or making use of "back-office" staff of the call centre 2 to handle the incoming culls 4; (d) changing the call handling strategy, for example, (i) saving time by sending out mortgage application forms to the caller instead of completing a mortgage application over the telephone or (ii) saving time by not cross-selling products, such as insurance for loans; (e) taking a message and calling the caller back at some point in the future; (i) reducing the time to perform the wrap-up by, for example, making less thorough notes of the conversation, (g) cancelling training; (h) sending some of the excess incoming calls 4 to a third party overflow call centre, despite incurring potentially large costs; (i) changing the priorities of the services, which can be achieved, for example, by having agents log out of one skill set and log in to another skill set; (j) changing the menu options of the IVR unit 6 at different times of the day, which lo may include providing sub-optimal self-service options (such as completing a mortgage application via the IVR unit 6) as well as providing self-service options more suited to the IVR unit 6 (such as balance enquiries).

The call centre supervisor 34 currently has a limited amount of information available for making decisions as to how to change the routing and handling of the incoming calls 4.

Such information includes: (a) the rate of handling the incoming calls 4; (b) the rate of abandonment of the incoming calls 4 by the caller; (c) the average or maximum size of the queues 42 of the ACD 8; (d) the average amount of time spent by the agents 12 talking to the callers; (e) the average amount of time spent by the agents 12 to answer the incoming calls 4; (f) the number of sales made; (g) the number of cross-sales made.

Whilst decisions based on these factors can be made by the call centre supervisor 34, it is very difficult for the call centre supervisor 34 to appreciate the overall impact such decisions have on both the organisation and the callers, especially when some decisions can be costly or time consuming (for example, changing hard-coded values within the logic of the IVR unit 6 or the ACD 8). As an example, spending more time completing telephone mortgage sales could be seen as of increased worth to the organization, especially if a sale is completed. However, this may result in a reduced number of the incoming calls 4 being handled by the agents 12 (one of the few measures that is monitored in the call centre), and these lost calls could, in fact, have had a combined value that is greater than the combined values of the mortgage sales. Additionally, caller satisfaction will be reduced for the callers who abandoned their incoming call 4 because of excessive queuing time. It is extremely difficult to determine wl.;ch call routing and handling strategy out of a group of strategies is the best to adopt given a particular scenario.

Some organizations have adopted a somewhat simplistic approach to this problem. For example, some of the incoming calls 4 can be classified as priority calls (for example by recognising the CLI of important callers or by providing important callers with a special telephone number to use). Priority calls can be placed by the ACD 8 on a special priority queue 42, the distribution logic 48 of the ACD 8 being designed to ensure that any incoming call 4 held on the priority queue 42 is handled before any of the other incoming calls 4. Such an approach is aimed at maximising the overall revenue produced for the organization from lo the incoming calls 4.

An alternative simplistic approach adopted by some organizations is that the incoming calls 4 are routed directly to any agent 12 if one is available to handle the call, thereby avoiding the IVR unit 6 and avoiding any potential dissatisfaction caused by the caller using the IVR unit 6. The IVR unit 6 is only used in circumstances when none of the agents 12 is able to handle the incoming calls 4. Such call routing systems and call handling strategies tend to be

relatively inflexible and incapable of being adapted to the true impacts on the organization and the callers.

Figure 9 is an example graph of the cost of one of the incoming calls 4 plotted against call time. There may be an initial call cost C, for example a connection charge levied by a telephone network company. In this model, the cost of the incoming call 4 increases linearly during each stage of the call, although the rate of increase may be different for each stage.

From the beginning of the call at time O up until a time T1, the incoming call 4 is being processed by the IVR unit 82. From the time T1 to a time T2, the incoming call 4 is being held in a queue associated with the ER 90. From the time T2 to a time T3, the incoming call 4 is being held in a queue of the ACD 8a. From the time T3 to a termination time T4a, T4b or T4c, the incoming call 4 is being handled the group of operators lea, with the incoming call 4 being terminated at the end of this period. The existence of the three different termination times T4a, T4b and T4c is representative of the fact that there may be multiple strategies that the agents 12 can use for handling this particular call type, although of course in a real situation there could be more or less than three such strategies.

If the call type of the incoming call 4 is known (for example, by the caller selecting a menu option at the IVR unit 82 or by the particular access number that the caller dialled), then, knowing also the current load on the system, it is possible to estimate the values of the times T1, T2, T3, T4a, T4b and T4c. As such, it is possible to calculate the contribution to the estimated costs ECla, EClb and EClc for the overall handling of the incoming call 4 which depends on the call handling strategy adopted by the agents 12. If the call type of the incoming call 4 is not known (for example, the caller may not have a tone dialling telephone and therefore cannot enter options at the IVR unit 82), then a "default" call type is assigned and a default set of times and estimated costs can be used.

As an example, the termination time T4c could represent the time spent completing a caller's mortgage application and additionally cross-selling insurance for the mortgage; the termination time T4b could represent the time spent completing the caller's mortgage application but not crossselling any product to the caller; and the termination time T4a could lo represent the time spent simply informing the caller that a mortgage application form will be sent to him by post. In a more advanced analysis, the additional costs of processing the mortgage application form (for example, delivery of forms, processing received completed forms and informing the caller of the success or failure of the application) are taken into account. These costs do not apply when the mortgage application is completed during the incoming call 4 (at times T4c and T4b) . The additional cost is therefore represented in Figure 9 by the line A, which results in an aggregate estimated cost for the incoming call 4 being EC2. It will be appreciated that different call handling and routing strategies may involve different levels of additional costs incurred after termination of the incoming call 4, and that these may be used to calculate associated aggregate estimated costs for the incoming call 4.

In addition to calculating estimated call costs for different strategies for the agents 12 handling the incoming calls 4, it is possible to calculate estimated call costs for different routing strategies for the incoming calls 4. For example, it may be possible, for the given call type, for the IVR unit 82 to completely handle the incoming call 4. The dashed line L represents a plot of the cost of the incoming call 4 against time when the IVR unit 82 completely handles the incoming call 4, giving a total estimated cost EC3.

It will be appreciated that different call types may have different call cost models.

The derivation of a call handling cost is carried out analytically by additional routing logic to be described below. For a particular call type, there are a limited number of routes that the call can take through the system. The initial call connection has an associated charge. Each possible queuing point has a charge, often expressed as a cost per unit time.

Telecommunications routes between call handling nodes (such as individual call centres) have associated charges, and so on. Each of the different strategies for an agent to deal with a call can be costed based on the average time and data processing resource required for that strategy, and these costs are maintained (and possibly updated in time) in a look-up table.

One main variable in this derivation is the queuing time. This can be predicted using known techniques from (a) the system loading, in terms of the number of calls queued ahead of the current call, and (is) the number of agents available to handle the current call, i.e. the number logged on to the skill set(s) needed to handle the current call.

The other main variable is the way in which the call is finally handled. IVRs tend to be the cheapest way of handling a call. Agents are more expensive, with the cost generally depending on the time devoted to a call by an agent.

0 As an example, a call relating to a mortgage enquiry could be itemised as follows: Fixed charges: call connection 0.02 Variable charges: (a) Routing strategy one - route to IVR IVR cost: 0.01 (b) Routing strategy two - route to organisation's own agent - full service telecommunications charge: 0.005 per minute queuing cost: 0.008 per minute agent cost: 0.70 expected queuing time: 7 minutes total variable cost: 0.791 (c) Routing strategy three - route to organisation's own agent - minimal service telecommunications charge: 0.005 per minute queuing cost: 0.008 per minute agent cost: 0.31 additional post-call costs (delivery of forms, handling replies etc.): 0.55 expected queuing time: 7 minutes total variable cost: 0.951 (d) Routing strategy four - route to overflow agent - mid-range service telecommunications charge: 0.005 per minute queuing cost: 0.008 per minute overflow agency fixed cost: 5.20 overflow agent handling cost: 0. 90 expected queuing time: 1 minute total variable cost: 6.1 13 and so on.

A less analytical tool for analysing call centre performance is a measure of customer satisfaction. This will now be discussed as background to some of the further analytical measures to be described below.

Figure 10 is an example graph of the satisfaction of the caller of the incoming call 4 plotted against call time in which the times T1 and T3 represent the same points of time during the incoming call 4 as in Figure 9, and a time T4 represents an arbitrary one of the times T4a, T4b and T4c. The caller is assumed to initiate the incoming call 4 with 100% satisfaction, although it will be appreciated that this may not always be the case, for example lo when the incoming call 4 is held on a queue 42 dedicated to customer complaints.

Up until the time T1 when the incoming call 4 is being handled by the IVR unit 82, the satisfaction level of the caller slowly decreases to a satisfaction level S1. The rate of decrease may depend on several things, such as the complexity of the menus used and the number of menus used during the incoming call 4 by the IVR unit 82.

From the time T1 when the incoming call 4 leaves the IVR unit 82 until the time T3 when one of the agents 12 begins to handle the incoming call 4, the incoming call 4 is being held in one of potentially many queues. It is to be expected that, during this period, the satisfaction level of the caller will drop at an increasing rate. At the time T3 when one of the agents 12 begins to handle the incoming call 4, the satisfaction level will have dropped to a satisfaction level S3.

From the time T3 when one of the agents 12 begins to handle the incoming call 4 up until the time T4 when the incoming call 4 is terminated, the satisfaction of the caller of the incoming call 4 may change in many different ways. For example, if the caller of the incoming call 4 receives good service and is content with the outcome of the incoming call 4, then the satisfaction level at the end of the incoming call 4 may have risen to a satisfaction level greater than the satisfaction level S3. Alternatively, if the caller of the incoming call 4 receives bad service and is not content with the outcome of the incoming call 4, then the satisfaction level at the end of the incoming call 4 may have dropped to a satisfaction level lower than the satisfaction level S3.

If the call type of the incoming call 4 is known (for example, by the caller selecting a menu option at the IVR unit 82), then, knowing also the current load on the system, it is possible to estimate the values of T1, T3 and T4. If the call type of the incoming call 4 is not known (for example, the caller may not have a tone dialling telephone and therefore cannot enter options at the IVR unit 82), then a default set of times and estimated satisfaction levels can be used.

It will be appreciated that different call types may have different customer satisfaction models. Note also that there may be adjustments made to the final satisfaction level, for example if the caller of the incoming call 4 is provided with the opportunity to express his level of satisfaction via either communication with one of the agents 12 or via a further IVR unit that may be utilised to complete the incoming call 4.

Figure 11 is an example graph of the corporate value of the incoming call 4 plotted against the satisfaction of the caller at the end of the incoming call 4. If the final satisfaction lo level is 100%, then this may be seen as having an overall value V100 to the corporation or organization. The way in which the value of the incoming call 4 may change as the satisfaction level changes may depend, for example, on the particular caller. If the caller of the incoming call 4 is a highly valued customer, then as the satisfaction level decreases from 100% to 0%, the value of the incoming call drops rapidly, eventually becoming a negative value Va, as the highly valued customer may decided to take future business elsewhere.

However, some organizations have so-called "bad" customers who are a burden to the organization. Therefore, for such bad customers, as the satisfaction level decreases from 100% to 0%, the value of the incoming call may increase, eventually rising to a value Vb greater than the 100% satisfaction value V100, as the bad customer may also decide to take future business elsewhere.

It will be appreciated that different call types may have different corporate value models. It will also be appreciated that the value V100 may also depending on the particular caller, it being lower for the "bad" customers.

As mentioned above, however, the notion of "satisfaction" is highly subjective and does not lend itself readily to an analytical derivation. However, a more objective measurement relating to customer satisfaction could be the time taken for a caller to abandon the incoming call 4.

The time to abandonment of course depends on the type of service being offered, but within a particular family of services the time that the caller is willing to spend on a call will generally depend on (a) e length of time spent queuing, and (b) whether the call is routed to a human agent or an IVR. In many cases where there is a choice of the two, human agents are often perceived to be preferable to IVRs.

So, for each call type, a statistical model can be built up from real data (and possibly updated in time) showing the likelihood of a typical caller abandoning the call as a queuing phase progresses or if We caller is routed to an IVR. When coupled with the expected queuing time for each strategy for dealing with the call, this can give a statistical likelihood of the caller hanging up before reaching an agent.

Note that the statistical likelihood of the caller hanging up may, in some cost models, be taken into account. For example, if the caller hangs up before reaching one of the agents 12, then a cost is still incurred by that abandoned call. If the caller telephones again for the same subject matter but this time completes the call with one of the agents 12, then an aggregate cost for the call could be considered to be the combined costs of the first and second calls. An expected additional cost for a call can be calculated based on the statistical lo likelihoods of the caller hanging up, as well as other parameters such as the call type and the identity of the caller. These expected additional costs may be included in a cost model.

In the example above, a seven minute queue might mean that there is a statistical likelihood of, say, 50% that the caller will hang up before reaching the head of the queue. A one minute queue for strategy four (routing to an overflow call centre) may give rise to a 15% likelihood of hanging up.

So, a statistical likelihood of the caller hanging up can be derived analytically from the current loading of the system, previously captured call statistics, and the nature of the various routing strategies available to handle that call.

A measure of the value of the call to the organization can then be derived analytically as follows.

The type of call is established. This can be found by the number that the caller dialled (e.g. "dial 0845 808080 for mortgage enquiries") or by a touch-tone or voice driven menu selection via an IVR. If this information is not available then a default "call type" is selected.

The type of caller is established. Again, this could be by the number that is called ("Gold card customers please dial 0845 909090"), by a lookup of the caller's CLI or by the caller entering an account or membership number at an initial IVR, which can then give a lookup to a customer or membership database.

These two pieces of information have an influence on the expected revenue from the transaction itself, as well as the likelihood of the caller abandoning before the transaction is handled.

Example - Mortgage S.les Enquiry If a client purchases a mortgage, there is of course a financial benefit to the organization. From an analysis of previous client interactions, it might have been established that 3% of customer contacts lead to a mortgage sale. The typical benefit to the organization might be 1000 for a "normal" customer, or 1500 for a "Gold card customer" who might be expected to have a greater income. A monetary value "e" (which will be modified by the abandonment statistics to be described below) would be the product of the typical benefit and the percentage of contacts which lead to a sale, or in this example 30 for a "normal" customer or 45 for a "Gold card" customer.

Because a mortgage enquiry is a relatively complex transaction, the call abandonment profile (which again can be obtained through an analysis of real data) might show that, say, 50% of calls are abandoned after seven minutes of queuing. It may be that this is the same lo between customer types, or it could be that, say, "Gold card" customers tend to be less patient when held in a queue. In general, there would be a call abandonment profile as a function of (time, call type, caller type).

Example - Account Balance Enouirv This is perceived to have relatively little value to the organization other than ongoing customer satisfaction. It could be perceived as more important to keep "Gold card" customers satisfied, so the typical benefit "e" to the organization might be 0.20 for a "normal" customer, or 0.50 for a "Gold card customer".

Because a balance enquiry is a relatively simple transaction, the call abandonment profile (which again can be obtained through an analysis of real data) might show that, say, 50% of calls are abandoned after just two minutes of queuing. Again, it may be that this is the same between customer types, or it could be that, say, "Gold card" customers tend to be less patient when held in a queue. As before, in general, there would be a call abandonment profile as a function of (time, call type, caller type).

Abandonment Of course, these values to the organization can be achieved only if the call is not abandoned before being handled. So, the abandonment statistics are applied to determine a "value" figure.

The likelihood of abandonment is known from previous calls as a function of (time, call type, caller type). So, for an expected queuing time, the probability "p" of calls which so are expected to have been abandoned is known.

If a call is abandoned, it can be considered to have a negative effect on customer satisfaction. This could be quantified as a value "w" as a function of (call type, caller type).

The value w would be expected to be greater (more negative) for higher value customers. It is set subjectively but that? stored in a look-up table for use in the present analysis.

So, the value to the organisation of a call is derived as follows: value = (1-p(queuing time, call type, caller type)) x e(call type, caller type) w(call type, caller type) x p(queuing time, call type, caller type) The information and metrics described above allow the impact of the decisions of the call centre supervisor 3a on the call costs, customer satisfaction and corporate value to be modelled and estimated. As such, advantage is provided in call routing systems that can both report such metrics and allow call routing and handling changes to be made based on such metrics. Additionally, the routing and handling of the incoming calls 4 can be varied on a per-call basis as the circumstances for every incoming call 4 are always different.

lo A simple example will now be given, in which a first incoming call A is currently at the head of one of the queues 42 in the ACD 8 for call handling by an agent. Suppose that a second incoming call B from a highly valued customer then arrives at the ACD 8.

Four example decisions may be available to the logic 40 and 48 of the ACD (there may well be more possibilities but four will be used here for this example): 1: to place the incoming call B from the highly valued customer at the head of the queue 42 and move the existing incoming call A to be handled after the incoming call B; this means that B will be handled more quickly but runs the risk of keeping A waiting too long; 2: to place the incoming call B from the highly valued customer behind the existing incoming call A in the same queue; this avoids any impact on A but runs the risk of losing call B because call B has to wait too long; 3: to route the call B to an IVR; this will give a quicker handling of call B but a potentially lower satisfaction level for the caller; 4: to route the call B to an external overflow agency; this will give a quicker handling of call B but is much more expensive to implement.

2s An alternative decision could be to place call A on an IVR, even though call A was previously waiting for an agent. However, it is considered bad queue management if a call is repeatedly passed around different queues in a potentially endless cycle.

So, these are considered to be the four call handling strategies available to the system.

In this example, the agent actions in 1, 2 and 4 when the call reaches the head of the queue are the same. Other strategies of course could include the agent handling the call differently, as described above. In that case the system could arrange that a textual or similar message is routed with the call, to appear on the agent's screen instructing the agent which way the agent should handle that call (e.g. "full service", "send out forms", "snatch name and address only" etc.).

Several existing call routing systems will automatically take the first decision, as, by its very nature, an incoming call B from a highly valued customer is assumed to be of higher corporate value. However, that approach can cause difficulties if a lot of "highly valued customers" call at the same time. In empirical trials it has been found that customers not falling into the category Of "highly valued" can be in a position of never reaching the head of a queue at all, because "highly valued" customers continually jump to a more advantageous position in the queue. So, this approach is not satisfactory.

in The other existing approach would be to place calls in the queue in strict order of receipt. However, this can lead to the highly valued customers having to wait too long to reach the head of the queue.

In the present embodiment, a third approach is presented based on an analytical derivation by the additional routing logic of the call cost and the call value which in turn is related to the abandonment statistics.

The value of the call also depends on the call type - that is, the type of transaction - and a classification of the particular caller obtained from a CLI lookup. As mentioned earlier, default values are used if either of these data items is not available. But it is assumed for the following discussion that the caller for call A is a "moderate value" customer to the organization, and the caller for call B is a "high value" customer to the organization.

Example - Mortgage Sales Enquiry The table below gives example estimates of the cost and value for both of the incoming calls A and B in dependence on the decision made by the ACD 8.

Decision Estimated cost Estimated value Incoming call A Incoming call B Incoming call A Incoming call B 1 (B first) 1.20 0.90 10 60 2 (B behind A) t0.80 1.30 40 50 3 (B to IVR) 0.80 0.30 40 20 (RIO owrlluv) 0.80 10.20 40 60 A simple comparison of cost and value would indicate that in this instance it is worthwhile routing call B to the overflow agency, even though the cost of doing this is relatively high.

Example - Account Balance Enquiry Again, the table below gives example estimates of the cost and value for both of the incoming calls A and B in dependence on the decision made by the ACD 8. The weighting applied to derive the value of this call type is very different to that applied in respect of the mortgage sales enquiry.

Decision Estimated cost Estimated value Incoming call A Incoming call B Incoming call A Incoming call B 1 (B first) 1.00 0.90 0.10 0.20 2 (B behind A) 0.80 1.00 0.20 0.10 3 (B to IVR) 0.80 0.30 0.20 0.20 4 (B to overflow) 0.80 10.20 0.20 0.20 A simple comparison of cost and value in this instance would indicate that it is worthwhile routing call to the IVR. In other words, the maximum value of (value - cost) can be obtained in this way.

A direct comparison need not be made. A relative weighting could be applied to the call cost and the call value, that weighting being potentially under the control of an operator.

The weighting would tend to vary the relative priorities of the organization in routing calls for either increased value or decreased cost.

Similarly, an operator-controlled weighting can be applied to each call type. So, the value "e" of, say, mortgage enquiries could be boosted relative to other call types by the user weighting, so that the system tends to give preference to mortgage enquiries. This could be done for business reasons, for example during a sales push on a new mortgage product.

So, it may well be, as in this situation, that by providing a reduced level of preferential treatment to highly valued customers, the overall costs to the organization can be reduced whilst increasing the overall corporate value. Previous call routing systems are, in general, less flexible, less efficient and less financially beneficial.

Figure 12 schematically illustrates a configuration of three call centres similar to that of Figure 8 but that includes additional call routing apparatus. The IVR 82, the ER 90 and the ACDs 8a, 8b and 8c all have additional routing logic 100. The additional routing logic provides data to support call routing and handling decisions described above, where such decisions are made based on factors including, but not limited to, the cost of the incoming calls 4, the value of the incoming calls 4 to the organisation and the satisfaction to the callers of the incoming calls 4. The additional routing logic may simply adjust the call routing and handling functionality based on the information provided to it from the call centre supervisors 34. Alternatively, the additional routing logic may form its own models of, say, lo corporate value, and be arranged to automatically make some routing decisions.

The additional rotating logic may receive information (such as the currently preferred options according to the call centre supervisors 34) via feedback channels (not shown) such as the ACD feedback channel 16 and the IVR feedback channel 14. It receives information defining caller type, call type and the statistical measures described above. It derives a call cost and a call value metric as described above and uses these metrics, along with corresponding metrics for currently live calls which have already been routed to generate routing decisions for an incoming call to be newly routed.

The additional routing logic 100 accesses data about particular callers. This data could be held in memory inside the additional routing logic 100 or may be accessed via a database.

Such data could represent, for example, whether or not the caller abandoned a previous incoming call and should therefore be given preferential treatment for future incoming calls 4. Another type of data that can be held in this way is the transaction type of a previous call.

For example, if this is the second call that a user has made about a mortgage, it could be much more likely that this call will lead to a sale (the user is definitely interested) and so the expected revenue from the call, e, can be weighted to be higher. A rolling store of these one or more parameters can be maintained by user. For example, only parameter data relating to a most recent n calls (where n is one or more) could be stored. Or a filtered approach could be applied, so that the stored parameter is, say, dependent partly on the previously stored value and partly on the most recently acquired value of that parameter, with the major influence preferably being given to the most recently acquired value. Such parameter data can be used to affect the call routing and handling decisions of the additional routing logic.

Figure 13 schematically illustrates an example data processing apparatus providing the functionality of the additional routing logic. A computer 110, such as a conventional personal computer, has a display unit 112 and is connected to a network by a network interface card 114 and a connection 116. The computer operates at least partly under the control of software, which may be supplied on a storage medium such as a disk medium or via the network connection 116 (e.g. via an internet connection) .

Claims (1)

1. s 1. Apparatus for routing voice and/or data calls, the apparatus comprising: means for detecting a transaction type relating to an incoming call; call routing logic for directing a call to one of several different call handling actions relating to that transaction type; means for deriving a facilities cost for each call in respect of each possible call lo handling action relating to that call, the facilities cost depending on at least telecommunications charges associated with that call; an operator control for setting a transaction weight associated with each transaction type; means for associating a value with each call / call handling action combination, the value depending on at 1,nst the call handling action, the transaction type and the transaction weight; and a memory for storing data representing facilities costs and associated values in respect of currently active calls which has been routed by the call routing logic; the call routing logic being responsive to data stored in the memory to route each call So to one of the call handling actions so as to aim towards a desired relationship between the aggregate facilities cost and the aggregate value of that call and other currently active calls which have been routed by the call routing logic.

   2. Apparatus according to claim 1, in which the call routing logic is arranged to route 2s each call to one of the call handling actions so as to aim towards an extreme amount of a weighted combination of the aggregate facilities cost and the aggregate value of that call and other currently routed calls.

   3. Apparatus according to claim 1 or claim 2, in which the value associated with a call / call handling action combination depends on the identity of the caller.

   4. Apparatus according to any one of the preceding claims, in which at least one of the call handling actions is provided by an automated call handling device.

   5. Apparatus according to claim 4, in which the facilities cost depends on at least whether that call handling action is automated or humanoperated.

   6. Apparatus according to any one of the preceding claims, in which at least two of the s call handling actions are human-operated, but have different associated levels of service and different respective contributions to the facilities cost.

   7. Apparatus according to claim 6, in which the call routing logic is operable to route a call to a human operator and to send a message to that operator indicating the level of service lo to be applied in respect of that call.

   8. Apparatus according to any one of the preceding claims, in which at least one of the call handling actions is associated with a queue for holding a call until that call handling means is ready to handle that call.

   9. Apparatus according to claim 8, in which the facilities cost depends on at least an anticipated queuing time or that call handling means.

   10. Apparatus according to any one of the preceding claims, comprising: means for storing, with reference to a caller identity, parameter data representing at least one parameter relating to a call, the value associated with a current call being dependent on the parameter stored in respect of at least a preceding call by that caller.

   11. Apparatus according to claim 10, in which the parameter data depends upon whether the caller abandoned a call before being connected to a call handling action.

   12. Apparatus according to claim 10 or claim 11, in which the parameter data depends upon the transaction type relating to a call.

   13. Apparatus according to any one of claims 10 to 12, in which the parameter data depends upon the outcome of a call.

   14. Apparatus according to any one of claims 10 to 13, in which the parameter data depends on at least two calls by that caller, the influence of each call on the parameter data being weighted so that a more recent call has a greater influence on the parameter data.

   IS. Apparatus according to any one of the preceding claims, in which the value associated with a call / call handling action combination depends upon: call abandonment statistics relating to other incoming calls handled by the apparatus; and the total anticipated duration of the call if routed to that call handling action.

   16. Apparatus according to any one of the preceding claims, in which the value associated with a call / call handling action combination depends upon the financial value of previous transactions by that caller.

   17. Apparatus according to any one of the preceding claims, in which the value associated with a call / call handling action combination depends upon the expected lifetime value of previous and anticipated future transactions by that caller.

   18. Apparatus according to any one of the preceding claims, comprising reporting logic for generating a report indicative of the facilities costs and associated values of calls routed by the apparatus.

   19. A telecommunications arrangement comprising: one or more call centres each providing human operated and/or automated voice and/or data call handling actions; and routing apparatus according to any one of the preceding claims, the routing apparatus being arranged to route incoming calls to the call handling actions provided by the one or more call centres.

   detecting an operator-controlled transaction weight associated with each transaction type; associating a value with each call / call handling action combination, the value depending on at least the call handling action, the transaction type and the transaction s weight; and storing data representing facilities costs and associated values in respect of currently active calls which has been routed by the call routing logic; responsive to data stored in the memory to route each call to one of the call handling actions so as to aim towards a desired relationship between the aggregate facilities cost and lo the aggregate value of that call and other currently active already-routed calls.

   24. A method according to claim 23, in which one or more call centres provide human operated and/or automated voice and/or data call handling actions.

   25. A data processing method for providing routing decision data to routing logic arranged to route incoming voice and/or data calls, being responsive to a transaction type relating to an incoming call, there being several different call handling actions relating to that transaction type; the method comprising the steps of: deriving a facilities cost for each call in respect of each possible call handling action relating to that call, the facilities cost depending on at least telecommunications charges associated with that call; detecting an opeiator-controlled transaction weight associated with each transaction type; associating a value with each call / call handling action combination, the value depending on at least the call handling action, the transaction type and the transaction weight; storing data representing facilities costs and associated values in respect of currently active calls which has been routed by the call routing logic; and so responsive to data stored in the memory, indicating, to the call routing logic, that one the call handling actions which will most closely result in a desired relationship between the aggregate facilities cost and the aggregate value of that call and other currently active calls which have been routed by the call routing logic.

   20. Data processing apparatus for providing routing decision data to routing logic arranged to route incoming voice and/or data calls, the apparatus being responsive to a transaction type relating to an incoming call, there being several different call handling actions relating to a transaction type; the apparatus comprising: means for deriving a facilities cost for each call in respect of each possible call handling action relating to that call, the facilities cost depending on at least telecommunications charges associated with that call; an operator control for setting a transaction weight associated with each transaction lo type; means for associating a value with each call / call handling action combination, the value depending on at least the call handling action, the transaction type and the transaction weight; a memory for storing data representing facilities costs and associated values in respect of currently active calls which has been routed by the call routing logic; and means responsive to data stored in the memory for indicating, to the call routing logic, that one the call handling actions which will most closely result in a desired relationship between the aggregate facilities cost and the aggregate value of that call and other currently active calls which have been routed by the call routing logic.

   21. Call routing ardor handling apparatus substantially as hereinbefore described with reference to the accompanying drawings.

   22. Data processing apparatus substantially as hereinbefore described with reference to the accompanying drawings.

   23. A method of routing voice and/or data calls, the method comprising the steps of: detecting a transaction type relating to an incoming call, there being several different call handling actions relating to a transaction type; deriving a facilities cost for each call in respect of each possible call handling action relating to that call, the facilities cost depending on at least telecommunications charges associated with that call; 26. A call routing and/or handling method substantially as hereinbefore described with reference to the accompanying drawings.

   27. A data processor method substantially as hereinbefore described with reference to s the accompanying drawings.

   28. Computer software having program code for carrying out a method according to any one of claims 23 to 27.

   lo 29. A providing medium by which software according to claim 28 is provided.

   30. A medium according to claim 29, the medium being a storage medium.

   31. A medium according to claim 29, the medium being a transmission medium.