With the ECE integrated with the Unified ICM, the Unified ICM can route chat requests.

The process for routing Web requests through the Unified ICM can be divided into 5 parts, as shown in the following image:

Enterprise Chat and Email can take advantage of the following types of Media Routing Domains (MRDs):

• Non-voice MRDs

• Voice MRD

For more information about MRDs, see the Administration Guide for Cisco Unified Contact Center Enterprise.

The Enterprise Chat and Email uses Non-voice MRDs for chat requests.

The Voice MRD handles these types of requests:

• Blended chat with legacy ACDs (these are requests for chat, but with agent reservation on the ACD)

• Web callback and delayed callback with both ACDs and Unified CCE

The following script example shows how a Web request can be queued to a skill group:

In this example:

1. This script is scheduled to run for web chat requests. For more information about call types and scheduling Web requests routing scripts, see Example - How Unified ICM Determines the Call Type for Web Request.

2. The script queues the request to a chat skill group. At this time, Unified ICM attempts to find an available agent who is a member of that skill group. When the agent is found, the system software returns the agent ID to the Cisco Interaction Manager.

3. The script is run and the Enterprise Chat and Email processes a new chat request. This script is scheduled to run for chat requests.

4. The script queues the request to a chat skill group. At this time, the Unified ICM attempts to find an available agent who is a member of that skill group. When the agent is found, the Unified ICM returns the agent ID to the Enterprise Chat and Email.

The following script example shows how a script can push a URL to a waiting caller before the Web request is queued to a skill group:

In this example, the Run External Script node pushes the selected URL to the caller's browser.

Note	For the Run External Script node to work, there must be an entry in the Network VRU list pointing to the URL map file. After the Run External Script node, the script functions just as the preceding example.

The following script example shows how you can queue a Web request directly to an agent:

In this example:

1. You can schedule this script to run for a particular type of request.

2. The script attempts to queue the request directly to an agent using the Queue to Agent node. The Queue to Agent node uses a direct reference to the agent, as shown in its Properties dialog box:

   

3. The script tries to do this for 600 seconds before ending, as defined in the Wait node.

The following script example shows how you can queue Web requests from different MRDs to different skill groups:

In this example:

1. The script is run to process a chat request. This script is scheduled to run for all these types of requests.

2. The script first detects the MRD of the request using the Media Routing Domain node. This node has two branches for the MRDs of the request: the email MRD (branch A) or chat MRD (branch B).

3. The script queues the request to the appropriate skill group for that type of request. At this time, the Unified ICM attempts to find an available agent who is a member of that skill group. When the agent is found, the system software returns the agent ID to the Cisco Interaction Manager.

When theECE is in an integrated environment, the administrator can choose to defer message assignment to Unified ICM. The administrator determines if skill groups can initiate message routing through the system software when the skill groups are created. The administrator then defines rules to assign messages to those Unified ICM Routing skill groups.

In this situation:

1. A message enters the ECE.

2. A rule assigns the message to a Unified ICM Routing skill group.

3. ECE sends a request for assignment to Unified ICM.

   Note	In a Unified ICM integrated with the ECE, the allowed responses for an invoked route request are: Return an Agent, Return a Label, or Failure (the script could not be found or something is wrong). The ECE deals with this by placing the e-mail message into the externalRoutingError system queue.

4. The Router runs a routing script to determine which ECE agent to assign the message to. The routing script can also determine that the message should be assigned to a local ECE routing skill group.

   Note	To assign a message directly to an agent, the Unified ICM script must use the Queue to Agent node to route e-mail messages, not the Agent node.

   Note

   While the system software can assign a message directly to a local ECE routing skill group, you would not typically design a script to do this without first trying to queue the message to a skill group or directly to an agent. If the message, based on its content, is meant to be assigned to a local ECE routing skill group, you could make that assignment directly through ECE rules, and not use the software.

5. Based on the routing script's determination, the Unified ICM instructs the ECE to assign the message to a particular agent or ECE routing skill group.

6. The message is placed in the agent's or skill group's queue.

7. If the message is assigned to an agent by the Unified ICM, it is presented to the agent in push mode; if the message is assigned to an ECE routing skill group, it is placed in that skill group's queue.

The following script example shows how an e-mail message can be queued to a skill group:

In this example:

1. The script is run when a e-mail message is assigned to a Unified ICM Routing skill group. This script is scheduled to run for messages assigned to that skill group. For more information about call types and scheduling e-mail routing scripts, see Example - How Unified ICM Determines the Call Type for an E-Mail contact.

2. The script queues the request to the skill group. At this time, the Unified ICM attempts to find an available agent who is a member of that skill group. When the agent is found, the system software instructs the Enterprise Chat and Email to push the e-mail message to that agent, so the agent can respond to the customer.

