The Call Center Jigsaw Puzzle

Putting the pieces of a CTI system together involves an amazing degree of coordination between products and vendors at several levels.

The bottom layer consists of the fundamental hardware and conjunctive elements: the boards that process the voice and data channels; the servers and networks, often ruggedized to reflect the mission criticality of what they are used for; and the standards and open APIs that link different vendors’ equipment together. The most common boards used in CTI systems are from manufacturers like Dialogic, Natural Microsystems, Lucent, Brooktrout and several other specialty companies, depending on the application.

Parallel to that sits the dual networking infrastructures: the phone switches and the data networks. The phone switches are usually PBXs or dedicated high-volume call routing switches called “automatic call distributors,” or ACDs. Phone service is also a core component. Not just because it’s an obvious necessity, but because increasingly, the carrier networks are being upgraded to deliver advanced call processing services through the network. Sometimes this works directly to the advantage of the smaller business — if messaging or call routing applications can be run from the network, you need to invest less in premise-based equipment. You can implement “high touch” services like call centers without spending so much on high tech infrastructure.

The data networking infrastructure, like the phone system, is probably already in place: LANs, intranets, external Internet connections and websites, desktop browsers and firewalls.

Between these two networking areas lies the middleware layer. The products in this category are what most people think of when they say CTI — the very specialized applications that draw data out of host systems and coordinate it with incoming telephony information, then format it for both sides. Originally, many of these products focused on coordinating between a single vendor’s switch and a single host format. As a rule of thumb, the older and more widespread the databases, the more important (and more complex, and customized) the middleware has to be. This has accounted for a lot of the tension surrounding the installation of CTI. For companies with decades-old legacy systems and extremely customized databases, installing CTI meant that to achieve any of the benefits, you had to go through a trying period of intimate customization between the switch and the database.

Increasingly, middleware connectivity is being sold as part of the switch, and middleware companies themselves are being acquired by larger companies above and below them on the CTI component chain.

The next level of product in the CTI hierarchy is the application layer. This is the software that actually does the things that make people more productive, things like messaging or speech recognition, automating sales forces or taking orders through the Web. It’s a good idea, when pondering a transition to CTI, to start here, with a concrete idea of what you want the system to accomplish. It’s akin to buying a PC based on what kind of application you want to run. You pick out the spreadsheet and word processor that has the features you need, then buy a PC that makes those features work best. CTI is no different. The best approach is to identify the applications that suit your business and then build up and down to integrate those apps with the infrastructure you already have.

Along with these layers of technology come the consulting services and systems integration know-how that ties it all together. For the most part, CTI is not an off-the-shelf accomplishment. It does require intimate connections between different technical realms — which are usually managed by different people, with different sets of priorities.