Cisco Release 4.6.2 Network Applications Manager (NAM) Product Description
CallRouter (Release 4.6.2)

Table Of Contents

CallRouter

CallRouter Process

NAM CallRouter

CICM CallRouter

The Script Editor

Enhanced Service Scripts

IVR Network Prompting Scripts

Routing to CICMs

Virtual Call Center Scripts

Script Monitoring

Call Segmentation

Script Scheduling

Routing Targets

Control Objects

Formula Editor

Expressions

Distribute Object

Percent Allocation Object

If Object

Route Select Object

External Database Lookup Object

Gateway Object


CallRouter


The heart of the NAM software is a process called the CallRouter. The CallRouter serves as the central source of intelligence for call routing in the NAM system. The CallRouter receives call routing requests, determines the best destination for each call, and collects information about the entire system. The data collected by the CallRouter are stored in a central database for use in call routing, real-time monitoring, and historical reporting.

The CallRouter allows you to translate customer business goals into call routing decisions. Customers can define how calls are routed by creating call routing scripts. The CallRouter uses these scripts, along with real-time data on call center and agent status, to make call-by-call routing decisions.

This chapter describes how the CallRouter uses scripts and event-driven data to deliver calls to the best answering resource available. It also introduces the Script Editor, which is the graphical tool used to define call routing scripts.

CallRouter Process

The CallRouter process receives and responds to routing requests from the routing clients (NICs and PGs), collects call center event data from the Peripheral Gateways (on CICMs, only) and communicates with Admin Workstations. Figure 5-1 shows how the CallRouter works with these NAM system components.

Figure 5-1 CallRouter Overview

The CallRouter plays a slightly different role depending on whether it is running on a NAM or a CICM.

NAM CallRouter

On the NAM, the CallRouter provides the first stage in call routing by handling route requests from the service provider network. The NAM CallRouter interfaces directly with the network via the NIC. It can handle requests for every dialed number in the NAM system. The NAM CallRouter might return a destination label itself or it might pass the request on to a CICM.

NAMs typically have a limited configuration (dialed numbers, labels, basic enhanced services routing scripts, etc.). They also have a set of call routing scripts that can route calls to several CICMs. NAM scripts are created on a Network Admin Workstation (AW) and are managed by the service provider.

CICM CallRouter

Each CICM typically has a full configuration, storing customer-specific scripts, configuration data, and real-time and historical reporting data. The CICM supports links to ACDs and desktops in the call center; therefore, it can base call routing decisions on real-time data gathered by the Peripheral Gateways at each site.

By using their own set of scripts on a CICM, customers can establish routing decisions for a wide range of agent and service performance metrics, including:

Agent availability

The ratio of calls in progress to logged-in/ready agents

The ratio of calls in queue to staffed/scheduled agents

Customer profile data

CICM scripts are created at a Limited AW that is located on the customer premises.

The Script Editor

The Script Editor provides a visual, object-oriented environment for defining call routing logic. In appearance, a script resembles a programming flowchart. You define the routing logic by choosing objects from a palette of drag-and-drop objects and placing them in a script window. You then define the relationship between the routing objects with interconnecting lines. Figure 5-2 shows the main Script Editor window with a sample script displayed.

Figure 5-2 Script Editor Window

The graphical nature of the Script Editor helps you understand the call flow for a given script based on visual inspection. A script usually has several branches that can be followed depending on current conditions at the call center.

The Script Editor comes with many pre-defined routing objects. Customers simply need to supply the CallRouter with business rules to arbitrate between routing options when the demand for a given skill or resource exceeds availability. Customers can also input threshold parameters to allow for the use of backup agents under certain circumstances or to prioritize call handling for a given class of caller.

Enhanced Service Scripts

The NAM runs scripts that provide enhanced toll-free services such as percentage allocation and time-of-day routing. Most call routing requests are handled to completion by a NAM script. A simple NAM script might map a dialed number to a script that routes calls on a time-of-day basis to a particular customer skill group. Other network scripts might be more complex. Figure 5-3 shows three enhanced services script examples: CLID Match, Percentage Allocation, and Time-of-Day Routing.

Figure 5-3 Enhanced Services Scripts

IVR Network Prompting Scripts