3. If no agent is found within 30 seconds, as defined in the Wait node, the script uses the Label node to return a label associated with the Enterprise Chat and Email local skill group. The Enterprise Chat and Email then places the message in that local skill group. Enterprise Chat and Email load balances the e-mail assignments to the available agent, based on load balancing.

Note

The ICM wait node can be used to keep the email in the queue when the agent is not available (for example, during a weekend) by setting the wait node to a high value such as 172800 seconds (48 hours). The maximum time that an activity can remain in the ICM queue is determined by the MRD setting "Max time in queue". By default, this setting is blank for all MRDs and the setting defined in the router registry is used.

The following script example shows how you can queue an e-mail message directly to an agent or to a skill group, depending on the message's priority:

In this example:

1. The script is run when a e-mail message is assigned by the Enterprise Chat and Email to a Unified ICM Routing skill group. This script is scheduled to run for messages in that skill group. For more information on call types and scheduling e-mail routing scripts, see Example - How Unified ICM Determines the Call Type for an E-Mail Contact.

2. The script tests the message's priority, the value of the cisco.ece.Priority variable. For more information, see Data for E-Mail Requests.

3. If the message is marked "Urgent" (cisco.ece.Priority value of 3), control passes to the Queue to Agent node. That node lists two agents who are e-mail supervisors and who handle urgent messages. The Enterprise Chat and Email then pushes the message to the first of these agents who is logged in.

4. If the message is not urgent, control passes to the Queue to Skill Group node. The Unified ICM attempts to find an available agent who is a member of that skill group. When the agent is found, the Unified ICM instructs the Enterprise Chat and Email to push the e-mail message to that agent.

5. If no agent is found within 30 seconds, in either the Queue to Agent node or Queue to Skill Group node, as defined in the Wait node, the script uses the Label node to return a label associated with a Enterprise Chat and Email local skill group. The Enterprise Chat and Email then places the message in that local skill group. The message is not pushed to an agent; rather, it waits in the local skill group queue for an agent to pick it.

Note

These Expanded Call Context (ECC) variables are optional. Before you use these ECC variables, configure them in Unified CCE and ECE. To configure these ECC variables in Configuration Manager's Expanded Call Variable List Tool, see the Configuration Guide for Cisco Unified ICM/Contact Center Enterpriseat https://www.cisco.com/c/en/us/support/customer-collaboration/unified-contact-center-enterprise/products-installation-and-configuration-guides-list.html. To configure these ECC variables in ECE, see at https://www.cisco.com/c/en/us/support/customer-collaboration/cisco-enterprise-chat-email/products-maintenance-guides-list.html.

The following script example shows how you can use a single script to route a push request or a pick or pull request using an IF node:

In this example:

1. The script is run when the Enterprise Chat and Email assigns an email message to a Unified ICM Routing Skill Group.

2. The script checks whether the service requested is one of the Pick or Pull service type using the builtin function – isPickPullRequest(). The success branch of IF node connects to Pick/Pull node and the failure branch connects to a queue node, which can be either a Queue to Skill Group node or Precision Queue node.

3. If the IF node evaluates to False, control passes to path of Push routing. The script queues the request to the skill group. At this time, the Unified ICM attempts to find an available agent who is a member of that skill group. When an agent is found, the system software instructs the Enterprise Chat and Email to push the e-mail message to that agent, so the agent can respond to the customer.

4. If no agent found within 30 seconds, as defined in the Wait node, the script uses the Label node to return a label associated with the Enterprise Chat and Email local skill group. The Enterprise Chat and Email then places the message in that local skill group. Enterprise Chat and Email load balances the e-mail assignments to the available agent, based on load balancing.

5. If the IF node evaluates to True, control passes to Pick / Pull routing. Based on the pick or pull service requested, the request will be handled in the Pick/Pull node.

6. Pick / Pull node can be used directly without an IF node which is shown in the example. In such case, the failure path can be used for Push routing. In addition, the reason for the failure through the Pick / Pull node is captured in the VRUStatus variable which can be set in one of the peripheral variables to be captured in the Route Call Detail record.

The following script example shows how contacts from different channels can be routed to the Longest Available Agents in skill groups that are specific to the different channels:

You schedule this script to run for Call Types associated with contacts from the different channels. The script then selects the Longest Available Agent from the skill group in the Media Routing Domain for that channel. The agents may be logged in to different Media Routing Domains and working with contacts from different channels; the Router determines an agent's availability across channels.

The following script example shows how contacts can be categorized by Media Routing Domain, then queued to skill groups specific to that Media Routing Domain:

You would schedule this script to run for Call Types associated with contacts from the different channels. The script then uses the Media Routing Domain node to detect the MRD of the contact and branches to a Queue to Skill Group node that specifies skill groups specific to that MRD.

The following script example shows how contacts can be categorized by Media Routing Domain, then queued to precision queues specific to that Media Routing Domain:

You would schedule this script to run for Call Types associated with contacts from the different channels. The script then uses the Media Routing Domain node to detect the MRD of the contact and branches to a Queue to Precision Queue node that a precision queue specific to that MRD.

The following script example shows how contacts from different channels can be queued to agents:

You would schedule this script to run for Call Types associated with contacts from the different channels. In the Queue to Agent node, each row defined for an agent also contains a Media Routing Domain selection. The script queues the contact to the agent with the selected MRD that matches the MRD of the contact.

This example only applies to tasks submitted by third-party multichannel applications that use the Task Routing APIs. This example script shows the call priority increase if the service requested is 2 (TRANSFER).

If the Call ServiceRequested call variable is set to 2 (TRANSFER) the call enters the Queue Priority node. The Queue Priority of the call is increased so that it is handled before any other calls in the queue. The Queue Priority node sends the call to the Queue to Skill Group node. If the Call ServiceRequested call variable is not set to 2 (TRANSFER), the call enters the Queue to Skill Group node.

This example only applies to tasks submitted by third-party multichannel applications that use the Task Routing APIs.

Scripts for estimated wait time include:

• A Set Variable Node to set the estimated wait time.

• A Run External Script node to apply a Network VRU script that returns the estimated wait time to the customer.

Set Variable (Call.Estimated Wait Time) node: Set the estimated wait time as follows:

1. From the Set Variable node, select Call from the Object type drop-down menu.

2. From the Variable drop-down menu, choose Estimated Wait Time().

   You can then work with the Formula Editor to use the default estimated wait value or create a formula and use your own value.

3. Click Formula Editor, and do either of the following:

   • To use the default estimated wait value, click the Built-In Functions tab and choose EstimatedWaitTime()

   • To create a formula and use your own value, click the Variables tab and choose an entry in the Object type list and an entry in the Object list. Then double-click a variable in the Variable list.

Run Ext Script node: Apply the Network VRU script as follows:

1. Click the Queue tab.

2. Click Run External Script.

3. Click inside the script. A Run External Script node appears.

4. Double-click the node and choose the Network VRU script from the list; then click OK.

   The call variable Estimated Wait Time now contains a value in the EstimatedWaitTime field and can be passed to peripherals.

   Note that a Run External Script node is required to send the EstimatedWaitTime to Customer Collaboration Platform.

When configuring the Unified ICM in a Unified CCE environment, you configure Agent Desk Settings. When creating agents, you then associate each agent with one of the Agent Desk Settings you created.

One attribute of Agent Desk Settings is the Ring no answer dialed number:

For calls to be routed when an agent does not answer, you must create and schedule a script for the Call Type mapped to the Dialed Number selected for the agent's Desktop Settings.

For example, you may schedule a simple script to run when agents do not answer that tries to select the longest available agent from a set of skill groups, and if that fails, requalifies the call to a new Call Type to have it rerouted:

When configuring Call Types and dialed numbers in a Unified CCE environment, you typically may have a Dialed Number of Routing_client.9999 for internal calls from agent to agent. You would create a call type associated with the Dialed Number, and schedule a script for calls of this call type. The script routes internal calls, which also allows you to track and report on such calls.

For example, you may schedule a simple script to run for internal calls that tries to route directly to the agent using the Agent to Agent node, which selects the agent by peripheral and the expression Call.CallerEnteredDigits:

If the node fails, then the script tries to select the longest available agent from the set of supervisor skill groups:

You can use an administrative script to control the setting the OutboundControl variable and the skill group reservation percentage. The Outbound Option Dialer uses these values to determine which mode each skill group uses. You can use one script to control all Outbound Option skill groups, or multiple scripts can control multiple Outbound Option skill groups.

This administrative script comprises of Start, Set, If , and End nodes. Use the Set node to set skill group variables (OutboundControl and OutboundPercent).

Set the OutboundControl variable by entering it in the Value field of the Set Properties window:

• INBOUND: Indicates that this skill group is disabled for outbound use and only takes inbound calls.

• PREDICTIVE_ONLY: Dials several customers per agent. After reaching a live contact, the Predictive Dialer transfers the customer to a live agent along with a screen pop to the agent’s desk. The predictive algorithm is designed to calculate the number of lines to dial per available agent to keep agent wait time to a minimum.

• PREDICTIVE_BLENDED: Agents receive inbound calls, but could be used for an outbound call when available.

• PREVIEW_ONLY: Reserves an agent prior to initiating an outbound call and presents the agent with a screen pop. The agent might then:

  Accept the call:

  • Dials the customer and transfers the call to the agent.

  Skip the call:

  • Agent receives another customer call.

  Skip-Close the call:

  • Skips the current preview call and closes the record so it will not be called again.

  Reject the call:

  • Releases the agent. At this point, the system might deliver the agent another preview outbound call or a new inbound call.

  Reject-Close the call:

  • Rejects the current preview call and closes the record so it will not be called again.

