METHOD AND SYSTEM FOR SELECTIVELY DEDICATING RESOURCES FOR RECORDING DATA EXCHANGED BETWEEN ENTITIES ATTACHED TO A NETWORK

Abstract

Recording resources are selectively dedicated for recording data exchanged between entities attached to a network including at least one agent in an enterprise, a user, and a server connected to the agent and the user. At least one interconnection point is selected among interconnection points in the network including one or more points between the user and the server, between the server and a data distributor connected to the user and the agent, and between the agent and the server for recording the exchanged data Recording resources are dedicated to the selected interconnection point for recording the exchanged data based on an objective for recording the data.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part of commonly assigned U.S. patent applications Ser. No. 10/061,469, 10/061,489, and 10/061,491 filed Jan. 31, 2002 and hereby incorporated by reference. This application is also a continuation-in-part of commonly assigned U.S. patent application Ser. No. 10/058,911, filed Jan. 28, 2002 and hereby incorporated by reference. This application is also related to copending, commonly assigned U.S. Patent Applications entitled “Methods and System for Categorizing and Cataloguing Recorded Interactions”, “Method and System for Providing Access to Captured Multimedia Data from a Multimedia Player” and “Method and System for Presenting Events Associated with Recorded Data Exchanged Between a Server and a User”, filed on the same day as the present application and hereby incorporated by reference.

BACKGROUND

The present invention is directed to a method and system for selectively dedicating recording resources. More particularly, the present invention is directed to a method and system for selectively dedicating recording resources for recording data exchanged between entities attached to a network.

For systems employing interactions between a user and server, it is often desirable to be able to view the interactions, ideally in a manner that is transparent to the user. This is particularly desirable in a context such as sales, customer service, and e-commerce, where interactions between customers and a service provider are important indicators of customer satisfaction. As enterprises grow, it is important to keep track of interactions between agents of the enterprise and other parties. For example, as businesses grow, it is important to keep track of customer service contacts.

Attempts have been made to record and replay interactions between a server and a user. However, these attempts are typically implemented at the server and are thus suitable only for a particular type of server. In addition, these approaches typically do not distinguish between interactions that are considered important and interactions that are not important. Thus, a lot of time and resources are wasted on replaying unimportant recorded interactions.

Another problem with conventional attempts for recording and replaying interactions is that recording resources are not typically handled efficiently. Depending on the data to be recorded, the point(s) in the network at which recording would be most efficient and/or optimal may vary. However, recording resources are typically designated for recording from a predefined point in the network, regardless of what type of data exchange is to be recorded. In many typical implementations, the recording resources are lumped together in a pool, and resources are assigned from this pool to the predefined point on an as needed basis. This pool of resources may become exhausted, leaving none available if additional recording is demanded. Thus, the conventional approach to assigning recording resources does not efficiently or optimally assign recording resources.

There is thus a need for a technique for dedicating recording resources for recording data exchanges between a server and a user in an efficient and optimal manner, depending on the type of interaction to be recorded.

SUMMARY

The present invention is directed a method and system for selectively dedicating resources for recording data exchanged between entities attached to a network including at least one agent in an enterprise, a user, and a server connected to the agent and the user.

According to exemplary embodiments, at least one interconnection point is selected among interconnection points in the network including one or more points between the user and the server, between the server and a data distributor connected to the user and the agent, and between the agent and the server for dedicating recording resources to record the exchanged data. Recording resources are dedicated to the selected interconnection point for recording the exchanged data based on an objective for recording the data.

According to one embodiment, the interconnection points between the user and the server and between the agent and the server may each include one or more passive taps from which the exchanged data is recorded, and the interconnection point between the server and the data distributor may include one or more active taps from which the exchanged data is recorded. A passive tap or an active tap may be selected, depending on an objective for recording the exchanged data. For example, when the objective is to record high volumes or 100% of the captured data, a passive tap may be selected.

According to another embodiment, the interconnection point between the user and the server or between the agent and the server is chosen when the objective is to record substantially all of the exchanged data. When the objective is to record only a portion of the exchanged data, e.g., for quality monitoring, the interconnection point between the server and the data distributor is selected for dedicating the recording resources for recording the exchanged data.

According to another embodiment, the interconnection point between the user and the server is selected for dedicating the recording resources when the objective is to record a data exchange from the user's perspective. The interconnection point between the server and the agent is selected for dedicating the recording resources when the objective is to record a data exchange from the agent's perspective.