The NAM might also run scripts that prompt callers to enter digits in response to voice prompts. These scripts can be implemented in cases where the customer requires network prompting services. Figure 5-4 shows a sample of an IVR network prompting script.

Figure 5-4 IVR Network Prompting Script

The script in Figure 5-4 takes calls from a general toll-free number and distributes them to other scripts based on the caller's prompt selections. This script is shown in Monitor mode, which is a Script Editor mode that lets you monitor real-time call allocation in percentages and numbers.

Routing to CICMs

NAMs may reference CICMs in scripts. The ICM Gateway node in a script serves as a path the NAM can take to access a CICM. If the Customer ICM can service the particular call, the route request is forwarded. Otherwise, another node within the NAM script can perform an alternative routing function. For example, the Go To Script node in Figure 5-5 forwards the route request to a network default routing script.

Figure 5-5 ICM Gateway Script

Virtual Call Center Scripts

CICMs have their own sets of routing scripts. These scripts are designed by the customer to meet specific business goals. CICM scripts can pre-route calls based on real-time call and agent data that are collected by PGs at call centers and, optionally, by customer data obtained from database lookups.

Figure 5-6 shows an example of a CICM Pre-Routing script. In this script, the business goals are to:

Segment high-priority customers and route them to a primary skill group for the highest level of service possible.

If agents in a primary skill group are not available, distribute the call volume in accordance with service and staffing levels at each call center location.

Ensure caller satisfaction by balancing the load across all sites in case any of the locations are unable to meet their service level objectives.

Figure 5-6 CICM Pre-Routing Script

Script Monitoring

To determine whether the routing scripts are truly sending calls to the appropriate destinations on a call-by-call basis, the Script Editor displays call volumes and percentages of calls in the context of the script that is routing the calls (see Figure 5-7).

Figure 5-7 Routing Script in Monitor Mode

The script monitoring capability lets you determine precisely how many calls took a given path in the script. You can then compare that data to the conditions that existed in the network during the same interval and expose anomalous behavior that exhibits itself only under specific load conditions.

With the Script Editor's advanced monitoring and editing capabilities, you can identify a potential call load problem, isolate it, make a script change, and rapidly introduce the change into the system.

Call Segmentation

The Script Editor provides a mechanism for logically segmenting callers based on the type of service request they are making. For example, a distinction can be made between a caller who wants to open a new account and a caller who already has an account and is simply inquiring about a new product or service. In another example, callers from one region of the country might be segmented from those calling from another region.

Script Scheduling

The Script Editor provides flexibility in scheduling when a given call routing script is used to route calls of a certain type. Some scripts might be active at all times; others might be active only during certain hours of the day or certain days of the week, month, or year. You might even define a script to run only on a specific date during a specific period of time.

Routing Targets

After determining the call type, NAM software runs one or more scripts to select a routing target for the call. NAM software can route a call to any of the following target objects:

Agent. An individual at a specific call center who is able to handle the call. Routing to a specific agent is subject to the capabilities of the target ACD/PBX.

Skill group. A group of individuals at a specific call center who are able to handle the call. The local switch at the call center is responsible for eventually picking an agent.

Service. The type of work or information that this caller needs and a specific call center that can provide it. The local switch at the call center is responsible for eventually picking a specific agent to handle the call.

Enterprise skill group. A collection of individual skill groups from several call centers. The CallRouter then further qualifies the target to determine which site has an agent that can best provide these skills.

Enterprise service. A collection of individual services from several call centers. The CallRouter then further qualifies the target to determine which site can best provide this service.

Announcement. A verbal message to the caller. After the caller hears the message, the call may be terminated.

Busy. Play a busy signal for the caller. This effectively terminates the call.

Ring. Play an unanswered ring for the caller. This effectively terminates the call.

Label. Returns a specific label to the routing client. A label is a value that ICM software returns to a routing client. The routing client maps the label to either an announcement or a trunk group and DNIS value.

Control Objects

Control objects are components of the Script Editor that control the selection of routing targets, the flow of script logic, script execution delays for a specified period of time, and the re-selection of a script based on current qualifier values.

The following sections describe only a few of the control objects available in the ICM scripting language. For more information, see the Cisco ICM Software Script Editor Guide.

Select Object