• PREVIEW_BLENDED: Agents receive inbound calls, but could be used for an outbound preview call when available.

• PREVIEW_DIRECT_ONLY: Agents can only place outbound calls and hear ring tones, such as phone ringing or busy signal.

• PREVIEW_DIRECT_BLENDED: Agents can receive inbound calls, place outbound calls, and hear ring tones, such as phone ringing or busy signal.

• PROGRESSIVE_ONLY: Similar to PREDICTIVE_ONLY; however, lines to dial per agent are not calculated—users configure a fixed number of lines that will always be dialed per available agent.

• PROGRESSIVE_BLENDED: Similar to PREDICTIVE_BLENDED, but a fixed number of lines will always be dialed per available agent.

Note

If the administrative script (where the OutboundControl variable or reservation percentage is set) is running, but the modes/percentages are not being updated at the Dialer, do the following: Make sure that the skill group being controlled is the base skill group, and not the primary or secondary skill groups. Although agents may be logged in to just the primary or secondary skill group, the outbound control variable must always be set on the base skill group Verify that the outbound control variable mode is spelled correctly.

Set the OutboundPercent variable in the same administrative script. Select the OutboundPercent variable in the Set Properties window and enter the agent percentage in the Value field. This variable controls the percentage of agents that are logged in to a particular skill group, which should be used for outbound dialing. For example, if there are 100 agents logged into skill group N, and the OutboundPercent variable is set to 50%, 50 agents would be allocated for outbound dialing.

Note	This variable does not allocate specific agents for outbound dialing, just a total percentage.

The following diagram displays a very simple administrative script where both the OutboundControl variable and the outbound percentage are set for a skill group. A script in a production call center would typically be more complex, perhaps changing these variables due to time of day or service level.

The following diagram displays a routing script for a transfer to VRU campaign using the Outbound Option with the Unified IP IVR.

The following diagram displays a routing script for a transfer to VRU campaign using the Outbound Option with the Unified CVP.

Look for a secondary skillgroup choice in the following situations:

• No available agents in the primary or first choice skill group

• The call has already been sent to a VRU queue point

• The call has been queued to the primary or first choice skill group

• An adequate amount of time has elapsed (customer and call dependent)

After the above conditions have been met, if there are no agents available in the subsequent or secondary choice skillgroup, then Minimum Expected Delay (MED) of the subsequent skillgroup should be calculated.

You can use the example formula below in an IF node to determine the EWT/MED for a call that you can route to either a primary or secondary skill group. The call is routed to the skill group with the lowest MED:

EntSkill.Default\EnterpriseSkillgroupSec.Avail ||

(EntSkill.Default\EnterpriseSkillgroupPri.LoggedOn>0)

&&

(EntSkill.Default\EnterpriseSkillgroupSec.LoggedOn>0)

&&

((SkillGroup.CCM_PG_1.CCM_SG.sec.RouterCallsQNow+1)*

(ValidValue(EntSkill.Default\EnterpriseSkillgroupSec.AvgHandledCallsTimeTo5,<constant>))

/EntSkill.Default\EnterpriseSkillgroupSec.LoggedOn)

<

((SkillGroup.CCM_PG_1.CCM_SG.pri.RouterCallsQNow+1)*

(ValidValue(EntSkill.Default\EnterpriseSkillgroupPri.AvgHandledCallsTimeTo5,<constant>))

/EntSkill.Default\EnterpriseSkillgroupPri.LoggedOn)

If there are agents available, then no there is no need to calculate the MED and the IF node should return a TRUE value. If there are no agents available, then the MED of the secondary skillgroup should be calculated.

The formula first checks to make sure agents are logged in to both the primary (already queued to) and secondary (not queued to) skill groups. If there are agents logged in to both skill groups, then the minimum expected delay of the secondary skillgroup is compared to the minimum expected delay of the primary skillgroup to see which is less.

If the secondary skillgroup MED is less, then the call should be queued at the new secondary skillgroup. (The call can either be kept in the initial skillgroup or taken out of the initial skillgroup when it is queued to the secondary skillgroup.)

However, if the secondary skillgroup's MED is not less than the primary skillgroup's MED, then the call should remain queued at the initial skillgroup only. +1 is used to add this new call into the algorithm.

Because the RouterCallsQNow variable is only applicable at a Skillgroup and not an Enterprise Skillgroup level, then the aggregate of all the skill groups within the Enterprise Skillgroup RouterCallsQNow field must be multiplied by the Enterprise SkillGroup AvgHandledCallsTime.

The <constant> value is site dependent. It should be a value that represents the average Handle time of a call. This constant is only used if it is at the start of the day and the proper AvgHandledCallsTime has not been calculated.