Method and apparatus for integrating business data and transaction data in a transaction processing environment

[0002] The present invention relates generally to the processing, storing and accessing of information within an information processing system. More particularly, the present invention relates to tracking and storing information about individual transactions for report generation.

[0003] Modem enterprises require the ability to collect detailed information about day to day activity such as changes in inventory, transactions with customers, and number, length and origination location of telephone calls. Any information that would aid in operation of the enterprise or future planning for the enterprise may be collected. Typically, an enterprise such as a mail order retail business or a stock brokerage uses an information processing system that collects specified information, stores it in a database, and allows a user to selectively access and arrange (“slice and dice”) and retrieve the data.

[0004] One example of a commonly used information processing system is a system that processes transactions between the enterprise and those outside the enterprise. For example, various systems exist for receiving, routing, tracking and recording information about telephone calls to and from the enterprise. Particularly in the case of enterprises that do a significant amount of business by telephone with clients or customers, it is extremely useful to collect accurate information about customer telephone calls that can be easily and completely accessed and arranged into various report formats. As an example, a stock brokerage that takes orders by telephone would like to collect information about who a customer is, how much money the customer spends per time period, how long an average telephone call takes, how long a customer must wait to speak to an agent, how long an average telephone call lasts, what revenue an agent generates per time period, how many telephone calls an agent handles per time period, and so on.

[0005] Existing call processing systems typically receive calls coming into the enterprise and route them to various locations. An attempt is made to collect data about the calls, but data collection and storage capabilities of existing call processing systems have serious limitations. One limitation is the inability of the call processing system to store “call data” and “business data” related to a single call in one location where it can be easily accessed. This is because conventional call processing systems have limited ability to communicate with a computer terminal operated by a human agent taking a customer call. Typically, when a call is received by the system, the system routes the call to a human agent at a computer terminal, sometimes using information entered by the caller. The routed call is sent to the human agent and, simultaneously, the computer operated by the agent receives data from the system causing the computer to display relevant information to the agent, such as caller identity, caller buying history, etc. The agent conducts a business transaction with the caller, and at the end of the transaction, the agent is typically prompted by the computer to enter some “business data” about the transaction. The business data may include, for example, success, failure, revenue generated, stocks sold, etc. The business data is typically entered by the agent as a code or codes in predesignated fields of a record. The business data entered by the agent is typically written to a “local” database, for example, a storage device on the computer that the agent operates. “Call data”, which includes information such as the duration of the call, the origin of the call, etc., is typically stored by the call processing system at the termination of the call connection. The call data is usually stored by the call processing system in a database that is local to the call processing system but remote from the agent's computer. The call processing system typically stores information about calls to many different agents in different locations.

[0006] In such prior call processing systems it is difficult or impossible to later extract coherent information about the entire customer call that includes both the business data and the call data. One of the reasons for this is current limitations in the communication link between the call processing system and the agent's computer. One prior call processing system uses a computer telephony integration (CTI) link to transmit American Standard Code for Information Interchange (ASCII) messages between the call processing system and an agent computer. Typically, control messages handling the call are sent from the call processing system to the agent computer during the call. These messages may include messages to indicate call connection and termination, or messages that cause a screen pop application to bring up relevant information on the agent's computer screen when the call is connected. The CTI link may also be used to transmit data from the agent computer to the call processing system during the call. This data may include business data related to the call that is entered by the agent during the call. Usually limited fields exist for the entry of business data by the agent. This limits the amount and types of business information that may be collected for a call. Another limitation of typical systems is that the CTI link is only open when the call is actually connected and is closed upon termination of the call. Therefore, the call may be disconnected before an agent has time to enter information about the call and transmit the information to the call processing system.

[0007] Conventional call processing systems thus have the disadvantage of allowing limited business data to be entered only in a narrow time window. Conventional call processing systems are also subject to error on the part of the agent in entering business data.

