GB2526876A - Database processing - Google Patents

Abstract

A method in which customer data is exchanged between a contact centre and a customer database server comprises operating a proxy server 160 between the contact centre and the customer database server 100 and detecting, at the proxy server 160, a subset of customer data being exchanged between the contact centre and the customer database server. Data items in the subset of customer data are associated with a current contact between a contact centre agent and a current customer. The identity of the customer can be detected from the data items in the subset, and the subset can exclude personal identification data.

Description

DATABASE PROCESSING

The present invention relates to database processing, for example in relation to a contact centre.

The use of contact centres as a means of interfacing between businesses and customers is now well established. An example of a contact centre is a call centre in which multiple operators or agents acting on behalf of a business speak in turn to customers, either as outgoing calls for marketing purposes or the like or in response to incoming calls from the consumers, for example to service enquiries or purchases made by the customers.

In general terms, customer satisfaction in relation to the customer's experience with the contact centre is very important to the businesses concerned. Not only is there a danger that a dissatisfied customer may move his or her custom elsewhere, but also the dissatisfied customer may relate his or her negative experiences to other potential customers. On the other hand, a highly satisfied customer may recommend the business to others.

However, amongst all the other performance metrics which may be used to assess the operational performance of contact centre routing software and the like, and the work performance of contact centre agents, customer satisfaction is in fact difficult to measure. It is possible to ask the customer, for example by means of a customer survey, whether the customer is satisfied with his or her experience with the contact centre. However, there is a danger that many customers would ignore such a survey or even resent the time it would take.

It is possible to automate the analysis of some aspects of a customer's experience associated with the customer's use of a contact centre, but a difficulty in this context is detecting the customer's identity. While it is not necessary, for the purposes of this type of analysis, to know any personal details of the customers such as name or address, it is useful to be able to tie together different instances of the same customer's interaction with the company, for example through its contact centre. It has been proposed that aspects such as the customer's incoming telephone number could be used as a proxy for customer identity, but this is subject to potential inaccuracies in situations such as multiple customers telephoning via an office switchboard, or customers using telephone services which do not indicate the customer's telephone number or -as with some voice over internet protocol (VOIP) services -give a false caller identity associated with an access point of the service rather than the individual customer.

It is a constant aim to improve the technology and operation of contact centres.

The invention is defined by claim 1.

Further respective aspects and features of the invention are defined by the appended claims.

Embodiments of the invention will now be described with reference to the accompanying drawings in which: Figure 1 is a schematic diagram of contact handling apparatus associated with a contact centre; Figure 2 schematically illustrates the use of customer relationship management (CRM) databases; Figure 3 is a schematic diagram of a CRM database; Figure 4 schematically illustrates a proxy server; Figure 5 is a schematic flowchart illustrating operations of the proxy server of Figure 4; Figure 6 schematically illustrates a data analyser; Figure 7 schematically illustrates an aspect of the operation of the data analyser; and Figure 8 is a schematic diagram of a data processing system.

Referring now to the drawings, Figure 1 is a schematic diagram of contact handling apparatus associated with a contact centre.

In the discussion which follows, the term "call", referring to a voice call, may be used as an example of a more generic "contact", which can include not only voice calls but also Internet chats, e-mails and the like. Accordingly, unless the technical context specifically requires it, any references to "calls", "chats", ore-mails" should be treated merely as examples of contacts.

Incoming calls are initially handled by an interactive voice response (IVR) unit 10 which, in an automated manner, obtains information from the caller about the nature of the call by using one or more menus 20 and accepting user input in response to those menus. For example, the user input may be in the form of spoken words which are recognised by speech recognition modules within the IVR 10 or by keystrokes on a telephone keypad for example. A further source of user input relates to the telephone number which the user dialled to access the contact centre. For example, a contact centre may have several telephone numbers all of which generate calls which are passed to the IVR 10 for handling. One telephone number may relate to general enquiries whereas another telephone number may relate to emergency situations such as a lost or stolen credit card. By detecting which number was originally dialled, the IVR 10 can make an initial assessment of the probable nature of the incoming call. To illustrate this, Figure 1 schematically shows two dialled numbers, dialled number A and dialled number B, being initially routed to two different instances of the menus 20. Generally speaking, however, if the user has called using the wrong dialled number, the menu systems are established to allow the user to re-enter the correct part of the IVR menu system.

