Contact center service monitoring and correcting

The present invention is directed generally to contact center administration and specifically to monitoring and correcting contact center performance.

Contact centers are employed by many enterprises to service customer contacts. A typical contact center includes a switch and/or server to receive and route incoming packet-switched and/or circuit-switched contacts and one or more resources, such as human agents and automated resources (e.g., Interactive Voice Response (IVR) units), to service the incoming contacts. Contact centers distribute contacts, whether inbound or outbound, for servicing to any suitable resource according to predefined criteria. In many existing systems, the criteria for servicing the contact from the moment that the contact center becomes aware of the contact until the contact is connected to an agent are customer-specifiable (i.e., programmable by the operator of the contact center), via a capability called vectoring. Normally in present-day ACDs when the ACD system's controller detects that an agent has become available to handle a contact, the controller identifies all predefined contact-handling queues for the agent (usually in some order of priority) and delivers to the agent the highest-priority oldest contact that matches the agent's highest-priority queue. Generally, the only condition that results in a contact not being delivered to an available agent is that there are no contacts waiting to be handled.

The primary objective of contact center management is to ultimately maximize contact center performance and profitability. An ongoing challenge in contact center administration is monitoring and optimizing contact center efficiency. Contact center efficiency is generally measured in two ways.

Service level is one measurement of contact center efficiency and is generally determined by dividing the number of contacts accepted within a selected period of time by the number of contacts arriving in a contact center over the same period of time plus the number that were not accepted, but completed in some other way (e.g., abandoned, given busy, canceled, flowed out, etc.). Of course, service level definitions may vary from one enterprise to another.

Match rate is another indicator used in measuring contact center efficiency. Match rate is usually determined by dividing the number of contacts accepted by a primary skill level agent within a period of time by the number of contacts accepted by any agent for a queue over the same period. An agent with a primary skill level is one that typically can handle contacts of a certain nature most effectively and/or efficiently. There are other contact center agents that may not be as proficient as the primary skill level agent, and those agents are identified either as secondary skill level agents or backup skill level agents. As can be appreciated, contacts received by a primary skill level agent are typically handled more quickly and accurately or effectively (e.g., higher revenue attained) than a contact received by a secondary or even backup skill level agent. Thus, it is an objective of most contact centers to optimize match rate along with service level.

In this pursuit of contact center optimization, a contact center administrator will often make administrative changes trying to improve the level of service and/or match rate. The administrative changes may include changing staffing levels, changing agent queue assignments, or changing contact routing vectors. Usually the contact center administrator makes these changes with a goal of optimizing performance locally (i.e., within a certain group or within a certain business unit). Unfortunately, it is very difficult for the contact center administrator to predict the effects of such a change globally. For example, if two additional agents were added to a particular queue by changing their skill levels, they may no longer be able to service two other queues. Thus, the performance of one queue group will be improved at the expense of two other queue groups. It would be convenient to reverse such a change that has a negative impact on the overall contact center performance.

A problem is that identifying what system change affected performance is not an easy task. Additionally, there are currently few or no provisions for reversing such a change, even if it were identified. Rather, it is up to the contact center administrator to identify what change had a negative impact on contact center performance and reverse the change. However, in a complex contact center it may be nearly impossible for the administrator to determine the change that resulted in a decrease of contact center performance. If the administrator is unable to identify the degrading change but attempts to remedy the situation by changing some other contact center parameter the problem may be compounded.

These and other needs are addressed by the various embodiments and configurations of the present invention. The present invention is directed generally to the identification, analysis, and/or tracking of administrative or configuration changes in a contact center.

In one embodiment, a method is provided for managing a contact center that includes the steps of:

(a) detecting a predetermined level of change in a primary contact center performance parameter;

(b) in response, identifying a change in a secondary contact center parameter that occurred no more than a selected time period before the detected change, where the primary and secondary parameters are different;

(c) performing at least one of the following substeps:

(c1) notifying a contact center administrator of the identified change in the secondary contact center parameter as a possible cause of the detected change; and (c2) automatically reversing the identified change in the secondary contact center parameter.

Often contact center parameter changes are made in an attempt to increase performance locally (i.e., within a particular contact center queue). However, due to the complex nature of contact centers, an increase of performance locally may actually result in a degradation of performance globally (i.e., across multiple queues).

The types of performance changes that are generally detected include a decrease in service level and a decrease in match rate. Upon the detection of such a decrease in the service level and/or match rate or any other primary performance parameter change (i.e., a measurement parameter), a root cause for the decrease is determined. The root cause for the decrease in performance can be determined by examining secondary contact center parameters (i.e., a controlling parameter) and determining whether one or more of those parameter such as contact center traffic, staffing, or staff utilization has changed. Additionally, staff behavior can be analyzed as a possible root cause. Moreover, changes in other secondary contact center parameters including system administration parameters like queue assignments and/or vector assignments can be analyzed to determine if they were a contributing factor to the decrease in performance. If the determined root cause includes a change to a queue assignment and/or vector assignment, then reasons for the queue assignment and/or vector assignment are determined. If the reason for the queue assignment and/or vector assignment change was to improve service, then the parameters corresponding to the queue assignment and/or vector assignment change can be automatically reversed using type 2 data, in one embodiment.

As can be appreciated, incoming and outgoing contact routing allocation among contact queues is understood to include queue assignment, vector configuration parameters, and other types of work item routing changes. Additionally, an agent queue assignment as used herein is understood to include agent skill sets, agent skill splits, and any other type of association between agents, agent queues, and skills.

