Patent Publication Number: US-2022215324-A1

Title: Data tracking and generation for workforce management

Description:
FIELD 
     Embodiments and examples of the present invention relate to contact centers and data processing. More particularly, embodiments of the present invention relate to systems and methods for data tracking and generation for workforce management. 
     BACKGROUND 
     Today, entities or companies provide customer service using a contact center. For instance, a customer can contact a contact center that routes the contact to an available agent for servicing the customer. A conventional contact center can use skill-based routing to route contacts from a customer based on the skills of the agent. For example, a customer may indicate a need to cancel a credit card that was stolen, and be placed in a queue serviced by an agent experienced with canceling credit cards. 
     Furthermore, contact centers provide service to customers on multiple communication channels, e.g., telephone contacts, emails, text messages, short message service (SMS) messages, social media, etc. Contact centers should also be flexible to adjust the routing of different contacts on multiple communication channels to appropriate agents based on any number of reasons to improve customer service. For example, a customer may have used SMS messaging to start a communication with a contact center, but realizes that sending texts is cumbersome and speaking with an agent directly would be more effective. 
     Prior to the existence of the Internet and cell phones, before email, text messages, instant messaging, online chats, online video chats, etc., call centers handled telephone contacts between customers and agents. A primary concern was whether the call center had the correct number of people (agents) to handle the volume of telephones and customer calls. If there were two few agents to handle the call volume, customers would not get the level of service that would leave them with a favorable impression of the company. If there were too many agents to handle the call volume, the company would end up with unnecessary spending to cover the cost of the agents that were not necessary to handle the call volume. 
     Now, however, contact centers handle so many types of contact between customers and agents on so many different types of channels, there is a much larger volume and variety of customer-agent contact. Concerns about staffing a contact center are more difficult and less straightforward to address than when a call center only had to deal with telephone calls. Furthermore, agents can handle more contacts at the same time in an efficient manner where such was not the case with telephone calls. For example, an agent can be handling multiple chat and/or emails sessions with different customers simultaneously. Thus, because of the types of contacts that are possible for a call center today, performing workforce management to determine staffing for a call center is much more difficult. Recently, workforce management (WFM) software and systems have been developed and become commercially available to meet some of these concerns. Yet, there is a need for improvements in the art. 
     SUMMARY 
     Systems and methods for tracking and generating data for workforce management are disclosed. In one embodiment, the workforce management is customer-focused workforce management. 
     One embodiment is a method for generating data for use in workforce management. The method is performed by a processor-based system. The method includes identifying one or more contact items within each of one or more conversations between one or more customers contacting a contact center and one or more agents associated with the contact center. Each contact item is tagged with a contact type and a channel type. Periods of agent activity are tracked for each channel for each agent. The tracked data is sent to a workforce management system or other system. 
     One embodiment is a tangible, non-transitory, computer readable media. The media has instructions. When the instructions are executed by a processor, the processor performs operations. The operations include identifying one or more contact items within each of one or more conversations that are between one or more customers contacting a contact center and one or more agents associated with the contact center. Each contact item is tagged with a contact type and a channel type. The channel type is selected from multiple channel types. Periods of agent activity are tracked for each channel for each agent. This tracking uses the tagging of the contact items for one or more work sessions. The tracked data is sent to a workforce management system. 
     One embodiment is a system. The system has a database in a memory, and one or more processors. The one or more processors are to identify one or more contact items within each conversation between one or more customers contacting a contact center and one or more agents associated with the contact center. The one or more processors are to tag each contact item with a contact type and a channel type. The one or more processors are to track periods of agent activity for each channel for each agent. The periods of agent activity are tracked using the tagging of the contact items for one or more work sessions. The one or more processors are to send the tracked data to a workforce management system. 
     Other methods, systems, and computer readable-mediums are described. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The appended drawings illustrate examples and embodiments and are, therefore, exemplary and not considered to be limiting in scope. 
         FIG. 1A  illustrates one embodiment of a flexible and extensible contact center environment. 
         FIG. 1B  illustrates one embodiment of communication channels for routing a customer to a selected agent in the contact center environment of  FIG. 1A . 
         FIG. 2A  illustrates one embodiment of a routing database table matching agents to customers based on a highest scoring pair. 
         FIG. 2B  illustrates one embodiment of a routing database table showing attributes for agents. 
         FIG. 2C  illustrates one embodiment of a routing database table showing attributes for customers. 
         FIG. 2D  illustrates one embodiment of a routing database table showing scoring based on customer and agent attributes of  FIG. 2C . 
         FIG. 2E  illustrates one embodiment of a routing database table showing a list of criteria to match agents with customers along with relative importance of those criteria to scoring. 
         FIG. 2F  illustrates one embodiment of a routing database table showing a scenario of evaluating an agent and customer according to the criteria of  FIG. 2E . 
         FIGS. 3A-3C  illustrates one embodiment of a contact center routing ecosystem and data flow. 
         FIGS. 4A-4B  illustrates one embodiment of screen shots of an administration interfaces for setting up communications with customers on multiple communication channels. 
         FIG. 5  illustrates one embodiment of a screen shot of exemplary rules or criteria for matching customers to agents. 
         FIG. 6  illustrates another embodiment of a screen shot of an agent interface for helping customers after a rule or criteria match. 
         FIG. 7  illustrates one embodiment of a block diagram of data processing system or computing system architecture to implement the enhanced contact routing between customers and agents. 
         FIG. 8  illustrates one embodiment of a flow diagram of an operation for routing contacts at a contact center. 
         FIG. 9  illustrates another embodiment of a flow diagram of an operation for routing contacts at a contact center. 
         FIG. 10  illustrates one embodiment of a flow diagram of an operation for changing communication channels. 
         FIG. 11  illustrates one embodiment of an administration interface for providing mapping rules and scoring criteria. 
         FIG. 12  illustrates one embodiment of an administration interface for providing scoring criteria for an exemplary account. 
         FIG. 13  illustrates one embodiment of an interface for an agent to help customers across multiple channels. 
         FIG. 14  illustrates one embodiment of a contact center with an accessible customer-focused workforce management (WFM) system. 
         FIG. 15  illustrates one embodiment of the database for in the workforce management system of  FIG. 14 . 
         FIG. 16  illustrates one embodiment of a user interface for use in the workforce management system of  FIG. 14 . 
         FIG. 17A  illustrates one embodiment of derived data, e.g., work bursts and work sessions involving a single channel and a single agent, that is tracked in the database in the workforce management system of  FIG. 14 . 
         FIG. 17B  illustrates one embodiment of derived data, e.g., work bursts and work sessions involving a single channel and multiple agents, that is tracked in the database in the workforce management system of  FIG. 14 . 
         FIG. 17C  illustrates one embodiment of derived data, e.g., work bursts and work sessions involving multiple channels and a single agent, that is tracked in the database in the workforce management system of  FIG. 14 . 
         FIG. 17D  illustrates one embodiment of derived data, e.g., work bursts and work sessions involving multiple channels and multiple agents, that is tracked in the database in the workforce management system of  FIG. 14 . 
         FIG. 18  illustrates a further embodiment of derived data, e.g., customer wait time, backlog time and agent response time, that is tracked in the database in the workforce management system of  FIG. 14 . 
         FIG. 19  illustrates a flow diagram of a method for customer-focused workforce management, which can be performed by embodiments of the workforce management system of  FIG. 14 . 
     
    
    
     DETAILED DESCRIPTION 
     In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. It will be apparent, however, to one skilled in the art, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present invention. 
     Data tracking and generation for workforce management are described. One of the goals, met in various embodiments disclosed herein, is to make tracking much less difficult than it is today. That is, the various embodiments described herein help companies access accurate, non-duplicated tracking of work. In a multi-channel world, where customers can be contacting a company using several channels at once, companies want to be sure they&#39;re not double-counting the work. Because typical contact tracking counts the handle time/work bursts for all channels at a given time, present embodiments remove the possibility of duplicate counting, while also giving an accurate view into the volume of work the contact center is managing. 
     In one embodiment, the data tracking and generation is associated with a contact center. In one embodiment, the contact center handles contacts using a customer-focused approach and the data related to the customer contacts is tracked and converted into data that can be used by a workforce management system. In one embodiment, the data tracking and generation is performed by the workforce management system. In another embodiment, the data tracking and generation is performed by a system separate from the workforce management system and is provided to the workforce management system. In one embodiment, the system that performs the data generation and tracking is part of the contact center (e.g., part of the contact center software and hardware, etc.). In response thereto, the workforce management system performs one or more of its well-known functions such as, for example, determining projected staffing levels for the contact center. 
     In one embodiment, the data tracking and generation system tracks customers and conversations between customers and agents. In this context, each contact, or conversation, item corresponds to the series of communications between a customer and agent that occurs during one communication session over one communication channel. A “conversation” as defined herein can be multiple contacts on multiple channels over a period of time, usually to resolve an issue. For example, processing a damaged shipment may take two phone calls and three emails, but would be considered one conversation, because all conversation, or contact, items were in support of resolving that one issue. For purposes herein, a communication channel can refer to any means of communication that can be used to provide service and communication between a company and a consumer or customer. In one embodiment, examples of communication channels include a short message service (SMS) message channel, text message channel, telephone contact channel, cell phone channel, email channel, social media channel, messenger channel, voicemail channel, phone callback channel, fax channel, or chat channel. Channels can include, but are not limited to, a video channel for one or more video calls, a video conferencing channel, a channel created by communication applications that include calling functionality such as, for example, FaceTime, WhatsApp, Skype, communication applications that operate such as, for example, Google Hangouts, real-time hologram, chat (e.g., web chat, mobile application chat, WeChat, Apple Business Chat, etc.), a channel created by a communications functionality including text, short message service (SMS), and Multimedia Messaging Service (MMS), email, voice mail, fax, radio, WhatsApp, Facebook Messenger, Twitter, Instagram, LinkedIn messaging, using a kiosk, and many other social media communication channels. 
     In one embodiment, the system tracks, tags and analyzes various aspects of the conversations (communications), which are of various types and occur over various channels. In one embodiment, the tracking and analysis divides each conversation, or communication, into discrete time segments that are tagged and associated with a particular type of channel. In one embodiment, this information is stored in a database or other storage facility. 
     The data that is tracked and generated from the conversations between agents and customers is provided or made available to the workforce management system. The availability may be accomplished by providing access for the workforce management system to one or more databases storing the tracked and generated data. Based on the data tracked and generated, the workforce management system performs one or more of field service management, human resource management, performance and training management, data collection, recruiting, budgeting, forecasting, scheduling and analytics. In one embodiment, the workforce management system generates various reports. In one embodiment, for input to the one or more databases, the system provides a user interface. In one embodiment, access to the one or more databases is also provided to workforce management systems through the use of an application programming interface (API). 
     The description below is divided into two parts. The first part includes systems and methods are disclosed for flexible and extensible contact center routing, with the embodiments illustrated in  FIGS. 1-14 , while the second part includes systems and methods disclosed for data tracking and generation for a customer-focused workforce management, with embodiments illustrated in  FIGS. 15-19 . For one embodiment, with respect to the contact center routing incoming contacts are routed on any number of communication channels between customers and agents. Routing of contacts on these communications channels can be flexible such that a contact center can switch from one communication channel to a different communication channel. For example, a customer may have started a contact using SMS messaging, but now desires to speak with an agent directly. The techniques disclosed herein allow the contact center to switch over from one communication channel to a different communication channel—e.g., switching between a SMS communication channel to a telephone communication channel. By doing so, the techniques enable a seamless transition of communication for the customer-agent pair when switching communication channels. Accordingly, the disclosed flexible and extensible routing techniques improve on the rigidness of conventional contact centers to meet customer needs which can be continuously changing. 
     For purposes herein, agents, service representatives, advisors, or any other title, can refer to any user of the system that would use a tool to provide service to consumers or customers. These agents can be interfacing with the consumers or customers, or they can be completing work that does not require them to interface with consumers or customers. Agents can benefit from this routing system whether they access their work through a user interface of the system described herein, or whether they access their work in an external system that is connected to the system described herein through API or other means or remote access and control. 
     Administrators, or admins, can refer to any user of the system, whether accessing the tool through a user interface or API or other remote access and control method, who has sufficient levels of permission to monitor and edit the settings that extend and adjust the routing system. 
     As set forth herein, various embodiments, examples and aspects will be described with reference to details discussed below, and the accompanying drawings will illustrate various embodiments and examples. The following description and drawings are illustrative and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of various embodiments and examples. However, in certain instances, well-known or conventional details are not described in order to provide a concise discussion of the disclosed embodiments and examples. 
     Flexible and Extensible Contact Center Routing Environment 
       FIG. 1A  illustrates one embodiment of a flexible and extensible contact center environment  100 . Contact center environment  100  includes a contact center data processing system  102  receiving incoming contacts from customers 1 to N ( 105 - 107 ) and routing the incoming contacts to agents 1 to M ( 108 - 110 ) for service. N and M can represent any number of customers and agents. For one embodiment, contact center data processing system  102  can include a computing architecture, as shown, e.g., in  FIG. 8 , having components to implement core routing module  103  and routing database  104 . For one embodiment, core routing module  103  can be a combination of hardware and/or software to implement programs or program modules that perform one or more functions or operations including the disclosed flexible and extensible contact routing techniques. For one embodiment, database  104  can be any type of database including a relational database management system (RDMS). 
     For one embodiment, routing database  104  stores attributes for customers 1 to N, agents 1 to M, and Boolean representations used to determine or generate scores or priorities on how agents 1 to M are assigned to service customers 1 to M. For example, routing database  104  can store tables as shown, e.g., in  FIGS. 2A-2F , describing attributes for customers and agents, guidelines, criteria, and Boolean representations used to determine and generate scoring pairs between agents and pair or determine priorities for servicing customers. The routing database  104  tables can be adjusted or programmed allowing for contact routing to be flexible and extensible for the changing needs of customers. For other embodiments, routing database  104  can store any number of guidelines, criteria or Boolean representations to further assist how to determine scoring pairs or set priorities for certain customers, which override a high pair score with respect to certain customers. For one embodiment, core routing module  103  can use one or more tables stored in database  104  and/or guidelines, criteria or Boolean representations to route incoming contacts from customer 1 to N to one of the agents 1 to M based on a pairing score or a priority. For example, each of the agents 1 to N can have a pairing score associated with each of the customers 1 to N, and the highest pairing score between an agent with the customers can be used to connect that agent related to a highest pairing score with a customer. For other embodiments, an override condition can exist to give priority to a particular customer regardless of a highest pairing score, e.g., a special status customer or customer in an emergency situation. 
       FIG. 1B  illustrates one embodiment of communication channels  113  to  117  for routing a customer  111  to a selected agent  112  in the contact center environment  100  of FIG.  1 A. For this example, communication channel  113  can represent a short message service (SMS) or text channel, communication channel  114  can represent an email channel, communication channel  115  can represent a telephone or cell channel, communication channel  116  can represent a social media channel, and communication channel  117  can represent other communication channels. For one embodiment, core routing module  103  can initially route customer  111  to selected agent  112  on a SMS/Text channel  113  represented by “A.” During the service session with selected agent  112 , the enhanced core routing module  103  can change the communication channel to telephone contact channel  115  represented by “B.” For example, customer  111  may have started communicating with selected agent  112  on channel A in which details were cumbersome to type in on a keypad and texted selected agent  112  that he wanted to speak personally over the phone. In this case, when customer  111  contacts the contact center, core routing module  103  can be configured to know that selected agent  112  was engaged with session on a SMS/text communication channel  113  and route the contact on telephone/cell communication channel  115  directly to selected agent  112 . In this way, customer service can be improved by allowing for seamless transition between communication channels at a contact center. 
     Agent and Customer Attributes and Scoring Pair Examples 
       FIG. 2A  illustrates one embodiment of a routing database table  200  matching agents  201  to a customer  202  based on a highest scoring pair. Database table  200  can be stored in routing database  104 . Referring to  FIG. 2A , database table  200  includes a list of agents  201  identified as “1” through “5.” Although five agents are listed, database table  200  can include any number of agents. For this example, each of the agents 1 through 5 is associated with a scoring pair  203  regarding customer “3”—i.e., scoring pairs of 14, 14, 12, 16 and 14 for agents 1 to 5, respectively. Based on the scoring pair, agent 4 has the highest scoring pair of “16” with respect to customer 3. As a result, in this example, core routing module  103  can route an incoming contact from customer 3 to agent 4 having the highest scoring pair 16 based on database table  200 . Each pairing score  203  can be based on customer  202  attributes, agent  201  attributes, guidelines, criteria or Boolean representations. For example, customer 3 may have an attribute of speaking Spanish, and agent 4 may also have an attribute of speaking Spanish and having serviced customer 3 previously which allows agent 4 to have the highest scoring pair. The attributes for agents  201  and customer  202 , guidelines, criteria or Boolean representation can be adjustable and extensible, which can be used by core routing module  103  to update or modify routing of incoming contacts from customer 3 to any of the agents 1 through 5 as contact center circumstances change or evolve. In other examples, there will be any number of customers and a respective scoring pair for each of the agents, e.g., agents 1-5. For example, there may be customers 1-20 having a scoring pair with each of the agents 1-5. This would allow the contact center to optimize for the best possible pairings across a range of customers and agents. 
       FIG. 2B  illustrates one embodiment of a routing database table  205  showing attributes  207 - 209  for agents  206 . Referring to  FIG. 2B , agents  206  are identified as 1 to 5 having names Salvatore, Gina, Terry, Jean-Michel, and Ling. The previously contacted customer  207  attributes refer to customers serviced previously by Salvatore, Gina, Terry, Jean-Michel and Ling. In this example of attributes, Salvatore, Terry and Ling had “None,” while Gina previously contacted customer 3, and Jean-Michael previously contacted customers 3 and 5. For languages(s)  208  attributes, Terry, Jean-Michel and Ling speak English only, and Salvatore speaks Spanish only, and Gina speaks both English and Spanish. And, for expertise  209  attributes, Salvatore, Jean-Michel and Ling have expertise in Products and Gina and Terry have expertise in Billing. These attributes can be used to determine scoring pairs or priorities using any number of guidelines, criteria or Boolean representations. For example, for an incoming contact by customer 3 who speaks Spanish and needs expertise in Billing, based on the attributes for agents  206 , Gina would have positive results because she previously serviced this customer, speaks Spanish and has expertise. Accordingly, for customer 3, Gina can have the highest pairing score among the other agents, which can be used by core routing module  103  to route an incoming contact from customer 3 to Gina. 
       FIG. 2C  illustrates one embodiment of a routing database table  210  showing attributes  212 - 218  for customers  211 . In this example, there are five customers (1 to 5) having names Ingrid, Maria, Jose, Jeanette and Antoine. Attributes associated with customers 1 to 5 are channel  213 , minutes waiting  214 , status  215 , languages  216 , snowstorm  217 , and issue area  218 . The channel  218  attributes show that text, SMS, email, phone and phone channels are used by customers 1 to 5 for an incoming contact to contact center environment  100 . The minutes waiting  214  attribute shows waiting times of 0.5, 7, 10, 15 and 4 minutes for customers 1 to 5. The status  215  attributes show status of premium, none, none, basic and none for customers 1 to 5. The languages  216  attributes show English, Spanish, English and Spanish, Spanish and English for customers 1 to 5. Snowstorm  217  attributes show no, no, yes, no and no for customers 1 to 5. And the issue area  218  attributes show billing, billing, products, billing and unknown for customers 1 to 5. 
     For one embodiment, a guideline, criteria or Boolean representations can be used for any one or combination of attributes  213  to  218  to determine a pairing score. For example, a guideline, criteria or Boolean representation can be if the status  215  attribute for a customer is “Premium,” then that customer (i.e., customer 1, Ingrid) should be routed first regardless of wait times of the other customers and thus provide a high score. In this example, Ingrid has the shortest wait time of 0.5 minutes while Jose has waited for 10 minutes. For this contact center, status of customer may give priority over non-premium customers to premium customers. Alternatively, a contact center can make long wait times as having higher priority over short wait times regardless of the status of customer. In other examples, if a customer is in an emergency situation, e.g., snowstorm  217  attribute is Yes (e.g., Jose is impacted by a snowstorm), that customer may be given a higher scoring pair or priority over other customers. Any number of guidelines, criteria or Boolean representations can be used using any number of customer attributes  213  to  218  to determine a scoring pair or to give priority to certain customers regardless of scoring pair. 
       FIG. 2D  illustrates one embodiment of a routing database table  220  showing scoring pairs based on customer and agent attributes of  FIGS. 2B-2C . For one embodiment, core routing module  103  can process the customer and agent attributes to determine matches along any number of guidelines, criteria or Boolean representations to calculate a scoring pair of 14 between Salvatore and Jose. In this example, agent Salvatore whose attributes  221  include Agent ID as 1, previously contacted customer ID(s) as None, Language(s) as Spanish, and Expertise as Products. In this example, the matched customer is Jose whose attributes  222  include Customer ID as 3, Channel as Email, Minutes waiting as 10, Status as None, Language(s) as English and Spanish, Snowstorm Impact as Yes and Extreme, and Issue area as Products. 
     For one embodiment, core routing module  103  can calculate or generate pairing scores for all customers  223  such that Ingrid, Maria, Jose, Jeannette and Antoine receive scores of 2, 3, 14, 7 and 1, respectively, with respect to Salvatore as the agent. These pairing scores can be based on any of the customer or agent attributes and any combination of guidelines, criteria or Boolean representations. For example, for the high score calculation  224  of 14 for Jose, the matched attributes for Salvatore as an agent and Jose as a customer included Snowstorm Impact with a sub-score of 10, Same Language with a sub-score of 2, and Subject Matter Expertise with a sub-score of 2 which totaled 14. For this contact center, Snowstorm Impact was given a high priority of 10. For example, the contact center could be for winter equipment products and, if snowstorm impact was observed, the contact center would give the customer impacted by a snow storm a higher priority and score because it has been also identified as “extreme.” For one embodiment, the communication channel of email by Jose could be switched over to telephone or SMS text such that agent Salvatore can provide a more immediate response to meet the needs of the customer—i.e., Jose. 
       FIG. 2E  illustrates one embodiment of a routing database table  225  showing a list of criteria and Boolean representations to match agents with customers. Referring to  FIG. 2E , the criteria ID  226  include 1 to 7 referring to Names Previous Contact, Premium Status, Snowstorm Impact, Some Wait, Long Wait, Same Language and Subject Matter Expertise. The table  225  shows how the criteria are satisfied based on Boolean representations or operations and if certain attributes are indicated or present. For one embodiment, core routing logic  103  can determine if each incoming contact from a customer meets the seven criteria and Boolean representations to determine scoring pairs for matching customers to an agent. 
     In this example, for the Previous Contact criteria (1) to be met, the agent&#39;s previous customer ID attributes include the same customer ID related to an incoming contact. The importance criteria can be indicated as Medium. If, for example, there is a tied pairing score for all customers, any type of tie-breaking mechanism can be used, such as the customer having the longest wait time, to match the customer to the agent. For Premium Status criteria (2) to be met, customer status equals Premium. The importance of this criteria can be indicated as Low. For Snowstorm Impact criteria (3) to be met, snowstorm impact indication for the customer equals Yes. The importance of this criteria can be indicated as Extreme. For the Some Wait criteria (4) to be met, customer wait time is greater or equal to 4 minutes AND customer wait time is less than 11 minutes. The importance of this criteria can be indicated as Low. For the Long Wait criteria (5) to be met, the customer wait time must be greater or equal to 11 minutes. The importance of this criteria can be indicated as High. The importance levels can assist in determining pairing scores or weighting scores. 
     For the Same Language criteria (6) to be met, the customer AND agent language equals English OR customer AND agent language equals Spanish. The importance of this criteria can be indicated as Medium. For the Subject Matter Expertise criteria (7) to be met, the customer issue area AND agent area of expertise equals Billing or customer issue area AND agent area of expertise equals Products OR customer issue area AND agent area of expertise equals Tech/Website. In the above examples, the number of criteria is extensible in which additional criteria can be added. The attributes and Boolean representations can also be adjusted, modified or extended. For one embodiment, if importance to routing is Extreme, the weighting or scoring can be increased. In this example, if a customer had Previous Contact, Premium Status, Long Wait, Same Language, and Subject Matter Expertise points, the customer could be matched or paired with an agent ahead of another customer who only has the Snowstorm Impact, but no other points. In other examples, an override condition can be determined on specific Boolean conditions that can place certain customers and agents ahead of a main group. 
       FIG. 2F  illustrates one embodiment of a routing database table  240  showing a scenario of evaluating an agent and customer pair  241  according to the criteria of  FIG. 2E . For this example, the pair to evaluate  241  includes agent 1 and customer 3 based on attributes and criteria of  FIGS. 2B-2E . Referring to  FIG. 2F , for the seven criteria of  FIG. 2E , in criteria T/F field  243 , criteria 3 (Snowstorm Impact), 6 (Same Language) and 7 (Subject Matter Expertise) were met and identified as TRUE. The other criteria were not met and identified as FALSE. The score for criteria 3 is 10 and criteria 6 and 7 the score was 2 such that the total score for the agent-customer pair is 14. For this pair, the agent Salvatore received a total score of 14 with customer 3. In the temporary data store  242 , attributes for the agent (Salvatore) include previously contacted customer ID (None), Language (Spanish) and Expertise (Products). And attributes for the customer (Jose) include channel (Email), minutes waiting (10 minutes), Status (None) Language(s) (English and Spanish), Snowstorm Impact (Yes) and Issue Area (Products). Table  240  can be stored in routing database  104  in which scenarios for all the agents and customers can be saved for data analysis. As can be seen from the above examples, the customer attributes, agent attributes, guidelines, criteria and Boolean expressions and parameters are flexible such that they can be adjusted and extensible. 
     Exemplary Contact Center Routing Ecosystem 
       FIGS. 3A-3C  illustrates embodiments of a contact center routing ecosystem  300  and data flow. Referring to  FIG. 3A , data is collected (identified as known data  337 ) at a contact center and external to a contact center, which can be stored in a routing database, e.g., routing database  104 , used for routing incoming contacts and task work. For example, the ecosystem  300  can take both inbound communications or contacts and route other types of work, e.g., such as calling a customer back or following up with an internal team to help or assist a customer issue. For one embodiment, multiple data sources within a contact center ecosystem  300  can supply information to known data  337  such as agents  302 , inbound customers  314 , inbound tasks  323  and reminders  327 . These are just examples of data sources and other data sources can be used to supply information for known data  337  used for contact routing. 
     For one embodiment, agents  302  can supply multiple types of information including information related to availability  304 , channel support  304 , attributes  308 , working pools  310  and teams(s)  312 . For example, information related to availability  304  can indicate which agents are available or have capacity to service incoming communications. Information related to channel support  306  can indicate which channels agents are working on, e.g., email, telephone, SMS/Text channels, etc. Information related to attributes  308  can indicate attributes such as languages (e.g., Spanish), area of expertise (e.g., Products) and etc. related to agents  302 . Information related to working pools  310  can indicate pools in which agents  302  work in such as different departments within an enterprise or company. Information related to team(s)  313  can indicate which agents  302  work on which teams, e.g., Western Regional Team, Operations Team, etc. 
     For one embodiment, inbound customers  314  can supply multiple types of information to known data  337  including information related to attributes  316 , current interaction  318 , message content  320 , current channel  321  and history  322 . For example, information related to attributes can indicate attributes of customers  314  such as language (e.g., Spanish), premium customer and etc. Information related to current interaction  318  can include a current interaction with the contact center, e.g., related to Billing, how long the customer has been waiting and etc. Information related to message content  320  can include what language the communication is in, whether the content has a negative sentiment or etc. Information related to current channel  321  can indicate which channel the customer is being serviced on, e.g., SMS channel, and what channels are available to service the customer. Information related to history  322  can include how many times a customer has contacted the enterprise or company recently, and how satisfied they were with previous interactions, and etc. 
     For one embodiment, inbound tasks  323  can supply multiple types of information to known data  337  including information related to urgency  324 , team  325  and attributes  326 . Information related to urgency can place a priority on an inbound task related to customers  314  and agents  302 . Information related to team  325  can indicate the agents in a team who should service the input tasks  323 . Information related to attributes  326  can include what type of task needs to be completed, e.g., Redress fraudulent transaction. 
     For one embodiment, reminders  327  can supply multiple types of information to known data  337  including information related to assigned tasks  328 , which includes information related to urgency  329  and assignee  330 , and information related to unread reminders  331  and abandoned contacts  332 . Information related to assigned tasks  328  can indicate if a task is urgent or non-urgent or have other priorities using information related to urgency  329  and information related to assignee can indicate which agent or agents is assigned to a task. Information related to unread  331  indicates if an inbound message has been read or reviewed by any of agents  302 . Information related to abandoned contacts  332  can indicate which contacts were abandoned and a reason for a contact being abandoned, e.g., customer dropped contact, so that agents can determine how to best reengage with customers, etc. 
     For one embodiment, known data  337  is coupled to data update sources  333 . Known data can update data from data update sources  333  or store some or all of the information in known data  337  as a cache. For other embodiments, data update sources  333  can supply multiple types of information to known data  337  including information related to external data  334 , changing data  335  and new inbound x-channel  336  (cross-channel) used for modifying or updating information in known data  337 . Information related to external data  334  can include updating customer attributes  316  from an external data source, e.g., refreshing the customer&#39;s latest banking transaction history. Information related to changing data  335  can be any type of data that is changing as the interaction unfolds, e.g., the time that a customer is waiting  318  or the channels  306  that an agent is available to service. Information related to new inbound x-channel  336  can indicate if customer or agent initiates additional communication over a new channel, e.g., when an inbound customer  314  reaches out by phone to start and then also reaches out on social media channels. 
     For one embodiment, core routing module  103  can implement criteria assessed  338  using known data  337  to route contacts at a contact center. Criteria assessed  338  can include Boolean representations or statements using attributes  308  for agents  302  and attributes  317  for inbound customers  314  or other information and guidelines from known data  337 . Criteria assessed  338  can also determine scores for matching agents  302  to inbound customers  314 . For other embodiments, criteria assessed  338  can provide guidelines to choose pools of agents  302  to service inbound customers  314 , provide overrides or restrictions while matching agents  302  to customers  314 , provide auto-reply rules, apply topics to the interaction, or trigger other rules for any issue matching agents  302  to inbound customers  314 . Outputs and information from criteria assessed  338  are forwarded to core routing  343  and parallel actions  348  as shown in  FIG. 3B . 
       FIG. 3B  is a continuation of the contact center ecosystem  300  shown in  FIG. 3A . Referring to  FIG. 3B , core routing  343  receives or uses information from criteria assessed  338 , which includes functions related to pool  344 , overrides and restrictions  345 , matching  346  and reverse matching  347 . Functions related to pool  344  perform tasks in distinct parts at a contact center or distinct parts of an organization such as region, brands, product types etc. Functions related to overrides and restrictions  345  can override matches between customers to a particular available agent or place restrictions on agents to which types of customers to service. For one embodiment, overrides and restrictions  345  can be prioritized for a small pool of customers, e.g., Premium. For one embodiment, overrides and restrictions  345  can limit the pool of customers who an available agent can match with, e.g., negative comments regarding the available agent, by one or more customers in the pool. 
     For one embodiment, functions related to matching  346  can implement a first-to-respond approach. For example, when an agent becomes available, matching  346  can assess possible matches based on attributes, Boolean representations, scores, criteria, guidelines, rules and priorities using techniques disclosed herein in order to match a customer with the best available agent. Reverse matching  347  can perform functions in the case when there are more agents than incoming tasks or contacts (e.g., conversations, tasks etc.). For example, when a customer contacts the contact center, reverse matching  347  can assess each possible agent match and pair the customer with the best agent. 
     For one embodiment, actions  348  can be performed at a contact center that receives information from criteria assessed  338  shown in  FIG. 3A . In one embodiment, actions  348  can include functions such as auto-apply  349 , auto-reply  350  or other  351 . Auto-apply  349  can apply topics to the interaction for reporting purposes. Auto-reply  350  can provide auto-reply messages if there are no available agents via the communication channel used by the customer, e.g., email, SMS/text messaging, chat etc. Other functions  351  can include future actions that would be triggered from criteria assessed  338 . 
     For one embodiment, self-serve work  339  can be performed along with core routing  343  and parallel actions  348 . Self-serve work  339  can be implemented by agents directed to functions related to personal inbox  340 , team inbox  341  and search  342 . For example, customer contacts may be directed to a personal inbox  340  of an agent or a team inbox  341  in which messages can be addressed and communicated within personal inbox  340  and team inbox  341 . An agent can also implement a search  342  such as searching data on a particular customer or recent messages from a customer etc. Conversation task customer  352 , as shown in  FIG. 3C , receive inputs from core routing  343  and self-serve work  393 . 
       FIG. 3C  is a continuation of the contact center ecosystem  300  shown in  FIGS. 3A-3B . Referring to  FIG. 3C , conversation-task-customer  352  operation assigns or pairs customers or tasks to agents. For example, a conversation for an incoming customer is assigned to an agent based on operations from core routing  342  and/or self-serve work  339 . Agent participation  353  interacts with conversation task customer  352  which includes assignee  354 , contributor  355 , watcher  356  and other functions during the conversation with a customer. Regarding the conversation with a customer, conversation task customer  352  can then lead to operations such as conclusion  359  operations, follow-up  365  operations, transfer  370  operations, and disruptions  377  operations. 
     For one embodiment, conclusion operations  358  includes functions such as close conversation  359 , end chat session  360 , session timeout  361 , mark task complete  362 , decline  363  and after-conversation time  364 . Other functions can be implemented and the above examples are not limiting. For one embodiment, follow-up operation  365  includes functions such as task creation  366 , note  367 , topic(s)  368 , and other  369 , which can be implemented by an agent for follow-up actions. For one embodiment, transfers  370  operations include functions such as warm transfer  371 , cold transfer  372 , reassign to inbox  373 , reassign agent  374 , automated re-routing  375  and escalations  376 , which can be implemented by one or more agents or system functions. For one embodiment, disruptions  377  operations include functions to provide indications to a customer such as agent away  378 , agent offline  379 , technical problems  380 , cross channel (x-channel) or communication channel decline  381  or other  382 . 
     Exemplary Agent Interfaces 
       FIGS. 4A-4B  illustrates one embodiment of screen shots  400  and  410  of administration interfaces for setting up communications with customers on multiple communication channels. Referring to  FIG. 4A , for one embodiment, screen shot  400  shows an interface for an administrator for contacts that may be provided by the company to enable incoming communication via an email channel. More specifically, these emails are email addresses that the company owns and publishes on their website for people to contact them. For instance, a company might have an email help@dogs.com, veterinarians@dogs.com, billing@dogs.com, etc. The company would put those email addresses here, and connect them to Pools as described above (see  FIG. 3B ) and as Mapping Rules in  FIG. 11 . Communications received via these email addresses can be routed to an agent, a pool of agents, or a team of agents. 
     For one embodiment, screen shot  400  shows a list of email entry points  401  to a contact center. For example, the first entry indicates an email to World Reservations at a contact center. A name field  402  is provided in the interface for an administrator to enter a name for the entry point email. The inbox  403  indicates an email for a group of agents working on the World Reservations Inbox and a field  404  an SLA (service level agreement) response time to service the email and for the first entry an SLA response time is 1440 minutes. 
     Referring to  FIG. 4B , the screen shot  410  is a continuation of screen shot  400 . For example, the top part of screen shot  410  continues with email entry points with a name field, in box and SLA response time in minutes. Screen shot  410  also shows another communication channel for phone  406  that identifies the phone numbers at entry point  401  that customers dial to connect with the contact center. When the contact center is in use, the inbox  403  includes a contact to si-voice-test automation having an SLA wait time  1440  minutes. In this situation, an agent may override all other contacts and may end up using a contact specified here because of the long wait time. Alternatively, core contact  104  routing may ignore long wait times if the customer from the incoming contact at entry point+11234567891 is a Premium customer and the contact center services Premium customers with the highest priority. 
     Exemplary Interfaces for Adjusting Rules and Criteria for Contact Routing 
       FIG. 5  illustrates one embodiment of a screen shot  500  of rules or criteria for matching customers to agents. For this example, an interface allows a Boolean representation to be created, modified or adjusted and allows the rules or criteria to be extensible. The example Boolean representation  501  is shown as, e.g., for a rule or criteria when an Email is received for a new an ongoing conversation AND meets all the conditions of:
         Email is from johndoe@anyemail.com
           AND   
           Email subject contains Sam.       

     For this interface an “Add” function is provided such that a user or agent or administrator can add new rules. The Boolean representation can also be modified or adjusted. In this example, if the rule or criteria is met, then there are options for the actions that should be taken  502 . For example, Topics can be added, was conversation negative, send Auto-reply, choose an answer or select other options. 
       FIG. 6  illustrates another embodiment of a screen shot  600  of an interface after a rules or criteria match. This interface is for agent Jane Doe to help customer Company. Once a rule or criteria has been met, e.g., as shown in  FIG. 5 , the interface as shown in  FIG. 6  can be provided to an agent. For example, the agent matched is identified as Jane Doe. For this customer, in the conversations window  603 , there have been previous conversations on May 2, 21 and 28 with the agent Jane Doe. Windows  605  and  606  shows the previous conversations with Jane Doe with the customer. 
     Data Processing System or Computing System Architecture 
       FIG. 7  illustrates one embodiment of a block diagram of a data processing system or computing system architecture  700  to implement the flexible and extensible contact routing techniques disclosed herein. The data processing system  700  can represent the various components for contact center data processing system  102  disclosed in  FIG. 1A . Although  FIG. 7  illustrates various components of a data processing system, the components are not intended to represent any particular architecture or manner of interconnecting the components, as such details are not germane to the disclosed examples or embodiments. Network computers and other data processing systems or other consumer electronic devices, which have fewer components or perhaps more components, may also be used with the disclosed examples and embodiments. 
     Referring to  FIG. 7 , data processing system  700 , which is a form of a computing system, includes a bus  701 , which is coupled to processor(s)  702  coupled to cache  704 , display controller  714  coupled to a display  715 , network interface  717 , non-volatile storage  706 , memory controller  708  coupled to memory  710 , I/O controller  718  coupled to I/O devices  720 , and database  712 . Processor(s)  702  can include one or more central processing units (CPUs), graphical processing units (GPUs), a specialized processor or any combination thereof. Processor(s)  702  can retrieve instructions from any of the memories including non-volatile storage  706 , memory  710 , or database  712 , and execute the instructions to perform operations described in  FIGS. 1A-6 . Database  712  can also represent a routing database  104  and processor(s)  802  can implement core routing module  103  shown in  FIG. 1A . 
     Examples of I/O devices  720  include mice, keyboards, printers and other like devices controlled by I/O controller  718 . Network interface  717  can include modems, wired and wireless transceivers and communicate using any type of networking protocol including wired or wireless WAN and LAN protocols including LTE and Bluetooth interface and an API interface to communicate with Bluetooth devices. Data processing system  700  can also include a Bluetooth interface  721  that provide Bluetooth communication with Bluetooth devices. Memory  710  can be any type of memory including random access memory (RAM), dynamic random-access memory (DRAM), which requires power continually in order to refresh or maintain the data in the memory. Non-volatile storage  706  can be a mass storage device including a magnetic hard drive or a magnetic optical drive or an optical drive or a digital video disc (DVD) RAM or a flash memory or other types of memory systems, which maintain data (e.g. large amounts of data) even after power is removed from the system. 
     For one example, memory devices  710  or database  712  can store customer attributes, agent attributes and Boolean representations for flexible and extensible contact routing. Although memory devices  710  and database  712  are shown coupled to system bus  701 , processor(s)  702  can be coupled to any number of external memory devices or databases locally or remotely by way of network interface  717  or Bluetooth interface  721 , e.g., database  712  can be secured storage in a cloud environment. 
     Embodiments and examples disclosed herein can be embodied in a data processing system architecture, data processing system or computing system, or a computer-readable medium or computer program product. Aspects, features, and details of the disclosed examples and embodiments can take the hardware or software or a combination of both, which can be referred to as a system or engine. The disclosed examples and embodiments can also be embodied in the form of a computer program product including one or more computer readable mediums having computer readable code which can be executed by one or more processors (e.g., processor(s)  702 ) to implement the techniques and operations disclosed herein for a flexible and extensible contact center routing. 
     Exemplary Contact Center Routing Operations 
       FIGS. 8-10  illustrate exemplary embodiments of operations  800 ,  900  and  1000  for routing incoming communications or contacts at a contact center. The following operations can be implemented by the contact center data processing system  100  of  FIG. 1A  in the contact center ecosystem  300  of  FIGS. 3A-3C . Operations  800 ,  900  and  1000  can be implemented according to the contact routing techniques described in  FIGS. 1A-7 . 
       FIG. 8 , illustrates one embodiment of a flow diagram of operation  800  for routing work or inbound communications or tasks at a contact center. Operation  800  includes operation blocks  802  to  806 . 
     At operation block  802 , an incoming communication is received at a contact center from a customer. 
     At operation block  804 , a pairing score is determined based on attributes, guidelines, criteria or Boolean representations. 
     At operation block  806 , an agent is selected with the highest pairing score with the customer. After selection of the agent, the contact center routes the incoming communication or the work to the selected agent. 
       FIG. 9  illustrates another embodiment of a flow diagram of operation  900  for routing work or incoming communications or tasks at a contact center. Operation  900  includes operation blocks  902  to  908 . 
     At operation block  902 , attributes, guidelines, criteria or Boolean representations are adjusted or extended. 
     At operation block  904 , an incoming communication is received at a contact center from a customer. 
     At operation block  906 , a pairing score is determined based on adjusted or extended attributes, guidelines, criteria, or Boolean representations. 
     At operation block  908 , an agent is selected with the highest pairing score with the customer. After selection of the agent, the contact center routes the incoming communication or the work to the selected agent. 
     For the above example operations  800  and  900 , routing can occur only when a new communication is initiated from a customer, and need not occur for each communication sent by a customer. For example, if a customer sends a SMS communication, the session can be routed to an agent using the disclosed routing techniques. If the customer sends successive SMS communications, the communication can go directly to the same agent servicing the customer without having to go through the above routing process. 
       FIG. 10  illustrates one embodiment of a flow diagram of operation  1000  for changing communication channels at a contact center. Operation  1000  includes operation blocks  1002  to  1005 . 
     At operation block  1002 , a determination is made if there is a need to change communication channels. 
     At operation block  1003 , if the determination is Y, the current communication channel is changed to another communication channel and continues to block  1005  to continue service with a customer. 
     At operation  1004 , if the determination is N, there is no change and the agent stays on the current communication channel and continues to block  1005  to continue service with a customer. 
     Additional Routing Interface Examples 
       FIGS. 11-13  show additional routing interface examples for the routing techniques disclosed herein. Referring to  FIG. 11 , an administration interface  1100  is shown for providing mapping rules and scoring criteria according to one embodiment. Interface  1100  includes mapping rules  1102  which can identify parameters to define mapping rules  102 . In this example, there are parameters for dogwalking and vet advice. Interface  1100  includes scoring criteria  1104  to assist in determining scoring. Parameters such as long wait on phone or messaging can be classified as “High,” which can be provided with a higher score in determining a pair scoring between an agent and customer. Referring to  FIG. 12 , an interface  1200  for providing scoring criteria is shown for an exemplary account according to one embodiment. Interface  1200  includes scoring criteria  1202  that provides a window  1204  for Vet advice having Boolean inputs on how to classify parameters to determine scoring. A section for preview  1206  is also shown. Referring to  FIG. 13 , an agent interface  1300  is shown according to one embodiment. Interface  1300  includes contact  1302 , conversation  1304 , and relationships sections  1305  for an agent to interface with customers. 
     Data Tracking and Generation for Workforce Management 
       FIG. 14  illustrates one embodiment of contact center containing a workforce management (WFM) system. In one embodiment, the WFM is a customer-focused WFM system. Note that although the WFM system is shown as part of the call center in  FIG. 14 , this is not required. The WFM system may be remotely located with respect to the contact center and accesses data tracked and generated by the contact center. 
     Referring to  FIG. 14 , customers  1404  of a business or company and agents  1406  in a contact center  1402  (owned or contracted by the business or company) have various conversations  1408 , which the workforce management system  1410  tracks, in the track  1450  action. In one embodiment, each conversation corresponds to the series of communications between each customer of customers  1404  and each agent of agents  1406  that occurs during one communication session over one communication channel. 
     In one embodiment, a network  1458  couples the workforce management system  1410  and users  1412 , other workforce management systems  1414  and the agents  1406 . The network  1458  could be wired or wireless, or combination thereof, and further embodiments of connections are readily devised. Embodiments of the workforce management system  1410  could support multiple businesses or companies, or support or be owned by one business or company. 
     In one embodiment, agents  1406  are individuals working for the contact center  1402 , but in further embodiments could be bots (e.g., artificial intelligence entities with natural language programming for voice and/or text communication), or various mixes of humans and bots. In some embodiments, some or all of the agents  1406  work remotely and are not necessarily physically in a contact center  1402  building(s). 
     Connections to the contact center  1402  for the conversations  1408  could include phone lines (e.g., one or more phone line trunks) and one or more networks (e.g., the Internet), which could be separate from or connected to the network  1458  within the contact center  1402  (e.g., a local area network or LAN and/or wireless area network or WAN) in various embodiments. 
     One or more processors  1416  in the workforce management system  1410  are coupled to a memory  1422  in which the system establishes and maintains a database  1444  and performs various actions for input, tracking, data analysis and access to the database  1444 . In one embodiment, the actions the system performs include track  1450  for tracking the conversations  1408  and customers  1404 , tag  1452  for tagging the conversations  1408 , and analyze  1454  for analyzing the tagged conversations  1408 . 
     The system provides or supports access  1448  for accessing the database  1444 , for example by agents  1406  through the user interface  1420 , and by users  1412  and other workforce management systems  1414  through the application programming interface (API)  1418  provided by the workforce management system  1410 . In one embodiment, the system performs a generate  1456  action to produce reports  1446 . Further actions that the processor(s)  1416  of the workforce management system  1410  can perform for data tracking and generation for workforce management are readily devised in keeping with the teachings herein. Some embodiments have portions or all of the system combined with or integrated with various embodiments of a contact center, routing ecosystem and data flow and routing database described above with reference to  FIGS. 1A-13 . 
       FIG. 15  illustrates one embodiment of the database  1444  used by the workforce management system  1410  of  FIG. 14 . The database  1444  is used by the workforce management system  1410 , and more specifically the processor(s)  1416 , to track customers  1404  and conversations  1408 . The system stores and tags the conversations  1408  to annotate the conversations  1408  with various pieces of information about the conversations, and records the tags  1502  in the database  1444  in association with the appropriate customer ID  1504 . Many customers  1404 , and their customer IDs  1504 , can be tracked in the database  1444 . Each customer  1404  can have one or more conversations  1408 , which are tracked in the database  1444 . In one embodiment, each conversation  1408 , identified by a conversation ID  1505 , can have one or more conversation items (contact items)  1706  (see  FIG. 17 ), which are tracked in the database  1444 , with tags  1502 , as follows. 
     In one embodiment, each conversation item (contact item)  1706  has a conversation item ID (contact item ID)  1506 , a conversation type (contact type)  1508 , a channel ID  1510 , a direction  1512 , begin time  1514 , an end time  1516 , a service level agreement (SLA)  1518 , a status  1520 , an agent ID  1522 , and an inbox ID  1524 , or various combinations or variations thereof or further tags  1502  in various embodiments. In various embodiments, contact items could be tagged with one or more of the following: a contact item identifier, a contact type, a channel, a direction with respect to the participants, a beginning timestamp indicating when a conversation related to the contact item began, an end timestamp indicating when a conversation related to the contact item ended, a service level agreement (SLA), a SLA fulfillment time or timestamp, information indicating whether the contact item was answered within an established SLA, a conversation routing timestamp indicating when a conversation was routed, status information related to the contact item indicative of whether a conversation was answered, abandoned, unanswered, or unknown, a calculated handle time for a work session indicating an amount of time taken to handle a matter, a wrap time indicating an amount of time that has passed since a contact has ended, or an agent identifier. 
     In one embodiment, the customer ID  1504  identifies the customer. In one embodiment, the customer ID  1504  identifies the customer, for example by name or number. The conversation ID  1505  identifies each conversation  1408 . In one embodiment, the conversation ID  1505  identifies each conversation  1408  by a descriptor and one or more of a letter, a number count, a code, a date, or a timestamp, etc. The conversation item ID (contact item ID)  1506  identifies each contact item with a conversation item ID (contact item ID)  1506  (e.g., conversation item (contact item ID)  1706 ) in a conversation  1408 . 
     In one embodiment, conversation type (contact type)  1508  identifies a type of each conversation of each conversation item with a conversation item ID item (e.g., conversation item  1706 ) in a conversation  1408 . In one embodiment, the conversation type (contact type)  1508  can specify communication types of a number of different channels, including, but not limited to, a phone call, a text message, a voice message, an email, a text chat and a video chat. Other contact types may be considered and readily devised in various embodiments. 
     In one embodiment, channel ID  1510  identifies the channel over which the conversation item takes place and, in one embodiment, includes a voice channel identifier identifying a specific voice channel (e.g., a telephone number or other identifier), a text channel identifier identifying a specific text channel (e.g., a short messaging service (SMS) capable cellular telephone number or other identifier), a voicemail channel identifier, an email channel identifier (e.g., an email address or other identifier), a chat channel identifier for text chats over the Internet or other network, and a video chat channel identifier for video chats, e.g., over the Internet or other network. 
     In one embodiment, direction  1512  identifies whether the conversation  1408  is initiated by a customer  1404  (e.g., from customer to agent) or is initiated by an agent  1406  (e.g., from agent to customer), and may also indicate whether the conversation is unidirectional (e.g., a single message) or bidirectional (e.g., an exchange of messages or conversation) in some embodiments. 
     In one embodiment, begin time  1514  and end time  1516  are timestamps of the conversation  1408  and conversation item(s) (e.g., conversation items  1706 ), and could also be labeled start and finish, initiate and close, enter and exit, etc. 
     In one embodiment, SLA  1518  identifies a service-level agreement. In one embodiment, the system allows SLA  1518  to differ among customers (e.g., customers could have one tier of service for free or for a period of time but pay for higher tiers of service, be within or outside of a warranty period, have purchased an extended warranty, or be a preferred customer, etc.) Status  1520  could indicate an issue is open, escalated, urgent, resolved, short-term, long-term, affects other products or an entire product line or closed, etc. Agent identifier  1522  identifies the agent(s) involved in the conversation. In another embodiment, this identifies the agent as primary agent or initial agent, secondary or supervising agent, or other role for the agent relative to the conversation  1408 . 
       FIG. 16  illustrates one embodiment of a user interface used in the workforce management system of  FIG. 14 . In one embodiment, the user interface  1604  is displayed on a browser  1602 . In another embodiment, the user interface  1604  is displayed through standalone applications executing on a wired or wireless connected computing device with display, e.g., any of various computers and mobile devices, etc. The user interface  1604  displays a customer profile selection  1606  with names or other identifiers of customers  1404  to an agent  1406  using a display of the system. The customer profile is selectable by the agent  1406 . In one embodiment, selecting the customer profile initiates a conversation and/or is automatically displayed when a customer initiates a conversation to the agent  1406 . In one embodiment, the conversation is routed to the agent  1406 , e.g., by systems and methods described with reference to  FIGS. 1-13 . The agent sees conversation content  1612  in the user interface  1604  (or in a separate display region in further embodiments), such as, for example, text content of a text message(s) or email(s), or speech recognition transcript from voicemail or live voice conversation, and/or has live or replay audio or video, in various embodiments. Other tracked conversations  1614  are also visible in some embodiments. In one embodiment, the conversation is started or stopped with a start conversation button  1608  and an end conversation button  1610 . Alternatively, these can be inferred and displayed based on actions taken to initiate or end a conversation through an appropriate channel, as shown on the channel ID  1616 . Variations and further versions of user interface are readily devised in keeping with the teachings herein. 
       FIGS. 17A-D  illustrate various embodiments of derived data, including work bursts  1702  and work sessions  1704  with examples involving various numbers of channels and agents  1406 . Work bursts and work sessions are described in more detail below. Based on tracking customers  1404  and conversations  1408 , a system, such as, for example, workforce management system  1410 , and more specifically the processor(s)  1416 , derive various forms of data, track the derived data in the database  1444  in association with customers  1404  (and customer profiles) and conversations  1408 , and provide the data as an input for functions performed by a workforce management system, such as, for example, generating reports  1446  with the derived data, as further described below. 
     One embodiment of the workforce management system  1410  and the data that is tracked and generated for use thereby is provided below. The following description provides multiple examples to illustrate these concepts. 
     Tracking Work in a One Embodiment of a Workforce Management System 
     In one embodiment, when an agent  1406  is logged into the workforce management system  1410 , the system has access to and can analyze what that agent  1406  is viewing on the display screen, for example, through monitoring the user interface  1604 . In one embodiment, when an agent  1406  views a customer&#39;s profile, the system operates on the assumption that the agent  1406  is working to help that customer  1404 , and when the agent  1406  navigates away from the customer profile, then the system operates on the assumption that the agent  1406  is no longer working to help that customer  1404 . Thus, when an agent  1406  is viewing a customer&#39;s profile, the system tracks this time as time an agent  1406  is working on or with a customer  1404 . 
     Key Objects in the Workforce Management System 
     In one embodiment, the workforce management system  1410  puts people at the center (i.e., takes a customer-focused or customer-centric approach) with a platform built for all communication channels, from voice to messaging. In one embodiment, putting people at the center means that the system does not have tickets nor cases. Instead of case and ticket-based metrics, or in some embodiments augmenting case and ticket-based metrics, various embodiments of the system have customer-based metrics. 
     In one embodiment, the objects in the workforce management system  1410  are organized in a few different levels as discussed below. 
     1. Customer—At the highest level, the system has the customer  1404 . This is the customer  1404  of a business or company, and the person whom agents  1406  help. Customers  1404  can have certain attributes like, for example, a CSAT score, Lifetime Value, or Loyalty status and more. In one embodiment, all customers also have a customer ID  1504 , which identifies both the customer  1404  and the customer profile in the database  1444 . 
     2. Conversation—Throughout a customer&#39;s lifetime, a customer  1404  can have many conversations  1408  with a company (or, more precisely, conversations  1408  with one or more agents  1406  who represent or are otherwise associated with the company). In one embodiment, however, a customer can only have one open conversation  1408  at a time (but potentially a large number of closed conversations in the past). In one embodiment, conversations can span multiple channels, agents or time (e.g., minutes, days, etc.). In one embodiment, a customer could have one open conversation  1408  that has multiple active conversation items or contacts at one time, e.g. an SMS and a chat interaction going at the same time. For a further example, the open conversation(s) could include communicating by voice (e.g., a voice call to request or comment on a document or image) and email or text messaging with image attachment(s) (e.g., messaging to send or receive a document or image or further comment in text, etc.). 
     In one embodiment, each of these conversations  1408  has certain attributes. In one embodiment, these attributes includes topics, created timestamp (e.g., begin time  1514 ), closed timestamp (e.g., end time  1516 ), channels (e.g., channel ID  1510 ) present within a conversation  1408 , and more. In one embodiment, all conversations  1408  have a conversation ID  1506  and exist within an inbox or equivalent. 
     3. Conversation Item—In one embodiment, each conversation  1408  can be composed of one or more conversation items  1706  (e.g., messages, emails, voice, voice messages, videos, etc.). In one embodiment, each of the conversation items are identified by conversation item ID (contact item ID)  1506  and conversation type (contact type)  1508 ). 
     For the voice channel, a conversation item  1706  is a phone call, e.g., by a landline call, a mobile phone call, etc. 
     For messaging-based channels (e.g., chat, SMS, Facebook Messenger, Twitter DMs, etc.), a messaging item (or messaging session) is a collection of messages between the agent  1406  and the customer  1404 . 
     For mail-based channels (e.g., email, voicemails, abandoned call follow-ups (not the original call itself), etc.), a mail item (or mail session) is a collection of emails, voicemails, abandoned call follow-ups, etc. In one embodiment, the system regards an email session as a “chat session” that contains emails instead of chat messages. 
     In one embodiment, conversation items  1706  have certain attributes that include a channel (e.g., identified by channel ID  1510 ), created at timestamp (e.g., begin time  1514 ), ended at timestamp (e.g., end time  1516 ), a direction (e.g., direction  1512 ), an SLA (e.g., SLA  1518 ), a status (e.g., status  1520 ). In alternative embodiments, conversation items  1706  has more and less attributes. 
     4. Work Sessions—When agents, such as agents  1406 , work with a customer  1404  within the workforce management system  1410 , a work session  1704  is created in the system. In one embodiment, a work session  1704  is created for any agent-customer-channel combination. If the agent  1406  returns to help the same customer, over the same channel, the work session  1704  continues. In one embodiment, a new work session  1704  is created if the agent  1406  is starting to help the customer, if the channel changes (be it by the customer or the agent), or if another agent starts helping the customer. In one embodiment, a work session  1704  ends when the conversation item  1706  ends or when the agent ID  1522 , inbox ID  1524 , conversation item ID  1506 , conversation ID  1505 , or channel (e.g., channel ID  1510 ) changes. In one embodiment, a work session  1704  has attributes like a started at timestamp, an agent ID  1522 , and a handle time. In one embodiment, the handle time for a work session  1704  is the sum of the duration all the Work Bursts (described below) that have the same agent ID, inbox ID, item ID, conversation ID, and channel. 
     5. Work Bursts—At the lowest level, the system derives and tracks work bursts  1702 . In one embodiment, a work burst (e.g., work burst  1702 ) starts when an agent views the customer&#39;s profile and ends when an agent navigates away from that customer&#39;s profile. In one embodiment, each time an agent views the customer&#39;s profile, a new work burst  1702  is created. In one embodiment, work bursts  1702  have certain attributes that include a start timestamp, end timestamp, and work session ID. In one embodiment, work bursts  1702  are the individual lengths of uninterrupted time when an agent is looking at a customers&#39; profile, and the duration of a work session  1704  is the sum of the duration of the work bursts  1702  associated to it. 
       FIG. 17A  illustrates one embodiment of derived data, e.g., work bursts  1702  and work sessions  1704  involving a single channel and a single agent  1406 , that is tracked in the database  1444  in the workforce management  1410  system of  FIG. 14 . 
     Example 1: Single Channel and Single Agent. In this example, the “bricks” labeled “Work Bursts Agent 1” represent the many work bursts  1702  that occurred while an agent  1406  was working with the customer  1404 . The sum of all of the work bursts  1702  is equivalent to the Work Session Handle Time. 
     To determine the channel, when a work session  1704  occurs, the system looks to see what conversation items  1706  are present in the conversation  1408 . In one embodiment, when a new work burst  1702  is being created, the system looks for any conversation items  1706  currently active for that customer and derives the channel for them. In one embodiment, if there is a single active conversation item  1706 , the system uses its channel, and if there are more than one conversation item  1706 , the system assigns the channel according to a hierarchy based on how ‘synchronous’ the channel is. For example, if assigning according to three channel types, the following hierarchy is used: 
     if there&#39;s a phone call included in the conversation items  1706 , it takes precedence and the system derives the channel as the telephone channel; 
     if there&#39;s no phone call, but there&#39;s a messaging channel type, then it takes precedence and the system derives the channel as the messaging channel; and 
     if there&#39;s no phone call and no messaging channel type, then the system derives the channel as the email channel. 
     In this example, only one channel is present during each work session  1704  so each work session  1704  is assigned the channel of that conversation item  1706 . 
     If no conversation item  1706  is present in the conversation  1408  at that time, the system still keeps track of the work session  1704  and assigns an “unknown” channel to the work session  1704 . In further embodiments, these “unknown” sessions will be split up between after contact work, outbound work, and more. In one embodiment, the system does not determine the channel and channel type when there aren&#39;t any active conversation items. Alternatively, in one embodiment, the system determines the channel later, by examining what channel the agent chooses to use to contact the customer. For example, an agent in a sales capacity opens a customer profile with no active conversation items and calls them to offer a product. At first, the channel type would be determined to be unknown, but once the call starts, the system goes back and attributes the channel type to be that of a telephone channel. 
       FIG. 17B  illustrates one embodiment of derived data, e.g., work bursts  1702  and work sessions  1704  involving a single channel and multiple agents  1406 , that is tracked in the database  1444  in the workforce management system  1410  of  FIG. 14 . 
     Example 2 Single Channel and Multiple Agents. In this example, two agents  1406  are working on the same conversation item  1706 . Since both agents  1406  are working on that conversation item  1706 , both agents  1406  receive credit for their work. In order to do that, the system creates a work session  1704  for each agent  1406 . 
     Similar to the scenario with one agent  1406 , the system sums the work bursts  1702  to determine the Work Session Handle Time. To determine the channel, when a work session  1704  occurs, the system looks to see what conversation items  1706  are present in the conversation  1408 . In this example, only one channel is present during each work session  1704  so each work session  1704  is assigned the channel of that conversation item  1706 . 
       FIG. 17C  illustrates one embodiment of derived data, e.g., work bursts  1702  and work sessions  1704  involving multiple channels and a single agent  1406 , that is tracked in the database  1444  in the workforce management system  1410  of  FIG. 14 . 
     Example 3: Multiple Channels and Single Agent. In this example, there is more than one conversation item  1706 , spanning more than one channel within one conversation  1408  and with one agent  1406 . In one embodiment, the system sums the work bursts  1702  to determine the Work Session Handle Time. 
     Here, in one embodiment, two channels overlap, so the system defines the channel by the most synchronous item (voice&gt;messaging&gt;mail). In one embodiment, if there are two conversation items  1706 , the system uses the most synchronous, most recently routed conversation item  1706  to determine the channel. Therefore, in this example, the agent  1406  has one Email Work Session and one Chat Work Session. 
       FIG. 17D  illustrates one embodiment of derived data, e.g., work bursts  1702  and work sessions  1704  involving multiple channels and multiple agents  1406 , that is tracked in the database  1444  in the workforce management system  1410  of  FIG. 14 . 
     Example 4: Multiple Channels and Multiple Agents. In this example, multiple agents  1406  are working on multiple conversation items  1706  within a conversation  1408 . In one embodiment, the system sums the work bursts  1702  to determine the Work Session Handle Time and define the channel by the most recently routed and most synchronous item (voice&gt;messaging&gt;mail). Each agent  1406  will also have multiple work sessions  1704 . 
     Thus, in one embodiment, when using the workforce management system  1410  WFM data
         Work sessions  1704  track time that agents  1406  are on a customer&#39;s profile, which is equivalent to the time agents  1406  are working;   Work sessions  1704  start/pause when agents  1406  see/leave a customer&#39;s profile;   Work sessions  1704  are tracked irrespective of assignment (e.g., two agents  1406  looking at a customer and associated customer profile at the same time will both get work sessions  1704 );   The work session channel is defined by the channel of the most recently routed conversation item  1706  and most synchronous channel (phone&gt;messaging&gt;mail); and   If any of the following happens, a new work session  1704  starts:
           A new agent  1406  starts working on that customer  1404  (e.g., agent ID  1522  changes);   A new conversation item  1706  on a different channel comes in (e.g., conversation item ID  1506  changes, conversation item session ends, or channel changes);   The customer  1404  is assigned to another inbox (e.g., inbox ID  1524  changes);   A customer  1404  receives a response (e.g., item session ends); and   A new conversation starts (e.g., conversation ID changes).   
               

       FIG. 18  illustrates a further embodiment of derived data, e.g., customer wait time, backlog time and agent response time, that is tracked in the database in the workforce management system of  FIG. 14 . In various embodiments, the workforce management system provides various types of derived data for workforce management, as further described below. 
     Data Output. Because of the different levels of data of which the workforce management system  1410  has access, the system can determine certain details such as which agents  1406  worked on what conversation items  1706  and for how long. In one embodiment, the system generates two reports to help a user or other WFM systems understand these details. These reports are referred to herein as the Work Session Report and the Work Burst Report. In one embodiment, the Work Session Report has all of the detail that WFM systems needs in order to create a schedule with respect to the number of individuals that are needed to provide coverage for all the communication channels being handled for the call center. In one embodiment, the Work Burst Report provides a granular view of each work burst  1702  which is often more detail than WFM vendors need. In various embodiments, work session reports or work burst reports are generated on a per agent, per customer, per channel, or per contact center basis, or combination thereof. 
     The following description provides further detail about the main event timestamps. 
     Example Timelines 
     In one embodiment, the Work Sessions Report provides five event timestamps that are useful for calculating key WFM metrics like Backlog Time  1804 , Customer Wait Time  1802 , and Agent Response Time  1806 . In one embodiment, the event timestamps are referred to herein as: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 item_created_at 
               
               
                   
                 item_routed_at 
               
               
                   
                 agent_accepted_at 
               
               
                   
                 sla fulfilled_at 
               
               
                   
                 item_ended_at 
               
               
                   
                   
               
            
           
         
       
     
     The timelines in  FIG. 18  illustrate when specific events can occur in relation to each other. Note that in one embodiment, a sixth timestamp is provided and is referred to herein as: 
     work_session_started_at 
     In one embodiment, this timestamp occurs when the agent first views the profile which is normally the same time as 
     item_routed_at. 
     The following description details how and when these events can occur. In one embodiment, event timestamps include: 
     item_created_at_and_item_ended_at 
     and these events occur when: 
     
       
         
           
               
               
               
             
               
                   
               
               
                 Item Type 
                 Created 
                 Ended 
               
               
                   
               
             
            
               
                 Mail 
                 Mail Received 
                 Agent responds on any channel 
               
               
                 (e.g., Voicemail, Email, 
                   
                 Agent chooses “No Reply Needed” 
               
               
                 Abandoned Calls) 
                   
                 Agent closes Conversation 
               
               
                 Messaging 
                 Message Received 
                 A messaging session can end in various ways: 
               
               
                 (e.g., Chat, SMS, FB 
                   
                 the agent was the last responder in the chat 
               
               
                 Messenger, WhatsApp) 
                   
                 and a predetermined period of time (e.g., 15 
               
               
                   
                   
                 minutes) have elapsed (this time period can be 
               
               
                   
                   
                 adjusted) 
               
               
                   
                   
                 the customer was the last responder in the chat 
               
               
                   
                   
                 and a predetermined period of time (e.g., a certain 
               
               
                   
                   
                 number of hours (e.g., 1 hour, 2 hours, 12 hours, 24 
               
               
                   
                   
                 hours, etc.) have elapsed 
               
               
                   
                   
                 the agent or a rule closes the conversation 
               
               
                   
                   
                 the agent or a rule marks the message as 
               
               
                   
                   
                 “No Reply Needed” 
               
               
                   
                   
                 Additionally, chat sessions can be ended if: 
               
               
                   
                   
                 the agent manually ends the chat from the UI 
               
               
                   
                   
                 the customer leaves the chat 
               
               
                   
                   
                 the customer closes their browser 
               
               
                 Voice 
                 Phone call Received 
                 Agent or Customer hangs up the phone 
               
               
                   
                   
                 Call is dropped 
               
               
                   
               
            
           
         
       
     
     In one embodiment, these timestamps are null when the conversation has not yet ended or if the conversation item was ended without proceeding through some of these steps. In one embodiment, all conversation items  1706  will have a created timestamp, and all conversation items  1706  are auto-ended based on a configuration set by a system administrator. In one embodiment, this auto-end timeout can be set to any number. In one embodiment, the system also configures this number by channel. 
     In one embodiment, the number of events per item for these timestamps include one item_created_at and one item_ended_at timestamp. 
     In one embodiment, the event timestamps include the following: 
     item_routed_at 
     and this event occurs when: 
     a) The agent  1406  is first offered the conversation item  1706  (regardless of whether the agent  1406  accepted the conversation item  1706  or not). 
     b) The agent  1406  assigns the conversation (and thus the conversation item  1706 ) to self 
     c) An agent  1406  sends an outgoing message in a conversation that nobody accepted yet. In this case, in one embodiment, the workforce management system  1410  assigns the conversation item  1706  to that agent  1406  and gives item_routed_at and sla_fulfilled_at the same timestamp. 
     In one embodiment, the item_routed_at timestamp is null when the conversation is assigned to another agent and then second agent responds before the first agent responds. In another embodiment, the item_routed_at timestamp is provided for all agents who are routed the work, regardless of who responds first. And in another embodiment, the item_routed_at timestamp is provided for the first time a conversation item is routed for each agent who worked on the conversation item. 
     In one embodiment, with respect to the number of events per item for the item_routed_at event, the same conversation item  1706  can have multiple item_routed_at timestamps. The different timestamps will be associated with different work sessions  1704 . In another embodiment, multiple work sessions are not created for each item_routed_at event, but instead the earliest of the timestamps for that agent and contact session is given. In yet another embodiment, work sessions are created for every Conversation Item-to-Agent grouping, and the earliest timestamp of the item_routed_at event is given for each agent. This approach provides less data than the one above, but it&#39;s more concise for system integration—so all are valid approaches for various embodiments. 
     In one embodiment, the event timestamps include: 
     agent_accepted_at 
     and the event occurs when: 
     a) the agent  1406  clicks “accept” on an offered conversation item  1706 . 
     In one embodiment, the agent_accepted_at timestamp is null when: 
     a) An agent  1406  manually assigns a conversation to self, or 
     b) An agent sends an outgoing message in a conversation that nobody accepted yet. In this case, the workforce management system  1410  assigns the conversation item  1706  to that agent  1406  and there is no agent_accepted_at timestamp. In another embodiment, the agent_accepted_at timestamp is automatically filled in these situations. 
     In one embodiment, with respect to the number of events per conversation item  1706  for the agent_accepted_at timestamp, the same conversation item  1706  can have multiple agent_accepted_at timestamps. The different timestamps will be associated with different work sessions  1704 . In another embodiment, the earliest agent_accepted_at timestamp is given for each agent who worked on the conversation item, and only one work session is created for each Conversation Item-to-Agent grouping. 
     In one embodiment, the event timestamps include: 
     sla_fulfilled_at 
     and the event occurs when the first of these happen: 
     a) An agent  1406  sends an outbound communication to the customer  1404 . 
     An outbound communication can be an outbound email, SMS message, chat message, FB message, or an outbound call to the customer  1404  (regardless of whether the customer  1404  answered the call). 
     Phone calls can fulfill the SLA  1518 
         when an agent  1406  answers an inbound call from the customer  1404 ,   when the customer  1404  chooses to have their inbound call forwarded outside the customer engagement system via IVR selection,   when an unknown number calls in and abandons their call, which causes the conversation to be closed automatically, or when an agent  1406  and a customer  1404  complete the phone call, whether that phone call was inbound or outbound.       

     Outbound email sessions can fulfill the SLA
         when an outgoing email contains an email address from the customer profile in any of TO, CC, BCC. That includes forwarded emails as well.       

     Messaging sessions can fulfill the SLA  1518 
         when an agent  1406  replies to an inbound chat, SMS, FB, WhatsApp message from the customer  1404 , or   when the chat session for that customer  1404  is ended, if previously there was not a reply from an agent  1406  (note: this excludes chat sessions that are ended as a result of a new chat session starting, which could happen if, for example, the user switches devices)       

     b) “No Reply Needed” is selected for an inbound conversation item  1706  in the same conversation  1408  (note: this can only be done on the last inbound email or message of the conversation  1408 , but this selection fulfills any unfulfilled SLA  1518  in the conversation  1408 ) 
     c) The conversation  1408  is closed 
     In one embodiment, only inbound communications can be fulfilled, and this concept does not apply to outbound communications. In one embodiment, a chat may be ended without being fulfilled if it is never offered to and accepted by an agent  1406  and 24 hours have elapsed since the last customer message. 
     In one embodiment, the event is null when an agent  1406  accepted a session and never sent a response. 
     In one embodiment, with respect to the number of events per item, the same item can only have one sla_fulfilled_at timestamp, even if there are multiple work sessions associated with the same item. 
     WFM Metric Calculations 
     With the data that is tracked, a WFM system can perform calculations key WFM metrics (e.g., average handle times, customer wait time, backlog time, agent response time, etc.). These are described in more detail below. 
     For example, with respect to key WFM metrics, the data provided in the Work Sessions Report and Work Burst Report allows calculation for WFM and more. The following examples are recommended for calculating some key metrics such as handle time and customer wait time. 
     An Example of Average Handle Time 
     In one embodiment, to calculate handle time, two parameter values are useful, time and volume. For volume, one recommendation is to use “conversation items” which will give the number of phone calls, messaging sessions, and email sessions. Depending on what unit is preferred as a basis for staffing, WFM could also use “Conversations,” “Customers” or “Work Bursts”.
         Inbound volume=count unique item id   Inbound volume per channel=count unique item_id grouped by channel   Inbound volume answered=count unique item_id with work_session_handle_time   Inbound volume answered per channel=count unique item_id with work_session_handle_time grouped by channel       

     Using the above for volume, the second measure that is useful is time. In one embodiment, the Work Session Handle Time is used, which is the amount of time that agents  1406  spent working (e.g., the time viewing a customer profile). 
     Time agents worked=sum work_session_handle_time 
     Time agents worked per channel=sum work_session_handle_time where channel is &lt;channel&gt; 
     After the volume and time measures have been determined, the overall handle time for a contact center can be determined. In one embodiment, the overall handle time for a contact center can be determined according to: 
     Overall Handle Time=time agents worked divided by inbound volume answered 
     Overall Handle Time per channel=time agents worked per channel divided by inbound volume answered per channel 
     Note that in other embodiments, the average handle time may be calculated in a number of different ways. 
     An Example of Agent Average Handle Time 
     In one embodiment, to calculate handle time at an agent level, two parameter values are useful, time and volume. For volume, in one embodiment, “conversation items”, which will give the number of phone calls, messaging sessions, and email sessions that an agent  1406  worked on, are used. In alternative embodiments, depending on what unit is preferred as a basis for staffing, WFM could also use “Conversations”, “Customers” or “Work Bursts”. 
     Items worked on=count of item_id where agent_id is &lt;agent_id&gt; 
     In one embodiment, this will give all of the conversation items  1706  on which an agent  1406  has worked. As discussed above, multiple agents  1406  can work on the same conversation item  1706 . 
     Using the above for volume, the second measure to use is time. For this, in one embodiment, the Work Session Handle Time, which is the amount of time that agents  1406  spent working (e.g. the time viewing a customer profile), is used. 
     Time worked by agent=sum of work_session_handle_time where agent_id is &lt;agent_id&gt; 
     Since multiple agents  1406  can work on the same conversation item  1706 , in one embodiment, the percentage of the work for a given conversation item  1706  the agent  1406  performed is determined according to the following: 
     Work Share % by agent by item=time worked by agent where item_id is &lt;item_id&gt; divided by 
     sum of work_session_handle_time where item_id is &lt;item_id&gt; 
     In one embodiment, this is summed across all items that an agent  1406  worked on. 
     Work Share % by agent for all conversation items touched=summation of (time worked by agent where item_id is &lt;item_id&gt; divided by sum of work_session_handle_time where item id is &lt;item id&gt;) over all item_id where agent id is &lt;agent_id&gt; 
     An Example of Agent Average Handle Time 
     In one embodiment, once the Work Share percentage by agent is determined, it is then possible to calculate the average handle time. In one embodiment, average handle times are determined according to: 
     Agent Avg Handle Time=time worked by agent multiplied by work Share % by agent 
     Agent Avg Handle Time per channel=time worked by agent where channel is &lt;channel&gt; divided by share of items worked by agent where channel is &lt;channel&gt; 
     Examples of Customer Wait Time, Backlog Time, Agent Response Time 
     In one embodiment, using the timestamps item_created_at, itern_routed_at, agent_accepted_at, sla_fulfilled_at, and item_ended_at, a variety of time-based metrics are calculated. In one embodiment, customer wait time, backlog time and agent response time are calculated as follows: 
     Customer Wait Time=sla_fulfilled_at−item_created_at where item_id is &lt;item_id&gt; 
     Backlog Time=item_routed_at−item_created_at where item_id is &lt;item_id&gt; 
     Agent Response Time=sla_fulfilled_at−item_routed_at where item_id is &lt;item_id&gt; 
     Examples of Additional Calculations 
     The following are some additional calculations that are made. 
     Abandoned Items=count abandoned 
     Inbound emails which required more than one channel=count conversation_id where channel of the first item id is email with more than 1 item_id associated 
     Outbound items=count unique item id where direction is outbound 
     Time spent on outbound SMS=sum work session duration of all rows with channel is &lt;sms&gt; and direction is outbound 
     Email SLA Achievement=count rows where channel is email where within_sla is true divided by count of rows where channel is email where direction is inbound times 100 
     In one embodiment, the data that is tracked is used by, provided and made available to a WFM system. In one embodiment, this is through an application programming interface (API). In one embodiment, the Work Sessions Report described above is accessible via a Reporting API, where the data is available under the “WorkSessionsReport” metric set. In one embodiment, time filters are needed for this metric set, although it is possible for a further embodiment to exclude time filters. 
     In one embodiment, the data available via the Work Sessions Report is delayed by a predetermined amount of time (e.g., one hour delayed, ten-minute delayed, etc.). In the case of being delayed one hour, this means that if a user or WFM system makes an API call at 1 pm, data is given from 11 a.m.-12 p.m. Various time spans and delay times are applied or available in further embodiments. 
       FIG. 19  illustrates a flow diagram of a method for customer-focused workforce management, which can be performed by embodiments of the workforce management system  1410  of  FIG. 14 . The method can be performed by one or more processor, for example by a processor of a workforce management system. 
     In an action  1902 , the system establishes a database. Details of a suitable database with contents are described above with reference to  FIG. 15 . Various types of databases may be suitable, and variations are readily devised in keeping with the teachings herein. 
     In an action  1904 , the system tracks customers, in the database. Each customer has an associated customer profile and customer ID in the database, which the system uses for tracking. 
     In an action  1906 , the system tracks conversations that customers have with agents, in the database. Conversations have conversation IDs and conversation items with conversation item IDs. 
     In an action  1908 , for each conversation, the system tags and tracks conversation item (contact item), conversation type (contact type) and channel. Descriptions of these and further tags are given above with reference to  FIG. 15 . 
     In an action  1910 , the system determines and tracks work sessions and work bursts, in the database. Examples of work sessions and work bursts are described above with reference to  FIGS. 17A-17D . 
     In an action  1912 , the system generates reports. Examples of work session reports and work burst reports are described above, with reference to  FIGS. 17A-17D  and  FIG. 18 . 
     In an action  1914 , the system provides access to the database, through a user interface and/or application programming interface. An example of a suitable user interface for use by agents is described above with reference to  FIG. 16 , and variations thereof are readily devised in keeping with the teachings herein. Details of a suitable API for use by users or further WFM systems are described above, an API is depicted in  FIG. 14 , and variations and further details thereof are readily devised. 
     There is a number of example embodiments described herein. 
     Example 1 is method generating data for workforce management, performed by a processor-based system, comprising: identifying one or more contact items within each conversation of one or more conversations, the one or more conversations being between one or more customers of a plurality of customers contacting a contact center and one or more agents associated with the contact center; tagging each contact item of the one or more contact items with a contact type and a channel type, including selecting the channel type from a plurality of channel types; and tracking periods of agent activity for each channel for each of the one or more agents using the tagging of the contact items for one or more work sessions. 
     Example 2 is method of example 1 that may optionally include that at least one conversation with one customer includes multiple channels at one time. 
     Example 3 is method of example 2 that may optionally include that tagging and tracking of work occur for each of the multiple channels at once only when an agent of the one or more agents is performing agent activity to handle the one customer. 
     Example 4 is method of example 3 that may optionally include that the tagging and tracking occur when agent activity switches between the multiple channels. 
     Example 5 is method of example 1 that may optionally include sending tracked data to a workforce management system. 
     Example 6 is method of example 5 that may optionally include that sending tracked data to a workforce management system comprises providing access to the tracked data by, or on behalf of, the workforce management system. 
     Example 7 is method of example 1 that may optionally include that the contact type is one of a plurality of contact types comprising a phone call on a voice channel, a message on a messaging-based channel, an email on a mail-based channel, a video chat, and a voicemail on a voice channel or voice messaging-based channel. 
     Example 8 is method of example 1 that may optionally include that a work burst of one or more work bursts of the one or more work sessions is to start when an agent views a customer profile and is to end when the agent navigates away from the customer profile. 
     Example 9 is method of example 8 that may optionally include performing a work session calculation for each customer of the one or more customers based on the one or more work bursts associated with said each customer, excluding agent activity away for each customer in the work session calculation. 
     Example 10 is method of example 8 that may optionally include providing a user interface for use by the one or more agents, the user interface supporting customer profile selection and channel identification or selection and for use in identifying the one or more work bursts based on navigation to and from the customer profile as part of profile selection. 
     Example 11 is method of example 1 that may optionally include that a work session is to begin when a contact item begins and is to end when the contact item ends, a work session is to begin when an agent identifier changes indicating another agent is involved with a contact item, or a work session is to begin when a channel changes. 
     Example 12 is method of example 1 that may optionally include tagging each contact item of the one or more contact items with one or more of: a contact item identifier, a contact type, a channel, a direction, a beginning timestamp, an end timestamp, a service level agreement (SLA), a SLA fulfillment time or timestamp, whether the contact item was answered within an established SLA, a conversation routing timestamp, a status of the contact item as to answered, abandoned, unanswered, or unknown, a calculated handle time for a work session, a wrap time after a contact ends, or an agent identifier. 
     Example 13 is method of example 1 that may optionally include generating work session reports or work burst reports, on a per agent, per customer, per channel, or per contact center basis. 
     Example 14 is method of example 1 that may optionally include determining, based on the tracked data, one or more of length or size of backlog, customer wait time, agent response time, fulfillment of service level agreement (SLA), agent handle time, and overall handle time for a contact center. 
     Example 15 is a tangible, non-transitory, computer-readable media having instructions thereupon which, when executed by a processor, cause the processor to perform operations comprising: identifying one or more contact items within each conversation of one or more conversations, the one or more conversations being between one or more customers of a plurality of customers contacting a contact center and one or more agents associated with the contact center; tagging each contact item of the one or more contact items with a contact type and a channel type, including selecting the channel type from a plurality of channel types; and tracking periods of agent activity for each channel for each of the one or more agents using the tagging of the contact items for one or more work sessions. 
     Example 16 is media of example 15 that may optionally include that at least one conversation with one customer includes multiple channels at one time. 
     Example 17 is media of example 16 that may optionally include that tagging and tracking of work occur for each of the multiple channels at once only when an agent of the one or more agents is performing agent activity to handle the one customer. 
     Example 18 is media of example 17 that may optionally include that the tagging and tracking occur when agent activity switches between the multiple channels. 
     Example 19 is media of example 15 that may optionally include that the method further comprises sending tracked data to a workforce management system. 
     Example 20 is media of example 15 that may optionally include that the sending the tracked data to the workforce management system comprises providing access to the tracked data by, or on behalf of, the workforce management system. 
     Example 21 is media of example 15 that may optionally include that the contact type is one of a plurality of contact types comprising a phone call on a voice channel, a message on a messaging-based channel, an email on a mail-based channel, a video chat, and a voicemail on a voice channel or voice messaging-based channel. 
     Example 22 is media of example 15 that may optionally include that a work burst of the one or more work bursts is to start when an agent views a customer profile and is to end when the agent navigates away from the customer profile. 
     Example 23 is media of example 22 that may optionally include that the operations further comprise: providing a user interface for use by the one or more agents, the user interface supporting customer profile selection and channel identification or selection and for use in identifying the one or more work bursts based on navigation to and from the customer profile as part of profile selection. 
     Example 24 is media of example 15 that may optionally include that a work session is to begin when a contact item begins and is to end when the contact item ends, agent identifier changes, inbox identifier changes, item identifier changes, conversation identifier changes, or channel changes. 
     Example 25 is media of example 15 that may optionally include that the operations further comprise: tagging each contact item of the one or more contact items with one or more of: a contact item identifier, a contact type, a channel, a direction, a beginning timestamp, an end timestamp, a service level agreement (SLA), a SLA fulfillment time or timestamp, whether the contact item was answered within an established SLA, a conversation routing timestamp, a status of the contact item as to answered, abandoned, unanswered, or unknown, a calculated handle time for a work session, a wrap time after a contact ends, or an agent identifier. 
     Example 26 is a system comprising: a database, in a memory; and one or more processors, to: identify one or more contact items within each conversation of one or more conversations, the one or more conversations being between one or more customers of a plurality of customers contacting a contact center and one or more agents associated with the contact center; tag each contact item of the one or more contact items with a contact type and a channel type, including selecting the channel type from a plurality of channel types; and track periods of agent activity for each channel for each of the one or more agents using the tagging of the contact items for one or more work sessions. 
     Example 27 is system of example 26 that may optionally include that at least one conversation with one customer includes multiple channels at one time. 
     Example 28 is system of example 27 that may optionally include that the one or more processors are operable to tag and track work occur for each of the multiple channels at once only when an agent of the one or more agents is performing agent activity to handle the one customer. 
     Example 29 is system of example 28 that may optionally include that the one or more processors are operable to perform tagging and tracking occur when agent activity switches between the multiple channels. 
     Example 30 is system of example 26 that may optionally include that the one or more processors are operable to send tracked data to a workforce management system. 
     Some portions of the detailed descriptions above are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. 
     It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the following discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system&#39;s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. 
     The present invention also relates to apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. 
     The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. 
     A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium includes read only memory (“ROM”); random access memory (“RAM”); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.); etc. 
     In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the broader spirit and scope of disclosed embodiments. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.