In the case of an internet chat or email contact, the IVR may be augmented or replaced by a process that parses the text (and possibly, in the case of an internet chat, responds to the answers which the user has given to a set of predetermined questions) to ascertain the nature of the contact, which can trigger an automatic response or enable the email or chat to be queued for the appropriate group of agents.

Once the nature of a contact or call has been detected by the IVR 10, the call is passed to a routing engine 30 which routes the call to a human operator or agent 40. There may be an intervening stage of queuing during which the call is held in a queue awaiting the aftention of an agent 40 if there are insufficient agents free at that time to handle the call straightaway.

Ultimately, the call is (or at least should be) passed to an individual agent 40 for handling. If necessary, the agent can transfer the call to another agent, for example if an enquiry arises for which the initial agent does not have the necessary skill or knowledge.

A call processor 50 receives call data 60 from the 1W and from the routing engine and detects aspects of the handling of each call or contact using techniques to be discussed below.

In some embodiments, the call processor provides a routing control signal 70 to control or influence the operation of the routing engine 30 so that acting together, the call processor 50 and the routing engine 30 may be considered as an example of a contact (or call) routing apparatus implementing a contact (or call) routing method.

A final feature of Figure 1 is a voice recorder 90 associated with the IVR. The voice recorder 90 is operable to record user calls, either for every call as received or on a selective basis for a subset of calls. Of course, if the contact type is other than a call, for example an Internet chat, the functionality of the voice recorder 90 can be replaced or augmented by a log of the textual content of the Internet chat.

It will be appreciated that aspects of the apparatus shown in Figure 1, and of apparatus described elsewhere in the present description, may be implemented at least in part by software-controlled data processing apparatus. Such software, and a storage or other medium by which such software is provided, such as a machine-readable non-transitory storage medium (for example, a flash memory or a magnetic or optical disk) are also considered as embodiments of the present invention.

Figure 2 schematically illustrates the use of customer relationship management (CRM) databases. CRM databases store details about customers such as information relating to customer accounts, contact details, details of previous interactions between that customer and the database owner (for example, the company operating or commissioning the contact centre discussed above) and for like. A CRM database as such is therefore representative of established technology. The present techniques relate to interaction with such CRM databases.

In the arrangement of Figure 2, an individual organisation has multiple CRM databases.

This is typical of current technology; different departments or functions within an organisation can often be linked to different respective CRM databases, even though the organisation as a whole shares its customer base. Purely by way of example, part of an arrangement relating to an organisation such as a bank is illustrated. Here, three independent or quasi-independent CRM databases 100, 102, 104 are provided and operated by the organisation, with one of the CRM databases 100 being accessible by the agents 40 of the contact centre discussed above, another CRM database 102 being accessible by the IVR 10 of Figure 1 the third ORM database 104 being accessible by automatic teller machines (AIMs) 110. It will be appreciated that in the normal course of operation of a bank, there are likely to be other types of interaction between the bank as an organisation and its customers (for example, counter service, Internet banking and the like) which may have their own CRM databases, but for the sake of simplicity of the present description, only three CRM databases are shown in Figure 2. In each instance in Figure 2, the CRM databases are accessible by the respective functional business unit shown.

However, coordinating the accuracy and updating of data between the CRM databases, and indeed linking customer records between the databases on a customer-by-customer basis, can be problematic.

Figure 3 is a schematic diagram of a CRM database, for example the CRM database accessible by the agents 40 in Figure 2. At a very basic level, the agents use a keyboard to request data from the CRM database and to input new data into the CRM database.

Examples of requests might include obtaining a customer's payment details or account balance.

Examples of new data might include changes of status provided by the customer in the course of a call or details of a new application by the customer, for example for a personal loan or a new account. A display 130 receives data from the CRM database and displays it to the agent 40.

In practice, the keyboard 120 and display 130 may form part of a terminal apparatus 140 used by the agent 40. The terminal apparatus 140 communicates with the CRM database 100 over a network link 150, so that in a practical situation, a single CRM database 100 may communicate with multiple terminals 140.