In another embodiment, a system administrator may be notified of the root cause for the decline in system performance and may further be instructed to reverse the change. If the reason for the change was not to improve service levels then the queue assignment and/or vector assignment change should not be reversed without further investigation of the reasons for the change. For example, if queue assignments and/or vector assignments were changed to comply with certain laws or business policies, then the change should not be reversed. Rather, other possible remedies for the decline in performance should be explored like changing staffing, adjusting the work flow management (WFM) schedule, and other contact center parameters (e.g., failure of automated resources creating increased traffic to the contact center).

In one embodiment, the notification to the system administrator may be in the form of a performance report that, at its highest level, outlines and describes the decrease in performance. The report may further include one set of reports for a measured decrease in service level and another set of reports for a measured decrease in match rate. The system administrator can drill down through each of the sets of reports to determine possible root causes for the decrease in system performance. Additionally, the reports may suggest causes that have a higher probability of being the root cause based on certain aspects of the decline in performance. The reports may further provide suggestions for correcting the problem. The suggestions may include reversing certain parameter changes that have been implemented in the contact center and implementing other parameter changes that could improve performance. These suggestions, in one embodiment, are based upon historical data related to changes that resulted in an increase in contact center performance.

As can be appreciated by one of skill in the art, a contact is understood herein to include voice calls, emails, chat, video calls, fax, and combinations thereof. Accordingly, a contact center may be equipped to handle any one or a number of the above-noted contact types.

These and other advantages will be apparent from the disclosure of the invention(s) contained herein. The above-described embodiments and configurations are neither complete nor exhaustive. As will be appreciated, other embodiments of the invention are possible utilizing, alone or in combination, one or more of the features set forth above or described in detail below.

As used herein, “at least one”, “one or more”, and “and/or” are open-ended expressions that are both conjunctive and disjunctive in operation. For example, each of the expressions “at least one of A, B and C”, “at least one of A, B, or C”, “one or more of A, B, and C”, “one or more of A, B, or C” and “A, B, and/or C” means A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B and C together.

FIG. 1 is a block diagram depicting a contact center according to an embodiment of the present invention;

FIG. 2 is a block diagram of a server according to an embodiment of the present invention;

FIG. 3 is a queue service level and match rate trend report graph in accordance with embodiments of the present invention;

FIG. 4 is a queue service level and match rate trend report table in accordance with embodiments of the present invention;

FIG. 5 is a queue service level cause trend report graph in accordance with embodiments of the present invention;

FIG. 6 is a queue service level cause trend report table in accordance with embodiments of the present invention;

FIG. 7 is an agent utilization summary report graph and table in accordance with embodiments of the present invention;

FIG. 8 is an agent queue utilization summary report graph and table in accordance with embodiments of the present invention;

FIG. 9 is a queue agent role summary report table in accordance with embodiments of the present invention;

FIG. 10 is a flowchart depicting a method of responding to changes in contact center performance in accordance with embodiments of the present invention;

FIG. 11 is a flowchart depicting a method of determining a cause of a contact center performance change in accordance with embodiments of the present invention; and

FIG. 12 is a flowchart depicting a method of maintaining a database of positive and negative contact center parameter changes in accordance with embodiments of the present invention.

The invention will be illustrated below in conjunction with an exemplary communication system. Although well suited for use with, e.g., a system having an ACD or other similar contact processing switch, the invention is not limited to any particular type of communication system switch or configuration of system elements. Those skilled in the art will recognize that the disclosed techniques may be used in any communication application in which it is desirable to provide improved contact processing.

FIG. 1 shows an illustrative embodiment of the present invention. A contact center 100 comprises a central server 110 , a set of data stores or databases 114 containing contact or customer related information and other information that can enhance the value and efficiency of the contact processing, and a plurality of servers, namely a voice mail server 118 , an Interactive Voice Response unit or IVR 122 , and other servers 126 , a switch 130 , a plurality of working agents operating packet-switched (first) communication devices 134 - 1 to N (such as computer work stations or personal computers), and/or circuit-switched (second) communication devices 138 - 1 to M, all interconnected by a local area network LAN (or wide area network WAN) 142 . The servers can be connected via optional communication lines 146 to the switch 130 . As will be appreciated, the other servers 126 can also include a scanner (which is normally not connected to the switch 130 or Web server), VoIP software, video call software, voice messaging software, an IP voice server, a fax server, a web server, an email server, and the like. The switch 130 is connected via a plurality of trunks 150 to the Public Switch Telephone Network or PSTN 154 and via link(s) 152 to the second communication devices 138 - 1 to M. A gateway 158 is positioned between the server 110 and the packet-switched network 162 to process communications passing between the server 110 and the network 162 .

The term “switch” or “server” as used herein should be understood to include a PBX, an ACD, an enterprise switch, or other type of communications system switch or server, as well as other types of processor-based communication control devices such as media servers, computers, adjuncts, etc.

Referring to FIG. 2 , one possible configuration of the server 110 is depicted. The server 110 is in communication with a plurality of customer communication lines 200 a - y (which can be one or more trunks, phone lines, etc.) and agent communication line 204 (which can be a voice-and-data transmission line such as LAN 142 and/or a circuit switched voice line 140 ). The server 110 can include a Call Management System™ or CMS 228 that gathers call records and contact-center statistics for use in generating contact-center reports. CMS 228 and any other reporting system, such as a Basic Call Management System™, Operational Analyst™ or Customer Call Routing or CCR™ will hereinafter be referred to jointly as CMS 228 .

