cc/td/doc/product/icm/icm46/core
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Target Selection

Target Selection

This chapter describes routing targets and how to use them. It includes:

Introducing Routing Targets

After you have classified a call by call type and, if necessary, performed further segmentation, you select the target to receive the call. You can route a call to either a skill target or a network target.

The following are skill targets:

Within a script, you can use a Select, Distribute, or Route Select node to choose from among a set of skill targets. You can also transfer control directly to a specific target based on numerical allocations or other criteria.

Enterprise services and enterprise skill groups are collections of peripheral targets.

The following are network targets:

Within a script, you can route a call directly to any network target.

Routing a Call Directly to a Target

The simplest way to direct a call to a target is to pass control directly to that target node within a script. When control passes to a target ICM software selects the first member in the target set. The call is then routed to that member. Any other members in the set are ignored.

To set up a target of this type, you first set up a target node that indicates a specific target and route and, then, create a connection directly from an output terminal (success or failure) of any node to the target set.


Figure 4-1:
Service Node


You can use this method at the end of a script after all other efforts to route the call have failed. You might also use it after branching, for example, in an If or Percent Allocation node. However, normally you should rely on a Select node or Distribute node to allocate calls among a set of targets.


Note   Although you would normally not use an enterprise service as a target in this way, ICM software would route the call to the first service listed in the enterprise service. Likewise, if you use an enterprise skill group, ICM software routes the call to the first skill group listed in the enterprise skill group.

Choosing a Target Node

The Script Editor contains several nodes that help you determine the best route for a call:

The sections that follow describe each of these nodes and how to use them.

Select Node

Use the Select node to set up a rule by which ICM software chooses among a set of targets. Rules are based on variables that hold current information about the targets.


Figure 4-2: Sample Select Node


You can select a standard rule or define your own custom rule. You can also specify acceptance criteria with either a standard rule or a custom rule.

In addition, you have two choices for evaluation order:

How to add a Select node

Step 1   Within Script Editor, place the Select object in the workspace.

Step 2   Place a target set object (Service, Skill group, or Agents) in the workspace and create a connection from the Select node's success terminal.

Step 3   Right-click to open the Select Properties dialog box.

Step 4   Specify the following:

Step 5   Optionally, enable target requery. See Router Requery for additional information.

Step 6   Optionally, modify the Comments tab.

Step 7   Optionally, modify the Labels tab.

Step 8   Click OK to apply changes and to close the dialog box.


Standard Selection Rules

Table 4-1 describes the standard selection rules.


Note   Any rule that applies to skill groups can also apply to enterprise skill groups. Any rule that applies to services can also apply to enterprise services.


Table 4-1: Table Selection Rules
Rule Targets What ICM Software Does Comments

Longest Available Agent (LAA)

Skill groups

Considers if: *.AgentsAvail > 0

Evaluates: MAX (*.LongestAvailable)

For each target in the set with available agents, finds the longest time an agent at that target has been continuously available.

Chooses the target with the agent who has been available for the longest time.

This rule helps to ensure that all agents in the set are kept equally busy. However, it does not ensure that a specific agent receives the call.

Next Available Agent (NAA)

Skill groups

Considers if: *.AgentsAvail > 0

Evaluates: MAX (*.AgentsAvail / *.AgentsSignedOn)

For each target in the set, finds the number of agents available and the number of agents signed on.

Chooses the target with the largest percentage of agents available.

This rule tends to keep all targets equally busy.

Minimum Average Speed Answer (Min ASA)

Services

Evaluates: MIN (*.AvgSpeedAnswerTo5)

For each target in the group, finds the target that is, on average, answering calls more quickly.

This rule depends on an average.

Consider using another rule, such as Minimum Expected Delay.

Minimum Calls in Queue Per Position (Min C/Q)

Services

Evaluates: MIN (*.CallsQNow / *.AgentsReady)

For each target in the group, finds the number of calls on hold and the number of stations currently staffed.

