Intro to Cisco CCE – Part 2 – Call Flow
In part 1, I outlined the fundamental parts that make up a call center system and the Cisco products that fit into each role:
- PBX – Cisco UCM
- ACD – Cisco CCE
- IVR – Cisco CVP
In this post, I’ll outline how a call flows through the system to give you an idea of how these parts interact.
First, I’m going to add one more component to the discussion: the Cisco Voice Gateway, responsible for connecting the public telephony provider – such as AT&T or Verizon – to the internal system (the public telephony provider’s network is often referred to as the “PSTN” or Public Switched Telephony Network). Usually this means translating from the provider’s analog signal to digital, but more and more you may see providers using SIP to connect directly with a digital signal. Even though a SIP provider can, in theory, connect directly to UCM or CVP without a gateway, you will still see a voice gateway in these setups since Cisco requires one to act as an intermediary and make sure the signaling follows Cisco’s standards.
Here’s a diagram putting these parts together and showing who talks to whom. The dashed lines represent signaling, where components only send instructions and data to one another, while the orange line is the actual voice stream.
Notice that most of the communication is signaling, the only parts interacting with the voice stream itself are the voice gateway and the agent’s phone.
Our call flow begins with a customer dialing an 800 number for our call center. The telephony carriers do their magic routing the call around the PSTN, which I assume consists of old ladies frantically plugging wires into a giant switchboard.
Thanks to the tireless work of these brave women, the number is eventually delivered to our voice gateway. The voice gateway, in turn, answers the call and notifies CVP that a new call has arrived, passing along the number dialed and the caller’s number – if available. CVP then passes this notification and call information along to CCE, which looks up the dialed number in it’s configuration to determine what kind of scripting should run for the call. Typically this will involve some kind of automated treatment, like playing menus or lying to the caller and telling them their call is important. To do this, CCE will instruct CVP to play certain prompts, menus, or entire IVR scripts, based on how administrators have configured the given dialed number. CVP will then translate these requests into detailed instructions for the voice gateway, which is responsible for the actual act of playing audio to the caller and receiving their responses.
It’s important to note here that CVP and CCE never directly stream any audio either to or from the caller, they only send instructions to the voice gateway, which is responsible for the actual audio stream. For readers accustomed to working with UCCX (Call Center Express, Cisco’s small to medium business focused call center product) this is a major difference in how the two products work. With UCCX, there is a single server that handles all call center logic and IVR treatment. All IVR audio is sourced and transmitted to the centralized UCCX server. The CVP approach brings some benefits as the relatively high bandwidth and latency sensitive audio traffic is kept close to the edge of the network, where the system directly connects to the PSTN provider. This reduces the strain on the network, especially when remote branch sites connect to a centralized data center. We’ll discuss this point in more detail later in the post.
At this point, the caller may be satisfied with their interaction and end the call, or become so frustrated that they rage hangup (contained vs. abandoned in call center parlance). If however the caller is at the appropriate level of rage where they are eager to yell at a live person, but aren’t so angry they crush their phone with their bare hands, then eventually the caller may need to be routed to a customer service agent. At this point, CCE scripting would queue the call (i.e. put it next in line) for a group of agents. While the call is queued, additional IVR scripting may continue to play messages and horrible, horrible music.
At the same time that calls are coming into the system, CCE is monitoring which agents are logged in, which are busy or already on a call, and which are available to take a call. This is done with a combination of agent software running on agents’ PCs communicating directly with CCE, and via CCE’s connection to UCM, which provides CCE with the status of each agent’s phone. Eventually, our caller will be the next in line and an agent will become available.
At this point, CCE will instruct CVP to transfer to the call to the selected agent’s extension (which CCE knows when an agent enters their extension on login). CVP will then mediate the transfer between the voice gateway and UCM to reach the agent’s phone. Provided everything has been configured correctly the agent’s phone will ring. Upon answering the call, a two-way audio stream is setup directly between the voice gateway and the phone, and the caller is now ready to scream obscenities at our agent. Our call flow is complete.
To recap, here is a step-by-step outline of what goes on, with diagrams:
1) Caller dials 800 number.
7) CCE continues to instruct CVP on which scripts to play based on how the dialed number was configured, while CVP relays these instructions and receieves any results from the voice gateway.
8) When ready, CCE assigns the call to a queue for an appropriate skillset.
In these first two posts, I’ve given a very high level view of what CCE and CVP are and how they fit together. In subsequent posts, I’ll start digging deeper into technical details. My next post will dive into the components, services, and processes that make up CCE. Later on, we’ll revisit the call flow and dive deeper into the nitty gritty details and the configuration that goes along with it. Stay tuned.
Continue on to Part 3 – Architecture.