where cardiac patients can hold a telephone to their chests and relay electrocardiogram data to distant telephony servers (see the sidebar "Visual Tools to the Rescue" in the article "Tools for Telephony Apps").
Unfortunately, launching a CTI implementation still isn't easy. For example, most of the savings in communications costs derived from CTI can be found at the beginning of the call, during the call setup. However, the setup also is the point where many companies face their first CTI disappointment. A poorly designed implementation can actually increase the time it takes to answer and process incoming calls.
Complications arise because CTI still requires you to integrate fundamentally different types of computer and communications systems and technologies. Some integration help comes as APIs such as Telephony Server API (TSAPI), Telephony API (TA
PI), and Java Telephony API (JTAPI) evolve. Also, automatic call distributor (ACD) and PBX vendors are opening up their system architectures to development tools that support industry standards. But to achieve the promise of reduced costs and to embrace advanced CTI capabilities, you need to understand the basic structure of a CTI implementation. Here's an overview.
The Basics
The first step in developing a basic CTI application is to add automatic number identification (ANI) service to incoming calls from your telephone company. ANI attaches caller ID with the voice call as it's being sent to your ACD or PBX. Phone companies typically charge you for the basic ANI service, then add an additional cost for each call. Note that the launch of a CTI project is a great time for you to review your relationship with your telephone company. At the least, make sure that yours bills each call in 15-second increments. Some customers are still being billed in 1-minute increments, which adds to the
cost of the CTI application and other telephone activities.
When the call arrives at your company, your ACD or PBX strips off the ANI data, combines it with an internal phone extension, and sends the caller information to a CTI server. The CTI server compares the caller ID and phone extension with its database to find the right PC. Next, the CTI server generates a data record and sends it to a customer database that may reside within the CTI server, on another computer at the same location, or even on a mainframe host system in another geographical area. This data record requests that the customer information associated with the caller's number goes to a specific PC in the company -- a telemarketing representative's, for example.
CTI servers -- the traffic cops that direct voice and data to the right desktops -- traditionally have been Unix boxes because of that platform's scalability and reliability. However, a new generation of Windows NT servers is gaining ground thanks to economical hardware cost
s and steady increases in the number of CTI applications that are being developed or ported to that platform. The next version of Microsoft's TAPI may provide better coordination between Windows NT and TAPI clients (see the sidebar "Building Bridges with TAPI and TSAPI").
You can team a CTI server with an ACD or PBX. In this way, you preserve your investment in existing telecommunications hardware, while adding the CTI capabilities you need. Alternatively, you can install multifunction servers in place of PBXes, thanks to chips from companies such as Dialogic and Mitel that can perform ACD/PBX-like switching tasks -- sending incoming calls to an interactive voice-response (IVR) board or to a person's desktop, for example. You will need to install the proper telephony-interface cards to connect the CTI server to the phone network and to the internal phone system. The CTI server's plug-in boards handle such chores as IVR, voice mail, and fax on demand. Board vendors also are merging switching functions and
telephony capabilities, such as IVR, onto single boards, thereby reducing the number of add-in boards and integration woes that CTI engineers need to contend with.
Another alternative is to use an ACD in lieu of a CTI server. Aspect Telecommunications, for example, can support CTI functionality directly in its ACD. The ACD acts like a transaction link server, where the ACD system itself takes on the role of the CTI server and provides routing information to a host system. This offers a cost-effective way to generate a basic screen-pop CTI application.
However, a transaction-link server works only if the CTI application does not need a front end to the host system database. A CTI server can program front-end information to rectify shortcomings in a host system's database. This front-end service is a benefit if a customer's calling-from number is missing from the host system's database or in a cellular operation where the customer may be calling from a number of different phones. A front-end CTI server
database can correct these shortcomings in the host system without your having to rewrite the host system's application.
In addition, if your CTI application needs to access a number of host systems to supply the first data screen, preloading the CTI server database will provide a single GUI even if your CTI application connects to a variety of hosts, such as a 3270, 5250, or telnet-supporting system.
Anyway you look at it, front-end loading the CTI server is a much better alternative than either rewriting the host system's database or trying to synchronize several host systems. Additionally, you can modify the front-end database in the CTI server with simple additions, modifications, and deletions as changes to the host system take effect.
What's Inside
The processing power you need for your CTI server depends on the size of your application. Some companies can fulfill their server needs with inexpensive 486-based systems (see the sidebar "When C++ Is Right" in the article "
Tools for Telephony Apps"). Whatever processor you choose, take advantage of today's low costs for RAM and disk-storage capacity, especially if the CTI server will act as a front end to a host system. The rule of thumb is to install the maximum amount of RAM the system can handle and buy at least a 5-GB hard drive. The last thing you want is to take down a CTI server to upgrade RAM and storage capacity when each is so cheap to install at the beginning. For reliability, many CTI applications require a RAID subsystem or a redundant CTI server that can automatically step in if the primary server fails.
Several methods are available to connect your CTI server to your ACD or PBX. Some ACD and PBX vendors provide a direct connection between ACD or PBX and the CTI server, but this is typically with proprietary systems. Others prefer that you connect the ACD or PBX to the CTI server using a LAN and TCP/IP. In either case the ACD or PBX vendor will supply the interface card to its product. TCP/IP is becoming the d
e facto standard for connecting PCs to CTI servers and CTI servers to the ACD or PBX. X.25 was prevalent when terminals outnumbered PCs on the desktop. Unfortunately, serial interfaces between PCs and the CTI server still exist, but no one should consider doing this today.
CTI projects often force companies to establish interface and connectivity standards for the way CTI components communicate. This is an area where the information systems and telecommunications departments may clash. If your company is like most, you're using the communications stacks provided by the network OS (NOS). However, the connectivity interface of the ACD/PBX will be limited and may force the CTI application to use an interface protocol that is not supported by the current information systems' network plan.
A CTI launch should be a catalyst for setting a company-wide standard if one does not exist. If you already have not done so, this will be the most costly part of the CTI application and may require you to purchase new h
ardware and software. In addition, you should design, configure, and deploy the data transport protocol (such as TCP/IP) in conjunction with your physical cabling plant. This is no simple task, so plan accordingly. Mistakes and lack of communication and understanding between the information systems and communications groups, as well as poor project management, can lead to improper specification of technologies, which could haunt your CTI application for years.
Accuracy Counts
The main job of the CTI server is to manage the routing table information -- the ACD or PBX phone extensions and the network LAN and WAN addresses of each PC. It is important that you program a detailed and precise routing table into the CTI database. You need only check and double-check the work of the person who entered the addressing data. Nevertheless, accurate routing-table input can be one of the most time-consuming parts of the CTI development and deployment cycle. Errors in routing tables can lead to disa
ster because a single mistake can take down two CTI positions at a time as a phone call and a data screen travel their separate ways through your company.
Once all the preceding items have been addressed, your next critical decision will be what CTI software development tools you'll use to create custom applications. If you have unlimited information systems resources and a talented coding team, you may choose Visual Basic, Delphi, PowerBuilder, C, or C++. Or you may choose canned development GUI tools (see "Tools for Telephony Apps").
Before you start any GUI development effort, you should sit down with your operators to get a detailed understanding of just how incoming calls flow and how the operators interface with customers. This may sound basic, but we've been involved in a number of CTI fixes where thousands of dollars were spent on the best equipment only to have the CTI project fail because no one asked the operators how the calls flowed once they answered the phone.
Plan for the F
uture
Once you've established the fundamental building blocks of a CTI application, customer-service improvements and cost savings can be just one more application away. For example, we recently expanded a basic CTI application into a system called computer and interactive voice response (CIVR). CIVR prompts the customer for specific information prior to the operator receiving the call. This can result in cost savings greater than the traditional CTI application because some callers may not need to speak to a person to get the information they want. If a caller needs a live operator, a simple key press will correctly route the call and ID information.
The best CTI project targets present needs while building for the future. Don't fall into the short-vision trap.
Where to Find
Aspect Telecommunications Corp.
San Jose, CA
Phone: (800) 541-7799
Phone: (408) 325-2200
Fax: (408) 325-2260
In
ternet:
http://www.aspect.com
CTI, Piece by Piece