The Select object allows you to choose among a set of routing targets for a call. The Select object can use predefined rules such as Longest Available Agent and Minimum Expected Delay, or it can use custom rules that you define. A routing target, for example, might be a Service target set that specifies one or more potential services as targets for the call. Figure 5-8 shows a Select object.

Figure 5-8 Select Object

You can also establish acceptance criteria for a Select object or define the order in which ICM software checks the availability of targets in the Select dialog box. The following are some of the options available with the Select object.

Longest Available Agent Group

ICM software uses real-time data on agent status in making its routing decisions. The Longest Available Agent (LAA) algorithm instructs the system to deliver calls to groups of representatives with the appropriate skills based on the agent who has been available for the longest time.

Existing network-based call routing technologies typically rely on percentage allocations or the number of simultaneous calls in progress in order to distribute incoming traffic across call center sites. The LAA algorithm improves the utilization of the agent work force by ensuring that all agents in a group are equally busy. It utilizes the same staff management principles applied within a single call center and applies them across the entire enterprise.

Minimum Expected Delay

ICM software calculates the expected delay across all the selected call queues and deposits the call in the queue with the minimum expected delay. ICM software considers the average queue delay, the number of calls in queue, and the number of positions staffed. Selecting this rule results in more uniform queue times and more consistent service levels so that network operators are not constantly "queue-busting" only to create an imbalance at another site.

ICM's routing algorithms allow you to program the system so that it equitably distributes the call load based on expected performance goals. Unlike call routing algorithms that rely solely on call handling rates, ICM software does not have the effect of rewarding a job well done with more work (unless your business objective is to force calls to specific agents).

Next Available Agent

ICM software searches through all skill groups in the target set and finds the number of agents available for each and the number of agents signed on for each. It then chooses the group with the largest percentage of its agents available. The ACD supporting that group must ultimately choose a specific agent within the group. Using this rule tends to keep all skill groups equally busy.

Maximum Calls in Progress

ICM software first checks that the number of calls in progress for each skill group in the target set is less than a specified value. Then for those groups that pass that condition, it chooses the group with the minimum expected delay. Some customers might use this to limit the number of calls in queue and return a busy signal to keep queues manageable.

Minimum Calls in Queue Per Position

ICM software searches all services in the target set to find the number of calls on hold and the number of stations currently staffed. It chooses the service with the lowest ratio of waiting calls to staffed stations.

Enable Target Requery

Checking this box enables the Router Requery feature. The Router Requery feature provides a mechanism that allows the routing client to requery the router for an alternative label (or labels) in case the destination indicated by the original label is unreachable.

For more information on the Router Requery feature, see the Cisco ICM Software Script Editor Guide.

Formula Editor

In addition to pre-defined routing optimization formulas such as Longest Available Agent (LAA), you can define custom criteria. Essentially any of the hundreds of call and agent metrics can be used to define routing criteria. For example, you can define a formula that filters the list of possible call targets. A second formula can then be applied to select among the remaining targets.

The Formula Editor, shown in Figure 5-9, is used to define the routing criteria in the Select dialog box. It allows you to define sophisticated conditional tests in a point-and click environment.

Figure 5-9 Formula Editor Dialog Box

Expressions

The Formula Editor helps you to build expressions. An expression is a formula made up of variables, constants, operators, and functions. ICM software evaluates an expression to produce a value. You can use expressions to define custom selection rules or distribution criteria in scripts. To build expressions within the Script Editor, you can use variables, operators, and several built-in functions.

Variables

ICM software supports several groups of variables.

Table 5-1 Variable Types 

Entity Type
Description

Application gateway

Real-time statistics about the status of each application gateway.

Call

Information about the current call request such as CallingLineID and DialedNumberString.

Database

Values from an external database record referenced in a DB Lookup node. Also, the variable Available indicates whether a record has been retrieved.

Enterprise Service

Information about an enterprise service. These values are derived by combining fields from the Service_Real_Time table for each member service.

Enterprise Skill Group

Information about an enterprise skill group. These values are derived by combining fields from the Skill_Group_Real_Time table for each member skill group.

Network trunk group

Real-time statistics about specific network trunk groups. These variables are taken from the Network_Trunk_Group_Real_Time table.

Peripheral

Information about a peripheral taken from the Peripheral_Real_Time table. The meanings of most peripheral variables depend on the type of peripheral. The Online variable applies to all peripherals.

Region