Chooses the target with the lowest ratio of calls waiting to staffed stations.

This rule calculates the shortest average hold times if agents are equally efficient at each target. However, if the staff for one target is more efficient than another, then some callers might wait longer than necessary at the less efficient target.

It might be more efficient to have more calls queued at the more efficient target. Also, if one target tends to handle calls that take longer to process, consider directing callers to another target or another rule, such as Minimum Expected Delay.

Minimum Average Queue Delay (Min AvgQD)

Services

Evaluates: MIN (*.AvgDelayQTo5)

Determines the average time callers spent on hold before reaching an agent. Choose the target with the lowest average.

This rule depends on an average. Consider using another rule, such as Minimum Expected Delay.

Minimum Longest Delayed Call (Min Delay)

Services

Evaluates: MIN (*.LongestCallQ)

For each target, finds the longest time that a call has currently been on hold waiting for an agent. Chooses the target with the lowest value.

This rule depends on an average. Under heavy call volume, many calls might be routed to a specific service before the longest delayed call value changes. Consider using Minimum Expected Delay instead.

Minimum Expected Delay (MED)

Services

Evaluates: MIN (*.ExpectedDelay)

For each target, determines the target where the shortest delay is expected. In making this determination, ICM software considers the average handle time, the number of calls in queue, and the number of positions staffed.

By combining current information about calls in queue and staffing levels with historical averages, this rule avoids the potential problems that purely historical rules can cause. This rule is usually the most effective for keeping queue times to a minimum.

Maximum Calls in Progress (Max C/P)

Skill groups

Not implemented.

Not implemented.

Always Select (Always)

Any target

Chooses the first target that passes the acceptance rule specified.

You can set the evaluation order to create a homing hunt (chooses either the first target every time) or a rotary hunt (rotates to the next target each time).


Warning Values used by the Minimum Average Speed Answer, Minimum Average Queue Delay, and Minimum Longest Delayed Call rules change slowly. Since the averages in these rules only consider what has happened in the past rather than what is currently happening, using these rules inappropriately can lead to load imbalances as newly routed calls have little immediate effect on the values used to route later calls. On the other hand, the Minimum Expected Delay rule takes into account each call as it is routed. Selecting the service with the Minimum Expected Delay usually provides the best balance among the services.

Custom Selection Rules

Instead of using the Standard field in the Select dialog box to choose one of the predefined selection rules, you can use the Custom field to set up your own selection criteria.

A Custom selection rule consists of two expressions that correspond to the two phases of selection:

You can also use the Accept If field with a custom rule to set up an acceptance rule that must be true for the target to be accepted. If the Accept If rule is not true for the target chosen by the Select formula, then the effect is the same as if no target was selected.

You can set up a rotary or homing hunt by setting the Selection rule to *.Avail>0. The evaluation order you choose determines the type of hunt: rotary (Start With Next Target) or homing (Start With First Target). If only one target meets the Consider If criteria, that target is chosen regardless of the evaluation order. However, if more than one target meets the criteria, then the evaluation order determines which of those targets is chosen.


Note   For more information on expressions and the formula editor, see "Formulas".

Distribute Node

The Distribute node allocates calls among the targets in a set based on current information about each target. For example, if you want to distribute calls among a set of services based on the number of agents in the Ready state for each service, services with more Ready agents would get more calls and services with fewer Ready agents would get fewer calls. This keeps the load balanced even as the number of agents logged on and ready varies through shift changes and other activities.


Figure 4-3: Distribute Node


With the Distribute node, you can specify consideration and distribution formulas. The success terminal of the Distribute node connects to a target set, which can be an Agent, Skill Group, Service, Enterprise Skill Group, or Enterprise Service set. If ICM software evaluates the Distribute node's "Consider If" formula to false, no calls are distributed to that target set.


Note   For information about the formulas you can specify for each type of target, see "Formulas".

How to add a Distribute node