The switch 130 and/or server 110 can be any architecture for directing contacts to one or more communication devices. In some embodiments, the switch 130 may perform load-balancing functions by allocating incoming or outgoing contacts among a plurality of logically and/or geographically distinct contact centers. Illustratively, the switch and/or server can be a modified form of the subscriber-premises equipment disclosed in U.S. Pat. Nos. 6,192,122; 6,173,053; 6,163,607; 5,982,873; 5,905,793; 5,828,747; and 5,206,903, all of which are incorporated herein by this reference; Avaya Inc.'s Definity™ Private-Branch Exchange (PBX)-based ACD system; MultiVantage™ PBX, CRM Central 2000 Server™, Communication Manager™, S8300™ media server, SIP Enabled Services™, and/or Avaya Interaction Center™. Typically, the switch/server is a stored-program-controlled system that conventionally includes interfaces to external communication links, a communications switching fabric, service circuits (e.g., tone generators, announcement circuits, etc.), memory for storing control programs and data, and a processor (i.e., a computer) for executing the stored control programs to control the interfaces and the fabric and to provide automatic contact-distribution functionality. The switch and/or server typically include a network interface card (not shown) to provide services to the serviced communication devices. Other types of known switches and servers are well known in the art and therefore not described in detail herein.

As can be seen in FIG. 2 , included among the data stored in the server 110 is a set of contact queues 208 a - n and a separate set of agent queues 212 a - n . Each contact queue 208 a - n corresponds to a different set of agent queues, as does each agent queue 212 a - n . Conventionally, contacts are prioritized and either are enqueued in individual ones of the contact queues 208 a - n in their order of priority or are enqueued in different ones of a plurality of contact queues that correspond to a different priority. Likewise, each agent's queues are prioritized according to his or her level of expertise in that queue, and either agents are enqueued in individual ones of agent queues 212 a - n in their order of expertise level or are enqueued in different ones of a plurality of agent queues 212 a - n that correspond to a queue and each one of which corresponds to a different expertise level. Included among the control programs in the server 110 is a contact vector 216 . Contacts incoming to the contact center are assigned by contact vector 216 to different contact queues 208 a - n based upon a number of predetermined criteria, including customer identity, customer needs, contact center needs, current contact center queue lengths, customer value, and the agent skill that is required for the proper handling of the contact. Agents who are available for handling contacts are assigned to agent queues 212 a - n based upon the skills that they possess. An agent may have multiple skills, and hence may be assigned to multiple agent queues 212 a - n simultaneously. Furthermore, an agent may have different levels of skill expertise (e.g., skill levels 1-N in one configuration or merely primary skill levels and secondary skill levels in another configuration), and hence may be assigned to different agent queues 212 a - n at different expertise levels. Call vectoring is described in DEFINITY Communications System Generic 3 Call Vectoring/Expert Agent Selection (EAS) Guide, AT&T publication no. 555-230-520 (Issue 3, November 1993). Skills-based ACD is described in further detail in U.S. Pat. Nos. 6,173,053 and 5,206,903.

Referring to FIG. 1 , the gateway 158 can be Avaya Inc.'s, G700 Media Gateway™ and may be implemented as hardware such as via an adjunct processor (as shown) or as a chip in the server.

The first communication devices 134 - 1 , . . . 134 -N are packet-switched and can include, for example, IP hardphones such as the Avaya Inc.'s, 4600 Series IP Phones™, IP softphones such as Avaya Inc.'s, IP Softphone™, Personal Digital Assistants or PDAs, Personal Computers or PCs, laptops, packet-based H.320 video phones and conferencing units, packet-based voice messaging and response units, packet-based traditional computer telephony adjuncts, peer-to-peer based communication devices, and any other communication device.

The second communication devices 138 - 1 , . . . 138 -M are circuit-switched. Each of the communication devices 138 - 1 , . . . 138 -M corresponds to one of a set of internal extensions Ext 1 , . . . ExtM, respectively. These extensions are referred to herein as “internal” in that they are extensions within the premises that are directly serviced by the switch. More particularly, these extensions correspond to conventional communication device endpoints serviced by the switch/server, and the switch/server can direct incoming calls to and receive outgoing calls from these extensions in a conventional manner. The second communication devices can include, for example, wired and wireless telephones, PDAs, H.320 videophones and conferencing units, voice messaging and response units, traditional computer telephony adjuncts, and any other communication device.

It should be noted that the invention does not require any particular type of information transport medium between switch or server and first and second communication devices, i.e., the invention may be implemented with any desired type of transport medium as well as combinations of different types of transport channels.

The packet-switched network 162 can be any data and/or distributed processing network, such as the Internet. The network 162 typically includes proxies (not shown), registrars (not shown), and routers (not shown) for managing packet flows.

The packet-switched network 162 is in communication with an external first communication device 174 via a gateway 178 , and the circuit-switched network 154 with an external second communication device 180 . These communication devices are referred to as “external” in that they are not directly supported as communication device endpoints by the switch or server. The communication devices 174 and 180 are an example of devices more generally referred to herein as “external endpoints.”

In a preferred configuration, the server 110 , network 162 , and first communication devices 134 are Session Initiation Protocol or SIP compatible and can include interfaces for various other protocols such as the Lightweight Directory Access Protocol or LDAP, H.248, H.323, Simple Mail Transfer Protocol or SMTP, IMAP4, ISDN, E1/T1, and analog line or trunk.

It should be emphasized that the configuration of the switch, server, user communication devices, and other elements as shown in FIG. 1 is for purposes of illustration only and should not be construed as limiting the invention to any particular arrangement of elements.

