TMCnet - World's Largest Communications and Technology Community




labs.GIF (1895 bytes)
April 2000


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

Nortel Networks' Meridian Option 11 Running With Symposium Call Center Server

Award logo

How often have your customers complained about having their calls transferred too many times because the agents who handled those calls along the way were not trained to address the customers' specific needs? How many high-priority customers have waited in queue while agents gave their attention to other, low-priority customers? If the answer is too many, skills-based routing may be a solution.

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.

In this article, we will investigate the implementation of a skills-based routing plan for a fictional call center using the first of two different switch platforms, the Nortel Meridian Option 11 running with Symposium Call Center Server. Part II of this review, which will focus on the Lucent Definity Enterprise Communications Server, will appear in C@LL CENTER CRM Solutions�' upcoming May 2000 issue.

Traditional ACD Vs. Skills-Based Routing
The traditional ACD delivers calls by selecting an agent from a queue based on some statistical criteria, such as the "idle time since last call" or "idle time since log-in." By selecting an agent in this way, the ACD balances the load of incoming calls among all agents and makes fairly good use of available agent resources. This mechanism assumes, however, that all agents are equal in their ability to service a caller's needs and that all callers are equal in their priority and value to the call center.

Modern call centers that are equipped with CTI, IVR and speech-recognition technology provide their frontline with a great deal more knowledge about a caller and can make sure the right agent with appropriate skills is talking with the customer. To provide the functionality of skills-based routing, the concept of the queue had to be expanded.

A queue is now directly associated with a specific skill an agent may possess. An agent, therefore, can be logged into several queues simultaneously if he or she possesses more than one skill. In addition, a pending call will be placed into more than one queue simultaneously, based on agent skill levels. When the call is finally delivered to an agent, it is removed from all of the queues it was waiting in.

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.

Nortel Option 11 And The Symposium Call Center Server
Our test environment included a Nortel Option 11 (M1) Release 24 and the Symposium Call Center Server. Nortel's Symposium Call Center Server provides a suite of applications for the management of call center resources, control of call processing and generation of real-time and historical reports. It works by "acquiring" resources that were administered in the M1 and assuming control of them. It provides a nice graphical user interface (GUI) for configuration of these resources and a decent scripting language for controlling the routing of calls and various voice and music treatments that can be delivered to the caller.

It is important to understand that three different tools are used to configure the call center as a whole. Each one of these tools focuses on the configuration of a specific aspect of the call center, whether that is a physical resource or a logical resource such as a script. The most primitive tool used to configure the call center is the terminal interface to the M1. This is still used to configure most of the physical resources within the switch and is accessed through a serial port on the switch. For configuration of the stations in the call center, we used the Release 5 of the Meridian Administrator Tools (MAT) Navigator. Although station configuration can still be done using the terminal interface, the MAT Navigator is a nice GUI environment for this task. Finally, the Symposium Client is used to configure most of the logical resources that exist within Symposium.

The Nortel Symposium Call Center Server architecture can be divided into three major components: telephony, server and client. The telephony component consists of the Meridian 1 PBX (M1) and associated telephony devices. The Symposium Server component is a Windows NT 3.51 platform, which communicates with the M1 using an embedded Ethernet TCP/IP LAN in the switch known as the ELAN. The Symposium Client is a software component that is configured within Release 5 of the Meridian Administrator Tools (MAT) Navigator application, and requires the Windows 95/98 platform. Finally, Release 6.5 of the MAT Navigator, which runs on Windows NT 4.0, is used to administer the stations on the M1 using a GUI in replacement of having to administer using the Meridian console. Unfortunately, we felt that the forced heterogeneous mix of operating systems was a slightly restrictive requirement.

The Symposium documentation is made up of a daunting 21 manuals. These manuals are used to implement a 22-step phased setup that is introduced in the End-To-End Task Flow Guide. This guide is also a good place to find which manuals apply to the type of task you are trying to administer in Symposium. Each phase of administration is listed and the associated manuals for the task are referenced.

Given the number of manuals, a good starting point is the Primer and Workbook Companion. In the Introduction chapter of that manual, the section, What is Symposium Call Center Server?, provides a decent overview of the system and its architecture. The Primer manual is used to give general information about the features of Symposium and to walk an administrator through the process of filling out worksheets, which are used later for input in the actual configuration dialogs.

For documentation that is specific to the task of setting up skills-based routing, the Setup and Configuration Guide, Call Center Management Guide and the Scripting Guide are the most appropriate. Although there is some overlap in the information provided in the Setup and Configuration Guide and the Call Center Management Guide, the Setup and Configuration Guide should probably be the first manual to read.