Step 1   Within Script Editor, place the Distribute object in the workspace and open the Distribute Properties dialog box.

Step 2   Specify the following:

Step 3   Optionally, modify the Comments tab.

Step 4   Optionally, modify the Labels tab.

Step 5   Click OK to apply changes and to close the dialog box.


Route Select Node

The Route Select node combines the functionality of the Select and Distribute nodes while providing you with the flexibility to set different criteria for each target. With the Route Select node, you do not need to include a separate routing target node in the script; all target information is contained within the node.


Figure 4-4: Route Select Node


A Select rule in the Route Select node can reference other targets. In the example shown below in Figure 4-5, the Target type is Services, but some Select rules reference skill group data.


Figure 4-5: Example of a Route Select Dialog Box


As you set up or modify values in Route Select node, be aware of the following:

How to add a Route Select node

Step 1   Within Script Editor, place the Route Select object in the workspace, and right-click to open the Route Select Properties dialog box.

Step 2   Click the Change button in the Route Select Type section of the dialog box. The Route Select Type dialog box appears.

Step 3   Select a Target Type (Agent, Enterprise Service, Enterprise Skill Group, Service, or Skill Group).

Step 4   Optionally, select a Business Entity and an Enterprise Target.

Step 5   Specify whether the Route Select node is to act like a Select node or a Distribute node:

Step 6   Specify a Target Reference setting:

Step 7   Click OK to close the Route Select Type dialog box. The label in the Route Select Type section and column names in the Target Type section of the Properties dialog box reflect your changes.

Step 8   Click the Add Targets button. The Add Targets dialog box appears, listing available options for the target type you specified in the Route Select dialog box.

Step 9   Use the Available targets list and the Add button to select targets.

Step 10   Click OK to close the Add dialog box. The target members you selected appear in the Route Select Properties dialog box.

Step 11   Continue defining Target Type information for each target member:

Step 12   Optionally, enable target requery. See Router Requery for additional information.

Step 13   Optionally, click the Validate button to check the integrity of the table. (For more information on validation, see "Script Editor Overview".)

Step 14   Optionally, modify the Labels tab.

Step 15   Click OK to apply changes and to close the Route Select Properties dialog box.


Percent Allocation

The Percent Allocation node lets you send a specific percentage of route requests to two or more paths within the script. Each path might lead directly to a target, or you can perform additional processing on one or more paths.


Figure 4-6: Percent Allocation Node


The Percent Allocation node never fails. Each routing request is sent to one of the branches. In the example above, 10% of calls are sent directly to a target in Boston, another 5% are sent directly to a target in Chicago, and the remaining 85% are distributed among a group of targets.


Note   If you use a Percent Allocation node to allocate calls among several targets, you lose much of the benefit of call-by-call routing. Usually, it is better to use a Select node or Distribute node to choose among peripheral targets based on real-time conditions at the call centers. Using a Percent Allocation node to distribute calls among targets can result in imbalances.

How to add a Percent Allocation node

Step 1   Within Script Editor, place the Percent Allocation object into the workspace and set up its target connections.

Step 2   Right-click to open the% Allocation Properties dialog box. The top part of the dialog box displays a column for each output branch, initially assigning a label (A, B, C, etc.) to each branch.

Step 3   To rename an output branch column, select the column name in the Connections field and click the Modify Label button. The label name becomes highlighted and you can make changes.

Step 4   To add a percentage for each connection, click the Modify Percentage button. The percentage value becomes highlighted and you can make changes. (The percentages for all labels must total 100.)


Warning If you ever delete a connection associated with a case, the case information you specified in the Properties dialog box is also deleted.

Step 5   Optionally, modify the Comments tab.

Step 6   Optionally, modify the Labels tab.

Step 7   Click OK to apply changes and to close the dialog box.


Skill Targets

A skill routing target object specifies a target at a peripheral to receive a call. You use Select or Distribute nodes to reference such targets.

There are two categories of skill targets:

After you choose the targets you want to route to, you can then use the Move buttons (up- and down-arrows) on the right side of the dialog box to rearrange the skill groups in the target.


Figure 4-7: Move Buttons in Routing Target Dialog


You must also set a route (and optionally a translation route) for each target within the set.

If you specify a translation route, the call is sent to that route first. The Peripheral Gateway associated with that peripheral then retrieves the final route from ICM software. In the meantime, the Peripheral Gateway can coordinate with an external host to perform other processing associated with the call. (For example, the external host might search a database of customer data and send information to the display of the agent that answers the call.)


Note   For information on defining routes and associating them with specific targets, see the Cisco ICM Software Configuration Guide.

Defining Skill Targets

The procedure for creating peripheral-level and enterprise-level skill targets is identical.

How to add a skill target

Step 1   Within Script Editor, place a peripheral-level object (Agent, Agent To Agent, Skill Group, or Services) or an enterprise-level object (Enterprise Skill Group or Enterprise Services) into the workspace and right-click to open the Properties dialog box. (The following Properties dialog box is for a Skill Groups target.)


Step 2   Click the Add Targets button. The Add Skill Groups Targets dialog box appears.


The field on the left lists all the defined services; the field on the right lists those services currently assigned to this target.

Step 3   Select a value from the Available Targets list and click the Add button. Repeat this until all the skill groups you require appear in the Add Targets list.

Step 4   Click OK to add the changes to the Skill Group Properties dialog box.

Step 5   Optionally, rearrange the order of the groups in the list using the Move arrow keys.

Step 6   Click a target group member and use the drop-down list in the Route field to associate a route with the target.

Step 7   Optionally, click a target group member and use the drop-down list in the Translation Route field to associate a translation route with the target.

Step 8   Optionally, modify the Labels tab.

Step 9   Click OK to apply changes and to close the dialog box.


Connections from Targets

Normally, once the script locates a valid target, it returns the route for that target and ends execution. However, you might want to do some processing after the target has been chosen. Usually, this processing is limited to setting variables that are dependent on the target chosen.

To set up additional processing from a skill target, check the Allow Connection For Each Target option in the Routing Target tab of the Properties dialog box. (This option is also available in the Route Select dialog box.)

When this option is checked, an output terminal appears for each element in the routing target.


Figure 4-8: Multiple Output Terminals


You can connect one or more elements of the target to additional nodes. After the script processes these nodes, it returns the route for the chosen target as usual.

If you deselect the Allow Connection For Each Target option for a target object, all connections from that target, and their associated nodes, are deleted.


Note   This capability is disabled if the target requery function is enabled. See Router Requery 4-21 for additional information.

Router Requery

Introduction

The Router Requery feature addresses routing failures due to transient failures in the network (such as network congestion). This feature allows the routing client (a Network Interface Controller (NIC) or a Peripheral Gateway (PG)) to interact with the ICM software CallRouter (router) to determine the appropriate destination for a call. If this destination is available, but not reachable, the Router Requery feature then comes into play to get the call routed. This feature works in the NICM/CICM environment as well.

The requery of the node is intended to cover the following cases:

The routing algorithms are changed on a per call basis, that is, the routing information for one call does not affect the state for other calls. If the first target selected for the call was not reachable, the target is not eliminated from the potential routing destinations for other calls.

Overview

In the ICM software system, when queried, the router returns a destination label to the routing client. The routing client then routes the call to the destination specified by the label. If the destination is not reachable (i.e., busy signal or no answer), the call is default routed.

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.

Since this feature is supported through the router, it is not only compatible with translation routing, but does not require special treatment for different failure cases (busy, no answer, route select failure, etc.). However, there are applications (such as Enterprise Agent) where it is important to distinguish between these cases.

Functional Implementation

The Router Requery feature is implemented using the Label, Queue, RouteSelect, and Select nodes. These script nodes have been modified for this purpose.