As will be appreciated, the central server 110 is notified via LAN 142 of an incoming contact by the communications component (e.g., switch 130 , fax server, email server, web server, and/or other server) receiving the incoming contact. The incoming contact is held by the receiving communications component until the server 110 forwards instructions to the component to forward or route the contact to a specific contact center resource, such as the IVR unit 122 , the voice mail server 118 , and/or first or second communication device 134 , 138 associated with a selected agent. The server 110 distributes and connects these contacts to communication devices of available agents based on the predetermined criteria noted above. When the central server 110 forwards a voice contact to an agent, the central server 110 also forwards customer-related information from databases 114 to the agent's computer work station for previewing and/or viewing (such as by a pop-up display) to permit the agent to better serve the customer. The agents process the contacts sent to them by the central server 110 .

According to at least one embodiment of the present invention, an event manager 232 is provided. The event manager 232 is stored either in the main memory or in a peripheral memory (e.g., disk, CD ROM, etc.) or some other computer-readable medium of the center 100 . The event manager 232 identifies and analyzes specific occurrences of changes in contact center performance. Specifically, the event manager 232 monitors service level of the agents in the contact center and match rates of the agent and contact selector 220 .

Service level is generally user-specified and provides an indication of how efficiently incoming contacts are being answered by agents in the agent queues 212 . In one embodiment, service level is defined as the total number of contacts accepted (i.e., answered) by agents in the agent queue 212 divided by the total number of contacts entering the contact queue 208 over the same period of time.

Match rate is another indicator of contact center performance and usually identifies how well contacts are being connected with agent's having the necessary skill set to fulfill the requests represented by the contact. As noted above, some agents in a particular agent queue 212 may have a primary skill level for that queue whereas other agents may have a secondary skill level for the same queue. Additionally, one agent may have a primary skill level in the first queue 212 a and a secondary skill level in the second queue 212 b . Based on availabilities of agents in the agent queues 212 and the number of contacts waiting in the contact queue 208 , the agent and contact selector 220 determines which agent should be assigned to which contact. It is a goal of the agent and contact selector 220 to assign contacts in the first customer queue 208 a with primary skill level agents in the first agent queue 212 a . Likewise, the agent and contact selector 220 would like to assign contacts in the second customer queue 208 b with primary skill level agents in the second agent queue 212 b . If the agent and contact selector 220 could realize such assignments, a substantially perfect match rate would be achieved. However, it is often the case that the number of contacts waiting in the contact queues 208 exceeds the number of agents waiting in the agent queues 212 . For this reason, and due to other assignment parameters like required answering time, the agent and contact selector 220 is sometimes forced to assign contacts to secondary or backup skill level agents. Since match rate is generally determined as the number of contacts connected to primary skill level agents divided by the total number of contacts assigned to agents over a predetermined amount of time, if the agent and contact selector 220 is forced to assign contacts to less than primary skill level agents, the match rate performance indicator decreases.

The results of service level and match rate are actively monitored by the event manager 232 and in the event that a change in performance occurs, the event manager 232 logs the change and attempts to determine why the change occurred. If the change was an increase in performance, then the event manager 232 determines what type of change was made and further determines what the system parameters (e.g., queue and/or vector assignment) of the agent and contact selector 220 were prior to the change. Then the event manager 232 can store data related to the change in a positive system change log file.

If the change was a decrease in performance, then the event manager 232 communicates with the CMS 228 and agent and contact selector 220 to determine what the root cause of the performance change was and possibly reverse any change that was associated with the root cause. The event manager 232 can control the queue and/or vector assignment parameters directly through the agent and contact selector 220 , which allows for automatic adjustment and maintenance of the contact center if negative changes are detected.

The event manager 232 is further operable to monitor system performance and maintain historical data related to the system performance. Additionally, the event manager 232 can monitor agent and contact selector parameter settings and other contact center parameters to supplement reports related to system performance.

Referring now to FIG. 3 a queue service level and match rate trend report graph 300 generated by the event manager 232 will be described in accordance with at least some embodiments of the present invention. The queue service level and match rate graph 300 generally comprises historical service level measurements 304 and historical match rate measurements 308 . The historical data may be periodically or continuously updated to reflect changes in performance. The report may be displayed to a system administrator in real-time such that the system administrator can be alerted to any sudden changes in performance. In an alternative embodiment, the queue service level and match rate graph 300 is displayed to a system administrator only when a substantial change in performance is detected. As will be appreciated, what is a substantial change is determined by a comparison to a selected threshold. The magnitude of the threshold depends on the parameter under analysis. For example, the threshold for service level will generally differ from that for match rate. Additionally, for a selected parameter, the parameter threshold can vary by time of day and by work item type, customer class, and/or agent skill type or level.

One example of a substantial change can be seen in the relatively sudden decrease of service level performance 306 . The service level 304 is expected to change throughout the day, but usually at a relative smooth rate. However, the sudden drop in service level performance 306 may be considered a substantial change in contact center performance.

Another example of a substantial change can be seen in the drop of match rate 310 that occurred around 12:00. This particular drop in match rate 310 may have been due to an increase of traffic entering the contact center or due to other parameter changes in the agent and contact selector 220 .

As can be seen in FIG. 4 , in one embodiment, when the service level 304 and/or match rate 308 changes drastically, the event manager 232 may generate a queue service level and match rate trend report table 400 to supplement the trend report graph 300 . The queue service level and match rate trend report table 400 generally comprises a field of data for the service level measurements and a field of data for the match rate measurements. The sudden decrease in service level 404 is highlighted for ease of reference by the system administrator. Additionally, the sudden decrease in match rate 408 can be highlighted. As can be seen in FIGS. 3 and 4 the decrease in match rate 308 preceded the decrease in service level 304 . This may be one indication that the decrease in match rate 308 resulted in the decrease in service level 304 ; however, such a determination should not be made until further analysis of the contact center parameters around the time of the decrease is completed.

