There are good reasons for an AS/400 and a telephone switch to learn to communicate with each other. Such a connection is known as computer telephony integration (CTI), and it is a powerful business tool. IBM helps somewhat with the connection by offering a software product called CallPath Server for AS/400. CallPath consists of many APIs that allow an AS/400 to communicate with a phone switch. For example, a phone switch can tell the AS/400 what number a caller is calling from and what number a caller dialed. An AS/400 can then use that information to direct calls to certain people. A customer might be directed to his service representative, or a customer with unpaid bills might be directed to accounts receivable instead of sales. CallPath has many more capabilities, and you can learn more about them at www-4.ibm.com/software/speech/enterprise/universalaccess_1.html and www.networking. ibm.com/n31/n31s21.htm.
CallPath is effective software, but it suffers from one major problem: different switches require different sequences of CallPath APIs to perform the same function. Suppose your business has a GeeWhiz 2000 phone switch and your RPG or COBOL programs are calling APIs A, B, C, D, and E to do a “screen pop” (they display a certain screen based on incoming call data). Everything works great until you upgrade to a GeeWhiz 2001 phone switch or move to a different manufacturer’s switch. All of a sudden, your programs need to call APIs B, D, and F instead of the APIs they were using before.
You have two choices: You can revise your programs, or you can use middleware, such as CallPro, to avoid these problems. CallPro is an AS/400-based software product from Cothern Computer Systems (CCS) that sits between your applications and CallPath. The philosophy behind CallPro is simple: You shouldn’t have to change your programs when you change telephone switches. You must tell CallPro what kind of switch you have. Make your applications call CallPro APIs instead of CallPath APIs. When you change switches, you simply notify CallPro of the change, but you do not need to change your applications.
CallPro is table-driven, so information about the various switches and the CallPath APIs they require is stored in DB2/400 database files. When your program calls a CallPro API, CallPro in turn calls the required CallPath APIs for you. If you change switches, you do not need to change your software. It continues to call the same CallPro APIs.
But CallPro is more than just an improved interface to CallPath. Figure 1 gives you an idea of what CallPro can do. It lists some of the APIs you can call from your application programs. Some of these APIs allow you to control the telephone from the keyboard (e.g., make a call or place your phone on do not disturb). Other APIs can handle routing of calls, such as transferring a call to another party. Still others are for administrative purposes.
Advantages of CallPro
There are several good reasons to consider using CallPro to connect a phone switch and an AS/400:
• CallPro can save money for any organization with a call center. Routing incoming calls to their proper destinations and giving the answering party information about the caller before or as soon as the phone conversation begins are two ways to shorten phone calls. Shorter phone calls mean toll charges are reduced and fewer operators are required.
• CallPro can improve customer satisfaction. Callers do not like to provide the same information (e.g., a loan number) again and again as they are routed from one agent to another.
• CallPro can be more robust than any software you could write in-house, using CallPath APIs. CCS has a staff of programmers devoted to maintaining and enhancing CallPro.
• CallPro can interface well to the Internet. For example, you might like to have CallPro retrieve a phone number that someone typed into a form on the Web and dial that number for you.
• CallPro can be, and has been, linked to popular commercial enterprise resource planning (ERP) packages, as well as to homegrown software.
• CallPro can support multiple switch connections. This allows an enterprise with multiple locations and one AS/400 to supply CTI services to all locations from one AS/400.
• CallPro can receive information from interactive voice response (IVR) and voice recognition unit (VRU) platforms. For example, a caller can enter preliminary information, such as an account number, before being transferred to an agent. The agent then has access to the information that was entered.
• CallPro can work with client programs on the AS/400 as well as on other platforms, especially Windows and UNIX, through industry-standard programming interfaces.
• CallPro is modular, so you can license only the modules you need. The base module includes screen popping, voice and data transfer, workstation telephony control, abandoned call tracking, and preview dialing. Besides the base module, there is host- enhanced routing, CallPro Reporter, power dialing, and predictive-dialing modules.
• CallPro’s extensive reporting module can help management make decisions based on incoming calls, outgoing calls, abandoned calls, and other factors.
• CCS has been involved with CTI since 1989 and was involved with CallPath even before it became generally available in 1991. The people of CCS spent time in IBM facilities, helping IBM bring CallPath to market. Since that time, CCS has maintained a close working relationship with IBM.
• CallPro includes both test and production environments. That is, you can test your applications against a phone switch to which your organization is converting while the old phone switch is still in use.
• CallPro provides multilingual support, since some CCS customers are in non-English- speaking countries.
Large organizations implemented CTI years ago, and many now use CallPro. However, smaller organizations can benefit from CallPro the most. Using CallPath and CallPro in tandem makes it possible for small organizations to offer a high-level of call-center support.