Further objects, advantages and features of the present invention will become more apparent when reference is made to the following description taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1A and 1B illustrate a system for selectively recording exchanged data according to an exemplary embodiment;

FIG. 2 illustrates an exemplary system for selectively recording exchanged data in which the invention may be implemented;

FIGS. 3A and 3B illustrate details of an application server for dedicating recording resources according to an exemplary embodiment; and

FIG. 4 illustrates an exemplary method for dedicating recording resources according to an exemplary embodiment.

DETAILED DESCRIPTION

According to exemplary embodiments, a method and system are provided for selectively recording interactions between entities attached to a network using recording resources selectively dedicated to recording data from particular interconnection points in the network.

According to exemplary embodiments, captured data exchanged between a server and a user is selectively processed. In the following description, the server is referred to as a web server, and the user is referred to as a web browser. It will be appreciated, however, that the invention may be applicable to other types of servers and users.

FIG. 1A illustrates an exemplary system for recording, capturing, and playing back interactions in which the invention may be implemented. The system includes a server, such as a web server 100, a data capturing module, such as a page capture module 110, and a user, such as a web browser 120. Although only one web server 100, page capture module 110, and web browser 120 are depicted in FIG. 1A, it will be appreciated that the invention is applicable to any number of servers, data capturing modules, and users.

The web browser 120 may be implemented in a personal computer, a telephone, etc. The web server 100 may be implemented as a server supporting any operating system, e.g., Unix, Linux, NT or Windows 2000.

The page capture module 110 is arranged between the web server 100 and the web browser 120. For security purposes, a firewall 115 may separate the web browser 120 and the page capture module 110.

The page capture module 110 operates independently from the web server 100 and the web browser 120. Thus, the page capture module 110 does not need to be customized for each type of web server but may be used with any web server, supporting any operating system.

Although the page capture module 110 operates independently from the web server 100 and the web browser, it may be implemented in the same device as the web server 100 or the web browser 120.

The page capture module 110 captures pages and other data exchanged between the web server 100 and the browser 120. Pages and other data may be captured continually or at designated intervals or time windows. The page capture module 110 may also record these pages and other data, or recording may be performed in a separate recorder server connected to the page capture module.

Each web browser 120 is assigned a unique machine identity (ID) by the web server 100. A persistent machine ID cookie may be created by the web server 110 and stored at the web browser 120 for this purpose. All pages served to a particular web browser 120 are identified and grouped by the machine ID.

Although the module 110 is described as a page capture module, according to exemplary embodiments, other types of data may also be captured. For example, events and attributes may be captured. Attributes may be captured in a manner similar to that in which pages are captured, as described above.

For event capturing, according to an exemplary embodiment an event capture module captures user side events and delivers these to the page capture module 110. The event capture module may be implemented as an applet 130 that is downloaded to the web browser 120. Although shown as a separate component, the event capture applet 130 is stored at the browser, with parameters such as the web browser machine ID, the host Internet Protocol (IP) address, and the current page name. The event capture applet 130 may be notified, for example, by JavaScript embedded in the current page, whenever an event needs to be recorded. The event capture applet 130 records events such as: page load, page unload, page scroll, page resize, and browser exit. The event capture applet 130 sends captured events to the page capturing module 110 via, for example, a Transmission Control Protocol/Internet Protocol (TCP/IP) socket connection on port 80 (or port 443 for secure exchanges).

Pages and other data captured during exchanges between the web server 100 and the web browser 120 at the page capture module 110 are sent from the page capturing module 110 to a page preprocessor 125 via, e.g., a TCP/IP socket.

According to an exemplary embodiment, each captured page is assigned a unique page ID and is associated with a specific browser user machine ID. Each page may also contain the date and time that the page was captured and the page status (recording, processing, playback, etc.) After pages are captured, this information is extracted from the captured page, and a new record is inserted into a database 145.

The page preprocessor 125 acts as a recorder server and stores the captured data in a device such as a database 145. The pages 135 are then passed on to the page post-processor 140. Alternatively, the page capturing module 110 may perform this recording. To reduce the amount of storage necessary, only predetermined portions of data may be stored, e.g., the request portion or the response portion. Also, only data satisfying predetermined rules, e.g., rules indicating timing, may be stored. When the captured pages are recorded, identifying information may also be recorded, e.g., a session record ID, a date/time of recording, a machine ID, etc.