If the first choice fails in the network, call processing returns to pick the label corresponding to the second choice in the node.

The router uses the SERVICE_DIVERT_ON_BUSY service type for calls that use requery. The Event Select in the connect message includes a REROUTE_REQUESTED_MASK. When a destination cannot be reached, the NIC queries the router for an alternative destination label.

The call dialog between the routing client and the router continues until either the routing client makes a successful connection; or the router exhausts all possible labels and the failure path for the script node is taken.

In the event of a failure, you can handle requerying in the scripting environment, as you deem appropriate.

The RequeryStatus Variable

You now have the ability to test the error path of these script nodes to determine the specific network cause of failure and conditionally retry the attempt as necessary. This is done using an If node to check the value of the Call variable RequeryStatus. The decision path for the script is then determined by the value of the RequeryStatus variable.

The following are possible values for the RequeryStatus variable:

Router internal use. Script ends and the call was successfully sent to the chosen target. Not visible to users.

Routing client generated error code from ReRouteReq msg indicating a Route Select failure

Routing client generated error code from ReRouteReq msg indicating the called party is busy

Routing client generated error code from ReRouteReq msg indicating no answer

Router generated error code. The attempt to send the call to target failed because the target was not reachable (i.e., busy, ring no answer).

Router internal use. Script ends. The attempt to send the call to target failed because the Routing Client did not respond within the DivertOnBusyCallTimeout period. Not visible to users.

Router internal use. Script ends. The attempt to send the call to target failed because the caller hung up or the call was lost. Not visible to users.

In the case of ABANDON and DISCONNECT, the router assumes the call has ended and ends the script. The RequeryStatus value is set to 6, indicating REQUERY_ABORTED. This is used for the internal workings of the router but is not visible to users.

Label, Queue, Route Select, Select, and Script Target Nodes

The execution logic in Label, Queue, Route Select, and Select nodes has been modified so that the router can use it for requery scenarios. Skill Groups, Services or Enterprise Agents can be the targets for these nodes. The RequeryStatus flag indicates the error condition as described in The RequeryStatus Variable. The minor differences as to how various targets are handled are discussed in the following sections.

Label Node

The label from the Label node is returned to the routing client, and in cases where this label is not accessible, the re-route consists of the Label node failure path.

If Router Requery is enabled, the Label node failure path is available and visible.

If Router Requery is disabled, the Label node failure path is not available and hidden.

Queue Node

The calls in the queue node are sent to the first available target. If the target is not accessible, the router takes the failure path for the Queue node. The script handles the failure path so you can treat the failure path as you wish (i.e., re-queue the call in the same VRU, or sends it to a different target).

Route Select and Select Nodes

Skill Groups and Services

These targets can have multiple labels or multiple routes to reach the destination. The router sends up to 9 labels for the selected target. It picks the first 9 labels found. If the routing client determines that the target is not reachable using any of the provided labels, the routing client sends a REROUTE_REQ to the router.

The router then picks the next target in the target list and sends up to 9 labels for the new target. If the second target is also unreachable, the routing client sends another REROUTE_REQ and the router takes the failure path on script node.

Enterprise Agent (EA)

If the first target is not reachable, the routing client sends a REROUTE_REQ request. The router then uses the second available agent in the list.

If the second agent is not reachable and if both agents were on the same peripheral, a third agent from a different peripheral is chosen as last try.

If the third agent is also unreachable, the router then uses the failure path of the script node.

The EA PG marks an agent "Not Ready" when the agent is not reachable.

Graphical User Interface Modifications

The Script Editor Label, Queue, Route Select, and Select nodes have been modified to provide an option to enable or disable the requery feature.

The RequeryStatus Call variable is available and the value for this variable can be tested at the failure node of the script nodes to see if a requery attempt failed.

The RouteSelect and Target nodes have a property called "Allow connections for each target". This property provides an external connection to other nodes for each target. The requery feature is valid only for nodes with this property disabled so the targets have no continuing connections.