[0008] Existing call processing systems have additional disadvantages related to the way in which call data is collected and stored by the system for later analysis. A “call” is typically defined in a limited way that prevents complete records about a call from being collected. For example, in the case of a call that is transferred at least once after being initially received by the system, the call is typically defined as occurring between connection and disconnection, or hang up. This definition is not very accurate or useful, because the call may have included several segments during which different resources were connected, and involved several different agents and several different periods during which a calling customer was required to “hold”. It would be extremely useful to be able to identify each segment of a call and what happened during each segment in order to in order to better analyze customer needs and agent performance.

[0009] Conventional systems lack the capability of identifying every segment of a call as being part of a single call. One prior attempt to identify call segments uses a tracking number in a field of a call record. This method identifies some segments of a call, but not all possible segments of a call. As an example, when a call from a customer is connected to a first agent, a tracking number is assigned to the record created by that connection. If, however, the first agent, during the same call, calls a second agent and then connects the customer to the second agent, the segment between the customer and the second agent receives the same tracking number as the segment between the customer and the first agent, but the segment between the first agent and the second agent receives a different tracking number. Call information collected by this method may be later retrieved and analyzed to produce an inaccurate report. For example, the call duration from the customer's point of view is recorded as the time actually spent connected to the agents, while the call duration actually experienced by the customer includes the time the customer waited to be connected to the second agent. The difficulty in collecting accurate data on all segments of a call is exacerbated in the common case of a call that is handled by multiple call processing systems of a large networked system, where each call processing system may do independent data marking and storage.

[0010] In addition to these data collection limitations, conventional call processing systems typically do not store business data and call data together so that it may be easily accessed and associated with the proper call. Most business data is not transmitted from the agent computer to the call processing system, but is stored locally with respect to the agent computer, for example, in a storage device of the agent computer. Although prior systems have limited capability to store some business data and some call data while preserving the relationship of the data to the call, retrieval is usually cumbersome. For example, it is possible to provide for an indirect linkage of stored business data and stored call data for the same call by placing matching information in a predesignated field of a record in the system database (for the call data) and a predesignated field of a record in the database external to the system (for the business data). Retrieval of the data for the single call, however, requires lookups in two databases. Yet another disadvantage of conventional transaction processing systems is that collected transaction data is usually assembled in a retrievable format only periodically so that near-real-time data is not available. For example, a conventional system may allow for database queries regarding transactions that occurred no more recently than one day prior to the query.

[0011] A method and apparatus for integrating business data and transaction data in a transaction processing environment are described. One embodiment comprises a telephone call processing system including a call distribution device connected to several agent devices through one type of communication link. The call distribution device is connected to an information server through another type of communication link. The information server includes a database for storing business data associated with call data for a particular call. One embodiment includes a machine implemented method for storing data related to a call comprising transmitting a host data value from an agent device to the information server during a transaction, and, if a host data signal is received by the data warehouse during the transaction, associating the host data value with a transaction identifier and storing the host data value in the database a predetermined time after a termination of the call.

[0012] Other features of the present invention will be apparent from the accompanying drawings and from the detailed description which follows.

[0013] The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:

[0014] FIG. 1 is a block diagram of one embodiment of an information processing environment.

[0015] FIG. 2 is a block diagram of one embodiment of an information server.

[0016] FIG. 3 is a block diagram of one embodiment of a call segment data model.

[0017] FIG. 4 is a block diagram of one embodiment of an agent activity fact table.

[0018] FIG. 5 is a block diagram of one embodiment of a trunk activity data model.

[0019] FIG. 6 is a block diagram of one embodiment of a call metrics summary data model.

[0020] FIG. 7 is a flow diagram of one embodiment of a method for storing business data and call data.

[0021] FIG. 8 is a block diagram of one embodiment of a persistent buffer.

[0022] FIG. 9 is a block diagram illustrating an exemplary machine, the form of a computer system, within which a set of instructions for causing machine to perform any of the methodologies of the present invention may be executed.