When the system administrator is provided with the queue service level and match rate trend reports 300 and 400 the event manager 232 may further provide the system administrator with the ability to drill down into service level and match rate specific reports. These reports allow a system administrator to gain perspective on possible causes of the decrease in contact center performance.

As can be seen in FIG. 5 , a queue service level cause trend report graph 500 may be provided to the system administrator as part of the drill down features associated with service level changes. The queue service level cause trend report graph 500 generally comprises a historical record of various contact center parameters around the time of the detected change in performance. Examples of the parameters that may be tracked include, for example, number of contact arrivals 504 , average number of positions staffed 508 , and average number of positions working 512 . The number of contact arrivals 504 is generally tracked to determine if a change in traffic may have been the cause of the change in contact center performance. For example, a decrease in traffic (i.e., inbound and outbound contacts) may result in an increase in contact center performance. Conversely, an increase in traffic may result in a decrease in contact center performance.

The average number of positions staffed 508 is also tracked to help determine if a change in contact center performance was the result of a staffing change. A decrease in the number of positions staffed may explain a decrease in contact center performance as defined by service level and match rate. Alternatively, an increase in the number of staffed positions may explain an increase in contact center performance. As can be appreciated, a combinational change in arrivals and positions staffed may also explain a sudden change in contact center performance. For example, if the number of arrivals increased and the number of staffed positions decreased at around the same time, then contact center performance would likely suffer. On the other hand, a decrease in arrivals and an increase in staffed positions may result in an increase in contact center performance.

Of course, the number of staffed positions does not necessarily dictate the number of people working. For instance, some staffed positions may be on break while other staffed positions may be working on other queues. For this reason, the average number of positions working 512 is tracked. Tracking the average number of positions working allows a system administrator to identify if the problem was actually staffing.

Referring now to FIG. 6 , a queue service level cause trend report table 600 will be described in accordance with embodiments of the present invention. The event manager 232 may provide the queue service level cause trend report table 600 to the system administrator along with the corresponding graph 500 . Additional information is contained in the table 600 as compared to the graph 500 . For example, the table 600 generally comprises an occupancy field 620 and a service level performance field 604 in addition to an arrivals field 608 , an average positions staffed field 612 , and an average positions working field 616 . The service level performance field 604 provides an indication of approximately when the change in performance occurred. The values of the other fields can be analyzed for around the same time to determine what, if any, were the reasons for the change in performance. As can be seen in the example depicted in FIG. 6 , the service level performance decreased around 12:30. During approximately the same time, the number of arrivals did not change dramatically nor did the number of positions staffed. Also, the number of positions working increased. However, the occupancy (i.e., the ratio of work time to staff time) decreased around the same time as the service level declined. This may provide a further indication that agent behavior may be a cause of the change in performance rather than a change to other system parameters.

In one embodiment, if traffic has changed, it may be compared to WFM forecasts to see if the traffic was predicted. If the WFM forecast was off, then it should be adjusted for the problem time period to ensure that performance does not drop in the same way due to another WFM misforecast.

As an example, if there was a sudden increase or spike in traffic, a system administrator could drill into where the traffic originated (e.g., by differentiating arrivals by area code or country code). If the increased traffic is from the same geographic area, then weather conditions or other regional events may have triggered the traffic. In some instances, such an increase of traffic may not be predictable. However, other instances of traffic may be predictable, for example if a certain town's baseball team is in the playoffs, traffic can be expected to increase. As another example, certain regional occurrences may lead to longer service times because people want to talk more.

In another embodiment, if the average positions staffed has changed, then the staffing can be compared to the WFM schedule. If the WFM schedule called for the change, then the WFM forecast parameters can be adjusted to staff more positions. If the WFM schedule does not have a change, then the system administrator can drill into an agent login/logout report or view a schedule adherence report to determine if the staffed positions were actually working as they were scheduled.

In still another embodiment, following the example depicted where average positions working has changed, a system administrator can check to see if agent occupancy has changed. If the agent occupancy is down, the system administrator can drill into an auxiliary state report that shows the various states of agents in the contact center. Alternatively, the system administrator may view an agent utilization or occupancy report 700 as shown in FIG. 7 . The agent utilization summary report 700 generally depicts the percentage of agent activity during a selected time interval. In the depicted example, the selected time interval is between 11:45 and 12:00. The agent utilization summary report 700 shows how agent utilization has changed over the selected time interval by various states available to the agent. The agent utilization summary report 700 generally includes preview duration, active duration, wrap-up duration, idle duration, initiate duration, and held duration as a percentage of total duration.

In the depicted example, the percentage of active duration increased from about 65% to about 70% between 11:45 and 12:00. Furthermore, percentage wrap up duration increased from about 10% to about 15% over the same time interval. The percentage idle duration decreased from about 15% to about 5% between 11:45 and 12:00. The slight increase in active duration and wrap-up duration may have been a result of local occurrences or may be the result of inefficient contact handling by an agent.

In one embodiment, if the percent active time is about the same over the selected duration, then the system administrator can drill down to an agent queue utilization summary report 800 to see what queues the agents are serving, as can be seen in FIG. 8 . The agent queue utilization summary report 800 generally shows from what queues agents are receiving contacts. In the depicted embodiment, the shoes queue took agents away from the outerwear queue. This dramatic change in agent utilization among queues may have been due to a change in skill levels at the CMS 228 and/or agent and contact selector 220 . Upon seeing such a change in agent utilization, a system administrator may view a system administration history to see if skill levels were previously changed for agents serving shoes. In the event that a skill level change for agents in shoes was made, the system administrator or the event manager 232 may reverse the change to restore contact center performance.

