Overview of CTI

1) Computer Telephony Integration (CTI), is a concept that enables computers and

phone systems to communicate with each other. In fact, CTI effectively merges the
functions and features of each of these two technologies into one integrated system.
CTI in its simplest terms includes placing and answering voice, fax, and data calls.

2) Computer telephony integration or CTI, is technology that allows interactions

on a telephone and a computer to be integrated or co-ordinated. As contact
channels have expanded from voice to include email, web, and fax, the definition
of CTI has expanded to include the integration of all customer contact channels
(voice, email, web, fax, etc.) with computer systems.

Evolution of CTI

First Phase of CTI Evolution

The first phase in the evolution of CTI involved custom development. Anyone
who wanted to integrate a telephone system and a computer system had to work
directly with the telephone system vendor to obtain that vendor's proprietary (and
often product-specific) CTI interface. These CTI interfaces ranged from
specifications for how a computer could be interfaced to the telephone system in
question, to special APIs for specific operating systems. This is illustrated below.
The economics of this arrangement were very poor. In most cases, customers
themselves (or systems integrators working on behalf of customers) were developing
vast quantities of highly specialized software that was hard-coded to a very specific
telephone system. Rarely could this software be reused by others who had the same
telephone system. Furthermore, should customers ever need to upgrade their
telephone systems, they generally needed to rewrite their CTI software.

In instances where telephone vendors had invested in some type of custom API, it
invariably was on the wrong operating system for many customers, and was in any
case only a slight improvement in the situation. The custom API still required that the
customer develop software specialized to a very specific telephone system. In
addition, the telephone system vendor had to keep track of all the popular operating
systems. They had to split their development resources between maintaining existing
custom API implementations (as new versions of supported operating systems were
released), and trying to develop or adapt ("port") the API for new operating systems
as they appeared.

Second Phase of CTI Evolution

The second phase of CTI evolved from the first phase, but it represented a
tremendous leap over earlier approaches. It involved APIs that were independent of
the telephone system. The phase-two approach was based on the prevailing
philosophy that, given a small number of pervasive operating systems to support,
each development platform would provide application developers and telephone
system vendors with APIs. Each group then could develop the necessary software
components to build a complete solution without being dependent upon one another.
This is illustrated below.
The intent of the new approach was to minimize the work necessary for software
developers writing CTI applications. Thanks to a single, stable API for a given
platform, application software can, in theory, run independently of any specific
telephone system or product. This allows software developers who sell shrink-wrap
software (not just customers and systems integrators) to develop CTI software. The
result should be more applications (so the thinking went), which in turn should mean
a more attractive incentive for telephone system vendors to develop the necessary
CTI interfaces for their products.

The intent of the new approach was to minimize the work necessary for software
developers writing CTI applications. Thanks to a single, stable API for a given
platform, application software can, in theory, run independently of any specific
telephone system or product. This allows software developers who sell shrink-wrap
software (not just customers and systems integrators) to develop CTI software. The
result should be more applications (so the thinking went), which in turn should mean
a more attractive incentive for telephone system vendors to develop the necessary
CTI interfaces for their products.

This approach was not perfect, however. While it addressed the needs of software
developers, it did little for telephone system vendors relative to the first phase.
Telephone system vendors still had to write code for all of the popular operating
systems, and they still had to rewrite those pieces of code every time a particular
operating system was revised. From their perspective, at a technical level, the only
real difference between the first and second phases was the fact that they no longer
had to take responsibility for the design of the API.

Another challenge associated with the second phase is that solutions built using this
approach tend not to be as robust or reliable as desired. The reliability that people
take for granted in the world of telephony is in large part the result of international
standards that define, in precise terms, the protocols for the ways systems interact.
APIs, unlike these protocol definitions, are open to much greater levels of selective
interpretation. Applications that use a particular standard API might not work with
certain telephone system implementations supporting that same API. This is in part
because the behaviors of the telephone system software are not normalized. As it was
for phase one, in these cases the applications must still be specifically modified to
work with a particular telephone system. (Generally, however, there is less of this
work to do.)

Third Phase of CTI Evolution

 While the second phase was characterized by its focus on the needs of application
developers, the third phase in the evolution of CTI is characterized by its focus on the
needs of telephone system vendors and customers. It involves improving on phase
two by addressing the reliability issues and eliminating the key bottleneck, that is, the
effort required by telephone system vendors to implement and maintain all the
different APIs for all the different operating systems. Both of these objectives are
accomplished through the addition of standardized CTI protocols to the APIs
developed during phase two.

In the third phase, telephone system vendors are responsible only for implementing
software that runs internally on their own products. The only interaction with
application software is through standardized CTI protocols. This is illustrated below.

The result is that telephone system vendors no longer have to be concerned with how many operating
systems they support and which operating systems their customers are using. This also allows their
telephony products to be used by devices that don'st even have operating systems (or CTI APIs in the
conventional sense). Freeing up their resources from platform-specific development projects allows
telephone system vendors to focus on providing richer functionality and more robust operation.

The benefit for customers and application developers is that the normalized protocols
provide a much higher level of reliability and robustness using the existing operating
system-based APIs. Application developers don't have to "special-case" specific telephone
systems (unless they want to take advantage of special and unique features) and customers
then can use applications without having to worry about compatibility.
 CTI Benefits
CTI delivers real business benefits in the following key areas: Reducing costs,
increasing productivity and delivering better customer service.

Often helpdesks or contact centers are overloaded with phone calls which results in
customers having to wait for an available agent and then answer a long list of trivial
questions before the real purpose of the call is addressed. Sometimes callers are
transferred to many different departments before reaching someone able to assist them.
This type of service results not only in errors and inconsistencies in data entry and
information relayed to a caller, but also to unhappy customers and lost time and profits.

Reducing Costs

Half the cost of running a call center, service center or helpdesk is tied up in labor, 40
per cent in communications charges and less than 10 per cent in equipment. Saving
seconds on each call can make a big difference enabling agents to be more efficient,
deliver a better service and dramatically reduce company overheads.

In a helpdesk or call center with a high volume of phone calls each day, it takes many
agents to handle these calls efficiently. Callers may have to wait for an available agent,
which increases costs to the customer and can be a potential loss of business, due to
abandoned calls and unhappy customers.

With CTI, costs can be reduced through the following:

• Shortening the average length and duration of calls thereby maximizing the number
of talk minutes per hour and reducing the required number of staff

• Reducing/reducing telephone line requirements

• By using CLI/ANI, automating the call-back of inbound abandoned calls, the warm
leads, and outbound calls that were unanswered or received a busy signal

• Professionalism improves the company image thereby increasing the volume of

customer calls

Increasing Productivity

By implementing CTI, organizations can reduce the average duration of each call,
ensuring that a higher percentage of call time is spent productively. This extra time can
be used to handle a larger call volume, without increasing staffing levels.
Better Customer Service

With CTI, customer service can be improved in the following ways:

• Offering a faster, more personalized service based on CLI/ANI, DDI/DID and voice
processing input by minimizing time spent on the ‘discovery’ phase of the call

• Providing a higher degree of accuracy of data entry

• Retaining customer information on transfer (avoiding the need to request or repeat

information when transferred to another agent).