Information about a geographical region. The only variable is Name which contains the name of the region as a character string.

Route

Information about a route taken from the Route_Real_Time table.

Schedule

Specific field values from an imported schedule.

Scheduled Target

Real-time statistics for each scheduled target.

Service

Information about a service taken from the Service_Real_Time table.

SkillGroup

Information about a skill group taken from the Skill_Group_Real_Time table.

TrunkGroup

Information about a trunk group taken from the Trunk_Group_Real_Time table.

User

These are variables that you can define. You can associate these variables with objects such as calls, services, or skill groups. Optionally, you can make variables persistent across scripts.


Call Control Variables

The call control variables provide information about the current call request. They include information about where the request came from, call classification information, and information to be passed to the peripheral that receives the call. Table 5-2 summarizes the call control variables.

Table 5-2 Call Control Variables 

Variable
Data Type
Description
Can Be Set

CallerEnteredDigits

String

Digits caller entered in response to prompts.

Via Set node

CallingLineID

String

Billing telephone number of the caller.

No

CustomerProvidedDigits

String

Digits to be passed to the routing client for forwarding to the call recipient.

Via Set node

DialedNumberString

String

Telephone number dialed by the caller.

No

ExpCallVarName

String

Expanded Call Variable value assigned in scripts and passed with call.

Via Set Node

PeripheralVariable1- PeripheralVariable10

String

Value passed to and from the peripheral.

Via Set node

RequeryStatus

Integer

Value that indicates the status of a requery attempt. See the Cisco ICM Software Script Editor Guide for information on the Router Requery feature.

No

RouterCallDay

Integer

An encoded value that indicates the date on which ICM software processes the call.

No

RouterCallKey

Integer

A value that is unique among all calls ICM software has processed since midnight. RouterCallDay and RouterCallKey combine to form a unique call identifier.

No

RoutingClient

String

Name of the routing client that made the route request.

No

UserToUserInfo

String

ISDN private network User to User information.

Via Set node

VruStatus

Integer

Indicates the result of a previous Send To VRU or VRU Script node.

Via Set node


For an Aspect ACD, PeripheralVariable1 through PeripheralVariable5 map to the Aspect variables A through E.

Enterprise Skill Group Variables

Skill group variables are taken from selected variables in the Skill_Group_Real_Time table. The values for enterprise skill group variables are derived by summing values for the individual skill groups that make up the enterprise skill group.

Peripheral Variables

ICM software continuously monitors whether it is in communication with the ACD/PBX systems that it is connected to. If communication with a given location is disrupted, this event can invoke backup routing plans. Peripheral values are taken from the Peripheral_Real_Time table.

Route Variables

Routes let you drill down and observe call performance by individual DNIS number. This "inside" view of a Service can provide insight into the specific types or sources of calls. For example, you can determine if the current surge in call volume is attributable to a certain region of the country, or the result of overflow from another site. Route variables are taken from the Route_Real_Time table.

Service Variables

The service variables that are exposed in the Script Editor include the same performance metrics calculated for routes and some additional variables. Service variables are taken from selected values in the Service_Real_Time table.

Skill Group Variables

In order to implement its skill-based routing capabilities, ICM software tracks a wealth of information regarding agent states. These skill group variables are taken from the Skill_Group_Real_Time table.

Trunk Group Variables

Several metrics of trunk availability are tracked by ICM software. These elements are captured primarily for use in monitoring trunk utilization, but they can also be referenced in call routing formulas.

Operators

Operators allow you to build mathematical and logical expressions. You can use the operators with routing variables to make calculations for a skill group, service, or route. For example, the expression AgentsLoggedOn - AgentsAvail gives the number of agents who are logged on to a skill group, but not currently available.

You can use equality and relational operators to compare two variables. For example, the value of AgentsLoggedOn == AgentsScheduled tells you whether the expected number of agents are currently logged on for a skill group. Or the expression, AgentsLoggedOn < AgentsScheduled is true if a skill group is currently understaffed. On the other hand, the expression AgentsLoggedOn >= AgentsScheduled is true if at least the expected number of agents are logged on.

Table 5-3 lists the operators available in the Script Editor.

Table 5-3 Script Editor Operators 

Operator
Description

+

Positive

-

Negative

!

Logical negation

~

One's complement

*

Multiplication

/

Division

+

Addition

