March 1998

COMPREHENSIVE TESTING FOR THE FEATURE/LOAD CALL CENTER

BY NATHAN DAVID

Call centers today are distinguished by their increasing role in business operations. As the "brick and mortar" fade, the call center is becoming the primary interface between corporations and their customers. This customer/ corporation interface continues to evolve — both technically and from a business function perspective. The call center is today’s example. What will tomorrow’s example be?

Superimposed on this continually changing environment is an abundance of vendors who is providing products with increasing capabilities and scope. Given this situation, it would appear easy to deploy a call center that can be extended to meet the corporation’s future needs. Unfortunately, it is possible to get into a state of implementation paralysis and not even meet the corporation’s needs of today. While call centers are developing at the speed of their markets, the most important implementation process, testing, is being minimized by delivery deadlines, the misunderstanding of the interdependencies of each component in the process, or the sheer absence in the development lifecycle.

FEATURE/LOAD TESTING
Comprehensive feature/load testing is critical to ensure that your applications will support the service level agreements with your customers, while providing the efficiencies to the call center market. Comprehensive testing means a lot more than making a few test calls or even traditional bulk call generation. Your testing must verify that the call center operates correctly under real world conditions. This requires measuring and verifying the reactions of the various call center components under varying load conditions.

The importance of a detailed technical architecture that describes how the various components meet your business objectives cannot be stressed strongly enough. It’s best to turn to the experts at evaluating and designing solutions that integrate the multiple technologies and applications required to deliver an intelligent call center solution. Examples of these solutions can be found in the sidebar titled Assorted Call Center Technologies.

The concept of computer-telephony integration (CTI) or any other integrated telephony application working in a lab environment and then performing less than spectacularly once in production is not so much a question of the robustness of the product, but rather inadequate planning and execution of testing and support methodologies.

A LIFE EXPERIENCE
Some time ago, I had the privilege (or curse) to have been deeply involved in the design, development, deployment, and support of an integrated CTI/IVR/PBX solution for a $200 billion financial institution. This project was to include all the bells and whistles: desktop telephony, IVR integration, common functions (i.e., customer history, call statistics), and the like. The rollout of this technology was going to solve all the ills of the organization and return thousands of dollars in toll savings and increased agent productivity. The product eventually did provide the envisioned return — but not before inflicting heavy casualties in the form of confused agents and frustrated customers.

Measure Twice, Cut Once
The rollout was painful at best, and upon reflection, comprehensive feature/ load testing of this implementation would have eliminated the negative impact experienced during that first harried month of production. This is not to say we were completely na�ve and incompetent, and pushed a product into production without the benefit of a test plan. Unfortunately, we made the mistake of believing we understood how to properly test a fully integrated CTI solution. This mistake is still made — daily — throughout the CTI industry. Those responsible for testing and support are either not fully aware of the complexity of the system or they are brought in only at the tail end of an implementation, rather than at the beginning.

Change The Mindset
As a solution moves through the various stages of design and development, an understanding must be cultivated within the IT organization: An understanding that the testing of CTI/IVR/PBX solutions must be approached differently and that a certification process of systems capacities must be developed. IT professionals must approach the CTI/IVR/PBX solutions as one complete product and not rely on individual vendors to test and certify individual components for maximum throughput and capacity.

For example, IVR system vendors will quickly sell fully loaded systems and assist buyers in capacity planning for these systems — all prior to actually building and stress/load testing the entire network with all components in place. The manner in which the script and messaging of any CTI/IVR/PBX solution is modeled will undoubtedly impact the performance of the overall system once capacity is increased to a specific level. It is, therefore, important to have a mechanism to determine that threshold and apply a compliance rating for the entire solution. This compliance rating will comprise all the key components within the solution network. Understanding the complexity of IVR scripting, CTI messaging, mainframe, or database communications (EHLLAPI, MQ threads, etc.) is just the first step to developing a compliance rating.

As an IT professional, you must then venture into uncharted waters. You must actually begin to understand all the different call types and the call mix. For example, the transaction sets to complete a simple inquiry of a DB2 database require less horsepower than the retrieval of months of customer history records for a large relationship. Understanding what the current mix of customer calls is will assist in determining what the system will be expected to support. Once you begin to peel back the layers of this onion, you may find that system you purchased and built to handle 20,000 calls a day will only handle 10,000 calls while maintaining appropriate service levels.

Proof Of Concept
Effective testing is based on a thorough understanding of the business purpose, design goals, system configurations, interfaces, and expected traffic conditions. As each capability is planned and designed, a proof of concept methodology can also be devised to support various stages of development as well as the final acceptance process.

EFFECTIVE TEST PLANS
The test plan for each situation is different, but there are some common elements. While using the public/private networks to access a call center, it is important to introduce testing at anticipated production volume levels. Engineers and developers who have been there can no doubt tell tales of countless midnight "pizza parties," placing a multitude of calls, attempting to create enough volume to stress applications, only to have that testing provide a false sense of security. The mentality of being in a development "silo" carries over to testing patterns. Historically, components are tested to a given set of standards and developers sign off on its completion. In a call center situation, you inevitably have multiple components that make up a singular process (Figure 1). Although each component has been vertically tested, it is critical to recognize the interdependencies of a horizontal testing approach, thus identifying areas of action. Examples of what to verify and where to implement such horizontal testing include: networks, ACD, voice response, CTI, and PBX and voice messaging.

Networks
Call prompting, call allocation, call distribution, call redirection, and other capabilities can be verified for functions and capacities. A variety of traffic patterns and volumes can explore the effectiveness of call handling mechanisms.

Automatic Call Distribution
DNIS routing, ANI routing, time/date routing, call prompting, management reports, and other capabilities can be verified for accuracy and completion.

Voice Response
ACD interaction, call prompting, information input, information access, database access, legacy system interaction, transfer to live ACD agents, and other capabilities can be verified for functions, capacities, and response times. The custom nature of each of these applications make them prime targets for verification under high traffic conditions.

Computer-Telephony Integration
ACD and other interfaces with data systems can be exercised for call routing, agent expertise, screen pop, outbound preview dialing, data network impact, and related services in terms of functions, capacities, and response times. Additionally, data networks are scrutinized due to the amount of data being communicated to the desktop.

PBX And Voice Messaging
A call to each direct inward dial (DID) telephone number can verify proper telco assignment, correct PBX administration, voice message coverage, fax machines, modems, and more. While the products are diverse, the process to a successful implementation should include a comprehensive feature/ load testing plan. The following actions will assist you in being successful in a call center implementation:

• Understand CTI testing. (There are numerous books and online sources of information on the testing of CTI systems and networks.)
• Address service objectives.
• Develop the test plan.
• Select test tools.
• Execute tests and analyze results throughout the entire lifecycle of a project.

NEXT STEPS
Today’s call center environments are complex and, the fact is, they will only continue to increase in both complexity and functionality. Enterprises of the future must be able to provide a level of service through alternative delivery systems, thus maintaining or even increasing market share. This can only be accomplished through an iterative process of improvement, the key of which is maintaining a superior level of available information and services through whichever channel a customer chooses to use. Feature testing and monitoring programs are the only way to ensure these delivery systems are available to push information and services out to your customers. If your systems are not available, those of your competitor will be.

Nathan David is president of ADSS, Inc., a leading provider of VRU/ CTI/Switch Stress Testing and Service Monitoring services based on systems from Hammer Technologies. Nathan can be reached at 904-262-2080. For more information, visit the company’s Web site at www.first2know.com.  Hammer’s Web site can be accessed at www.hammer.com.