In an alternative embodiment, if the percent wrap-up time or percent held duration time changed, then the system administrator may be provided agent problem behavior reports. Examples of agent problem behavior reports are described in U.S. patent application Ser. No. 11/193,585, the entire disclosure of which is hereby incorporated herein by this reference. The agent problem behavior reports may provide the system administrator information on how particulars agent can be coached to improve their contact handling efficiency.

Of course, service level may not be the only performance measurement parameter that has suffered as a result of contact center changes. Match rate is another indicator used to measure performance levels. The match rate sets of reports available for a system administrator to drill down through are somewhat similar in nature to the service level reports described above.

In one embodiment, if the system administrator or event manager 232 determines that a change has occurred in match rate, then a queue agent role summary report 900 may be generated as can be seen in FIG. 9 . The queue agent role summary report 900 generally comprises a total queue information section 904 and an agent information section 908 . The queue information section 904 shows agents' roles within a particular queue (e.g., outerwear). It is preferable to have the queue populated in large part with primary skill level agents. There may also be secondary or backup skill level agents as well as reserve agents. The information shown in the queue information section 904 indicates the number of contacts received on a per skill level basis. The queue information 904 further shows the percent handles for the entire queue by skill level and the average handle time for each skill level. If the ratio of skill levels handling contacts is not at an optimum level, for example if the backup skill level agents are handling more contacts than the primary skill level agents, then the system administrator can drill down through performance reports to determine if a system change resulted in the improper handling ratio. The system administrator can drill down into various reports that show different performance parameters including, without limitation, staff, primary staffing, occupancy, primary occupancy, queue state, possible reasons for primary and reserve agents, number of agents logged out, number of agents working on other work, and administration changes (e.g., workflow changes, vector changes, IVR changes, queue assignments, etc.).

Instead of requiring the system administrator to drill down through different reports, the event manager 232 may automatically drill down through each report. By drilling down through various performance parameters the event manager 232 is operable to identify a root cause of a change in contact center performance and may further provide suggestions to a system administrator to correct such changes, if necessary. Alternatively, the event manager 232 may automatically adjust certain contact center parameters to correct the problem and notify an administrator of actions taken.

Referring now to FIG. 10 , a method of responding to changes in contact center performance will be described in accordance with at least some embodiments of the present invention. The method begins by detecting a significant change in contact center performance as evidenced by a first or primary parameter (e.g., service level, match rate, percent abandon, or average speed of answer) (step 1004 ). A significant change may be defined as a percentage change and/or when a change is statistically significant within a particular time interval. An exemplary percentage change threshold may be if the service level and/or match rate changes by more than about +/−5% from the previous time interval measurement. An exemplary standard deviation threshold may be defined by the previous five time intervals. For instance, the previous five time intervals may have an average value of about 81% within service level. The standard deviation for those five values may be about +/−7%. Thus, the threshold for a significant change may be the standard deviation of the previous five values. Of course, a significant change may also be defined as any multiple or fraction of a standard deviation, depending upon user-defined tolerances. It should be noted that the thresholds are generally dynamic, in that they depend upon changing data. In the example above, when a new data point is added for a new time interval, the oldest of the five time interval values may be removed from the determination of a standard deviation and a new standard deviation may be calculated based on the new five most recent time interval measurements.

After a significant change has been detected, it is determined when the significant change occurred in the primary parameter (step 1008 ). This particular step helps to create a time line and a starting point for the drill-down reports described above. Moreover, determining when a significant change occurred can be useful in determining causal relationships. For example, a change in system parameters (or secondary parameters) after a significant change has been detected is not a likely cause of the significant change. Examples of secondary parameters include, but are not limited to, traffic, routing, staffing, occupancy, queue assignment, and any other contact center parameter that can change the operation or performance of the contact center.

It may also be informative to determine what queues were affected by the significant change. In step 1012 , this particular determination is made regarding the parties affected by the significant change. For example, if one queue had a significant increase in performance at about the same time another queue had a significant decrease in performance, it could be the case that a queue assignment or vector change was implemented involving one of the two affected queues.

If a cause of the significant change can be identified, and the cause was at least partially due to a change in contact center parameters (or secondary parameters), it is determined what the purpose of the change was (step 1016 ). In some instances this determination may be speculative. For example, if records indicate that a fire drill was scheduled around the time the significant change was detected, then the reason for the parameter change may be related to that event. However, in accordance with some embodiments, a system administrator may be required to enter a reason for a system (secondary) parameter change. Thus, when the event manager 232 is searching for changes that resulted in a decrease/increase of performance, it may be able to definitively identify the reason for the change.

Based on the determined reason for the change and other factors, the event manager 232 may identify a set of possible causes of the change in system performance. Based on these causes, the event manager 232 may suggest a new parameter change for the contact center (step 1020 ). The suggestion for a change may be as simple as reversing the change that caused the alteration in performance. However, under certain circumstances, the change may not be reversible and the event manager 232 may supply other alternatives for changing contact center parameters. In some embodiments, the identified reasons for change may help determine if a particular change may be reversed.

The suggestions are provided by the event manager 232 to a system administrator. The suggestions may be provided in the form of an email or some other alert notification. The event manager 232 waits for a response from the system administrator to determine what changes should be made (step 1024 ). Of course, in certain embodiments, a system administrator may provide the event manager 232 standing instructions to reverse any reversible change that negatively affected contact center performance. This way a system administrator is only asked to make decisions regarding non-reversible changes.