[0023] A method and apparatus for integrating business data and transaction data in a transaction processing system are described. In the following description, for the purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the present invention may be practiced without these specific details.

[0024] FIG. 1 is a block diagram of an embodiment of a telephone call processing system 100. Call processing system 100 includes information server 112, which includes hardware and software for collecting and storing information regarding call transactions in system 100. Information server 112 collects, processes, consolidates and provides access to near-real-time and historical transaction data generated by, and pertaining to, multiple transaction processing systems. As described in more detail with reference to FIG. 2, information server 112 is of the type sometimes referred to as a data mart or data warehouse. Information server 112 stores multiple gigabytes of data in a database that constitutes information (e.g., both data and metadata) regarding resource configurations, transactions and other environment parameters, conditions and functions (e.g., call, agent and trunk events, fact records and summaries). In one embodiment, the database uses a data model that is an open star schema data model suitable for querying and reporting. This data model is especially suitable for online analytical processing (OLAP) and provides many benefits compared to prior relational databases. For example, the star schema facilitates ad-hoc queries and report writing. Another benefit is that the model is extensible and allows tracking of resource configuration changes, such as a new agent using an old agent's extension. Another benefit is the ability to fully link related database records. A star schema data model is generally described by Ralph Kimball in The Data Warehouse Toolkit (John Wiley & Sons, Inc., 1996).

[0025] System 100 includes call distribution system 102, which receives and processes calls from outside system 100. Call distribution system 102 may be the Aspect® automatic call distributor (ACD) system manufactured by Aspect Telecommunications Corp. of San Jose, Calif. Processing includes routing calls and logging and storing information regarding calls. Call distribution system 102 is connected to information server 112 by data link 116. Data link 116 is a point-to-point communications link. In one embodiment, data link 116 is a transmission control protocol/internet protocol (TCP/IP) link for transmitting near-real-time data between call processing system 102 and information server 112 in, for example, a C programmatic format. Call distribution system 102 is connected to multiple telephone units 126, 128, and 130 through public switched telephone network (PSTN) 124. Call distribution system 102 receives and processes incoming calls through PSTN 124. In other embodiments, call distribution system 102 is coupled to other devices (not shown) that initiate calls into system 100. For example, call distribution system 102 may be connected to a device that initiates calls to call distribution system 102 through a different network than PSTN 124.

[0026] Call distribution system 102 is connected to computer telephony interface (CTI) server 104 through application bridge 114. In one embodiment, application bridge 114 transmits American Standard Code for Information Interchange (ASCII) messages between CTI server 104 and call distribution system 102. In one embodiment, CTI server 104 is coupled to multiple agent devices, or agent computers 103 used by a human agent who participates in call transactions. The human agent may transmit messages regarding a current call transaction at any time during the call and also for a predetermined time after the call is disconnected. In one embodiment, call transaction information may be sent over the application bridge 114 for up to 30 seconds after a call is disconnected. In other embodiments, the time may be more than 30 seconds or less than 30 seconds.

[0027] Information server 112 is connected to reporting client 140 through link 124. Reporting client 140 may be any open database connectivity (ODBC) compliant application, and makes queries against the database of information server 112, and formats the results of these queries based on a predefined set of instructions (i.e., a report definition). The reporting client 140 may further include a method of scheduling reports to run at predetermined times.

[0028] Information server 112 is connected to administrator 110 through link 122. Administrator 110, in one embodiment, is an application that allows a user to view, configure, and control the operation of information server 112 through programming interfaces (APIs). Administrator 110 may be a Microsoft Foundation Class (MFC) 4.0 application, and could accordingly reside on a Windows 95, Windows NT workstation or Windows NT Server platform. Administrator 110 facilitates configuration and management of information server 112. For example, utilizing a graphical user interface (GUI) provided by the administrator 110, a user may define data sources, set data destinations, specify rules, formulas and frequencies for data summaries, view server system metadata information, events, and task statuses. Administrator 110 communicates with server components of information server 112 through an API that makes use of Remote Procedure Call (RPC) to facilitate remote management of information server 112.