An exemplary page capturing module and an exemplary page preprocessor are described in more detail in the afore-mentioned U.S. patent application Ser. No. 10/061,469.

A post-processing module 140 determines which captured data satisfies predefined rules, e.g., business rules, and records this data in a file 180, such as a Java Archive (JAR) file. The database 145 is updated to indicate what captured data has been selected and recorded for playback. This is described in more detail below with reference to FIG. 1B.

A playback tool 190 selects recorded data from the database 180, using the information in the database 145. An exemplary playback tool is described in more detail in the aforementioned U.S. patent application Ser. No. 10/061,491.

Although not shown in the interest of simplifying the illustrations, it will be appreciated that the system in FIG. 1A may also include other components, e.g., configuration files used for processing.

FIG. 1B illustrates in detail an exemplary system for processing captured data according to an exemplary embodiment. Captured and recorded pages, attributes, and events are fed to a page post-processing program running on a page post-processor 140. A business rules engine 150 delivers business rules to the post-processor 140 that evaluate the captured/recorded pages to determine whether they satisfy the business rules.

The terminology “business rules” has a commonly accepted meaning in the art and in this context refers to business elements for comparison with captured data in real time. Examples of comparison of captured data with business rules include determining whether an interaction resulted in a sale greater than a predetermined number of dollars, determining whether an interaction lasted longer than a predetermined number of minutes, etc. Also, a business rule comparison may be in the form of voice recognition. Business rule comparison may be made active or inactive on a defined schedule.

Data from a page table database 160 and a page rule table database 170 may be used during the evaluation by the business rule engine 150. Pages that satisfy the business rules are recorded for future playback. The page table and page rule database are updated after post-processing.

Further details regarding post-processing are provided in the afore-mentioned U.S. patent application Ser. No. 10/061,489.

According to an exemplary embodiment, business rules are applied to captured pages using an applications server such as the server 200 shown in FIG. 2. The server 200 show in FIG. 2 may be implemented as a Component Object Model (COM) based server.

According to an exemplary embodiment, the server 200 includes a business rules engine, such as the engine 150 shown in FIG. 1B, an editor, and a scheduled rules processor. The server 200 may also be connected to a business object layer (BOL) 210, a data abstraction layer (DAL) 220 and 225 and a repository or database 230. The components 210, 220, 225 and 230 may be included in the server or as one or more separate entities.

Attributes of contacts and metadata may be stored in the database 230, as well as business rule data populated and manipulated by the editor. The server 200 communicates with the database 230 to obtain the business rules. The engine 150 applies the business rules to the captured data and communicates with a recorder server 240 for recording the captured data that satisfies predetermined business rules.

The business rules editor may be a Java applet running in a browser (e.g., MSIE or NN) on the client machine such as the computer 250 shown in FIG. 2. The applet may communicate to COM objects on the server 200 using a COM-Java bridging tool. This provides the capability for the applet to access the COM objects as though they were Java objects. The editor applet may be integrated with a category manager and user security administrator applets into what appears to the user to be one application The BOL 210 interfaces with both the business rule editor applet and the DAL 220 and 225 to manage traffic to and from the database 230.

The server 200 communicates with a client computer, such as the computer 250, which may be used by an agent. The client computer may be implemented as a browser-based application, utilizing Java applets and HTML, and interfacing with some COM-Java bridging tool (Jintegra or R-JAX) to allow the Java-based client to communicate with the COM-based server.

The recorder server 240 communicates with an end user via, e.g., a phone switch 260 and a PSTN 270. The phone switch also referred to as a “data distributor” may include, e.g., a private branch exchange (PBX) and an automatic call distributor device (ACD).

According to an exemplary embodiment, only captured data that satisfies predetermined business rules is recorded. According to this embodiment, the server 200 selects data from data exchanged over the network connecting the server 200, the client 250, and the user 280 that satisfies predetermined business rules. Captured attributes and content are analyzed in, for example, the BRE 150 at the server 200, to determine whether they satisfy predetermined business rules. Data that satisfies these rules may be recorded in a database 230. A user may be notified of customer contact center transactions.

According to another embodiment, all captured data may be recorded, and the data that does not satisfy predetermined business rules may be discarded. This ensures that the entire interaction is captured. If the storage capacity is large enough, this can, in effect, capture interactions in the past.

