The role of workforce management software is to use historical data to predict the future, creating a reasonably accurate forecast of workload and a schedule for staff which matches it. Generally, the historical and even real-time data comes from the ACD or from the reporting system associated with the ACD. The advent of third-party routing systems is changing the configurations required to support accurate forecasting and scheduling.
There are three basic components of data needed to develop a reasonable forecast:
Patterns – Patterns include the number of calls for each period of a day (typically half-hours), each day of a week or date of the month, and monthly seasonal patterns. Special patterns develop around each organization’s call volume drivers such as promotions, mailings, weather events, and holidays. These historical patterns tend to repeat themselves and this is the basis of a good forecast.
Number of calls offered (NCO) – A prediction of the number of calls that will be offered to the system and agents during each period is required. This NCO must be developed for each unique call type which will be handled by a defined set of personnel in the call center. While there may some overflow of calls among agent groups, the forecast must identify how the calls were offered in order to ensure that appropriate scheduling, recruiting, and hiring take place to meet the requirement of each call type.
Average handling time (AHT) – A prediction of the AHT that will be experienced during each period for each call type is required. Experience shows that the AHT varies by time of day and day of week within the same agent group handling the same type of call. When agents handle a mix of call types, it is important to identify the work required to handle each type separately so that any mix can be accurately predicted in terms of workload and agent requirements.
In a traditional call routing environment, the ACD receives a call and determines the type by dialed number, trunk group, or even data entered by the caller in response to menus and IVR scripts. The call is then directed to an available agent who handles that call type or queued for the next agent who becomes available in that group when no one is readily available. The call is handled in a group which is associated only with that call type – service calls are handled by service agents and sales calls by sales agents, for example. In the universal agent group situation, all calls are handled by any available agent and there is really only one call type for forecasting purposes.
The workforce management system will generally have a data link to the ACD MIS processor to receive the historical data regularly. In a traditional routing arrangement, the data on NCO and AHT can be taken directly from the statistics gathered for each agent group or split as each is dedicated to handling just that call type.
In a more complex call routing environment, the ACD may have several optional agent groups to pick from in delivering a call. This is the case in a skill-based routing scenario, for example. A call may be identified as a customer service call by the dialed number, but the ACD will first try agents in the customer service group and then try agents in the sales group, perhaps queuing calls to both groups waiting for any agent to become free. If a customer service agent is free first, the ACD will deliver the call to that group. If a sales agent becomes free first, then the ACD will deliver the call to that group. This is where the way calls are offered and the way they are handled begin to diverge.
The process is similar when agents are capable of taking calls of multiple types and are essentially logged into more than one agent group simultaneously. As long as the ACD routes the call to only one agent group regardless of how agents are prioritized within that group (perhaps primary and secondary), the offered call type and handling agent group are the same. If the ACD chooses among several agent groups, and adds the option to select among agents within those groups by priority, then the offered call type and the agent group that handles the call may not be the same.
When the ACD is in control of the call routing process in a skill-based routing environment, it is essential for the workforce management system to get its data from the point where the call is identified by originating type. This would be the VDN (Vector Directory Number) for a Lucent system or the CDN for a Nortel system, for example. If the data is captured here, the true offered load by call type will be known and forecasting and scheduling can be reasonably accurate.
Generally, if the data is captured at the agent group level, the data will be skewed. A sales call handled as an overflow call into the customer service group will appear to be a customer service call since it shows up in that group’s statistics. When there are not enough personnel in one group to handle its own load, the calls will be handled elsewhere, and the forecast will incorrectly interpret this as offered work for the wrong groups. Poor staffing and scheduling decisions will be concealed and even perpetuated.
There are some exceptions to this rule, however. When the multiple agent skills associated with a VDN/CDN equivalent are all dedicated to handling only that call type, then the data can be captured in either point. For example, agents can log into a primary group in their own business unit and special back-up groups/skills in other units they support. In this case, the calls for sales go to agents primary on sales and to others logged into back-up groups/skills for sales, but all calls are sales to any of these groups/skills. While an agent may handle a mix of calls, the data on each call type is in a separate group/skill record rather than mixed together.
When a third-party routing system is added into the equation, the ACD may be utilized in the more traditional manner, allowing all of the decisions about call routing to be handled outside of the ACD. This is true whether the third-party router is used in a single site environment or to link together multiple sites.
Let us assume for example that a GeoTel or Genesys system is being used to provide a unique skill-based routing capability. The call will be presented to the router, the router will look at the situation in each of its attached ACDs, and the router will direct the call to the “best” place as defined by its routing scripts. There are two basic potential scenarios at this point:
The router may simply choose among sites and route the call to the site with the best chance of serving the caller, allowing the ACD to make the choice among agent groups within that site.
The router may consider multiple agent groups within a single site or multiple sites and direct the call to a specific agent group (or even individual agent) utilizing the ACD as a “dumb switch” with no routing properties.
The question is where must the WFM system go to find the true number of calls for each unique call type or skill? In the first scenario, it could get the information from the router or the ACD and it would be essentially the same. However, at the ACD it would be important to identify it at the point of entry rather than at the handling agent group or split.
In the second scenario, the third-party router has bypassed the ACD routing process and directed the call to a specific group which may well be a backup group for this call type rather than a dedicated agent group. In this case, capturing data at the point of entry or at the agent group level would both provide inaccurate data. The WFM must get its data from the router to know what kind of call this truly was. Therefore, a data link to the router is essential to accurate forecasting.
Some implementations of third-party routers allow only some subset of the calls to be routed by the system. This may be due to a portion of calls that are local rather than toll- free. It can also be an effort to minimize the expense of the router by having it only skim off the top percentage of calls for call-by-call routing, allowing a more gross distribution such as percentage or area code routing to handle the bulk of calls. In these cases, the WFM system will need to have links to both the router and the ACD with very clear identification of which data to get from each system to avoid double counting calls that go through both systems and missing calls that only go through the ACD.
While the implementation of a third-party router may provide a mechanism to more evenly distribute workload among sites and achieve complex skill-based routing applications, the implications for accurate forecasting and scheduling are considerable. It is still possible to obtain accurate data, but the configuration and routing rules must be clearly understood and the data captured at the point where it is most appropriate. As these systems are reconfigured to meet changing organizational requirements, coordination with the provider of the WFM system will be essential to maintain the full function and accuracy of these vital planning systems.
Maggie Klenke is founding partner of Lebanon, TN-based The Call Center School, a consulting an education company.