[0029] Network router 108 is connected to information server 112 through data link 120. Data link 120 is of the same type as data link 116 and allows communication using ASCII messages in some predetermined format. Workflow server 106 is connected to information server 112 through data link 118, which is of the same type as data link 116. Data links 116, 118 and 120 allow transmission of a recoverable near-real-time data stream. In contrast to conventional data marts which periodically poll a data source and store the poll results in a database, system 100 collects, arranges and stores data in near-real-time so that a user may query the database is required to extract, for example, data for the preceding hour.

[0030] In some embodiments, system 100 includes multiple call distribution centers 102. In these embodiments, data from each call distribution system 102 is collected and managed by information server 112.

[0031] FIG. 2 is a block diagram of one embodiment of information server 112. Information server 112 includes data model 236, which in one embodiment, is a star schema on an Oracle database. Data engine 208 and custom applications 206 access data model 236 through ODBCs 210. Data engine 208 and custom application 206 transmit information from APIs 212 through data conduits 204. For example, data engine 208 is an information server 112 application that gathers, stores, and summarizes records received via data conduits 204. APIs 212 allow remote applications to monitor and control information server 112 and its data.

[0032] Call distribution center 234 is connected to information server 112 through a local area network (LAN) or a wide area network (WAN) and a data feed client 222. Network router 232 is connected to information server 112 through a LAN or WAN and a data feed client 220. Workflow server 230 is connected to information server 112 through a LAN or WAN and a data feed client 218.

[0033] Database maintenance applications 216 communicate with data model 236 through APIs 212. On or off board applications 224 communicate with information server 112 through a LAN or WAN and APIs 212. On or off board applications 224 include system administrator 226 and system monitor 228, which allow users to view, configure, and control the operation of information server 112. System administrator 226 and system monitor 228, in one embodiment, run on information server 112. In other embodiments, system administrator 226 and system monitor 228 run on a remote administration workstation.

[0034] Service applications 202 controls data feeds, distributes records to information server applications and manages access to information server metadata.

[0035] The data model of information server 112 implements star schemas for calls, agent and trunk events, other fact tables, and summaries. A star schema is a method of organizing data in which a central fact table contains scalar and other data, along with keys pointing to dimension tables (often referred to as dimensions) which contain descriptions of the attributes of the dimension. FIG. 3 is a diagram of an information server call segment fact table 302. Call segment fact table 302 includes flags indicating special characteristics of the call, such as whether it was the first segment of the call, whether a customer was involved, etc. Call segment fact table 302 further includes keys pointing to various dimensions such as the resource dimension for a description of the agent who handled the call, the call type dimension for a description of how the call was handled, the resource dimension again for a description of the trunk that was used for the call, and so forth. Call segment fact table 302 includes keys pointing to various dimensions. For example, call segment fact table 302 includes keys to node dimension 310, calendar_time dimension 312, call_segment_type dimension 314, call_resource_set 316, calendar_date dimension 304, business_application dimension 306, and call_resource dimension 308.

[0036] FIG. 4 is a diagram of agent activity fact table 402 and various associated dimension tables. Agent activity fact table 402 shows the type and duration of agent states, such as idle, talk, hold, and wrapup. In agent activity fact table 402, both call_resource_set_id and team_id point into the call resource set dimension 412, describing the agent's agent group and supervisor team respectively. A call_segment_id identifies the call segment, if any, associated with the agent activity. The agent activity fact table also includes keys pointing to node dimension 414, calendar_time dimension 416, resource_activity_type dimension 418, resource_type dimension 420, calendar_date dimension 406, business_application dimension 408, call_resource dimension 410, and call_resource_set dimension 412.