According to the present techniques, a so-called proxy server is used as an intermediate between the terminals 140 and the CRM database (such as the CRM database 100).

Figure 4 schematically illustrates an example of a proxy server 160. The proxy server is positioned, in terms of a data communication path, between the terminals and the CRM database 100. From the point of view of a terminal 140, the terminal simply accesses the proxy server 160 via the network link 150 and receives back from the proxy server 160 the required data. So, the arrangement is such that the terminal 140 may be unaware that the proxy server 160 is not in fact the CRM database 100 itself In turn, the proxy server 160 passes on requests for information to the CRM database 100 via a data link 170 and receives back from the CRM database 100 the required data. So, when the proxy server 160 receives an input from a terminal 140, the proxy server 160 passes on that input to the CRM database 100. When the CRM database 100 provides the required output data in response, the proxy server 160 passes on that output data to the appropriate terminal 140. The proxy server 160 and the CRM database 100 therefore cooperate to provide a CRM system 180 which, from the point of view of a terminal 140, appears to act conventionally as a CRM database.

However, the proxy server 160 also has a further data input and/or output 190. Details of the operations relating to this input and/or output 190 will be discussed further below. As part of this functionality, the proxy server comprises an analyser 195 which acts on the data passing in either direction through the proxy server and also, optionally, on other inputs.

As discussed below, the arrangement of Figure provides an example of a proxy server disposed in a data path between a contact centre and a customer database server so that customer data exchanged between the contact centre and the customer database server pass through the proxy server; the proxy server comprising: a detector configured to detect a subset of customer data being exchanged between the contact centre and the customer database server; and a processor configured to associate data items in the subset of customer data with a current contact between a contact centre agent and a current customer.

Figure 5 is a schematic flowchart illustrating operations of the proxy server of Figure 4.

At a step 200, the proxy server 160 receives data. This could be a receipt of data from a terminal 140, or it could be a receipt of data from the CRM database 100. At a step 210, the analyser 195 detects whether the data being transferred, or at least a part of it, is relevant according to a set of criteria. If so, then at a step 220 the proxy server saves a copy of that data or data part and passes control to a step 230. If not, control is passed directly from the step 210 to the step 230. At the step 230, the data received at the step 200 is forwarded in the normal manner associated with operation of a proxy server. That is to say, if the data was received from the CRM database 100, itis forwarded to the appropriate terminal 140. If the data was received from a terminal 140, it is forwarded to the CRM database 100.

This process therefore provides an example of a data processing method in which customer data are exchanged between a contact centre and a customer database server, the method comprising: operating a proxy server between the contact centre and the customer database server; detecting, at the proxy server, a subset of customer data being exchanged between the contact centre and the customer database server; and associating data items in the subset of customer data with a current contact between a contact centre agent and a current customer.

Two aspects of the operations discussed above will now be clarified further. These relate to the steps 210, 220. They will be described further with reference to Figures 6 and 7.

Figure 6 schematically illustrates the data analyser 195 which, in some embodiments, may form part of the proxy server 160. In other embodiments, the analyser 195 may be a separate device such as a separate server connected for data communication with the proxy server 160 by a data link.

The analyser 195 receives various data inputs. One class 240 of data input provides an indication from the IVR 10 and/or the contact details of a current contact associated with an agent as to the customer which the agent is currently dealing with. A second set 250 of data comes from the operation of the proxy server 160 to obtain CRM information (at the step 220).

A third set 260 of data provides criteria by which the step 210 selects data items to be passed to the step 220 out of all of the data available to the proxy server 160.

Considering the criteria 260, one example of such criteria is such as to exclude personal data such as the name, address or other traceable identifier relating to a customer. In respect of such data items, they are deemed not relevant by the step 210 and are passed directly to the step 230 of Figure 5. Other data is separated and passed to the step 220. Note that the customer may still be identified from data in such other data, but simply in order to distinguish that customer from other customers, and not necessarily in a way which divulges personal contact detail of the customer.

The data 240 from the IVR and the agent are used to provide an indication of which customer is being communicated with at the time that the access to the CRM database 100 is made. Additionally, this data 240 can provide an indication of aspects of the customer experience leading to the interaction with the CRM database, for example: (a) the customeis path through the IVR, (b) the identity of the agent which the customer is dealing with, (c) the number of agents the customer has dealt with and so on. All of this data can be assembled into an overall indication of the customer's experience in dealing with the company concerned.

