Reading Data From XML Documents in UCCX

Have you ever wanted to do any of the following from a Contact Center application?

  • Read a schedule from a local document, rather than having to use script editor to edit schedules
  • Be able to load a schedule from a web server, so you didn’t even need to touch you CCX server
  • Bring in external data without UCCX Premium
  • Bring in external data from a database there isn’t a driver for

All these and more can be done by reading XML formatted data either stored in the local repository, or served from an external web server, and retrieved using the Create URL Document or Make REST Call steps. Since you are able to read from a web server, any web programing language, like PHP, ASP, or JSP, could be used to retrieve and format the data.

Once UCCX has the XML formatted data, the Get XML Document Data step uses the XPath syntax to get data out of the document. This is a powerful syntax for reading data from XML formatted documents, as we will explore here.

In this post, we will use the Make REST Call step to retrieve information from the REST interface on the UCCX server, which provides easy access to a remote source of XML formatted data. Continue reading

UCCX Automatic Call Distribution (ACD) Part 3

In previous posts, we have looked at setting up the queues, skills, and agents for an ACD (Automatic Call Distribution) call center. In this post, we will take a look at setting up a very basic queuing script from a template, and creating an application to use it.

Continue reading

UCCX Work Timer Expired Not Ready Reason Code

I recently ran into a situation where agents in a call center that had a Work timer and reason codes enabled where going into Not Ready with a system reason code: 32758 (Work Timer Expired).

The agents and queue were configured so that the agents would become available again after the work timer, and the majority of the time they were. What we discovered, with TACs help was that these were instances of a non-ACD call in or out to the agent phone being active when the work timer expires.

The agent states in a normal scenario would be as follows: The agent is in a Ready state, a call is presented, and they go into the Reserved state while the phone is ringing. Once the call is answered, they go into the Talking state, followed by the Work state when they hang up, and the 10 seconds later they go into the Ready state.

In the cases where we were seeing “Work Timer Expired,” the agent starts in a Ready state, goes through the reserved and talking states as above, and Work when they hang up. Then they either place an outbound call or receive a call directly to their extension, not through UCCX. Once the work timer expires, they are placed in the Not Ready (Work Timer Expired) state for the duration of the non-ACD call, and when that call is completed, they are returned to the Ready state.

In short, assuming the agent and queue are correctly configured with Auto Available, the 32758 (Work Timer Expired) reason code should be read as equivalent to the non-ACD Call reason code.

Check out my other UCCX posts.

UCCX Automatic Call Distribution (ACD) Part 2

In my last post, we looked at configuring UCCX Queues, Skills, and Resource Groups. In this post, we will look at Agents, Supervisors, and Teams. These are how UCCX manages the call center employees. Agents (or Resources) are the people that  answer the incoming phone calls, or are assigned outgoing calls. Supervisors are usually the call center managers, although this capability may be assigned to other people, such as marketing, HR, or IT employees. Teams are administrative groupings of agents, supervisors, and queues.

Configuring Agents (Resources)

In UCCX, agents are referred to a Resources. A Resource can be assigned skills, be assigned to a Resource Group, or both. Agents are the people that calls are directed to, based on skills or resource groups.

The Agent capability cannot be assigned directly to a user; to make a CUCM user a call center agent, find the end user in UCM end users, and assign the user’s phone as a controlled device. Once you click save, you will be able to select a line from any of the controlled devices as the IPCC (IP Contact Center, one of the various names UCCX has had) extension. The extension used for UCCX must not be shared, and should be the first line on the phone. Once a UCM end user has an IPCC extension assigned, they have the agent ability assigned automatically. Continue reading

UCCX Automatic Call Distribution (ACD) Part 1

Automatic Call Distribution, or ACD, is one of the most fundamental features of any call center software. It includes taking calls, queuing them until a qualified agent it is available, and transferring the call to that agent. There are a number of components that make up ACD in UCCX, which I will address over several posts. This page assumes you have installed UCCX, and run through the UCCX initial setup.

Queues, Resource Groups, and Skills

In this post, we will deal with queues, and the ways to assign agents to them.

