Call centers, vendors, dealers, and VARs have all benefited from telephony standards. We take for granted the screen-pop on an agent's desktop. But before Microsoft and telecom standards committees devised third-party call control, only the largest organizations could afford a call center because the software that controls phones and computers had to be built from scratch. With the introduction of CT middleware, vendors finally appeared on the scene that could deliver prepackaged, mass-market ACD (automatic call distributor) software.

Call center apps became more affordable; and call centers for companies outside the Fortune 500 sprang up. A new standard that manages media resources, S.100, may change the call center application landscape again by lowering costs and letting vendors and VARs craft highly specific call center solutions.

From First- To Third-Party Call Control

To appreciate S.100's promise, we need to revisit some middleware history, starting with the kick-off 1.0 release of the Telephone Application Programming Interface (or TAPI) in the early '90s. Developed jointly by Microsoft and Intel, TAPI was a layer of middleware that performed basic telephony functions, like autodialing.

You linked a serial cable between the vendor's modem or digital phone (modified to hold an RS-232 port) and desktop personal computer. PC application software made TAPI calls, and the TAPI middleware translated these computer commands into telephony ones, which were sent to the PBX via the phone. Because you - or the software on your desk - were directly communicating with the attached telephony device, the arrangement was referred to as first-party call control.

The response to TAPI 1.0 from the telecom world was less than enthusiastic. "The industry looked at TAPI and sort of laughed at it," says Murray Judy, vice president of engineering at San Diego-based Sonant Corporation, a maker of call center ACD software. "The only thing it turned out to be truly useful for was modems".

"Modem vendors jumped on TAPI," he adds. "For actual telephony, the early versions of TAPI were not very useful." One of TAPI's disadvantages: Information collected about the caller - phone or account number - could not follow the call when it was transferred, making TAPI 1.0 less than suitable for call center environments.

TAPI became more useful, especially to PBX vendors, after the release of version 2.1 in 1998. The upgrade let users control a desktop phone via an external server (from the vantage point of the desktop phone). The industry labeled the new architecture third-party or client-server call control.

"You could write software that would talk to TAPI and allow you to answer and control calls for telephones that were not your own," says Judy. "[TAPI] could be employed in a server environment rather than a desktop one."

Judy says that to get into the CT game, PBX vendors needed to expose enough of their switch's functionality to support Microsoft's telephony interface. In the Microsoft worldview, vendors of telephony equipment had to develop the Telephony Service Provider Interface (TSPI) layer of the middleware, which performed the real work of controlling the switch. The TAPI acronym is probably more familiar to Teleconnect readers, but its fame exceeds its actual function. Judy told me TAPI merely relays commands between the application and the TSPI.

"All Microsoft really did was provide this common set of interface calls [TAPI], but it didn't really do anything," says Judy. "There's no real functionality built into TAPI. It requires a service provider [TSP] to do the work."

Starting with TAPI 2.1, PBX makers wrote the TSPI layer - essentially a device driver for their switch. They loaded the TSPI onto an NT server linked to the PBX by a serial cable or other interface. The single NT server running the CT software became the "CT server" , the central repository of all call-related information. Because the server could control calls for each extension, PBX vendors no longer had to TAPI-enable individual phone sets and force customers to link ugly cabling between phones and computers. That kept costs down and made for swifter deployments.

With third-party call control standards now available, independent developers got into the game of designing "soft" ACDs. Running as an application on the CT server, call routing software could send calls to the right agents and deliver the associated caller ID and IVR-(interactive voice response-) collected data to the agent's desktop workstations. Communications between desktop CT applications, like soft-phones and TAPI-compliant PIMs (personal information managers), and the CT server occurred over the existing office LAN (local area network).

In parallel with Microsoft's efforts, ECMA (European Computer Manufacturers Association) standards committee devised a CT standard for third-party call control, CSTA (Computer Supported Telecommunications Applications). ECMA brought together computer companies and telecom company's, AT&T being the most significant member on the voice side.

Later, Novell adopted CSTA when AT&T sold its UNIX division to this Provo, UT-based networking company. In the early '90s, Novell created a programmatic interface for CSTA, called TSAPI (Telephony Services API), which translated CSTA to Novell Netware. Novell thereby beat Microsoft to a client-server call control architecture by several years. In the telecom world, Parsippany, NJ-based Dialogic (now Intel's Telecommunications and Embedded Group) incorporated CSTA into its CT Connect middleware. Many soft ACD vendors, in turn, embedded CT Connect into their call center software.

Everyone Likes Middleware Standards

Whether call center software is based on CT Connect, TSAPI, CSTA, or TAPI 2.1, third-party-based software, with its layers of software abstraction, hides PBX and telephony device dependencies from the application software. Call centers buy soft ACDs for their telephone switches. But when the time comes to replace the phone system, they can continue to use the same middleware, just switching one PBX vendor's TSPI for another. The rest of the middleware infrastructure and applications remain.

Makers of call center software gain from these CT middleware standards as well. They maintain one set of application code, which can work with any vendor's switch. Upshot: lower development costs and lower application prices to call center customers.

However, there's one catch for call center application developers who build on top of third-party middleware: lower profits because the developer typically pays a percentage of revenue from software licenses to the middleware provider.

"Most [developers] start with [Intel/Dialogic's] CT Connect; and if they see a lot of business with one switch, they write [the middleware] natively because they don't want to give up the margin to Dialogic," says Ernie Wallenstein, VP of marketing and business development at EasyRun, which integrates CT Connect into its EPICCenter ACD software.

"For the small to medium business marketplace, the cost [of adding CT Connect to a call center application] is actually a percentage point," he adds. "At the high end, five or eight grand on a $500,000 deal doesn't mean anything. But five or eight grand on a $50,000 deal means something."

Though reducing the developer's margin, the middleware is well suited to a rapid "go-to-market strategy", says Wallenstein. And, if the business looks good, you regain margin by writing the CT middleware layer yourself.

Back at the Call Center

What do call centers want? Depending on whom you talk to, there are from 60,000 to 100,000 call centers below 100 seats. Wallenstein believes this segment, which represents 90% of all call centers, can't afford, and doesn't necessarily need, all the customer relationship management (CRM) tools that Fortune 500 companies buy. Even large enterprises don't always implement, or efficiently use, some contact center solutions, such as voice over the Web.

Wallenstein (who previously studied the business models of CRM competitors Aspect Telecommunications and Genesys Telecommunications Laboratories at software developer Apropos) suggests most small contact centers would probably be satisfied with the essentials. These include good skills-based routing; interactive voice response (IVR) for simple customer requests; multimedia interaction (e.g., voice and email); and a quick deployment.

"By building apps on top of client-server CT middleware, call center solutions providers", says Wallenstein, "can quickly and cost-effectively deliver this functionality. Standardized interfaces to PBXs make for easy installation. Centralized databases in CT servers drive the routing decisions. If agents are busy, an IVR application communicating with a voice card on the CT server can pull up account balances or other customer information in response to DTMF (dual tone multi-frequency) or touchtones."

CT middleware, embedded in call center ACD applications, brings caller ID to the desktop, transporting the data via LAN from the CT server. However, application providers still must integrate their software with existing customer apps. Yes, a TAPI-compliant PIM, like Outlook or a soft phone, will work right away. But applications not designed for telephony, such as a Windows-based data entry program, present more difficulties.

Microsoft had the answer with its many Windows standards for exchanging data between applications, like DDE (dynamic data exchange), OLE (object linking and embedding), and, more recently, COM (component object model). VARs or dealers who install the CT application software will usually perform the Windows customization needed to pass call data to a customer's back-office applications.