Alternatively or in addition, the data can be stored, for example according to customer identifier, in a shadow database 185 which can also store details of the items (a), (b), (c) listed above.

Figure 7 schematically illustrates an aspect of the operation of the data analyser.

As discussed above, the analyser 195 serves to combine (by means of a combining function 300) information 310 from the operation as the CRM proxy, information 320 from the IVR (for example from the analyser 80) and information 330 from other sources. The use of the data from the CRM proxy allows individual customers to be identified, albeit by anonymised data such as customer identifiers (excluding personal details such as personal identification data relating to the current customer as discussed above), and the customer's total experience in passing through the IVR and contact centre, as well as other aspects of the customer's interaction with the company, to be linked and assessed.

In an example mode of operation, the data analyser 195 collates information relating to a single customer (identifiable, in an anonymised way, from the CRM proxy information) into a schedule of data defining successive customer interactions with the organisation responsible for the contact centre, thereby associating data relating to successive instances of the current customer's interaction with an organisation responsible for the contact centre and the customer database server. An example of such a schedule, with each entry having an associated data and time (not shown) might be: IVR contact: typed four keys, spent 1 minute 30 seconds Agent contact: 3 minutes 23 seconds Automatic teller machine operation Website access: seven distinct pages, nine minutes 11 seconds IVR contact: typed seven keys, spent 2 minutes 05 seconds Agent contact: 4 minutes 11 seconds Purchase: new mortgage product From this string of entries, and its associated outcome (whether positive, in terms of a purchase, negative, in terms of an account closure or complaint, or neutral in terms of no specific outcome), it is possible to ascertain the customer's "journey" through the organisation's S systems. This would not be possible without the ability, as discussed above, to associate customer identities (even if anonymised) with different aspects of the customer journey.

Figure 8 is a schematic diagram of a data processing system, for example the type which can be used to implement the proxy server 160 and the analyser 195. A bus structure 400 links various components, examples of which include a central processing unit (CPU) 410, a random access memory (RAM) 420, a read only memory (ROM) 430, a non-volatile storage device such as a hard disk drive (HOD) 440, a user interface (UI) 450 which may include, for example, input devices such as a keyboard, mouse and the like and an output device such as a display, and an interface (I/F) 464 providing data connections to and from (for example) the terminals 140 and the CRM database 100.

In operation, the CPU 410 executes computer software to provide the functionality described above. The computer software may be stored, for example, by the ROM 430 and/or by the HDD 440. It will be appreciated that in embodiments in which at least part of the functionality described above is provided by software-controlled data processing apparatus of the type illustrated schematically in Figure 8, such software, and a storage or other providing medium (for example, a machine-readable non--transitory storage medium such as the ROM 430 or the HDD 440) are also considered to represent embodiments of the present disclosure.

Claims (7)

1. CLAIMS1. A data processing method in which customer data are exchanged between a contact centre and a customer database server, the method comprising: operating a proxy server between the contact centre and the customer database server; detecting, at the proxy server, a subset of customer data being exchanged between the contact centre and the customer database server; and associating data items in the subset of customer data with a current contact between a contact centre agent and a current customer.
2. 2. A method according to claim 1, comprising the step of: detecting the identity of the current customer from the data items in the subset.
3. 3. A method according to claim 2, comprising: associating data relating to successive instances of the current customer's interaction with an organisation responsible for the contact centre and the customer database server.
4. 4. A method according to any one of claims 1 to 3, in which the subset of customer data excludes personal identification data relating to the current customer.
5. 5. Computer software which, when executed by a computer, causes the computer to carry out the method of any one of the preceding claims.
6. 6. A machine-readable non-transitory storage medium which stores computer software according to claim 5.
7. 7. A proxy server disposed in a data path between a contact centre and a customer database server so that customer data exchanged between the contact centre and the customer database server pass through the proxy seiver; the proxy server comprising: a detector configured to detect a subset of customer data being exchanged between the contact centre and the customer database server; and a processor configured to associate data items in the subset of customer data with a current contact between a contact centre agent and a current customer.