The tasks outlined in the chapters of these manuals must be performed in the same order as they are presented in the manual. The reason for this is that the configuration is presented as a cumulative process, where each chapter builds on items that were configured in the previous chapters. This points out what we felt was a shortcoming in the documentation. The manuals were useful as a reference for procedures related to data entry in the configuration dialog, but if you are looking for general information about a subject within the Symposium Server, it is difficult to find the information you are looking for. The context-sensitive help also displayed similar problems.

Operational Testing
Configuring Switch Resources
The first phase in setting up the Symposium Call Center server for skills-based routing is configuring resources within the M1. These resources will later be acquired by Symposium for its exclusive use. For the purposes of our test, this included one Control Directory Number (CDN), four TNs (agent phonesets) and two Dialed Number Identification Services (DNIS). The Symposium and Meridian1 Guide is a Symposium-centric reference guide which discusses the commands that must be entered in the terminal interface to configure these types of resources. Although this manual should not be used as a substitute for the actual M1 documentation, it is an excellent reference for pinpointing exactly what you need to configure to get Symposium to work.

Finally, the switch must be configured such that calls can be made which simulate a call emanating from the PSTN. This is necessary so that the appropriate scripts can be executed on the basis of DNIS information. Specifically, if a call arrives from a DNIS for the sales organization, the call will eventually be queued for either a sales engineer or a general sales agent. If the call arrives from a DNIS for the support organization, the call will be queued to a first- or second-tier support agent. If no DNIS information is available, the caller will be prompted for his or her desired destination. To make this occur within a test environment, a T1 loopback is necessary to simulate outbound calls leaving the switch and re-entering the switch. This typically requires two T1 cards.

Acquiring Resources
The next phase in setting up the Symposium Call Center server is acquiring the resources configured within the switch. These configuration items can be found in the Switch Administration section of the Call Center Management application in the MAT Navigator. All of these resources must first be configured within the M1 for them to be acquired. Only when events occur in the switch that relate to these resources will the Symposium server be able to respond.

CDNs are used to direct incoming calls into the switch and send control messages to the Symposium Call Center Server. The CDN is the "bridge" from the telephony component of the architecture into the Symposium Call Center Server. Only calls that have been routed through an acquired CDN can be controlled by the Symposium Server in this way. Acquiring a CDN is a simple process involving specifying a number in the CDN number in a configuration dialog and then executing the "acquire" command on the resource. In our test environment, one CDN was configured and acquired. Calls were routed through this CDN and then Symposium would take control of the call from there.

Dialed number identification service (DNIS) is the method of determining the phone number dialed by the incoming caller. The DNIS will be used to determine the type of service the caller is looking for. In this case, DNIS will be used to determine if the caller should be queued to sales or technical support. Acquiring a number from DNIS is a similar process to acquiring a CDN. A telephone number is specified in the configuration dialog using its DNIS number. It also involves an extra step of specifying a "service level threshold" value which indicates the timeframe within which a call must be handled before it is abandoned. Two DNIS values were configured for our test environment, one for sales and one for technical support.

Finally, phoneset resources represent the physical agent and supervisor telephones. These are configured within Symposium by specifying the telephony port address of the phoneset and then acquiring the associated device. Four phonesets were configured in our test, which represented three agents and one supervisor.

We found that, in general, the process of acquiring resources was fairly straightforward and simple. The only issue we encountered was the format of specifying the telephony port address of the phoneset when acquiring the phoneset resource. Since we were using a smaller switch with fewer ports, it was not necessary to specify all four digits as the example in the Setup and Configuration Guide does. In fact, we had to specify only two digits and learned that it was necessary to trim all leading zeros in these digits. This was slightly confusing because the MAT Navigator station administration displays the port addresses using leading zeros.

Configuring Call Presentation Classes
A Call Presentation Class is a logical resource which defines the manner in which a call is delivered to a user. For example, a call may be configured to ring at a phoneset for 18 seconds and if the call is not answered in that time, it will be re-queued for another agent. Alternatively, the call can be configured to ring at the phoneset indefinitely. In our tests, two call presentation classes were created for the sake of illustration. Technical support users were associated with a call presentation class that rings for 18 seconds and is then re-queued to another agent. Sales users were associated with a call presentation class that rings at the agent phoneset indefinitely.

Configuring Call Presentation Classes is very easy. Since there is no physical resource that must be acquired, it is simply a matter of clicking the desired requirements in the configuration dialog. Later, these Presentation Classes will be associated with specific users.