-

Subtraction

==

Equal to

!=

Not equal to

>

Greater than

<

Less than

>=

Greater than or equal to

<=

Less than or equal to

&

Concatenation

&&

And

?

Conditional

&

Concatenation (Misc. Operator)

,

Sequential

<<

Shift left

>>

Shift right

&

And (Bitwise operator)

|

Inclusive Or

^

Exclusive Or


Built-in Functions

ICM software provides a number of built-in functions that you can use in expressions. These functions let you manipulate dates and times, perform standard mathematical operations, and so forth. The following tables summarize the functions according to category. Table 5-4 lists the functions that manipulate dates and times.

Table 5-4 Date and Time Functions

Function
Return Value

Date

Today's date as a number of days

Time

Current time as a fraction of day

Now

Date + Time

Year(date)

Year of the given date

Month(date)

Month (1 - 12) of the given date

Day(date)

Day of month (1 - 31) of the given date

Weekday(date)

Day of week (1 - 7) of the given date

Hour(time)

Hour (0 - 23) of the given time

Minute(time)

Minute (0 - 59) of the given time

Second(time)

Second (0 - 59) of the given time


Table 5-5 lists the mathematical functions.

Table 5-5 Mathematical Functions 

Function
Return Value

Max(n1, n2 [, n3] . . .)

The largest of the operands

Min(n1, n2 [, n3] . . .)

The smallest of the operands

Mod(n1, n2)

Remainder of n1 divided by n2

Random()

Random value between 0 and 1

Sqrt(n)

Square root of n

Trunc(n)

Value of n truncated to an integer

Abs(n)

Absolute value


Table 5-6 lists the remaining functions.

Table 5-6 Miscellaneous Functions  

Function
Data Type
Return Value

after(string1, string2)

String

That portion of string2 following the first occurrence of string1.

before(string1, string2)

String

That portion of string2 that precedes the first occurrence of string1.

ClidInRegion(string)

Logical

Indicates whether the CLID for the current call is in the specified region.

if(condition, true-value, false-value)

Logical

Value of true-value if condition is true; otherwise, false-value.

concatenate(string1, string2, . . . )

String

The concatenation of the arguments.

find(string1, string2 [ , index ] )

Integer

The starting location of the string1 within string2.

left(string, n)

String

Leftmost n characters of string.

len(string)

Integer

Length of string.

mid(string , start, length)

String

Substring of string beginning with start character and continuing for length characters.

result

Numeric

The selected value in a Select node. (valid only in a Select node).

right(string, n)

String

Rightmost n characters of string.

substr(string, start [ , length ] )

String

Substring of string beginning with start character and continuing for length characters.

text(n)

String

String value of n.

valid(variable)

Logical

Whether variable has a valid value.

ValidValue(variable, value)

String

If variable is valid, returns the value of variable; otherwise returns value.

value(string)

Numeric

Numerical value of string.


Distribute Object

The Distribute object, like the Select object, allows you to distribute calls among a set of routing targets using a user-defined condition or an allocation formula that determines the distribution of calls. Figure 5-10 shows an example of a Distribute object.

Figure 5-10 Distribute Object

Two formulas can be defined in the Distribute object:

A Boolean formula that determines whether a specific target is eligible for the distribution. If the value is false, no calls are distributed to that specific target.

An allocation formula that determines how calls are distributed. If the Consider If expression is false for all targets, then the Distribution node fails.

The Distribute rule in Figure 5-11 distributes calls based on the number of active agents, but only to locations that are currently reporting a service level above 85%.

Figure 5-11 Distribute Properties Dialog Box

Percent Allocation Object

The Percent Allocation object distributes calls among several output branches based on percentages (see Figure 5-12).

Figure 5-12 Percent Allocation Object

You specify the percentages through the Percent Allocation dialog box (see Figure 5-13).

Figure 5-13 Percent Allocation Dialog Box

If Object

The If object distributes calls based on a Boolean expression. An If object has two output terminals: True and False. ICM software directs a call down the True branch if it satisfies the Boolean condition; if not, the call follows the False (or fail) branch. Figure 5-14 shows an If object.

Figure 5-14 If Object

The Formula Editor ( Figure 5-15) can define the specific decision criteria.

Figure 5-15 Formula Editor Dialog Box for a Routing Object