According to yet another embodiment, only portions of captured data may be recorded. This partial recording may be most beneficial for purposes such as transaction verification in which partial samples are sufficient.

According to another embodiment, data may be captured by capturing only changed areas of an agent's screen to minimize network utilization. This is described in more detail in commonly assigned U.S. Pat. No. 5,790,798, incorporated herein by reference.

According to another embodiment, random agent monitoring and event monitoring are provided in which a percent of contacts is automatically monitored and recorded for future playback. Live monitoring may also provided, in which monitoring for both voice and data or real-time contacts may be initiated, and these contacts may then be recorded. This sampling may be most beneficial for purposes such as quality monitoring, in which samples of interactions are sufficient.

According to another embodiment, one or more agents 250 may also initiate recording of real-time contacts, e.g., when there is a serious complaint or customer feedback about a new product or service that is being provided to a customer. Agents may also disable monitoring for a particular call for various purposes, e.g., if a customer requests it for legal purposes.

According to an exemplary embodiment, exchanged data may be recorded from one or more points between the user 280 and the phone switch 260, between the phone switch and the server 200, or between the client (agent) 250 and the server 200. Points between the user 280 and the phone switch 260 may be referred to as “trunk-side points”, points between the server 200 and the phone switch 260 may be referred to as “service observation points”, and points between the agent 250 and the server 200 may be referred to as “station-side points”. The determination of which point to record from may be performed by the server 200.

According to exemplary embodiments, the server 200 selectively dedicates recording resources for recording data from one ore more points within the network. For this purpose, the server includes a media channel broker that assigns available recording resources from a media list for recording from one or more interconnection points that are selected based, e.g., on the objective(s) for recording the data. The channel media broker may be contained in a content manager 155 shown as part of a system shown in FIG. 3A and FIG. 3B.

Referring to FIG. 3A and 3B, the content manager 155, which manages how content is recorded, communicates with a contact manager 151. The contact manager 151 manages contact folders in which contacts/exchanged data is recorded. The contact manager 151 is in communication with the business rules engine 150 for mapping business rules to folders. The business rules engine 150, in turn, is in communication with a BOL 510 that communicates with the database, e.g., through the DAL 520.

As shown in FIG. 3B, the contact manager 151 may communicate with the business rule engine 150 via an internal event notification service 156. The internal event notification service 156 controls notification of event occurrence through the email notification service 158 and the pager notification server 157. Notification is described in more detail in the afore-mentioned U.S. Patent Applications entitled “Methods and System for Categorizing and Cataloguing Recorded Interactions” and “Method and System for Providing Access to Captured Multimedia Data from a Multimedia Player”.

As shown in both FIGS. 3A and 3B, the contact manager is 151 also in communication with the client via a call or session manager 152 that manages sessions, a DCOM interface 153, and a CTI adapter 555. The contact manager 151 also communicates with the event persistence 154, e.g., through the internal event notification service 156. The event persistence 154 maintains events and permits a user to jump to a point in a contact at which an event occurred. The event persistence 154, in turn, communicates with the database 530.

Also shown in FIG. 3B are a scheduler 159 and a live monitoring and playback service 161. The scheduler 159 coordinates scheduling of event occurrence. The live monitoring and playback service 161 controls playback of recorded data and live monitoring of data and is connected via a playback socket to a user desiring to playback or monitor the data.

The components to the right of the dashed-dotted lines in FIGS. 3A and 3B may be implemented, e.g., in an application server 200. Alternatively, some of the components shown to the right of the dashed-dotted lines in FIGS. 3A and 3B may be implemented as separate entities.

According to an exemplary embodiment, the content manager 155 takes into account one ore more objectives for recording the data for selecting which point(s) in the network to record from.

Another objective for recording the data may be for recording only a portion of the exchanged data. This may be useful for quality assurance monitoring, when only a few samples of data are needed. According to exemplary embodiment, the service observation point is best suited for recording data for this objective. The service observation point typically leverages a pool of resources (service observation ports) on a user's phone switch. This is best suited for customers who are interested primarily in quality assurance sampling or otherwise very low volume recording.

Service observation ports are typically provisioned for a relatively small percentage of the overall number of agents that might be monitored. Thus, it is possible to run out of these ports at certain times. Thus, the service observation point may not be suitable when larger percentages of data needs to recording.