Configuring Skills
Skillsets are the foundation of skills-based routing as they define the criteria used to match the needs of a caller with the capabilities of an agent. These skills must be administered within Symposium before they can be applied to users.

To define the skillsets within Symposium, a "skills matrix" must be constructed to list all of the individual skills users may possess; then composite skills can be created based on combinations of individual skills. These composites will become the actual skills that are defined within Symposium. This is necessary because of the way calls are distributed within Symposium. When a call is queued to multiple skills, the first available agent who has any one of the skills the call requires will be routed the call. In reality, however, a routed call may require an agent to possess all of the designated skills. For instance, if an agent were administered with the English and general sales skills and a call was queued to the English and Tier 1 Support skills, then the call would be sent to the first available agent who has either the English or Tier 1 Support skills. In this case, the general sales agent may be delivered the general sales call simply because he speaks English! To avoid this situation, the skills-matrix is created, as shown in Figure 2.

In addition, Symposium has the concept of a "default skillset." This is used when a script which is controlling the call has finished executing and has not yet queued the call for any skillsets. The default skillset will be used as the catch-all safety measure to avoid abandoning these types of calls.

Configuring a skillset is very similar to configuring any other resource in Symposium. The configuration is made up of three sections: General, Call Presentation and Thresholds.

The General section is used for the main configuration of the skillset. This is where the name of the skillset is defined as well as some other optional parameters. One of these optional parameters, the activity-code, can be associated with a skillset for Symposium reporting and accounting reasons. An activity-code is a mechanism for an agent to associate a call they are handling with a specific accounting reason. Later, reports can be executed which show agent activity by activity-code. By associating the activity-code with a skillset in this way, the accounting can be done automatically without agent intervention. The default setting for the activity-code was used for our testing.

A Threshold Class can also be associated with the skillset. The Threshold Class is a configurable Symposium resource which defines upper and lower boundaries for values that are displayed during real-time reporting. This value was left at the default value of "Skillset_Template."

You are also given the option of configuring an "ACD DN Number" associated with the skillset. This option is enabled to associate a "dummy skillset" with an existing ACD DN. This is used when you desire the call distribution to be handled directly by the ACD hardware and not by Symposium scripting. By associating the skillset with the ACD DN, statistics will be collected on a skills-basis for reporting purposes. This option, by default, is not selected.

The Call Presentation section in the skillset configuration dialog allows you to specify the order in which calls are serviced in the queue. This can either be defined as the "Oldest" for the call that has been waiting in queue the longest or "First in Queue" for service on a first-come, first-served basis. We selected "First in Queue" for our tests.

Finally, the Thresholds section is used for defining threshold values associated with the skillset. These thresholds are used for saving historical (pegging) values and for values which are highlighted in real-time reports. We accepted the values that were given as defaults for the purposes of the test. If thresholds are to be used, however, they must first be configured as a Threshold Class resource so they are available for selection in the skillset configuration dialog.

The default-skillset is a predefined skill that is viewable in the skillset window. Configuring this item lets you select from a drop-down list a skillset that will service that call if it falls through a script without being queued. We selected the default value of "Default_Skillset" for this item.

Configuring Users
There are three different types of users in Symposium: call center agents, call center supervisors and desktop users. These are configured in the User Configuration window by checking the appropriate checkbox properties that apply to the type of user you want when you first create the user resource. Of the call-center-type agents, a supervisor should be created before an agent. This is necessary because when you create a call center agent, you will be required to identify the agent's supervisor.

The next step in configuring a call center user, whether it is a supervisor or an agent, is defining the general information about the user such as name, title, department and language spoken. The language setting should not be confused with a skillset; it is used to configure the LCD display on the phoneset to display in a specified language. Minimally, this portion of the user configuration requires the first and last name to be configured and the rest of the field can be left at default.

The Phoneset section of the user configuration defines the Login ID, Position ID and Personal DN of the user. The Login ID is an arbitrarily chosen identification number that the user will enter when he or she logs in to the phoneset. This number is a logical setting that is known to Symposium and is not tied to a specific M1 resource. Typically, a user will press the "In Calls" button on the phoneset, enter his or her Symposium Login ID and press the "#" button to be identified by the system. The process of logging into the phoneset is one of the first glimpses of feedback from Symposium that it has, in fact, "taken over" certain aspects of the call center. Normally, if Symposium is not installed, an agent enters a four-digit ID to log-in to phoneset and does not need to terminate his or her ID with the "#" symbol. Upon successful log-in, the name specified for the user in the General section should be viewable in the phoneset LCD display of the phoneset, if it has one.