Route Select Object

The Route Select object combines the functionality of the Select and Distribute nodes while providing you with the flexibility to set different criteria for each target. The Route Select node does not reference a separate routing target. All target information is contained within the node. Figure 5-16 shows an example of a Route Select object.

Figure 5-16 Route Select Object

The Route Select dialog box allows you to set the targets and rules for selection or distribution. You can choose the target type associated with the object: agent, enterprise service, enterprise skill group, service, or skill group.

External Database Lookup Object

The DB Lookup object queries an external Mircrosoft SQL Server database and uses the data in call routing. In order to use the DB Lookup object, you must have the Gateway SQL feature. Figure 5-17 shows an example of a DB Lookup Object.

Figure 5-17 DB Lookup Object

The DB Lookup object allows your scripts to make precise routing decisions. For example, if you have a database that contains information about your callers, you could perform a database lookup based on Calling Line ID (CLID), Dialed Number (DN), or Caller Entered Digits (CEDs) such as an account number or social security number. The CEDs can be obtained from the network, an ACD, or an IVR system.

A typical DB Lookup application might be to classify callers as premium or mid-tier customers based on their average monthly bills. The call routing script would access the external database and retrieve the row of data that contains the caller's average monthly bill. Based on this information, the script could select an appropriate target for the call. Premium customers would be routed to the best resource available, even if the resource is at another call center site. All other callers would be routed to lower cost agent resources.

Performing database lookups of this kind involves:

Creating and populating an external SQL Server database

Entering information in Configure ICM about the table and the columns you want to reference

In the Script Editor, adding a DB Lookup object to a routing script

In the Script Editor, referencing database columns in the script (for example, in an If object)

The External Database

You can create the external Microsoft SQL Server database using whatever tools you want. The Script_Table Configuration window allows you to add the external database to your ICM configuration ( Figure 5-18).

Figure 5-18 Script_Table Configuration Window

Specifying a Table and Lookup Value

Once the external database is defined, you can create a script that queries a specific row of data from the table. You can then reference columns from that row within the script. To query the database table, you add a DB Lookup object to a script. The Database Lookup dialog box allows you to choose the enterprise name of the table and row you want to query. In the table field, you indicate the enterprise name of the table you want to query. In the Lookup Value, you enter an expression to match the key value in the row you want to retrieve.

Gateway Object

The Gateway object passes call variables to an external application and receives variables in return. This object is part of the Gateway feature. Figure 5-19 shows an example of a Gateway object.

Figure 5-19 Gateway Object

With a Gateway object in your script, you can define the variables that are sent to and received from the application. For example, you might create a routing script in which the Gateway object passes the caller's Calling Line ID to an external application and requests the caller's account number in return. More complex requests might ask for additional account information.

Call and Peripheral Variables

You can pass the following call variables to an external application:

Caller Entered Digits

Calling Line ID

Customer Provided Digits

Dialed Number String

Routing Client

Peripheral Variables 1 through 10

In return, you can request the following variables from the application:

Customer Provided Digits

Peripheral Variables 1 through 10

You define the peripheral variables (1-10) to identify the data you want to be available from the application. For example, Peripheral Variable 1 might represent an account number; Peripheral Variable 2 might represent a date; and so on.

Using Data Returned by the Application

ICM software can base subsequent routing decisions on the results obtained from the application. For example, if the application returned a variable that identified the caller as having a certain type of account, the script could use this information to control where and how the call is routed. Optionally, ICM software can pass any data returned by the application along with the call to an answering resource.

Setting Up an External Application

The Gateway node can query any type of customer application. You need to configure the machine on which the application resides to be able to communicate with the Gateway software. By using the Configure ICM tool, you configure the external application as an Application Gateway. This enables your application to be used by scripts within the ICM system.

Application Gateway Properties Dialog

Within the Script Editor, the Application Gateway Properties dialog allows you to set up the Gateway object. The Send tab allows you to specify the external application to invoke and the data to send to the application.

Figure 5-20 Application Gateway Properties

The Application Gateway Properties dialog box sends Caller Entered Digits, Calling Line ID, and any Customer Provided Digits to an external application called Accounts.

The Receive tab of the Application Gateway Properties dialog box allows you to specify the data you want returned from the application ( Figure 5-21).

Figure 5-21 Receive Tab