Abstract:
Systems and methods for determining workforce staffing statistics in a contact center are disclosed. In one embodiment, the method comprises the steps of: receiving activity records associated with agents; and producing queue-specific staff counts for an interval. The counts are based on an activity record subset, and an agent skill, and a contact queue skill set. In one embodiment, the system comprises: an activity collector operative to receive events; and a staff statistics calculator operative to determine a staff count for a specified staffing interval. Each of the events describes a worker activity. In this embodiment, the calculator comprises: logic for receiving activity records derived from one of the events; logic for identifying contact queues for each worker in the activity records; and logic for incrementing a contact queue staff count if at least one skill for the respective worker is included in the respective contact skill set.

Description:
FIELD OF THE DISCLOSURE 
     The present disclosure relates to software for contact centers, and more specifically, to a systems and methods for calculating workforce staffing statistics. 
     BACKGROUND 
     The business of a contact center is to provide rapid and efficient interaction between agents and customers, or prospective customers, using various interaction methods and media, including phone, fax, e-mail and messaging. A manager in a contact center typically uses force management software (FMS) to produce a schedule that includes agents assigned to work activities for specific time periods. During the workday, the FMS produces staffing statistics. The manager uses staffing statistics to adjust the number of agents assigned to particular activities when the contact center performance is either above or below contact center goals (e.g., a desired service level.) If performance exceeds the goals, the manager can reduce the number of agents. If performance does not meet goals, the manager can add more agents to the schedule. 
     Skills-based routing attempts to find the best available match between the needs of the customer and the various proficiencies or skills of available agents. Providing staffing statistics in a skills-based environment is difficult. One problem is providing an accurate count of agents. A multi-skill agent could be counted against more than one (skill) queue. A conventional FMS simply counts an agent with multiple skills against all queues, resulting in an miscount. Furthermore, a conventional FMS reports one combined count, rather than a count for each skill-related queue. 
     SUMMARY OF THE INVENTION 
     Systems and methods are disclosed for determining workforce staffing statistics in a contact center. In one embodiment, the method comprises the steps of: receiving a plurality of activity records; and producing staff counts for a staffing interval. Each activity record is associated with an agent. The staff counts are based on at least some of the activity records, and on agent skill sets, and on queue skill sets. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. 
         FIG. 1  is a block diagram of a contact center environment for an embodiment of a system and method for calculating workforce staffing statistics from activity records. 
         FIG. 2  illustrates the process of contact routing based on agent skills, according to one embodiment of a system and method for calculating workforce staffing statistics from activity records. 
         FIG. 3  is a block diagram showing several components of the WFMS of  FIG. 1 . 
         FIG. 4  is a flowchart of one implementation of the staff statistics calculator of  FIG. 3 . 
         FIG. 5  is a data flow diagram of one embodiment of the queue selection process of  FIG. 4 . 
         FIG. 6  is a hardware block diagram of a general-purpose computer which can be used to implement systems and methods for calculating workforce staffing statistics from activity records. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a block diagram of a contact center environment  100 . The contact center  100  is staffed by agents who handle incoming and/or outgoing contacts. Although the traditional and most common form of contact is by phone, other types of contacts can be used, such as text chat, web collaboration, email, and fax. An agent workspace includes an agent phone  110  and a workstation computer  120 . A network  130  connects one or more of the workstations  120 . 
     A contact router  140  distributes or routes contacts (incoming or outgoing) to an agent position. Voice over Internet Protocol (VoIP) calls and computer-based contacts (e.g., chat, email) are routed over one or more data networks, and distributed over network  130  to one of the agent workstations  120 . Contact router  140  may include an automatic call distributor (ACD)  120  to route phone contacts. The embodiments described herein will refer to the ACD  120  instead of contact router  140 , but analogous contact router actions and operations are intended to be captured by this disclosure. 
     If an agent is not available to handle a particular call, ACD  120  puts the call into a queue, which effectively places the caller on hold. When an agent is available, ACD  120  connecting the outside trunk line  150  carrying the phone call to one of the agents. More specifically, ACD  120  connects the outside trunk line  150  to the trunk line  160  of the selected agent. 
     When an agent is ready to handle contacts, the agent first logs into the contact router  140 . This login notifies the contact router  140  that the agent is available to generate outgoing contacts or to handle incoming contacts. An agent&#39;s state with respect to the router changes throughout the workday, as the agent performs work activities such as handling calls, performing after-call work, and taking breaks. An example list of states includes available, busy, after-call work, and unavailable. 
     While handling a contact, the agent interacts with one or more applications  170  running on workstation  120 . By way of example, workstation applications could provide the agent with access to customer records, product information, ordering status, and transaction history. The applications may access one or more business databases (not shown) via network  130 . 
     The contact center  100  also includes a work force management system (WFMS)  180 . WFMS  180  performs many functions. One of these functions is calculating staffing levels and agent schedules based on historical patterns of incoming calls. Another function of WFMS  180  is collecting call center contact statistics and providing this information, both historical and real-time, to the call center supervisor or manager. Some of these statistics are typically displayed on a periodic basis in a “pulse” window. The pulse window is used by a call center manager to obtain a quick summary of call center operations during the last period. One statistic commonly shown in a pulse window is an actual staff count for the last period. 
     The WFMS  180  also maintains a list of agents and skills associated with each agent. Examples of agent skills include knowledge of a particular product or process (e.g., customer service or sales), and the ability to speak a particular language (e.g., Spanish). This agent-skill association information is provided to contact router  140  so that contact router  140  can route calls based on agent skills, as shown in  FIG. 2 . 
     As each agent  210  begins work in the contact center, the agent  210  logs in to contact router  140 . Contact router  140  uses the agent login information to determine the skills associated with an agent. Each skill is associated with one or more queues  230 . 
     For example, the scenario shown in  FIG. 2  includes four agents ( 210 A-D) and three queues ( 230 A-C). Agent  210 A has only one skill ( 1 ), and is therefore associated with queue # 1  ( 230 A). Agent  210 B has two skills ( 1 ,  2 ) and is therefore associated with queue # 1  ( 230 A) and queue # 2  ( 230 B). Agent  210 C also has two skills ( 2 ,  3 ), and is therefore associated with queue # 2  ( 230 B) and queue # 3  ( 230 C). Finally, agent  210 D has a single skill ( 3 ), and is therefore associated with queue # 3  ( 230 C). 
     The contact router  140  receives incoming contacts and distributes each contact  220  to one of a set of queues  230 , where each queue  230  is associated with a particular agent skill. The contacts  220  remain queued until an agent  210  with appropriate skills is available. 
     To determine in which queue  230  a contact is to be placed, the contact router  140  identifies which agent skills the contact relates to. The contact router  140  makes this determination by classifying the contact based on various parameters, such as customer input (e.g., touchtone or interactive voice recognition) or contact information (e.g. called number or calling number). Based on this classification, the contact is then distributed to a particular queue  230 , handled by agents having that skill. Two simple examples of classification are: customer presses 1 for English, or 2 for Spanish; customer dials one toll-free number for Sales or a different number for Customer Service. In that example, contacts classified as “Spanish” would be routed to a queue associated with an agent having a Spanish-speaking skill. 
     As an agent  210  becomes available to handle a contact  220 , the contact router  140  routes, to that agent  210 , the next contact in one of the queues  230  associated with that agent  210 . In this scenario, all four agents are available to handle contacts. Thus, the first contact in queue # 1  ( 220 A) could be routed to agent  210 A or agent  210 B. The first contact in queue # 2  ( 220 B) could be routed to agent  210 B or agent  210 C. The first contact in queue # 3  ( 220 C) could be routed to agent  210 C or agent  210 D. 
       FIG. 3  is a block diagram showing several components of the WFMS  180 , including an activity collector  310 , an activity database  320 , a staff statistics calculator  330 , and a user interface  340 . As an agent handles contacts throughout a workday, the contact router  140  reports changes in the state of the agent&#39;s phone to the WFMS  180 , as ACD events  350 P. As an agent interacts with various applications  170  on his workstation  120 , an application monitor  360  tracks and reports application events  350 A to the WFMS  180 . In some embodiments, the granularity of application events  350 A is application-level, so that events describe when applications start and exit, and when a user switches from one application to another. In other embodiments, the granularity is screen-level (events describe a particular screen displayed within an application) or low-level (events describe input and/or output associated with each application such as keystrokes, mouse clicks, and screen updates). 
     The collector  310  receives these events  350  from multiple sources. An event  350  has an occurrence time and a descriptor which includes fields such as event source (e.g., ACD, application monitor), type, and agent identifier. If the event  350  does not include an agent identifier, the collector  310  maps the phone or workstation identifier to a corresponding agent identifier based on information obtained at agent login. Thus, the event  350  indicates, either directly or indirectly, an agent identifier. 
     From the reported events  350 , the collector  310  creates agent activity records  370 , and stores them in the database  320 . In some embodiments, the activity records  370  stored in the database  320  include an agent identifier, an activity source, an activity code, a start time, a stop time, and a duration. 
     The database  320  stores various other types of records also. A contact center manager uses the user interface  340  to create agent records  375 , each of which includes the skill(s) possessed by each agent. The user interface  340  is also used to create campaign records  380 , each of which includes a set of ACD queues which is associated with the campaign. 
     A person of ordinary skill in the art of software development will understand that the data organization described above is only one way among many to organize database  320 . Database  320  can be organized in many other ways that allow the same relationships to be expressed, and all such organizations are intended to be captured by this disclosure. 
     The staff statistics calculator  330  uses the information provided by the activity records  370 , agent records  375 , and campaign records  380  to calculate per-queue staff statistics  390  for a staffing interval. The staff statistics calculator  330  produces queue-specific staff counts for the interval, based on activity records, skill sets associated with agents, and skill sets associated with contact queues. In some embodiments, staff statistics  390  include a body, or staff, count. As will be understood by one skilled in the art, a staff count is the number of agents logged into a queue in some time interval. The body count does not take into account the fact that agents with multiple skills can handle multiple queues, and therefore divide their time among specific queues (associated with the agent&#39;s skills). In some embodiments, staff statistics  390  include a full-time equivalent (FTE) count. As will also be understood by one skilled in the art, an FTE count is the number of dedicated agents needed to achieve the service levels being seen on a queue. Thus, the FTE count does take into account the way agents divide their time among queues, and that agents with multiple skills are more efficient. In some embodiments, the calculation of staff statistics  390  is run periodically, and in others the calculation is performed on demand. 
     The staff statistics calculator  330  will now be described in further detail. Although an activity record  370  describes which agent  210  performed the activity, an activity record  370  does not directly specify which of the queues  230  the agent was servicing at the time associated with the activity. Therefore, the staff statistics calculator  330  performs further processing to determine which ACD queue or queues  230  an agent  210  is counted against when calculating the per-queue staff statistics  390 . 
       FIG. 4  is a flowchart depicting functionality of an embodiment of the staff statistics calculator  330 . At block  410 , the activity records  370  for an agent  210  are retrieved. Next (block  420 ), the activity records  370  are examined to determine the duration of all activities occurring within the desired time period. At block  430 , the total duration is compared to a threshold. If the threshold is not met, then processing continues with the next agent  210 , at block  410 . 
     If the total duration threshold is met, then processing continues at block  440 , where a subset of queues is selected. The queue selection process will be described in further detail later, in connection with  FIG. 5 . Next (block  450 ), the body count in each of the per-queue staff statistics  390  is incremented by one for each of queues selected in block  440 . At block  460 , the full time equivalent (FTE) count in the per-queue staff statistics  390  is calculated for each of queues selected in block  440 . By way of example, calculation of FTE counts can be performed using a reverse Erlang C formula, as follows 
               P   c     =           E   N       N   !       ×     N     N   -   E           ∑     (         E   X       X   !       +     (         E   N       N   !       ×     N     N   -   E         )       )               
where P c  is the probability that a customer will experience a non zero delay, E is the total traffic offered (in Erlangs), and N is the total number of resources available. One of ordinary skill in the art should understand Erlang calculations, so this will not be discussed in further detail.
 
     At block  470 , a determination is made as to whether all agents  210  have been processed. If Yes, then processing is finished. If No, then processing continues with the next agent  210 , at block  410 . 
       FIG. 5  is a data flow diagram of an embodiment of the queue selection process  440 . An agent record  510  is provided as input to the queue selection process  440 . In the implementation shown in  FIG. 5 , the agent record  510  has an association ( 520 ) with one or more campaign records  530 , and each campaign record  530  has an association ( 540 ) with one or more queue records  550 . Thus, each agent record  510  is associated, through one or more campaign records  530 , with a set ( 560 ) of one or more queue records. In another implementations (not shown), the campaign feature may not be present, thus an agent can be directly associated with a queue. 
     Using information in the agent record  510 , a subset  570  of the set  560  of queue records is selected for update as follows. For each queue record  550  in the set  560 , the skill list ( 580 ) of the queue record  550  is compared with the skill list ( 590 ) of the agent record  510 . In the case of a queue skill list  580  with no skills, then the queue record  550  is put into the selection subset  570 . Otherwise, the matching queue record  550  goes into the selection subset  570  if all skills in the queue skill list  580  are found in the agent skill list  590 . Instead of adding queues to an initially-empty selection subset, an alternative embodiment could instead produce a selection set by removing queues with non-matching skills from the original set  560  of queue records. 
     For example, in the scenario shown in  FIG. 5 , agent record  510  has an association with two campaigns ( 530 A,  530 B). Campaign  530 A has an association with two queues ( 550 A,  550 B). Campaign  530 B has an association with two queues ( 550 C,  550 D). The original queue set  560  thus comprises four queues,  550 A-D. 
     The agent skill list  590  includes two skills:  2  and  5 . Only one of the four queues has a skill list  580  that includes both skill  2  and skill  5 : queue  550 A. Thus, queue  550 A goes into the selection subset  570 . Queue  550 D also goes into the selection subset  570  because queue  550 D has no skills in the queue skill list  580 . 
     Another implementation of queue selection process  440  (not shown) handles distributed campaigns. A distributed campaign uses at least one distributed queue, which is represented as a parent queue having a list of (normal) child queues. In this implementation, queue selection process  440  further expands the selection subset  570  by including in the selection subset  570  the parent of each child queue record. Thus, the staff statistics  390  are incremented for the parent queue as well as the child queue. 
     In another variation of staff statistics calculator  330 , each contact queue  230  is associated with a media type (e.g., phone, e-mail, or chat). The staff statistics calculator  330  in this embodiment computes the staff counts for a particular media, or across all media (a feature called “combined staffing”.) When this multi-media embodiment is combined with a distributed campaign embodiment, the staff statistics  390  for the child queue are incremented only if that queue is associated with the same data source as the agent under consideration. 
       FIG. 6  is a hardware block diagram of a general-purpose computer  600  which can be used to implement the system and method for calculating workforce staffing statistics from activity records. The computer  600  contains a number of components that are well known in the art of contact center software, including a processor  610 , a network interface  620 , memory  630 , and non-volatile storage  640 . Examples of non-volatile storage include, for example, a hard disk, flash RAM, flash ROM, EEPROM, etc. These components are coupled via a bus  650 . The memory  630  contains instructions which, when executed by the processor  610 , implement the system and method for calculating workforce staffing statistics from activity records such as the process depicted in the flowcharts and dataflow diagrams of  FIGS. 4 and 5 . Omitted from  FIG. 6  are a number of conventional components, known to those skilled in the art, that are unnecessary to explain the operation of system  600 . 
     The systems and methods for calculating workforce staffing statistics from activity records disclosed herein can be implemented in software, hardware, or a combination thereof. In some embodiments, the system and/or method is implemented in software that is stored in a memory and that is executed by a suitable microprocessor situated in a computing device. However, the systems and methods can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device. Such instruction execution systems include any computer-based system, processor-containing system, or other system that can fetch and execute the instructions from the instruction execution system. In the context of this disclosure, a “computer-readable medium” can be any means that can contain, store, communicate, propagate, or transport the program for use by, or in connection with, the instruction execution system. The computer readable medium can be, for example but not limited to, a system or propagation medium that is based on electronic, magnetic, optical, electromagnetic, infrared, or semiconductor technology. The functionality could also be implemented in logic embodied in hardware or software-configured media. 
     Specific examples of a computer-readable medium using electronic technology would include (but are not limited to) the following: an electrical connection (electronic) having one or more wires; a random access memory (RAM); a read-only memory (ROM); an erasable programmable read-only memory (EPROM or Flash memory). A specific example using magnetic technology includes (but is not limited to) a portable computer diskette. Specific examples using optical technology includes (but are not limited to): an optical fiber; and a portable compact disk read-only memory (CD-ROM). 
     Any process descriptions or blocks in flowcharts should be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps in the process. As would be understood by those of ordinary skill in the art of the software development, alternate embodiments are also included within the scope of the disclosure. In these alternate embodiments, functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved. 
     This description has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise forms disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiments discussed, however, were chosen to illustrate the principles of the disclosure, and its practical application. The disclosure is thus intended to enable one of ordinary skill in the art to use the disclosure, in various embodiments and with various modifications, as are suited to the particular use contemplated. All such modifications and variation are within the scope of this disclosure, as determined by the appended claims when interpreted in accordance with the breadth to which they are fairly and legally entitled.