May 2000

Special TMC Labs Review: Skills-Based Routing: Matchmaking And The Call Center, Part II

Skills-based routing provides an automated mechanism for routing calls to find the best available match between the needs of the customer and the various proficiencies of available agents. Skills-based routing is an ideal solution for providing callers with a quality experience in an automated manner.

This article investigates the implementation of a skills-based routing plan for a fictional call center using the first of two different switch platforms. Here, in Part II, we focus on the Lucent Definity Enterprise Communications Server. In Part I, which appeared in our April 2000 issue, we highlighted the Nortel Meridian Option 11 running with Symposium Call Center Server.

The Fictional Call Center
The first phase in implementing an effective skills-based routing plan is understanding the business requirements of the call center. To do this, a fictional call center was invented for the purpose of illustrating the deployment of this technology in a real-world scenario.

Our call center served as the sales and technical support hotline for a fictional computer software company. There were two direct in-dial (DID) numbers configured: one was configured as the entry point for all sales-related calls and the other was the entry point for all technical-support-related calls.

For sales and technical support calls, agents can be English-speaking, Spanish-speaking or both. Since Spanish-speaking agents are a commodity in our call center, callers who request service in English are given to English-language-only agents first. If agents who speak only English are busy on other calls, bilingual agents can serve as backup.

For sales-oriented calls, a caller may want to buy the product or obtain information. As a result, there are two varieties of sales agents. A sales engineer agent is the only type of sales agent capable of answering questions about the software product. A general sales agent is only capable of executing sales requests and must transfer the call to a sales engineer if the caller is seeking presales information. A sales engineer can act as a backup to general sales agents, but the general sales agents are given higher priority in supporting sales-execution-type calls.

Technical support calls are always queued to first-tier support agents. If there are no first-tier support agents available, then the call will be queued to a second-tier support agent by transferring the call to an assigned call directory number (CDN). If the call is delivered to a first-tier support agent and he or she is unable to support the caller, the agent may re-queue the call to a second-tier support agent. If the caller sits in queue for longer than five minutes, he or she will be automatically forwarded to a voice mailbox.

The tests on the Lucent platform were performed using Release 6 of the Lucent Definity Enterprise Communi-cations Server (ECS). Lucent's Definity ECS system is an embedded processor within the switch that performs the basic call flow handling as well as system maintenance functions for the switch. Definity ECS comes equipped with a System Administration Terminal (SAT) that is used to access the administrative and maintenance capabilities on the switch. It is connected to the Definity ECS using a standard serial interface, but can also be configured for remote administration using a modem. No adjunct processors or reporting packages were used in these tests.

Within the context of Definity ECS, skills-based routing is referred to as "Expert Agent Selection," or EAS. It provides the same functionality of matching the needs of the caller with the skills or talents of the agents. This is executed using the ACD and call vectoring features of the switch.

Documentation
The Definity ECS library is organized into a set of Adobe Acrobat documents that are linked together using in-text hyperlinks and buttons. The first part contains links to documents that provide generalized content information such as an overall introduction, a global index of all documents and a global glossary. We found these global cross-references very useful because they link all of the documents together that pertain to a specific subject and provide a quick way to surf to specific content.

A logical starting point in the documentation is the "Administration and Feature Description" reference in the Basic Administration Documents section. This reference document provides an introduction to all of the major features of the switch.

The "Call Vectoring/Expert Agent Selection (EAS) Guide" is the appropriate manual for information related specifically to skills-based routing. In it, the distinction between basic call vectoring using splits and expert agent selection using skill hunt groups are defined and discussed in great detail. The various functions of EAS, such as skill administration, delivering calls to a queue and routing of calls to agents are discussed in tutorial fashion by administering a fictional "Auto Club" call center and tracing all of the steps a typical administrator may follow.

We found the documentation to be very useful and easy to use. All of the information was organized in a way that allowed maximum flexibility when researching specific topics and drives the reader directly to the detailed information they are interested in. However, the language of the documentation as compared to the Nortel Symposium Documentation is arguably more technical in nature and sprinkled with many more technical terms.

Operational Testing
Administering Skill Hunt Groups. Skills are administered within the Definity ECS by creating "skill hunt groups." Skill hunt groups are similar to traditional ACD queues, which are referred to as "splits" within the context of Definity ECS. Where they differ is how they treat agent log-ins and the distribution of calls throughout the call center. When using traditional ACD splits, the agent is associated with a static station and calls are distributed evenly across all logged-in stations. Skill Hunt Groups allow agents to log-in using a logical agent I.D., which binds the agent's skills with the station at login time. Calls, which have a set of skill requirements associated with them, are distributed to agents based on the match between a call's requirements and an agent's skill sets and other intrinsic statistics such as most-idle agent time. This serves the requirement for skills-based routing as well as providing the facility for "free seating" in the call center. It should be noted that the entire switch is optioned to either have EAS on or off. What this implies is that all hunt groups are referred to either as splits if EAS is turned off, or skill hunt groups if EAS is turned on.