If the user being created is a call center supervisor, the Position ID of the user must be specified. We used the MAT Navigator for station administration to look up the Position ID that was already specified within the M1 for the Supervisor's phoneset. As the documentation specifies, agents are not required to enter a Position ID because they are not restricted to a single phoneset and are assigned Position IDs when they log-in to their phones.

The last step in phoneset configuration is specifying a Personal DN for the phoneset. This is the DN for non-ACD- type calls. Again, we used the MAT Navigator to look up the appearance DN that was administered for each station and configured the user resource appropriately. If all of the phoneset configurations are correct, and the user has logged in successfully, the Status field in this tab of the configuration dialog should accurately display the logged in status of the user. This can provide further feedback of whether or not the phoneset and user resources have been configured properly.

The Call Presentation section of the user configuration is used to select a Call Presentation resource that has already been defined. The settings of the resource will be displayed for viewing only. If you wish to edit this resource, you must go to the Call Presentation resource itself and modify it. Similarly, a Thresholds section is available to select a Threshold Class resource for statistical and reporting uses.

The Skillsets section of the user configuration is used to assign specific skills to a user. The skillset resources that were configured in the previous steps will be available for selection from a drop-down control and can be added to the list of skills he given user possesses. Each skill can be given a Standby status or a Priority status. If a skill is specified as Standby, the user will not initially be selected for calls of this skill, but the supervisor has the option of changing this skillset if the call center becomes busy. Otherwise, priority values indicate the relative proficiencies in the skills the user possesses.

In our test, however, the scripts will be used to service different skills if the primary skill requirement for the call cannot be met. Instead of administering users with many skills, they are only administered with their primary skill. The scripts, which control the call flow, will queue the call to a list of queues at the same time. Symposium is designed to evaluate the command by trying to satisfy the requirements of the call one skillset at a time. If there are no available agents for the first skillset specified in the queuing command, then the next skillset in the list will be evaluated. For example, a single user may be administered with the Bilingual_SalesEngineer skillset. If a call is queued to both English_SalesEngineer and Bilingual_SalesEngineer (in that order), then if there are no available English_SalesEngineers, a Bilingual_SalesEngineer will be selected next. This is convenient because changes in the policy of the call center do not force the administrator to reconfigure all of the users in the call center.

If the user is a call center agent, the primary and associated supervisors must be specified. The supervisor section of the user configuration provides a list-box control of all of the available supervisor users that can be selected. A primary supervisor is specified using the "Report To" button and represents the agent's direct line of reporting. All other associated supervisors for this user are specified using the "Associate" button.

If the user is a call center supervisor, an Agents tab will be available for specifying agents that are assigned to the supervisor user. In addition, the supervisor may specify the key number on their phoneset that will call the agent directly.

The Symposium scripting language is a robust, miniature programming language that is used to define the sequence of steps that a call follows as it flows through the switch. It can be used to provide call treatment, call routing and voice processing for the caller as well as use intrinsic information within Symposium to make intelligent decisions about call handling.

There are three types of scripts within Symposium: Master scripts, Primary scripts and Secondary scripts. Master scripts are built into Symposium and cannot be deleted, but can be edited. Master scripts are the main entry point for all calls and are typically used to route the call through another script based on Dialed Number Identification Service (DNIS), Calling Line ID (CLID), or some other criteria such as time of day. When a Master script references another script, the referenced script is referred to as the Primary script. When a Primary script references yet another script, the referenced script is referred to as a Secondary script. Secondary scripts may also reference other Secondary scripts.

The scripting language itself is reminiscent of a simple programming language. It has the concept of commands, expressions, operators and variables. In addition, intrinsic information about the state of Symposium is also available for expression evaluation. There are, in fact, two flavors of variables that differ by their scope and accessibility. Call variables exist within the scope of a given call, and as a call moves around the switch, the call variable values follow it. A user is only allowed to have 20 call variables because of the overhead involved with using them. There will be a copy of each of these variables for every call that is within the switch. Global variables can be used by any script in the system at any time, but the value is, in essence, hard-coded.

The Master Script
The scripting we implemented for skills-based routing started with the Master script. In our case, the Master script is very simple and just calls through to one of two scripts, the Main script or Tier2SupportScript, depending on the value of the queue_to_support variable.

The script works as follows: The WHERE command is used to select from a list of options based on a parameter. In this case, the parameter is the call variable queue_to_support, which has a default value of 0. Therefore, normally, all calls will be routed through the PrimaryScript script. However, if a call has been through support once already, and has been resent to queue, the queue_to_support variable will be assigned to the value of 1, signifying that the call should be routed to a Tier-2 Support Agent. This allows re-use of the same CDN, while providing multiple functionality.