Note   The requery feature and use of connections to other nodes are mutually exclusive. If requery is enabled, the targets must not be connected to other script nodes. Script Editor prevents you from creating a target node with outgoing connections and requery enabled. If such situation is found the script validation will fail with an Error.

Network Targets

The Script Editor contains several network target nodes:

A network target terminates execution of the script and returns an appropriate label to the routing client.

Announcement Node

When ICM software executes an Announcement node, the script terminates and ICM software returns the label associated with the announcement to the routing client. The routing client then plays a network announcement for the caller.


Figure 4-9: Announcement Node


You might use an announcement node to:

How to add an Announcement node

Step 1   Within Script Editor, place the Announcement object in the workspace and right-click to open the Announcement Properties dialog box. The Announcement selection list contains all announcements that are currently configured in the system.

Step 2   Choose the announcement you want to play. If available, descriptive text about the announcement appears in the bottom field of the dialog box.

Step 3   Optionally, modify the Comments tab.

Step 4   Click OK to apply changes and to close the dialog box.


Scheduled Targets

A scheduled target is a destination that can handle a specific number of simultaneous calls based on a periodic schedule. ICM software keeps track of the schedule and the number of calls it sends to the target. The routing client informs ICM software when a call at the target ends. Therefore, ICM software always knows how many calls are currently in progress at the target and whether it can handle an additional call.


Figure 4-10: Scheduled Select Node



Note   Not all routing clients support the Scheduled Select node.

When ICM software executes a Scheduled Select node, it searches the list of selected targets to find one that is capable of handling the call, based on its current schedule.

If a suitable target is found, the routing script ends and returns a label associated with that target to the routing client. The routing client then translates the label to a peripheral target.


Note   Before you can use a Schedule Select node in a script, it must first be configured and assigned a label through the Configuration Manager. For more information, see the Cisco ICM Software Configuration Guide.

How to add a Scheduled Select node

Step 1   Within Script Editor, place the Scheduled Select object in the workspace and right-click to open the Scheduled Select dialog box. The list on the left of the dialog box lists all the scheduled targets currently configured in the system.

Step 2   Use the Evaluation Order radio buttons to specify whether ICM software:

Step 3   Select a value from the Available Scheduled Target list and click the Add button. The target moves to the Selected Targets list.

Step 4   Optionally, modify the Labels tab.

Step 5   Click OK to apply changes and to close the dialog box.


Busy and Ring Nodes

When ICM software executes a Busy node, it finds the first Busy label configured for the current routing client and returns that label. The routing client then plays a busy signal for the caller.


Figure 4-11: Busy Node



Note   Not all routing clients support the Busy and Ring nodes.

Likewise, when ICM software executes a Ring node, it finds the first Ring label for the routing client and returns that label. The routing client then plays an unanswered ring for the caller.


Figure 4-12: Ring Node



Note   If you use a Busy or Ring node, you must ensure that you have defined a label of the Busy or Ring type for the routing client. (This procedure is described in the Label Node section below.)

How to add a Busy or Ring node

Within Script Editor, place the Busy or Ring object in the workspace and open the Properties dialog box.


Note   There are no properties that need to be set for the Busy or Ring nodes. However, you can use this dialog box to create text that will display on the nodes in the Script Editor.

Label Node

Use the Label node to specify a set of valid labels that can be returned to the routing client.


Figure 4-13: Label Node


When ICM software executes a Label node, it chooses the first valid label for the current routing client.


Note   This differs from the Divert Label node, which returns all the values in the Selected Labels list to the routing client.

If it finds no valid label, ICM software returns the default label for the dialed number. In either case, the Label node terminates execution of the script.

The Label Properties dialog box displays information about the configured labels in the system. Configured labels are static, defined through the Configuration Manager. A second label type, dynamic labels, is also available. Dynamic labels are expressions the CallRouter processes "on the fly," converting an expression into a character string that is then returned to the routing client as a label.

