Billing and Customer Care: Meet Java

These days talking about information technology development without having Java enter the picture is nearly impossible. It seems that everyone is jumping on the Java bandwagon, and the telecommunications industry is no different. Java's technology promises hardware independence, simplified application development, legacy system integration, standardized APIs, reduced IT and training costs, and a host of Web-enabled services. Of course, no one will know for sure if Java can deliver until it's put to the test. Regardless, this technology is moving at high speed at a time when the industry needs answers. Billing and customer care are two areas that may benefit the most from Java, and particularly call center operations as telecommunications providers look to reduce costs and increase efficiency. Similarly, Java technology will help enable a wide range of Web-based customer self-service applications that might otherwise not be possible or economically feasible.

Java in the Call Center

"The whole goal of any billing or business group within a telco environment is uniformity, "says Doug Ehrenreich, director of market strategies and technologies for the telco market at Sun Microsystems. "They're trying to take the complexities out of a heterogeneous environment." A complicated, heterogeneous environment is often the case in a call center. There may be any sort of mix of desktop computing environments backed up by various underlying data and voice technologies from different vendors and vintages with multiple APIs. The result is often an uncoordinated set of systems that becomes increasingly complex as new functions or technologies are added. Furthermore, even those systems that manage customers and information effectively become increasingly inflexible due to a lack of a uniform development environment and this mix of technologies.

To solve these problems, Ehrenreich says, telcos will look to "fix the cost of operation and maintenance within the call centers and improve the customer service levels. That tends to focus on improving the environment for the agents, helping them with better tools, better information and abilities to service the customer."

The browser environment

Java may provide the uniform environment telcos have been looking for. Because Java runs in a Web browser paradigm, Java applications are relatively easy to learn, using the same point and click, page-turning capability that has helped the Web become exceedingly popular. Such an environment may reduce training time while making CSRs more efficient. Many older customer service front-ends were script-oriented and not generally integrated. This meant that CSRs, while in contact with a customer, had to collect information from several different sources and then enter it into a rigid set of screens or fields. Once a screen was completed, however, it was extremely difficult, if not impossible, for the CSR to go back and make changes. With a browser environment, a CSR can move back and forth between pages, while the system may graphically prompt the user for any necessary information. As well, the overall application can be updated or expanded without the CSR having to learn a new working environment, because the browser framework remains basically the same.

The desktop

Another benefit that Java may bring is a reduction in the cost of the desktop device. Currently, desktop devices generally are PCs that require a large amount of memory and disk space to run locally stored applications. But PCs are expensive, and the common CSR doesn't really need a PC's power. Sun Microsystems has developed Java-devices for the desktop, so-called "thin clients." These require much less memory than PCs and no disk space because Java applications that are stored on and downloaded from a central server. Because thin clients require less hardware, they are less expensive and should help to reduce costs. Further, because Java applications are stored and managed centrally rather than locally, updates and maintenance to call center software become much simpler, thus improving system uniformity.

Java APIs

For Java applications to be implemented in a call center environment, application-program interfaces (APIs) are necessary so Java applications can communicate with embedded call center hardware, such as ACDs and PBXs. The first of such APIs-the Java Telephony API or JTAPI-was developed jointly by Lucent, IBM, Intel, Nortel, Novell and Sun. JTAPI was designed to define the core set of class libraries, functions and capability sets for integrating computer telephony integration (CTI) functions into Java applications. With the API and thus the necessary parameters defined, call center applications can be developed in Java using one of several toolkits. IBM, Sun and Lucent have all released development toolkits based on the JTAPI and more are on the way.

The problem with older development environments is that certain telephony functions become extremely difficult to enable for CTI. Bill Riley, director of CTI for Lucent, explains that in the early days of CTI "most of the API libraries did the same thing in the end, but from a syntax and format perspective everything was different." Dealing with multiple nonstandard APIs makes any development project a nightmare. Lucent introduced its Telephony Services API (TSAPI) to address this issue but it is, Riley admits, "still a procedural API with specific functions within a C language library. Just to do basic telephony kinds of things which today on a telephone set seem obvious É the software developer must write a series of function calls, or a fairly detailed amount of coding, to make that happen."

