COMPUTER TELEPHONY INTEGRATION

Computer Telephony Integration (CTI) signalled the move from ACD or PBX only services, where call routing decisions are made by proprietary routing engines configured through text-based terminals, to a new era in call routing and configuration. The ability to utilise corporate databases such as those held by marketing to segment the inbound calls based on the market segmentation of the customer. CTI has also created the ability to integrate multiple call centres in different physical locations into a single entity. The combination of CTI and intelligent network services has created the ability for call centres to route calls across national and international boundaries transparent to the caller.

How is CTI achieved? There are essentially two types of CTI, first-party call control and third-party call control. First-party call control is where a computer takes over the role of a telephone handset’s functions and links the basic call functions of a handset (make call, release call, transfer, hold, caller number presentation) to a software package that provides database integration (Figure 11.1). Examples of first-party call control are through programs such as Microsoft Outlook and contact management software such as ACT! In these examples the software controls a modem for exam- ple, with a conventional handset attached to it. Calls can be initiated from the software on the PC using point-and-click selection from the software. Or inbound calls can be intercepted and a ‘screen-pop’ of information about the contact displayed, based on caller number.

Third-party call control is a much more powerful capability, allowing a computer to control and monitor a large collection of telephone sets via a special interface connected directly to the PBX or ACD. This link instead of carrying telephony signalling messages carries status and control messages about all the events occurring in the PBX/ACD, from on- and off-hook messages from handsets through to call arrivals on trunks and call queue events. The control messages allow the computer system to establish new calls, terminate existing calls and even control the destina- tion of newly arriving calls. The best way to explain third-party CTI is by

CALL CENTRES

146

way of an example and a ladder diagram of the messages (Figure 11.2). First we’ll explore a single site solution and then look at a more complex multiple site multi-vendor solution.

Before we rush off into an example, it’s worth expanding on the issue of the ‘I’ in CTI. One of the biggest issues for the telecoms industry has been the use of proprietary control protocols between the PBX/ACD and CTI servers for third-party call control. Each vendor having implemented their own (in some cases more than one) protocols for third-party call control, for example Nortel have Compucall and Meridian/Symposium link on their DMS and Meridian products, respectively. Lucent have Call- Visor ASAI on their Definity product. Aspect has Application Bridge and Event Bridge on their ACD product and the list goes on.

Early work did take place on standardisation in the area of third-party call control. The International Telecommunications Union telecommuni- cations (ITU-T) had its work on telecommunications applications for switches and computers (TASC) and American National Standards Insti- tute (ANSI) its work on Switch Computer Application Interface (SCAI). The ITU-T and ANSI both looked at CTI as an extension of Intelligent Network (IN) standardisation and in fact the ITU-T specifications (Q.1300 et al.) were at the outset going to allow IN service invocation and were to

11.2 COMPUTER TELEPHONY INTEGRATION

Figure 11.2 Third-party call control – single site

share the IN call model. Alas apart from some initial documentation this work floundered. The European Computer Manufacturers Association (ECMA) group have their Computer Supported Telecommunications Applications (CSTA) standards and latterly the Enterprise Computer Telephony Forum (ECTF) have worked hard to define a whole services approach to protocols, architectures and Application Programming Inter- faces (APIs) for the open development of CTI services (S.200 being the CTI protocol).

Finally not to be left out both Novell and Microsoft have had a go at defining CTI protocols in the form of Telephony Server Application Programming Interface (TSAPI) and telephone application programming interface (TAPI1), respectively.

Alas this work has not really helped in persuading vendors of PBXs and ACDs to provide a standard set of interfaces. This has left computer telephony server vendors the job of integrating all the different CTI proto- cols into their products, creating a plethora of integration issues.

In the example I shall use a generalisation and simplification of the messages that flow between a CTI server and a PBX/ACD, as the para- graph above explains there are many variants of protocol, and that all perform the same role.

With reference to Figure 11.3, the following text explains the kind of interaction that takes place for third-party CTI. When a call arrives at the ACD, the ACD places the call in a holding queue that is generally deter- mined by the dialled number (direct dial in – DDI or dialled number interception service – DNIS). This triggers a message (1) to be generated by the ACD to inform the CTI server of the call’s arrival.

The CTI server initiates a database lookup in the customer database (2, 3) using the calling line id provided or the DNIS if the CLI is not present. If either DNIS or CLI is keyed to a specific customer or group of customers the CTI server then instructs the ACD to place the call in a specific queue (4). The ACD places the call in the queue and informs the CTI server (5).

When an agent of the type required to answer the call becomes avail- able the call is connected to that agent’s telephone set, and a message sent to the CTI server to indicate the call has been presented (6). This triggers the CTI server into retrieving the customer details (7, 8) and passing them to the application on the agent’s PC causing a ‘screen pop’ to occur (9).

The agent is then in conversation with the caller and can place them on hold (10) and look up more information in the database (12, 13) using their desktop applications. The agent can then resume the call (14) and complete the interaction with the caller (16). The agent can then wrap up the call, completing any tasks such as updating the database (16) and become ready to take the next call (20).

CALL CENTRES

148

1

In this simple example, you can see how the CTI server is at the centre of the interaction and the ACD/PBX is constantly updating the CTI server with state changes and responding to requests from the CTI server to perform the required tasks. The agent desktop application communicates its state changes through the CTI server to ensure co-ordination of all aspects of the call. One very good reason for doing this is in the case where a call is transferred from one agent to another, the CTI server can ensure any context information is retained and passed on to the new agent. The CTI server needs to retain call state information and like the IN needs to have a call state model – in the case of IN this as we have discovered earlier in the book is called the Basic Call State Model (BCSM). In the case of the CTI server the call states have to be compatible with the particular ACD/PBX call states to ensure step-by-step tracking of call flow.

11.2 COMPUTER TELEPHONY INTEGRATION

Figure 11.3 Simplified CTI message exchange

In a multi-site multi-vendor situation things get a little more complex, the CTI server needs to maintain state for multiple agents spread across multiple ACDs each with a different call model and set of CTI messages (Figure 11.4). In the two most prominent products on the market, a gate- way device performs the mapping of call state and proprietary third- party call control messages. The gateway device translates the vendor- specific messages into an internal generic message set. The internalised messages are used to update a centralised control point, which contains the queuing and routing rules to ensure multi-vendor and multi-site co- ordination. This type of solution works reasonably well for an enterprise situation, however, calls arriving at a specific location that are then onward routed to an agent on another ACD/PBX in the group, will have to be connected between the two ACDs (hair pined or tromboned). This onward connecting of calls costs money in the form of dedicated interconnecting trunks.

The solution to the problem of dedicated trunks is to utilise the network operator’s IN to perform pre-routing decisions. More efficient call routing can be achieved this way, allowing calls to transit the public

CALL CENTRES

150

network before reaching the PBX/ACD that the agent destined to handle the call resides on. In this type of solution the network operator also commonly provides ‘in-net’ Interactive Voice Response (IVR) services so that calls can be more efficiently pre-routed. Two types of IVR control are common: the IVR can be configured as an IN Intelligent Peripheral (IP) or third-party call control (CTI) interfaces are used to communicate with the scripts in the IVR platform. An example of the architecture is shown in Figure 11.4.