If the event manager 232 receives notification from the system administrator that one or more of the suggested changes should be implemented, then the event manager 232 implements the new changes (step 1028 ). This particular step may include changing queue and/or vector assignments, adjusting the WFM forecasts, changing staffing, and the like. Thereafter, a contact center performance report may be generated for the system administrator (step 1036 ). Of course, the report may be provided to the system administrator as a part of the change suggestions. The report provided to the system administrator after the change is implemented may include a performance comparison report showing that the system has at least returned back to normal performance levels, or the performance levels have improved since a prior decrease in performance.

In the event that the system administrator either does not respond to the suggestions for changes or declines the suggestions, the system settings are maintained (step 1032 ). This essentially means that the contact center will continue running under the parameters that resulted in the change to contact center performance. Thereafter, the contact center performance report may be provided to the system administrator showing that no changes were made and further showing the updated levels of contact center performance (step 1036 ).

With reference now to FIG. 11 , a method of determining a root cause of a performance change will be described in accordance with at least some embodiments of the present invention. The method begins when a significant change is detected in system performance or a primary parameter (step 1104 ). This particular step is similar to step 1004 described above. The change in performance may have been measured in either service level, match rate, both, or other indicators of contact center performance like percent abandon and average speed of answer. Once a significant change has been detected, it is determined if a secondary parameter such as traffic levels have changed (step 1108 ). The types of traffic that could have changed can include both inbound and outbound contacts from a particular queue or the entire contact center. One reason why traffic may change is because routing has been adjusted in the form of a queue change or a vector change. Thus, it is determined if a secondary parameter such as a routing change was made in temporal proximity before or around the time of the detected performance change (i.e., the target time) (step 1112 ). In the event that the traffic changed as a result of a routing change, it is determined if the routing change was made in an attempt to improve service level, match rate, and/or any other primary parameter (step 1124 ). If the routing change was made in an attempt to improve service level, match rate, and/or any other primary parameter, then the routing change is reversed (step 1128 ). As can be appreciated, the routing change could be automatically reversed by the event manager 232 or by a system administrator.

In one embodiment, a change in one secondary parameter may have been intended to improve service level numbers for a particular customer. Such a local change may have a negative impact on contact center performance globally. If an attempt to improve service locally resulted in a global degradation of service, the change may be reversed as noted above with respect to step 1128 . As can be appreciated by one of skill in the art, hysteresis can be built into the system such that one parameter change is not continually reversed then reversed again. This hysteresis allows one parameter change to take effect on the contact center performance before the determination to make another change to the system is made.

In another embodiment, rather than simply reversing the last system change that may have resulted in the change of performance, system setting could be restored to a baseline configuration. In other words, the system may be restored to a “last known” working state having a predetermined setting for agent queue and vector assignments. The event manager 232 can decide to swing to this predetermined configuration if there are too many changes that need to be analyzed and reversed.

There are a number of instances where a routing change may have been made without intending to improve service. Some of these reasons may still provide a reversible routing change, whereas others may indicate that the routing change should not be reversed. For example, if a routing change was made to accommodate a mandatory staff meeting, then the routing change cannot be reversed until the staff meeting is over. Another example of a potentially irreversible routing change is if the queue assignment change was made to compensate for an agent that just wasn't qualified to handle a particular queue. In the event that the routing change should not be reversed (i.e., the routing change was not made to improve service), then other options are explored like changing other routing parameters, changing staffing, or changing the WFM schedule (step 1120 ). Another example of a change that should not necessarily be reversed is a change in system settings to accommodate for a sudden increase in traffic in a certain queue. Such a change may remain temporarily until the local traffic in a particular queue has returned to normal. Thereafter, the event manager 232 may reverse the change sending the system settings back to their previous state.

In the event that there was a traffic change but no routing change as determined by steps 1108 and 1112 respectively, a determination is made as to where traffic is coming from (step 1116 ). In other words, it is determined if the increase in traffic is from a particular customer, region, queue, or the like. After the origination of the traffic is determined, then suggestions are provided to adjust routing, adjust staffing, or change the WFM schedule (step 1120 ).

In the event that traffic did not substantially change, the method continues by determining if a secondary parameter such as staffing changed in temporal proximity before and/or around the target time (step 1132 ). Examples of a staffing change may be in preparation for an expected contact volume change or in preparation for a holiday. If it is determined that a staffing change was made, then it is determined if the changed schedule was adhered to (step 1136 ). In other words, it is determined if the scheduled agents showed up for work. In the event that the agents did adhere to the changed schedule, then the problem is in the schedule itself and therefore a suggestion is made to adjust the schedule (step 1140 ). In other words, the workflow forecast may have been off and therefore an adjustment to the schedule should be made.

However, if the workflow was forecast properly but the agents did not adhere to the schedule then other forms of adjustment should be made. For example, if agent's were coming in to work late or leaving early, then they may need to be coached or otherwise spoken with by a supervisor (step 1144 ). Alternatively, some agents may have been sick and the deviation from the schedule was unavoidable. Under these circumstances there may be no recourse for adjusting the system parameters but rather the system administrator must make adjustments to deal with an understaffed workforce.

If there was no determined traffic change and no staffing change, then the method continues to determine if there was a significant change in a secondary parameter such as agent occupancy (step 1148 ). As noted above, occupancy is an indicator of agent efficiency and provides a measure of how busy a particular agent is. Examples of an occupancy change include, longer or shorter talk times, longer or shorter hold times, longer or shorter wrap-up times, and/or longer or shorter ring times. Also, depending on how occupancy is calculated, breaks and non-contact work may affect occupancy as well.

