Dịch vụ mạng thế hệ kế tiếp P11

11
Call Centres
11.1 INTRODUCTION
Call centres are the place where technology advances seem to be taken
up with the most gusto and where the saying ‘time is money’ is so true.
A call centre environment is a pressure bottle where agents are
constantly trying to serve the customer, whilst keeping their interaction
times to a bare minimum, they have been labelled the sweat-shops of
the 1990s and gained a bad reputation for staff morale. A call centre
manager’s job is to maximise customer satisfaction whilst minimising
costs. The requirements for innovative technology solutions in call
centres are vast and challenging. These needs have led to a number of
creative solutions.
In the early 1990s Automatic Call Distribution systems (ACDs) and
Private Branch Exchanges (PBXs) were the mainstay of call centres. In
just 10 years we are now on the verge of network-based softACDs that
integrate web, email and voice interactions with Customer Relationship
Management (CRM) suites into a seamless service set. This has allowed
the now re-branded ‘contact centre’ manager to partition the customer
base according to a complex mixture of business rules and to prioritise
and route inbound contacts to the best available source of help. This
change has been an evolution over the 10-year period, with each year
bringing incremental improvements to the technical solutions available
to contact centre managers.
In this chapter we explore the rise of the call centre from a single site
solution through to a multinational operation with real flexibility in the
way callers can be routed, and on to the next-generation presence
centre.
Next Generation Network Services
Neill Wilkinson
Copyright q 2002 John Wiley & Sons, Ltd

ISBNs: 0-471-48667-1 (Hardback); 0-470-84603-8 (Electronic)
11.2 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 CENTRES146
Figure 11.1 First-party call control
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
147
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 (TAPI
1
), 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 CENTRES148
1
TAPI version 3.0 did bring H.323 and IP telephony to the PC, so all was not lost
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
149