CTI and ICM Software (Release 4.6)

Table Of Contents

CTI and ICM Software

The CTI Server, CTI Clients, and ICM Software

Pre-Routed Call

Translation Route Call

Post-Routed Call

Transfer Call

Conference Call

CTI Client Application Models

Agent Workstation (Desktop) Application

CTI Bridge (All Events) Application

CTI Server Configurations

Simplex/Duplex Configuration

Combined/Separate PG/CTI Server Configuration

CTI and ICM Software

---

This chapter provides an overview of the ways in which CTI clients can work together with the CTI Server and ICM software. It includes the following:

•Description of the Cisco Intelligent Contact Management (ICM) software and the way that Cisco CTI fits in with ICM software.

•Description of various CTI Server configurations.

The CTI Server, CTI Clients, and ICM Software

Cisco Intelligent Contact Management (ICM) software is central to Cisco's overall call center routing solution. The Cisco CTI Server is the heart of Cisco's CTI. This section give an overview of how they fit together.

The CTI Server provides an interface between Intelligent Contact Management software and client CTI applications so that these applications can make use of the enterprise wide routing data managed by ICM software. The CTI Server runs at the call center site on either an ICM Peripheral Gateway (PG) with ACD interface software or on a dedicated CTI Gateway (CG) platform. Figure 3-1 shows a sample Cisco CTI system in which the CTI Server runs on a PG platform along with the ACD interface software. CTI Servers may be running at one or several call centers in the enterprise.

Figure 3-1 CTI Server Overview

ICM software, via the CTI Server, forwards pre-route indications to CTI application servers. Pre-route indications identify the caller and provide associated call attributes to applications while the call is still in the public or private network (that is, before the call is connected to an agent or internal IVR/VRU).

A screen pop is most useful if it happens on or before the first ring. A screen pop that occurs several seconds after the agent is already speaking with the customer may be of little value. ICM software gets the network call data (ANI, DNIS, CED, ...) and call profile data (from a database lookup) to the application by means of the pre-route indications. When ICM software returns the routing label to the network, it simultaneously passes this destination down to the CTI client. This permits the client time to do a pre-fetch of the appropriate database record, allowing for an extremely quick screen pop when the agent ultimately receives the call. ICM software can do this because it knows where the call is going to land, even before the carrier network knows. (ICM software knows this because it has determined the best answering resource—agent or IVR—within the entire enterprise, based on call data, profile data, availability, and the scripting algorithm.)

In the case of a desktop client, call event information is automatically delivered to the targeted desktop when the call is delivered. CTI Server reports call events and agent work state changes to the application as they occur through each stage of the call flow—from the moment a call arrives at an answering resource (ACD, PBX, IVR, Web server), until the caller hangs up.

---

Note In the case of a CTI Bridge (All Events) application, the application must deliver the event information to the desktop. See the "CTI Client Application Models" section.

---

The following brief overview of several different examples of ICM call processing flows may be helpful when considering the CTI services and data provided by this interface. In the following discussion, call data refers to the user data associated with a specific call collected by ICM software. Call data may include ANI, DNIS, CED, and an array of Call Variables containing user-defined data.

Pre-Routed Call

In this example, an incoming call is automatically routed.

1. A customer dials an "800" number.

2. The caller responds to in-network prompting (if any).

3. The network forwards a route request to Cisco ICM software (including any available call data).

4. ICM software, through the use of a routing script, chooses a destination to handle the call. The routing script almost certainly makes use of any CED.

5. A route response is returned to the network.

6. The call arrives at the chosen ACD and is monitored by the Cisco Peripheral Gateway (PG).

---

Note The call can, in fact, go anywhere that the business rules tell it to go, not necessarily to the ACD. For example, it might go to an in-front-of-the-switch IVR.

---

7. The call may pass through several states (queued, alerting, ...) before finally being connected to an IVR or agent.

8. The IVR or agent may either handle the call directly or transfer the call to another agent.

9. Upon completion of the call, a Termination Call Detail record is created and sent to the Central Controller database.

Translation Route Call

---

Note The reason for using a translation route call is so that data can be translated (that is, transported) to the ACD. In a pre-routed call, call data is used by ICM software in its decision making, but is not passed on to the ACD—let alone any data generated by the routing script.

---

1. A customer dials an "800" number.

2. The caller responds to in-network prompting (if any).

3. The network forwards a route request to ICM software (including any available call data).

4. ICM software, through the use of a routing script, chooses two destinations for the call: an intermediate target and an ultimate target. The intermediate target is chosen from a special pool of targets reserved for just this purpose. No other calls are expected to arrive at the intermediate target.

5. A route response is returned to the network to send the call to the intermediate target. At the same time, the ultimate target data is sent to the PG monitoring the ACD where the call is expected to arrive. CED collected in the network and any other call data set by the routing script is also sent to the PG in the message.

6. The call arrives at the chosen ACD and is monitored by the Cisco Peripheral Gateway (PG).

7. The ACD, recognizing the special nature of the call, performs a Route Request to collect the call's ultimate target.

8. The ultimate target and other call data determined by ICM software in step 5 is returned by the PG in a Route Response.

9. The ACD routes the call to the ultimate target. As in the pre-routed call case, the PG is informed of the call's state changes as they occur. Eventually the call is connected to an IVR or agent.

10. The IVR or agent may either handle the call directly or transfer the call to another agent.

11. Upon completion of the call, a Termination Call Detail record is created and sent to the Central Controller database.

Post-Routed Call

In this example, a redirected call is automatically routed in the same way that an incoming call was pre-routed.