In the event that an occupancy change is detected around the time that a significant change in performance (a primary parameter) was detected, then it is determined if there are any problem behaviors with one or more of the agents in the workforce (step 1152 ). Examples of methods used to determine if there are agent behavior problems are explained in U.S. patent application Ser. No. 11/193,585. If there were problem behaviors detected, then the identified agent is coached on how to handle contacts with more efficiency (step 1144 ). Other forms of coaching an agent include motivating the agent by giving them a different shift or discussing other options that would make the agent more willing to work efficiently. Also, the agent may have his or her work observed for a period of time to determine with more accuracy what their problem behaviors are.

In the event that there are no problem behaviors detected, then there is either a problem with the number of agents staffed or the schedule, which are both secondary parameters. Therefore, the staffing or schedule is adjusted (step 1164 ). This particular step may include adjusting the WFM forecast to accommodate for the occupancy change. Alternatively, the staffing may need to be changed by having agents work overtime, do split shifts, or assigning agents new queues.

If there have been no significant determined traffic changes, staffing changes, or occupancy changes, then it is determined where agents are spending their time (step 1156 ). For example, if before a particular decline in service agents were distributed across three queues relatively evenly then after a decline the distribution had more agents in the first two queues, then the agents are possibly spending too much time in the first two queues and should be redistributed among all queues.

Once it is determined where the agents were spending their time, then it is determined if there was an assignment change (a secondary parameter) (step 1160 ). Examples of a queue assignment change include, without limitation, increasing an agent's skill level, decreasing an agent's skill level, adding a queue, and removing a queue. If there were no queue assignment changes, then the problem is still likely in the staffing and/or schedule. Therefore, if no queue assignment change was detected, then the staffing and/or schedule is adjusted (step 1164 ).

However, if there was an assignment change, then it is determined if the reason for the assignment change was to improve service, either locally or globally (step 1168 ). If the reason for the change was to improve service, or was any other reversible reason, then the change is reversed and the system parameters are restored to their last known working condition (step 1172 ). However, if the reason for the change should not be reversed, then the staffing and/or schedule needs to be changed (step 1164 ). Additionally, other routing parameters may be changed to compensate for the other change that should not be reversed (not shown).

FIG. 12 depicts a method of maintaining a database of positive system changes in accordance with at least some embodiments of the present invention. Initially, an administrator decides to implement a change to one or more the contact center parameters (step 1204 ). The change may include a staffing change, a schedule change, a queue assignment change, a vector change, or any other change known in the art. Thereafter, the administrator records the reason for the change (step 1208 ). The administrator may choose among various options for a reason of change, such as to improve service, to compensate for understaffing, to comply with new regulations, etc.

Once the reason for the change is known, the event manager 232 implements the change as defined by the system administrator (step 1212 ). Then the performance level of the contact center is monitored (step 1216 ). The performance level may be monitored by tracking the service level, match rate, both, or some other primary parameter. As the performance level of the contact center is monitored, it is determined if the performance level has declined (step 1220 ). If the performance level has not declined (i.e., it has improved or remained the same), then the event manager stores the positive change, the system parameters before the change, the system parameters after the change, and the reason for the change in the database 114 (step 1224 ). The positive change is preferably added to a positive change history log that can be accessed by the event manager 232 at a later time to create suggestions for future changes to the system administrator. For example, if the event manager 232 has noticed that a particular system change worked multiple times in the past for a specified set of contact center parameter settings, then if the same set of parameter settings are encountered at a later date, the event manager 232 can suggest the same changes to the system administrator with a reasonable amount of assurance that the performance will improve. The use of a positive change history log allows the event manager 232 to learn what types of system changes provide positive results. This is particularly useful when a change to the system parameters should not be reversed and a new change needs to be suggested to the system administrator.

The change may also be stored as a positive change if no change in performance was detected. This may be useful if the administrator changed system parameters to make a particular agent or agents happier as they worked. If no degradation to performance was detected as the result of such a change it may be regarded as a positive change and can therefore be stored in the positive changes history log along with its reason for the change.

It may also be useful to store negative changes in some circumstances in a negative change database. Specifically, a database of previous negative changes may be referenced to identify if the requested change may likely result in a decrease in contact center performance.

If there was a decline in performance detected by monitoring a primary parameter, then it is determined if the change is reversible (step 1228 ). If the change should not be reversed, then the event manager 232 can access the positive changes history log and suggest additional changes to the system parameters (step 1232 ). However, if the change was reversible, then the change is reversed and the system parameters are restored to their previous state (step 1236 ). The ability to change parameters and have the event manager 232 either automatically reverse them if they are bad or store them for future reference if they are good provides the system administrator the ability to learn how to work with the contact center. This learning tool also provides the event manager 232 with more information which can ultimately help the system administrator when other changes in system performance are detected.

The present invention, in various embodiments, includes components, methods, processes, systems and/or apparatus substantially as depicted and described herein, including various embodiments, subcombinations, and subsets thereof. Those of skill in the art will understand how to make and use the present invention after understanding the present disclosure. The present invention, in various embodiments, includes providing devices and processes in the absence of items not depicted and/or described herein or in various embodiments hereof, including in the absence of such items as may have been used in previous devices or processes, e.g., for improving performance, achieving ease and/or reducing cost of implementation.

The foregoing discussion of the invention has been presented for purposes of illustration and description. The foregoing is not intended to limit the invention to the form or forms disclosed herein. In the foregoing Detailed Description for example, various features of the invention are grouped together in one or more embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate preferred embodiment of the invention.

Moreover, though the description of the invention has included description of one or more embodiments and certain variations and modifications, other variations and modifications are within the scope of the invention, e.g., as may be within the skill and knowledge of those in the art, after understanding the present disclosure. It is intended to obtain rights which include alternative embodiments to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangeable and/or equivalent structures, functions, ranges or steps are disclosed herein, and without intending to publicly dedicate any patentable subject matter.