The Primary Script
In our implementation, the Primary script was called PrimaryScript. It is used to find the language preference of the caller and also references one of two Secondary scripts based on the DNIS. If the caller dialed the number associated with the sales department, the SalesScript script is executed. Otherwise, if the caller dialed the number of the service department, the ServiceScript script is executed. If the dialed number is not known, the caller will be prompted for which division he or she is seeking.

The script works as follows: The script starts by opening a session with the default voice port and playing a pre-defined prompt to the caller. Note that voice prompts must be pre-recorded using the Voice Prompt Editor and a voice segment variable must be created as a placeholder for the actual recording. This variable is referenced in the script when it is time to play it. After playing the prompt, the script waits for the caller to enter their language preference, either 1 for English or 2 for Spanish. If the caller fails to provide a correct entry, the process of asking for language preference is repeated until the caller is successful. The language choice is saved for later.

The first WHERE command is used to select from a table of options based on a given parameter. In this case, the parameter specified is a Symposium intrinsic value, the DNIS. If the DNIS value is 5551111, then the Sales script is executed. Otherwise, the Service script is executed. If a call comes through that does not belong to either DNIS or the DNIS could not be evaluated, the script will fall through to the section where the caller can select the division (sales or service) he or she requires.

The EXECUTE SCRIPT command returns execution back to the calling script when the sub-script is done. In this specific case, that feature is a beneficial one because it avoids accidentally falling through and asking the caller what division they want after successfully completing either the Sales or Service scripts. However, returnable sub-scripts would be useful if they did exist. This would give script writers a greater level of re-use of scripts if they could be invoked as sub-routines that return to the calling script once completed.

Finally, if the DNIS value was not available or it was not one that was in our list, the caller will be prompted for his or her desired division, Sales or Support. Note that the prompting will be in the appropriate language according to what the caller selected at the top of the script. If the caller does not select either 1 for Sales or 2 for Support, the process of selecting the appropriate service will be repeated until successful. If the caller is given an invalid selection message, he or she will receive it in the proper language.

We found it curious that the scripting language did not include the ELSEIF keyword in the language. The ELSEIF keyword is commonly used to start a new conditional statement within the ELSE clause of an IF statement. So, instead of having to create a new IF/END-IF inside the ELSE clause of an IF statement, a single statement could be used which makes the resulting script easier to read and understand.

The Sales Script
The Sales script is used to determine whether the caller is seeking general sales or a sales engineer. Since sales engineers are a commodity in this call center, it is always preferable to queue most of the calls to the general sales skillset unless the caller specifically requires the sales engineer. Once the type of sales function has been determined, the call will be queued to the appropriate skillsets.

The Service Script
The Service script is fairly simple because all service-related calls first go to Tier 1 Support Agents. If the Tier 1 Support Agent is not able to answer the caller's question, the call will be manually transferred by the agent to the main CDN again. Since the queue_to_support variable has been set, the next time the call reaches the Master script, it will be queued for a Tier 2 Support Agent and will keep the language preference that was originally selected by the caller.

Tier 2 Service Script
The Tier 2 Support script is invoked when a Tier 1 Support Agent has manually transferred a call to the Tier 2 Support CDN. Normally, all inbound calls are executing using the Primary script. However, the Master script has been coded to inspect a Call Variable that gets set when the call has been to a Tier 1 Support Agent, which will redirect the call to a Tier 2 Support Agent if the call is queued for a second time.

It is important to note that the language choice and queue_to_support call variables from the previous session "followed" the call even though it had been transferred to the CDN for a second time. This is important, because if it did not, then the caller would have to be re-prompted for their language preference. It would probably not be popular with most callers to have to enter the same information twice.

The Nortel Symposium solution is a significant improvement over the previous methods of administering the switch. The GUI is, for the most part, straightforward and easy to use. We felt that the scripting language was especially powerful and robust, although we did have some simple recommendations for improvements on the language. The largest criticism that we had about Symposium was with the documentation. For the most part, we felt that the documentation was focused more on data-entry procedures than providing generalized information about the inner-workings of Symposium. Therefore, it was sometimes difficult to read a chapter without first realizing the context of the instructions. We also felt the requirement that different components of Symposium run on very specific operating systems was prohibitive. This was especially the case for the Symposium client, where we had to use only Windows 95 for administration.

Technology Marketing Corporation

2 Trap Falls Road Suite 106, Shelton, CT 06484 USA
Ph: +1-203-852-6800, 800-243-6002

General comments: [email protected].
Comments about this site: [email protected].


© 2024 Technology Marketing Corporation. All rights reserved | Privacy Policy