Another objective for recording the data may be for recording 100% or a high volume of interactions. This may be useful for sales verification where an agent needs to record the customer's consent to purchase a product, and a recording resource needs to always be available. The agent (station) side interconnection point can handle a designated recording resource for each agent telephone that is capable of being recorded. The trunk-side interconnection point can handle dedicated recording resources for each trunk (or telephone line) that is capable of being recorded. Also, passive taps, such as those that may be included at the trunk side and at the station side do not require monitoring while active taps, such as those that may be included at the service observation port, do require monitoring, e.g., at the switch (PBX). Thus, for recording a large number of interactions, the station-side interconnection point and the trunk side interconnection would likely be most suitable.

Another objective for recording the data may be to record the data from a particular entity's perspective, e.g., the user's perspective. This may be useful, for example, if a call from a user is not completed and never deliver to the agent. With agent-side recording, the call must first have been connected to an agent in order to record. Thus, agent-side recording may not be a suitable implementation for this condition. With trunk-side recording, the call may be captured as the customer navigates his or her way through eh interactive voice response system (IVR) system that asks for the customer's account number, PIN, etc. This allows the entire call center transaction to be captured form the customer's perspective.

It will be appreciated that the recording objective may also be to record data from the agent's perspective or from the station's perspective. For these cases, agent-side recording and service observation point recording would be selected, respectively.

According to an exemplary embodiment, objectives for recording data may correspond to one or more business rules that are applied to determine what data is recorded.

For example, if an objective for recording data is to record a 3% random sample of all agent calls for quality assurance purposes, a business rule may be created that indicates that data satisfying a 3% random sample of all agent calls is to be recorded. Given the small number of calls represented by this business rules, the service observation point is the most suitable interconnection point from which to record the exchanged data. Thus, if this is the business rule to be applied, a service observation point would be selected as the interconnection point from which to record the exchanged data.

As another example, if an objective for recording data is to record 100% of those calls that have results in the sale of a particular product, a business rule may be created that indicates that 100% of data resulting in the sale of that particular product should be recorded. Since the station-side points and the trunk-side points are the most suitable for 100% recording, either or both of these points may be selected as the interconnection point(s) from which to record the exchanged data.

As yet another example, if an objective for recording data is to record 100% of those calls where the customer transaction ended “in” the interactive voice response (IVR) and was not routed to agent for handling, a business rule may be created that indicates that 100% of data ending in the IVR should be recorded. Given that the trunk-side point is the only suitable point for 100% recording and recording where the agent is not contacted, the trunk-side point would be selected as the interconnection point from which to record the exchanged data.

FIG. 4 illustrates an exemplary method for designating recording resources for recording from one or more interconnection points. The method begins at step 400 at which one or more interconnection points are selected in the network from this to record data based, e.g., on one or more objectives for recording the data. Next, at step 450, the recording resources are dedicated to the selected interconnection points(s). From this point, recording may commence.

In addition to data recording, after-call monitoring may also be provided, by which an agent's screen actions after the contact ends may be monitored or recorded. For example, an agent may wait until after the customer hangs up to enter information that could have been entered during a call. This type of situation offers an excellent training opportunity. Agents may be monitored from any point, based, e.g., on login information from the switch.

Also, customer transactions may be documented and retained by capturing the customer's verbal authorization. This voice signature capability simplifies the sale process and reduces costs by leveraging verbal rather than written authorization for certain types of transactions, such as consumer debits authorized over the telephone.

In addition, agent feedback may be provided either during a contact or after a contact, informing the agent that the contact is being recorded or has been recorded. Training may be provided to the agent as appropriate, based on the recorded interaction.

It should be understood that the foregoing description and accompanying drawings are by example only. A variety of modifications are envisioned that do not depart from the scope and spirit of the invention. The above description is intended by way of example only and is not intended to limit the present invention in any way.

Claims

1. A method for selectively dedicating resources for recording data exchanged between entities attached to a network including at least one agent in an enterprise, a user, and a server connected to the agent and the user, the method comprising the steps of:

selecting at least one interconnection point among interconnection points in the network including one or more points between the user and the server, between the server and a data distributor connected to the user and the agent, and between the agent and the server for recording the exchanged data based on an at least one objective for recording the data; and

dedicating recording resources to the selected interconnection point for recording the exchanged data.