[0037] FIG. 5 is a diagram of trunk activity fact table 502 and associated dimension tables. In trunk activity fact table 502, records can describe events for a trunk, a voice trunk, or a trunk group. If the resource type is a trunk group and the activity type is an all trunks busy event, number_of_trunks contains the number of trunks in the trunk group. Like agent activity, trunk activity has a call_segment_id to identify the call, if any, associated with a trunk event.

[0038] Trunk activity fact table 502 includes keys to node dimension table 512, calendar_time dimension table 514, resource_activity_type dimension table 516, resource_type dimension table 518, calendar_date dimension table 504, call_resource dimension table 506, and call_resource_set dimension table 508.

[0039] FIG. 6 is a diagram of application call metrics summary fact table 602. Summary fact tables 602 summarize records from a fact table along one or more dimensions. For example, call records could be summarized along the time dimension and along the agent group dimension, creating one record summarizing all the calls processed by one agent group for a period of one hour. Summary tables use the same dimensions as ordinary fact records. Application call metrics summary fact table 602 includes keys to calendar_time dimension table 608, node dimension table 610, call_segment_type dimension table 612, calendar_date dimension table 604 and business_application dimension table 606.

[0040] In one embodiment, the present invention stores business data with call data in near-real-time in a fault tolerant manner. FIG. 7 is a flow diagram of one embodiment of call processing. Referring to FIG. 7, at 702, and FIG. 1, at 802, a call is connected from call distribution system 102 to an agent computer coupled to the CTI server 104. A host data signal (HDS) message is sent from the CTI server 104 via CTI link 114 to call distribution system 102 at 704. The host data signal message signals software on information server 112 to wait for a host data value message before writing all the information about a call to disk. This allows for the storage of business data in the call segment record. A time out value is specified on information server 112. The default is thirty seconds. This allows data associated with a call to be transmitted for up to thirty seconds after the call is disconnected. The call with which the host data is to be associated is specified by a callID field. The host data signal message has the format shown in Table 1 below.

[0041] The HDS message format also include a length field (not shown in Table 1) that conforms to the standard definition in Ethernet applications and precedes the header field.

[0042] The header identifies the host machine name for an Ethernet connection or a RS-232 connection. The header field is a variable-length alphanumeric field. The type field may be used to identify a type of HDS message as required. CallID is a 4 byte numeric field that identifies the call origination number assigned to the call by call distribution system 102.

[0043] At 706, a host data value (HDV) message is sent on CTI link 114 from the CTI server 104 to call distribution system 102. The HDV message contains information from a host application which is to be stored with the call segment record written on information server 112. This message is of variable length and can be sent at any time during the call. However, information server 112 software will only wait for this message before it writes a call segment if a host data signal message had been sent previously for the call. One embodiment of a host data value message is shown below.

[0044] A length field (not shown) precedes the header field and must include the length of the entire message including all the host information variables being sent.

[0045] The header identifies the host machine name for an Ethernet connection or for a RS-232 connection. It is a variable-length alphanumeric field. The type field may be used to identify a type of HDV message as required.

[0046] CallID is a 4 byte numeric field identifies the call origination number assigned to the call by call processing. The number of variables field is a 2 byte field that indicates a number of host information variables to follow.

[0047] Variable identifier is a 2 byte numeric field that contains the variable identifier of this host information variable (for example, 1=Customer Id, 2=Business Transaction Id, 3=Revenue). Variable identifiers of one embodiment are shown in Table 3.

[0048] The variable length field is a 3 byte numeric field contains the length of the data field following.

[0049] The data field contains the data content of the host information variable being sent.

[0050] At 708, the HDS message and the HDV message are encapsulated according to the TCP/IP format by call distribution system 102 and stored with a sequence number in a disk file on call distribution system 102. The TCP/IP format is the proper format for storage in information server 112. The TCP/IP format in which the HDS and HDV signal ASCII messages are encapsulated as partially described in Tables 4 and 5.