The administration of skill hunt groups begins with the creation of a skills matrix. This is necessary due to the way Definity ECS handles agents who have multiple skills and calls that have multiple skill requirements. When a call is queued to multiple queues, the first available agent who has any one of the skills the call requires will be routed the call. In reality, however, the call may require an agent who has all of the required skills, not just any one of them. So, similar to Nortel Symposium, handling this type of call center requres the creation of a skills matrix to cover every skill set possible.

The skills matrix we defined for our tests is defined in Table 1.

Table 1. Skills Matrix.

For each skill type defined in the skills matrix, a skill hunt group will be administered. These skill hunt groups will be associated with a vector directory number (VDN), which is used to provide access to the actual call-handling instructions defined in a vector.

The important features of the administration of this feature are:

Group number. This is the number that other features, such as vectors and VDNs, refer to when referencing this hunt group.

Group name. For display purposes only, this field uniquely identifies this hunt group.

ACD. Specifies that this hunt group functions as an ACD split/skill.

Queue. Specifies that this hunt group will queue calls if an agent is not readily available.

Vector. Specifies that this hunt group may be vector controlled.

Group type. Specifies the type of distribution for calls in this hunt group. In this case, expert agent eistribution for the most idle agent has been selected. This specifies that a call will be delivered to the available agent with the highest skill level for the call. If there is more than one available agent with the same skills, then the call will be routed to the agent with the most idle time. In total, there are five different group types that may be selected: uniform call distribution (UCD) for either most idle agent (MIA) or least occupied agent (LEA); expert agent distribution (EAD) for either most idle agent or least occupied agent; and direct department calling (DDC).

Queue length. Specifies the number of calls that can back up into this queue.

Skill. Specifies that this hunt group is an EAS skill.

Administering Agent Log-Ins
An agent log-in I.D. is a logical extension administered in the switch which is associated with a specific agent, and identifies, among other things, that agent's skills. The agent log-in I.D. is not associated with a particular station until the agent has actually logged in, and that same association is broken once the agent has logged off. When agents log-in, they identify themselves using their I.D.s. Then, calls that may be queued to a skill hunt group that a specific agent posesses can be delivered to that agent.

The important features of the administration of this feature are:

Log-in I.D. Specifies the unique identifier for the logical agent.

Name. An optional entry which names the agent.

SN (skill number). Lists a skill assignment for this agent. This contains the value of the skill hunt group number, which was administered when the skill hunt group was created.

SL (skill level). Specifies the priority, 1-16, for this skill for this agent. If this value is blank, it designates that the given skill is a "reserve skill" and can be activated at a later time. In our case, each agent will be administered with a single, primary skill.

Administering Vectors And VDNs
The processing that is performed on an inbound call to the switch is defined as a sequence of commands that are administered as a vector resource. When a call goes into a vector, the treatment of the call is defined by the steps that are configured within that vector. This includes call routing, queuing to skill sets, collecting DTMF digits and playing announcements. Eventually, the call is either routed to a voice terminal or the control flow "falls out" of the vectoring steps, which cause the call to be terminated. Vectors are logical resources that are not associated with equipment or a particular extension. Rather, they are accessed indirectly using a VDN.

A VDN is a soft extension number that is used to map to a predefined vector. The VDN is dialed directly and provides accessibility to its associated vector. Many VDNs may map to the same vector, and this capability is often exploited to make re-use of vectors. In addition, different dialed numbers will be associated with different VDNs based on DNIS information. As calls enter the call center, they are routed directly to the VDN that is appropriate for the number that was dialed. In our case, two VDNs were administered, one for sales-oriented calls and another for support-oriented calls. In addition, VDNs may be associated with a set of specific skill sets. Used in this way, the vector that is invoked by the given VDN can indirectly refer to the skill sets as defined in the VDN rather than coding specific skills within the vector itself. This allows the administrator to re-use the same vectors with different skill sets.

