Building the next-generation customer contact center

Picture this: Instead of having to operate an expensive call center tied to a physical location, you’ve created a virtual, multimedia contact center staffed by agents working from home or in distant offices, connected through a voice-over-IP network. Is this hype or reality?

Picture this: Instead of having to operate an expensive call center tied to a physical location, you’ve created a virtual, multimedia contact center staffed by agents working from home or in distant offices, connected through a voice-over-IP network.

You’ve launched money-saving, self-service customer applications based on standards such as XML and VoiceXML that reduce the load on your agents. You’ve integrated your CRM  software with computer-telephone integration (CTI) so that back-end database information on customers is available to agents in the form of screen pops.

Customers reach your contact center any way they wish – voice call, e-mail,chat and real-time collaboration over the Web. The customer experience is consistent across all media, and each interaction is immediately reported so updated information is available right away. The contact center blends resources, and manages and reports on all contacts via a common application suite.

Is this vision hype or reality? The answer is a little of both. This contact center is possible with today’s technologies, but full-blown implementations are still few and far between. However, experts are confident that VoIP-based, multichannel contact centers are the future of customer relations, so it’s important to start planning.

The next-generation contact center requires two fundamental architectural shifts. In the network infrastructure you need to shift from the TDM/PBX world to VoIP. And in the applications infrastructure you need to migrate call routing and reporting, traditionally handled by automatic call distributors (ACD), from closed switching systems to open, industry-standard servers.

Open architecture

Open architecture offers the promise of infrastructure-agnostic applications. Routing, reporting and management functions can run on a server that talks to the switching infrastructure. Open applications can seamlessly route voice calls, e-mail and Web-based contacts, and they can connect online customers with contact center agents via chat, escorted browsing or collaborative form completion. Switch vendors offering open architecture contact-center products include Aspect, Avaya, Cisco and Nortel .

The idea is that once contact-center applications are freed from single-vendor proprietary systems, customers would be able to select best-of-breed products. This open architecture would attract a larger pool of application developers, leading to new capabilities, lower costs and improved integration.

For example, Nordea, a Swedish financial services company servicing 3 million customers and handling 44 million calls per year (85% of them automated), has deployed Genesys’  Framework to transform its contact-center operation, improve the customer experience, and save more than $1.5 million per year.

Nordea migrated from the ACD applications on its Nortel switch to Genesys server-based software to manage not only phone calls, but also other media. The Genesys IP Contact Center routes contacts and integrates with Nordea’s information systems and databases. And rolling the system out to additional sites was relatively quick once the initial infrastructure was in place.

Customers have the choice of which channel they want to use to reach the company, and the Genesys software funnels customers to the best available and qualified of 1,000 agents in 14 centers, considering language, product/service and customer type.

Limitations, opportunities

With an open architecture, users theoretically can mix and match products from various vendors. But that point has not been reached yet. For example, switch infrastructure vendors offer specialized applications that are tuned to their own products or they promote the pre-integrated capabilities of their server applications – tying together ACD, interactive voice response (IVR) and CTI functionality. So the world is not as “open” as it might seem.

On the plus side, customers can use standard interfaces to make integration easier. For example, APIs, such as TAPI and JTAPI, link switches to servers. CRM and CTI solutions integrate with prebuilt adapters, such as the Siemens CRM Ready Kit or the Genesys G-Plus adapters. These allow for integration with a top-tier CRM package, such as Siebel, in hours or days, rather than weeks or months. Similar connectors integrate IVR systems and reporting tools. (See graphic)

Other tools further the goals of openness for ease of integration, interoperability and portability. Standardized yet flexible data schemas and data access provided through SQL, Open Database Connectivity (ODBC) and XML are examples. The architecture frameworks of Java 2 Platform Enterprise Edition, .Net and Common Object Request Broker Architecture  also are becoming prevalent in contact-center applications today.

Vendors have been responsive to customers’ need for easy integration by offering an increasing number of connectors. Many leverage standard tools, such as ODBC; XML; and extraction, transformation and loading (ETL) applications. Faster and easier integration of the diverse elements in a center is critical to enabling efficient and effective resource management.

Most vendors seeking to integrate with CRM solutions have, or will have, connectors to the top four products (Oracle, PeopleSoft, SAP, Siebel ). For these vendors, there likely is a full-blown product. For others, it is an open hook – a software development kit (SDK) or API that can be written to more readily. CRM and CTI integration now is tackling the thin client architecture, which most CRM packages also are migrating to.

One example of a successful connector approach is the AT&T Headend in the Sky (HITS) implementation of Siemens CRM Ready kit with Clarify (now Amdocs). The HITS Digital Media Center services cable companies nationwide. The cable companies wanted to route contacts on open issues to the last agent who handled it if possible, and pop the trouble ticket on the screen. Siemens and AT&T integrated 60 agent desktops in one weekend, avoiding a large systems-integration effort.

Voice self-service apps go standard

Open architecture also applies to interactive voice response, where one server runs the speech processing for a natural-language user interface, and another runs the standard VoiceXML code of the core application. Both are communicating with standard voice-processing cards.

IVR vendors are supporting the VXML standard; most are or will soon be Version 2.0-compliant. This architectural change has huge potential to open the previously small pool of developers and enable portability of applications, while leveraging the Web infrastructure and common data.

However, Version 2.0 of the VXML standard needs significant extensions to support customer contact applications. CTI-based call control, screen pops and integrated reporting are examples of functions that require capabilities beyond the standard. So a standards-compliant application might not be portable across platforms.

Many vendors generate VXML code from their proprietary graphical user interface as an option, easing the migration for those with in-house programming expertise on their current platform (but this code is not portable to a different platform if it includes any extensions). Some, such as Genesys, are agnostic about standards. They will work to promote the development of the VXML as well as Call Control XML standards. They also will comply with and support Speech Application Language Tags, a competing standard Microsoft is promoting.

Ready, set, implement?

So what’s holding users back from implementing open application architectures?

•  Some products aren’t mature; VXML, for example, is just being used by early adopters.

•  Some interfaces aren’t truly open.

•  Not enough “canned” interfaces exist, partly because they are vendor-specific, not standards-based.

•  It can be hard to integrate solution elements, potentially resulting in significant system integration costs.

•  The products don’t plug and play the way they’re marketed.

•  Not many have done it before them.

•  Maintenance and ongoing management costs can be high; for example, an upgrade or new release in one element can have a ripple effect to other elements for upgrades and testing.

As a customer, you must evaluate potential costs and trade-offs in integration, problem resolution, upgrades and the like. Your strategic approach to vendor and product selection needs to consider the tradeoffs of integrating best-of-breed products vs. buying a suite of products from one vendor.