[0051] In one embodiment, the disk file is a persistent circular buffer 700 as shown, for example, in FIG. 8. Persistent buffering of data prevents loss in the event of a network or transaction processing system failure such as a failure of data link 116, insufficient bandwidth, a controlled shutdown or a power failure. New messages are placed at the head of buffer 700, and messages are removed from the tail for transmission. When the head or tail of buffer 700 reaches the end of the memory set aside for buffer 700, it is reset to the beginning.

[0052] FIG. 8 shows a circular buffer 700 with fourteen buckets for data. Seventeen records have been added to buffer 700, and eleven have been removed. The next record inserted will be number 18, and will go into position 4. The next record read will be number 12. In one embodiment, the size of the recovery buffer is 95 MB, which is approximately sufficient to hold events and data corresponding to 100,000 single-segment calls. Other embodiments include a 300 MB buffer, which is approximately sufficient to hold events and data corresponding to more than 300,000 single-segment calls. An example of a single-segment call is an incoming call that is handled by an agent, with no transfers or new transaction steps.

[0053] If information server 112 reconnects to call distribution system 102 before buffer 700 has overflowed, the data feed will begin sending messages from the tail of buffer 700. This means that older data is sent first, while new data continues to be added at the head of buffer 700. If buffer 700 does not overflow during the downtime and subsequent recovery, no data will be lost. However, until the tail of buffer 700 catches up with the head, data will not be available in near-real-time.

[0054] If the head of buffer 700 passes the tail at any time, the head and tail of buffer 700 reset. Some data maybe lost, but this is necessary to ensure the integrity of the data that is preserved. The network bandwidth should be of sufficient capacity and reliability to ensure that buffer 700 will not overflow.

[0055] The amount of time buffer 700 can defend against data loss while a connection is down depends upon the size of buffer 700 and the rate at which information is being placed in buffer 700. The amount of time it takes to return to near-real-time operation depends upon the amount of data generated during downtime, and difference between the amount of bandwidth available and the rate at which new data is being generated.

[0056] FIG. 9 shows a diagrammatic representation of machine in the exemplary form of a computer system 800 within which a set of instructions, for causing the machine to perform any one of the methodologies discussed above, may be executed. The computer system 800 and includes a processor 0802, a main memory 804 and a static memory 805, which communicate with each other via a bus 806. The computer system 800 is further shown to include a video display unit 808 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). The computer system 800 also includes an alphanumeric input device 810 (e.g. a keyboard), a cursor control device 812 (e.g. a mouse), a disk drive unit 814, a signal generation device 816 (e.g. a speaker) and a network interface device 818. The disk drive unit 814 includes a computer-readable medium 815 on which is stored a set of instructions (i.e., software) 820 embodying any one, or all, of the methodologies described above. The software 820 is also shown to reside, completely or at least partially, within the main memory 804 and/or within the processor 802. The software 820 may further be transmitted or received via the network interface device 818. For the purposes of this specification, the term “machine-readable medium” shall be taken to include any medium which is capable of storing or encoding a sequence of instructions for execution by the machine and that cause the machine to perform any one of the methodologies of the present invention. The term “machine-readable medium” shall accordingly be taken to included, but not be limited to, solid-state memories, optical and magnetic disks, and carrier wave signals.

[0057] Thus, a method and apparatus for integrating business and transaction data in a transaction processing environment have been described. Although the present invention has been described with reference to specific exemplary embodiments, it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

[0058] Referring again to FIG. 7, at 710, it is determined whether direct data link 116 is functional. If data link 116 is not functional, at 714, when data link 116 becomes available, the next record in sequence is requested from call distribution system 102 by information server 112. If data link is functional, the converted HDS and HDV messages are sent on data link 116 to the data warehouse of information server 112, as shown at 712. At 716, when the call terminates, the HDV information associated with the call as identified by the callID is stored only after 30 seconds have passed. It should be noted that records are written to the data buffer 700 regardless of whether the data link 116 is functional or not.