1. A routing client, such as an agent, ACD, or Web server, sends a Route Request to ICM software in order to determine the destination for a call it wishes to redirect. The Route Request may supply call data such as CED and any other call data that that peripheral type supports.

2. ICM software, through the use of a routing script, chooses a destination to handle the call. The routing script almost certainly makes use of any CED.

3. A route response is returned to the ACD, along with call data (that may have been updated by the routing script).

4. The ACD routes the call to the ultimate target. As in the pre-routed call case, the ACD informs the PG of the call's state changes as they occur. Eventually the call is connected to an agent.

5. The agent may either handle the call directly or transfer the call to another agent.

6. Upon completion of the call, a Termination Call Detail record is created and sent to the Central Controller database.

Transfer Call

1. In the case of a local transfer, the agent handling a call directs the ACD to transfer the call to another destination on the same ACD.

2. The ACD informs the PG of the various events associated with the call's transfer.

3. Call transfers are handled differently by different types of ACDs, but in general a new logical call is created for the resulting call, and a Termination Call Detail record is created for the original call.

4. The new call is connected to an agent and is subsequently handled or transferred (again) like any other call.

In the case of a remote transfer, the call leaves the realm of the monitoring PG and the original call is terminated in the usual way. If the remote transfer is to another ACD that is monitored by ICM software, the new call is monitored on that ACD's PG when the call arrives. Depending upon the particular ACD's capabilities and tie-line configuration, the ACDs may be set up to transfer calls using the post route and translation route features previously described. In this case, the call data is preserved by being sent through ICM software via the route request and translation route mechanisms to the remote PG, and is thus available to the CTI client, if any, associated with the destination device.

However, if the remote transfer does not use translation routing, the new (transferred) call has none of the call data of the original call.

Conference Call

Like call transfers, call conferences are handled differently by different types of ACDs and may involve the creation of several calls that are all linked together.

CTI Client Application Models

You can use either of two client models to integrate call center applications with ICM software: agent workstation or CTI Bridge.

Agent Workstation (Desktop) Application

In the agent workstation model, the client is an application running on a personal computer on an agent's desktop. This client is interested in the call data and call events related to a single agent teleset. The agent workstation application might also be interested in agent state changes.

Typically, when the agent workstation application is informed of an incoming call, it will likely use the call data collected by ICM software to retrieve caller-specific data from a database. This data is presented on the agent workstation screen at approximately the same time that the incoming call is connected to the agent.

While handling the call, the agent may wish to update some of the call data. For example, an agent who is processing an insurance claim may make some adjustments to the call data; an update ensures that the changes are not lost before the call is transferred to a second agent. Upon completion of the call, the client may be used by the agent to add call-specific wrap-up information to the Termination Call Detail record logged in the ICM database. This wrap-up data may be a key value that can help locate more detailed transaction information in some other database. If the agent should conference with or transfer the call to another agent on the same ACD with a CTI client workstation, then that agent's CTI client also receives the incoming call data, including any updates made by the first agent. If the transfer or conference involves an agent on another ACD, the call data is provided to the remote CTI client if a translation route is used.

CTI Bridge (All Events) Application

CTI Bridge applications are interested in all call and agent state events that are occurring on the ACD, unlike agent workstation applications that are interested only in the events associated with a particular teleset. The CTI Bridge application is a user-written program that converts or adapts some or all of the CTI Server messages into another format; a single CTI Bridge application provides such services for multiple agent desktops. The CTI Bridge application can be designed to interface with CTI Servers or similar applications on systems that are already in use in the call center.

Some examples of CTI Bridge applications include:

•Message converter applications. For example, an application may convert the CTI Server message set to the message set of a foreign telephony server.

•Server-to-server communication applications. For example, an application may enable the CTI Server to speak directly to a help desk application's middle tier server.

In a CTI Bridge configuration, a CTI Bridge application provides the connection between an existing desktop CTI application and ICM software (see Figure 3-2—although only a single Bridge client is indicated in the figure, multiple clients are allowed).

Figure 3-2 CTI Bridge Model

---

Note All of the functionality found in the agent workstation (desktop) model is also available in the CTI Bridge application model. The CTI Bridge application lets you look at all events, and the agent workstation is a subset of all events. However, the CTI Bridge application must be written to support this functionality.

---

CTI Server Configurations

The Cisco CTI interface uses TCP/IP Ethernet for network connectivity to the CTI Server. You can use multi-protocol IP routers to provide connectivity to CTI clients on other types of LANs. You can use the Ethernet interface used for CTI client communication with the CTI Server for other purposes, such as the PG's public network interface; a dedicated interface is not required.

---

Note You must not use the PG private network for CTI communication. (In a private network configuration, the PG sends routing requests to the Central Controller and receives routing information in return.)

---

The following CTI Server configurations can be used in association with desktop clients, Bridge clients, or both.

Simplex/Duplex Configuration

In simplex configurations, there is one CTI Server on the local network with the CTI clients. In duplex configurations, two CTI Servers are present. There may be other equipment (for example, ACDs) on the network as well. Figure 3-3 shows a typical duplex configuration.

Figure 3-3 Typical Duplex Configuration Environment

Combined/Separate PG/CTI Server Configuration

In configurations where the ICM Peripheral Gateway (PG) computer has sufficient CPU and memory resources, the CTI Server may be installed on the PG, as shown in Figure 3-3—thus combining the CTI Server and PG software on the same machines. This is not essential, however, and the CTI Server may be installed on separate machines—as shown, for example, in Figure 3-4.

Figure 3-4 Separate PG/CTI Server Environment