The dialog box contains two tree structures:

Finally, the Label Information section of the dialog box displays detailed information about the currently selected value in this list.

How to add a Label node

Step 1   Within Script Editor, place the Label object in the workspace and right-click to open the Label Properties dialog box.

Step 2   To assign a configured label to this node, do the following:

Step 3   To assign a dynamic label to this node, do the following:

Step 4   Optionally, enable target requery. See Router Requery for additional information.

Step 5   Optionally, modify the Comments tab.

Step 6   Click OK to apply changes and to close the dialog box.


Divert Label Node

Use the Divert Label node to specify a set of valid labels that can be returned to the routing client.


Figure 4-14:
Divert Label Node


When ICM software executes a Divert Label node, it returns all the values in the Selected Labels list to the routing client.


Note   This differs from the Label node, which returns the first valid label for the current routing client.

ICM software then tries each label until it finds one that does not produce a Busy or Ring Tone No Response.

In most cases, you can specify up to ten labels in the Divert Label node. The exception is in NAM/CICM configurations, where you can specify up to nine labels; one label must be reserved for use by the NAM.


Note   This node is not available for all routing clients.


Figure 4-15:
Divert Label Properties Dialog Box



Note   Figure 4-15 shows a Divert Label Properties dialog box displaying information about the configured labels in the system. A second label type, dynamic labels, is also available. Dynamic labels are expressions the CallRouter processes "on the fly," converting the expression into a character string that is then returned to the routing client as a label.

The dialog box contains two tree structures:

Finally, the Label Information section displays detailed information about the currently selected value in this list.

How to add a Divert Label node

Step 1   Within Script Editor, place the Divert Label object in the workspace and right-click to open the Divert Label Properties dialog box, shown in
Figure 4-15. To assign a configured label to this node, do the following:

Step 2   To assign dynamic labels to this node, do the following:

Step 3   Optionally, modify the Comments tab.

Step 4   To add a label to the list for this node, select the label in the Available Labels list and click the Add button.

Step 5   Optionally, modify the Comments tab.

Step 6   Click OK to apply changes and to close the dialog box.


Script Termination Nodes

The Script Editor also contains some nodes that specifically address script termination:

The sections that follow describe each of these nodes and how to use them.

End Node

The End node marks a termination point within a script.


Figure 4-16: End Node


If the script reaches this point, it has failed to find a target for the call and ICM software then uses the default route for the dialed number.

Several End nodes can appear in the same script. The End node is never required; a script can terminate with any node.

How to add an End node

Within Script Editor, place the End object in the workspace and open the Properties dialog box.


Note   There are no properties that need to set for the End node. However, you can use this dialog box to create text that will display on the node in the Script Editor.

Termination Node

A Termination node ends a script and specifies how to handle a call. It includes options to invoke a default call processing action or route for the dialed number.


Figure 4-17: Termination Node


How to add a Termination node

Step 1   Within Script Editor, place the Termination object in the workspace and open the Properties dialog box.

Step 2   Select a termination type:

Step 3   Optionally, modify the Comments tab.

Step 4   Click OK to apply changes and to close the dialog box.


Release Call Node

A Release Call node terminates execution of the current routing script and disconnects the caller.


Figure 4-18: Release Call Node


You can use a Release Call node in situations where the caller needs no further service after executing several IVR scripts.

How to add a Release Call node

Within Script Editor, place the Release Call object in the workspace and open the Properties dialog box.


Note   There are no properties that need to be set for the Release Call node. However, you can use this dialog box to create text that will display on the node in the Script Editor.

Checking Targets

Use the Call Tracer tool to confirm that ICM software is selecting targets as you expect.

The Call Tracer sends routing requests to ICM software and reports on the response. When the Call Tracer sends a request, it reports the script and the specific nodes that the software executes. It also indicates the skill target to which ICM software routes the call.

Figure 4-19 shows some sample results from the Call Tracer.