There are some limitations to vectoring that affect the way they are administered. First, vectors do not have the concept of "variables." Without them, many vectors may need to be administered that perform the same exact call processing, but differ in some minute way. For example, it is necessary to configure two different sets of vectors for English and Spanish treatment. Even though the vectors effectively perform the same tasks, they must be separated because there is no way to inspect the previous selection of language preference. In addition, the size of a Vector is limited to 24 steps. Therefore, avoiding the problem of not having variables by using conditional branching within the same script is not possible either because the script will grow beyond its maximum size. The correct solution is to branch from one vector to another using the appropriate VDNs.

Sales VDN And Vector
The sales VDN and vector are used to handle all inquiries related to the sales function of the sample call center. This includes prompting the caller for their language preference, prompting for the kind of sales agent they specifically require and finally, queueing the call to an agent with the appropriate skills.

This is accomplished using two vectors. The first vector, named "Sales," performs all of the call handling up to the point of queuing. The second vector, named "Queue to Skill," performs the actual queueing of the call by searching for an available agent with the required skills. "Queue to Skill" is shared by several different VDNs to get a level of re-use out of the vector. This is accomplished by administering each component VDN with the skill sets that the vector will queue the call for. By using different VDNs with the same vector, the administrator can save vector development time. It also provides a single point to make changes to skill requirements without having to directly modify any vectors.

When the switch first receives a call on the sales dialed-number, it will route the call directly to the Sales VDN. The VDN is administered to execute the Sales Vector and does not list any specific skill requirements. In addition, the VDN has been configured such that subsequent VDNs that are dialed can override the parameters defined within the first. This is especially important for the requirements of our sample call center, because the sales vector routes the call to one of many other VDNs whose job is to queue the call for a very specific list of skill requirements. If the sales VDN was not administered to override its parameters, the subsequent VDNs dialed would not be able to use the list of skill requirements that they have defined. Instead, the queueing vectors would be invoked with the empty set of skills that are defined in the original sales VDN and the call would not be sent to any agents at all.

The steps of the vector are detailed in Table 2.

First-Tier Technical Support VDN And Vector
The technical support VDN and vector are used as the first point of entry for technical-support-related calls. Since the strategy for technical support is to initially queue calls to tier-1 support agents who can manually escalate issues to tier-2 support agents, the VDN and vector associated with first-tier technical support will only prompt for a language preference and will then immediately queue the call.

This is accomplished using two vectors. The first vector, named "Support," performs call handling up to the point of queueing, in the same way that the sales vector performs the equivalent work. The second vector, named "Queue to Skill," performs the actual queueing of the call by searching for an available agent with the required skills. The "Queue to Skill" vector is shared by several different VDNs (including the sales-oriented VDNs) and performs the actual job of queueing the call.

When the switch first receives a call on the support dialed-number, it will route the call directly to the support VDN. The VDN is administered to execute the support vector and does not list any specific skill requirements. As is also the case with the sales VDN, the support VDN is configured to use VDN override so that the skill parameters administered in subsequent VDNs will be used by the "Queue to Skill" vector.

The steps of the vector are detailed in Table 3.

Steps Of The Vector

It should be noted that the procedure for an agent to escalate a call to a second-tier support agent requires that they manually transfer the caller to the appropriate VDN. That is, the agent must select either the VDN associated with "English: Tier2Support" or "Spanish: Tier2Support." Both of these VDNs will route the call using the "Queue to Skill" using the given skill sets as specified by the number that was dialed by the agent. There is no automatic way for the agent to transfer the call to a single place and have the call "remember" the original language selection of the caller. That is why the agent must manually select the VDN to which they transfer the call.

Call Queuing VDNs And Vectors
The VDNs that are referenced by the sales and support vectors above are now defined in this section. There is defined a single vector, named "Queue to Skill," that does the job of queueing calls for different skill sets for all service and support calls. It is accessed, however, through many different VDNs. It is the VDN which actually defines the skill requirements a call will have. The "Queue to Skill" vector will then reference these skill parameters by their order of definition (1st, 2nd or 3rd). This ability to re-use a single vector and to administer VDNs simplifies the necessary administration both up front and when changes need to be made.

The steps of the vector are detailed in Table 4.

Steps Of The "Queue To Skills" Vector

We found that the administration of the Definity ECS to perform skills-based routing was relatively straightforward and simple. Although the System Administration Terminal is not a graphical user interface, the command set is simple and powerful enough to make up for what it lacks in beauty. The documentation is first-rate and is especially useful in its online form. The only drawbacks to administering for skills-based routing revolved around the problems associated with Vectors and VDN administration. Often, we found that we faced system-imposed limitations, such as the number of skill sets that can be administered in a VDN, the length of vectors and the vectoring commands that were available to us.

Table 2. Steps Of The Sales Vector.

[return to the text]