Resource groups are a static group of agents that can be assigned to one or more queues.

Skills based routing can be configured to require an agent to be assigned one or more skills, and at a minimum level, before calls can be routed to them, and route the calls to agents based on the skill level assigned to them. Queues can be configured to route based on a number of functions based on the agent’s skill level, high to low, low to high, and based on weighting. Continue reading

UCCX Architecture

UCCX is an application server in the Cisco’s Unified Communications suite that provides basic or advanced IVR, call queuing, Automatic Call Distribution (ACD), agent management like reporting and recording (both built in, and using the Quality Management and Advanced Quality Management products. The basic components required to process calls in UCCX are a Unified Communications Manager cluster, gateways for PSTN access, and a UCCX node or HA cluster.

A CCX HA cluster is based on a Publisher/Subscriber relationship, like UCM, but is an active/passive cluster. One node performs all call processing and the other node is available as a hot standby. When a failover occurs, either administrative, based on a failure, or for instance if a node is restarted, the node will stay active until something causes it to fail back the other node. This is because, since calls can be actively terminated to the UCCX server, failover can cause an interruption of call processing. When a failover occurs, call that are terminated to the CCX server will be lost, while calls actively talking to agents should not be.

The basis of call handling in UCCX is the application, which is a combination of a script, one or more triggers, and zero or more parameters. There are also prompts, queues, agents, and a lot of other pieces, but they center around these 3.

Scripts: Created by a dedicated editor (Cisco Unified CCX Editor) can preform a wide variety of call handling operations (answer calls, transfer calls, collect DTMF digits, play prompts, etc.), interact with CCX queues and agents, process data, etc.

Triggers: CTI route points registered with Unified CM. Ports are used to route a call to a specific application. Triggers can also set the language in a multi-language environment, and can be referenced in a script, so the script can handle calls to individual triggers differently.

Parameters: Values that can be fed to a script to customize it for a specific application.

A single script can be used for multiple applications. For instance, a script could be created that answers a call, plays a welcome prompt, and places the caller in a queue, playing music on hold and a periodic announcement until an agent becomes available. The company using it needs 2 call flows, one for sales, and one for repairs. The call flows are identical, except that the welcome prompt should reflect the department called, and the callers should be placed in the queues called “sales” and “repairs,” respectively. Rather than create a separate script for each department, a single script can be used, that expects parameters for the welcome prompt and the queue name. Then, “sales” and “service” applications are created, with the appropriate values configured as parameters. Then, triggers are assigned to each of them, say 1000 for sales, and 1001 for service. When a person called 1000, UCM rings the trigger 1000 on CCX, and CCX handles the call using the application (script and parameters) assigned to that trigger.

Note that it is possible to create a single script, single application, with multiple triggers, and route the call based on that. I tend to prefer the first way, as it tends to allow for easier administration.

Over some upcoming posts, I will take a deeper dive into these topics, and provide some examples.

Cisco Unified Contact Center Express (UCCX) Initial Setup

Unified Contact Center Express (UCCX) is the solution for small to medium (up to 400 agents) call centers in Cisco’s Unified Communications suite.  It runs on the same UCOS platform that Unified Communications Manager and Unity Connection run on, the initial install is identical. This post takes you from the end of that install to a point where you can configure applications to process calls.

Once UCCX is installed, it will run through a setup wizard when you first log in to the web interface. Before the wizard is run, a CUCM AXL user needs to be configured, and a license file obtained. Continue reading

Cisco Unified Contact Center Express (UCCX) Install

Starting with version 8.0, UCCX is based on the same hardened Red Hat Enterprise Linux  version that CUCM and Unity Connection are based on. The install follows the same steps that they do. Since UCCX is still licensed based on license MAC, pretty much everything you enter here will be used to calculate the license MAC, so make sure you have the correct settings.

UCCX Install Platform Installation Wizard

Select “Proceed” to the perform the platform configuration. If you select “Cancel,” the install will proceed without configuring the platform. When the server is booted again, it will prompt you to complete the platform configuration. This is useful to stage subscribers, or deploying remote servers where you cannot complete the install.

Continue reading