Intelligent Computer Telephony

First, decide on the tasks that the CTI application will accomplish for your operation. This is very important since CTI implementation is a costly undertaking. Suppose the goal is to reduce the number of analysts and maintain the same customer satisfaction. Let’s look at one of the more common applications, namely the screen-pops, and let’s make the decision based on the following four assumptions: Based on the above assumptions, it will take 41,667 successful screen-pops just to pay for the application. Number of calls to break even = (Application Cost) ((Analysts cost per hour) / 60 / 2) Number of successful screen-pops required to save the

equivalent of a man-year’s time = (2000 * 60 *2) or 240,000 The support center meeting these assumptions above must receive 240,000 calls per year using the CTI application to justify a reduction of one analyst. These are the hard dollar and cents reasons, but a support center would gain goodwill


Assumption 1 Each successful screen-pop will save the analysts 30 seconds. Assumption 2 The hardware, software development, and testing of the application will cost $50,000. Assumption 3 The average salary of the analysts is $17.50 per hour Assumption 4 Each analyst answers 45 calls per day. from the customer with the better service provided by the CTI application. Screen-pops alone may not justify the implementation of a CTI system, but by adding other functionality such as password resets and status information calls, the CTI application may be cost effective. Steps Required to Implement CTI After making the decision to go forward with a CTI

implementation, the present systems must be evaluated. The following questions are crucial: • Will the present telephony equipment such as PBX, ACD, and IVR support CTI integration (both hardware and software?) • Is it possible to integrate these systems with third

party vendor equipment? Do the other non-telephony systems that will be part of this implementation support the API (Application rogramming Interface?) Next, you need to find a telephony integrator. It is extremely important that the CTI applications integrate with the technology currently implemented in the support center. Ask the CTI vendor such questions as “Has your product been integrated with product X?” If the answer is “yes,” make sure by checking references. If the answer is “no,” you may want to

look at other vendors. Here are a few questions to consider about the CTI application and integrator: • Is the application easy to nstall, operate and manage? • Is there single view, integrated systems management?


• Will an increasing number of ports decrease system performance? What will be the overall cost of ownership? Is the architecture based on open standards? Are there any proprietary features or functions? Does the vendor offer a choice of support services?

• Will those support services be able to address the overall architecture or a subset of components? Is the system scalable?

In addition, make sure that your CTI application has the ability to grow with your business needs and with some of the technologies that are emerging, such as integration of fax back, voice mail, and Web interface.

CTI Testing

When the vendor has the CTI application and all other tools ready, don’t forget to test. Many experts suggest the application undergo four types of testing:

Onformance Testing – Call generators put the entire network through its paces by simulating actual user calls, including all possible interactions with the CTI application.

Load Testing – Using the parameters in the conformance test, the system is then tested to verify how it will perform under varying load conditions, which will include a large number of calls of short duration, and long and complex call interactions.

Regression Testing – In regression testing, call generators again are used to create a nominal amount of highly variable and complex traffic to simulate every possible path and decision a user could make. MANAGING TELEPHONY product and then run again with the new release to ensure that the new release will yield predictable results in all scenarios. If this is a new implementation, then this test will be useful when upgrading the application, the hardware, or any of the other pieces in the integration.

Acceptance Testing – Acceptance tests address the specific performance requirements checklist agreed to by the vendor and purchaser, and stipulates exactly how the product should perform in the purchaser’s specific environment. It is the responsibility of the purchaser to provide the vendor with this checklist, so the vendor can prove that the application meets all requirements.


Just a few years ago each of the applications–PBX, ACD, IVR and CTI–were systems that required their own hardware and software. Today, as the computing power of the server/PC is increasing and the price of these powerful servers has come down, more vendors have been able to offer one or more of the specialized applications as a package that can run almost any hardware and operation system combination.

However, this ability comes with two edges: the tools have been brought into reach for more companies, but these multifunctioning telephony servers and applications also bring some problems. The single application server has demonstrated strong reliability. The single application server can expect good reliability because the vendor has selected components that work well together and are compatible with their applications. Also, when a server supports only the operating system and a single telephony application, reliability is much more straightforward.

It does not take much to guess that a new level of difficulty is added when we incorporate factors such as unknown hardware and more than one application, each competing for resources while trying to communicate with each other. When problems arise in the multi-application environment on a single server, finding both the cause of the problem and the solution can be costly and time consuming. There is nothing so helpless as a customer service center without

About the author