Implementing functions such as transfer or conference on a workstation requires a high level of custom, API-by-API coding. Java APIs simplify this process because they allow prewritten Java objects that would be included in a Java CTI toolkit to be used instead. A combination of widespread acceptance and simplified development capability seem to be turning Java into a new, unofficial industry standard. JTAPI has been submitted to the ECTF (Enterprise Computer Telephony Forum) for further definition.

Java's Limitations

Though Java has entered the market with much bravado, there are limits to what it can do. "The software development community, specifically those folks who are writing customer service/customer care applications, don't know what they don't know yet," says Riley. Because the Java APIs and development kits are new, what will come out of them is difficult to predict. At present, most of the work being done is migratory-current functions are being migrated into Java. New functions will be integrated in time, but software developers are just beginning to understand what the telephony component of Java has to offer. "We're going to see applications feature and function-wise that do things that no one is doing today," Riley suggests. What will these functions be? No one is quite sure yet, but as Riley explains, toolkit developers such as Lucent have never really been able to predict the creative uses their customers often devise for development kits.

What about the Present?

"Our view is that [Java toolkits are] not yet robust or as full functioned as current development environments," says Russell Stanners, director of telecommunications systems at IBM. "It has a lot to do with the newness of the toolsets. In terms of [Java] becoming the accepted market standard, it's only been a year or two so the toolsets aren't as mature." Will this cause any serious problems for Java in the near future? Probably not. Java's momentum will keep it moving and as development grows, so will the toolkits. Is the Java development environment ready to take on mission-critical applications? It is beginning to be used for such projects, but Stanners says, "I wouldn't bet my business on it, but I would bet my business on some of the tools that will be going to Java in six to eight months." This is, he says, because many of these tools are already robust, proven development kits. IBM has already invested a great deal of money and manpower in Java, according to Stanners, with development teams working 24 hours a day in the United States, Europe, Asia and Africa to Java-enable their VisualAge development kit. Says Stanners, "What we're doing is advising our customers on the technology that will allow them to move down the Java path once it's a bit more functional."

Java Provides Self-service for BT Customers

Most of Java's use so far in billing and customer care has been to provide enhanced, interactive Web-based services. While Java may not be ready to handle mission-critical applications yet, it is generally agreed that "it's particularly good, at this point in time, for supporting simple inquiry-type transactions," says Stanners. Java can enable a host of customer self-service functions such as access to billing information and online service ordering. Eventually Web-based telephony will allow a customer to automatically contact a CSR by, for example, clicking on a specific icon.

British telecommunications provider BT is currently taking advantage of Java's Web capability and has recently rolled out a new service, ServiceView, to its large corporate customers. ServiceView is a thin-client, Java-based set of customer service applications that will allow customers to check billing records, order new services, check network status and configuration, submit trouble reports and eventually video-conference with CSRs online. The system was designed using Oracle's Developer 2000 development toolkit. BT will give its customers Sun JavaStation thin-clients to access the system, which should cost 40 to 60 percent less than typical thick-client PCs, according to the company.

BT hopes to convince customers who are not necessarily experienced Internet users to use this service. ServiceView has been designed with a built-in wizard to guide novice users through the system, thus eliminating the need for a training course. "Basically what BT is doing is opening their operational network to their customers. It's what they call a CNM, customer network managed, application. So their customers can actually provision, change and modify the circuits they are running within their virtual private networks," explains Ehrenreich. ServiceView reportedly supports automated, flow-through provisioning so that when a customer orders and provisions a new service, the system sends commands to the proper back-office systems to activate it automatically. If successful, BT will offer ServiceView on the open market under a new name to companies that wish to increase their Web-based customer service capabilities.

Java's Long-term Impact

Considering the current frenzy around Java, there is no doubt that it will soon play a more significant role in billing and customer care. Several RBOCs are reportedly Java-tizing their service negotiation systems right now with many billing vendors following suit as well. There are complaints arising, however, that say early Java applications can't perform up to expectations. Though it seems that many problems have already been worked out for the next wave of Java applications, Riley says, "The real truth will come when we're in the process of rolling out applications."

Billing World will continue to follow Java's effect on billing and customer care throughout the next twelve months. If your company is active in this field and has anything to contribute, please contact Ed Finegold at (703) 734-2622 or finegold@telestrategies.com.