Figure 4-19: Call Tracer Results Example, Version 1 =========================================================== > DialedNumber (8005551212) using CallType (General_Sales - 6) Start #3   Sales\Sales__General (version 2) Percent allocation #54   *42% = 0   16% = 0   42% = 0 Target #64   Service: Scranton.Sales R Route: Scranton.Sales Peripheral target: DNIS: 1111, Trunk group: Scranton.Incoming800 Label: 2010000000 ===========================================================

In Figure 4-19, ICM software invokes a script called sales. It begins with the Start node and then executes a Percent Allocation node that has three branches allocated for 42%, 16%, and 42%, respectively. The asterisk indicates that for this call ICM software choose the first branch. This branch leads to a target that maps to the service Scranton.Sales. Had this been an actual call, the call would have been delivered to that service.

As you continue to send calls to ICM software, the numbers for each node change to indicate how calls have been distributed. Each time a call arrives at a Percent Allocation node, ICM software calculates the percentage of calls previously sent to each branch.


Figure 4-20:
Call Tracer Results Example, Version 2 =========================================================== > DialedNumber (8005551212) using CallType (General_Sales - 6)
Start #3
  Sales\Sales__General (version 2)
Percent allocation #54
  42% = 0.416667
  16% = 0.166667
  *42% = 0.375
Target #58
  Service: Gary.Sales
Route: Gary.Sales
Peripheral target: DNIS: 1111, Trunk group: Gary.Incoming800
Label: 3010000000
===========================================================

In Figure 4-20, the new call is counted in the denominator for each branch, but not in the numerator. Therefore, the numbers add up to less than 1.0 (but the total gradually approaches 1.0 as you send more calls). ICM software then picks the branch that is most below its allocation value. In this example, ICM software picked the third branch (because 0.375 is well below the allocation of 42% or 0.42) and would send the call to the Gary.Sales service.

The Call Tracer results refer to script nodes by their internal integer identifiers. To find which node maps to each identifier, open the script and choose Display Node IDs from the Script menu.

How to trace calls

Step 1   Start the Call Tracer from the ICM Admin Workstation group. The Call Tracer main window appears.

Step 2   Select Trace > Connect. The Call Tracer attempts to establish a connection to a CallRouter and Distributor Admin Workstation. If successful, it then loads the configuration data from the Admin Workstation's local database. Once the configuration is loaded, you can begin tracing a call.

Step 3   In the Call Tracer window, choose a Routing Client and a Dialed Number.

Step 4   Optionally, enter an ANI (caller's telephone number).

Step 5   If you want to test a response from a IVR/VRU routing script, enter values in CED (caller-entered digits) and VRU Responses for Run Script. (For more information see, How to check VRU scripts with the Call Tracer.)

Step 6   If you want to test a Network Transfer call target, click the Use Network Transfer box and then choose a routing client and a dialed number value.

Step 7   Click the Send Call button to submit the request. The results appear in the Call Trace Results field.

Step 8   To send additional calls, optionally change any of the call parameters and then click the Send Call button again. The Call Trace Results field is updated.

The dialog box below shows an example of a Call Tracer dialog box displaying results.


Step 9   Optionally, select File > Save Trace to save the Call Tracer results.

Step 10   To exit the Call Tracer, choose File > Exit.


Checking IVR/VRU scripts

The Call Tracer allows you to simulate responses from IVR/VRU routing scripts. For each Script node ICM software encounters, you can specify one of the following responses:

How to check VRU scripts with the Call Tracer

Step 1   In the Call Tracer dialog box, click the Add button. The VRU Response dialog box appears.

Step 2   Select the type of response (Fail, No Response, Response) the Call Tracer should simulate.

Step 3   If you chose Response in Step 2, optionally specify values to be returned for CED and Variable1 through Variable10.

Step 4   Click OK to apply changes and close the dialog box.



hometocprevnextglossaryfeedbacksearchhelp
Posted: Tue Jun 25 08:26:03 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.