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.
Documentation
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.
Scripting
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.
Variables
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.
Conclusion
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.
|