TITLE
User-Controlled Voice Application and Voice Application System Infrastructure Component Testing
FIELD OF THE INVENTION
The present invention relates generally to voice application testing (VAT) and voice application system infrastructure component (VASIC) testing, and more specifically to user-controlled VAT and VASIC testing wherein performance metrics are available at a web site and are accessible via a web browser.
BACKGROUND OF THE INVENTION
Contact centers are well known as those systems to which a person can communicate to receive information. Such communication can include, but is not limited to, telephone calls, Internet access, email, and FAX. A contact center can include one or more PBX/ACDs or interactive voice response (IVR) systems. The one or more PBX/ACDs may route the call to the appropriate IVR or the one or more IVRs provide automatic branching voice queries to which the caller responds with button pushes on a telephone keypad or with voice responses on a telephone. The contact center is provided having only the one or more IVR systems, or alternatively, it is also provided having human agents. For example, at the end of the IVR branching voice queries, the caller can be directed to press zero to speak to an agent. The agent is a person having a telephone to talk to the caller, hereafter referred to as an "agent telephone," and a computer to access information about the caller, hereafter referred to as an "agent computer." Note that though the agent telephone and the agent computer are often associated with one person, they correspond to distinct electronic systems and will be separately referred to herein.
The contact center can also include one or more database server computers, one or more database storage areas, one or more web server computers, and one or more email server computers. These systems are also referred to as voice application system infrastructure components which have voice applications running thereon.
The VAT and VASIC systems associated with a contact center can be tested in a variety of test contexts. A virtual telephone caller system has been applied to the variety of test contexts. For example, functional testing is known as the testing generally performed before the VAT and VASIC system is released to the public to verify that the system is properly functioning, the functional testing generally performed by a designer of the VAT and VASIC system. For another example, load testing is known as the testing that is generally performed while the VAT and VASIC system is in public use to verify that the system can accommodate at least a certain number of simultaneous telephone calls, the load testing generally performed by a contact center manager. Alternatively, the load testing can be performed while the VAT and VASIC system is not in public use. For yet another example, monitoring testing is known as the testing also generally performed while the VAT and VASIC system is in public use to verify that the system is operational, the monitoring testing also generally performed by the contact center manager yet in an automatic background mode (e.g., a single test call every 15 minutes with one or more retries if the initial call fails).
It should be appreciated that the term testing as used herein includes functional testing, load testing, and monitoring testing, each have different requirements. For example, a designer of the VAT and VASIC system using a functional test may want to test each of the variety of paths through the call flow diagram representing the VAT and VASIC system, i.e. each path through the variety of branching call options presented to a telephone caller. In functional testing it may only be necessary to provide a single virtual telephone caller which exercises in sequence most or all of the possible paths through the call flow diagram. For another example, a contact center manager using a load test may want to test only some of the variety of paths through the call flow diagram. In load testing, it is desirable to provide a large number of virtual telephone callers to test the delay time latencies that can be caused by many simultaneous telephone callers. For yet another example, a contact center using a monitoring test may want to minimally test the general operation of the contact center from time to time. In monitoring testing it may only be necessary to provide a single virtual telephone caller, thereby exercising one or a small number of paths through the call flow diagram.
The contact center is the primary point of customer contact for many companies today. Many VAT and VASIC transaction problems occur as a result of system or network slowdowns and failures outside of the system itself. The transaction problems may be the result of system and network problems external to the system. For example, a common problem occurs when mainframe database connections to the VAT and VASIC system slow down or fail completely. Mainframe slowdowns and outages impact database lookups such as verifying account and PIN numbers, account balance inquiries, and the like. In these situations, the VAT and VASIC system itself may appear to be working normally to a Network Operations Center when, in fact, customers are encountering problems. Another example occurs when trunk groups are out of order or call routing errors are occurring. Customers, thinking the system isn't working, may try to "zero out" to Customer Service Representatives (CSRs). As a direct result queue times in the contact center start rapidly escalating, or even worse, customers, faced with non-functioning systems, may simply hang up and call a competitor. At one large contact center recently, an entire trunk group was out of order for 24 hours before the problem was discovered. It was estimated that over 20,000 customer calls were lost.
For smaller contact centers, which do not staff 24x7 operations, VAT and VASIC applications may be the only service available to customers for after-hours inquiries or transactions. Should the VAT and VASIC become unavailable over a weekend or holiday, it may take 48 hours or longer before the problem is even discovered.
Sometimes, undiscovered errors on VAT applications can cause customer calls to be mishandled or dropped entirely. For example, a large computer manufacturer using VAT and VASIC system for its customer service operations was unknowingly playing the wrong prompt. Callers to one of the company's many 800 numbers were greeted with "All of our representatives are busy. Please call back later." Calls were then disconnected. It wasn't until a customer called the company's main switchboard to complain that the contact center became aware there was a problem. In another situation, a large bank had an undiscovered error in one of its VAT applications that caused calls received after 11 :00 PM to go into an endless loop.
One large contact center estimated that it took nearly four hours for contact center operations to return to normal after a VAT and VASIC outage. Customers, unable to use the system, typically "zero out" to speak to a CSR, encounter excessive hold times, hang up, and try again later. This process starts a snowball effect as hundreds or thousands of callers repeat the same pattern.
The impact of VAT and VASIC outages on contact centers can be significant. It is estimated that, on average, a single 20-minute outage results in nearly four hours of contact center overload. The costs of these outages included extra staffing expense in the contact center, extra lines required because of repeated customer calls during the outages and extra toll expenses due to increase wait times. Most significantly, additional expense is incurred for each call handled by a CSR that would previously have been handled by the VAT and VASIC systems.
It is surprising that so many contact centers, given the relatively high potential of experiencing a serious failure, take few if any preventative measures. Most contact centers today perform only minimal testing of new or modified applications and systems prior to live deployment. Most testing that is done is manual, including testing of VRUs and other CTI systems. Manual testing typically consists of a handful of people dialing in, and trying to find problems.
The only way most companies know anything is wrong with their VAT and VASIC systems is if a customer calls to complain. While most companies actively monitor their human contact center agents to make sure customers are not encountering problems, most are not proactively monitoring their automated VAT and VASIC systems. This represents a significant business risk. With VAT and VASIC systems handling an estimated 70-80% of all customer inquiries in some companies, undetected transaction problems can quickly translate into lost customers and lost revenues. A single 20-minute outage or slowdown of VAT and VASIC systems in larger contact centers can impact thousands of calls at a potential cost in the tens of thousands of dollars.
Even after discovering that there is a problem with one or more VAT and VASICs, finding exactly where the problem is and correcting it can pose a significant challenge. In an age of distributed contact centers and distributed call routing, it can
take hours just to identify the source and cause of a VAT and VASIC problem if you have a large number of VAT and VASIC system
Recognizing the serious customer service problems and higher expenses caused by "out of order" VAT and VASIC applications, some companies have started manually monitoring their contact center VAT and VASIC applications with the goal of reducing system service or downtime. A group of technicians monitor VAT and VASIC systems by physically dialing into each system and application on a scheduled basis to ensure that everything is working properly and customers are not encountering problems. This approach, though time consuming and expensive, has helped to reduce the impact of undiscovered VAT and VASIC outages. This manual process pays for itself by reducing the time it takes to discover problems and pinpoint the cause. By finding and fixing VAT and VASIC problems more quickly, fewer calls overflow from out-of-service systems to contact center CSRs. Keeping more calls in the VAT and VASIC systems reduces overall transaction costs and more than pays for the cost of physically monitoring the VAT and VASIC applications.
Manual testing, in most instances, simply cannot replicate the conditions that cause contact center system and applications to fail. This is because many network, system, or application failures only show up under normal operating conditions or under extreme operating conditions. Manual testing cannot replicate the call volumes or variability in call type and duration that cause systems and applications to fail. Manual testing also suffers from a lack of consistency and repeatability; two critical requirements for effective test plans. As a result, it is the customers who are finding most of the bugs and problems in contact centers today.
Traditionally, voice application testing and monitoring has been accomplished through two means. A first means is by contracted service personnel who configure, schedule, and run tests. The contracted service personnel then view real-time results of the testing and configure associated alerting.
A second means to accomplish voice application testing and monitoring requires the downloading of specific, sophisticated client software for direct access to a specific test system. Both of these prior means require specific, technical system knowledge, as well as specific client software.
Voice application testing involves automated generation of test calls and measurements to ensure that contact center applications - voice, CTI and web - are fully functioning from a customer perspective. Voice application testing and monitoring is critical for both detecting contact center problems before they affect customer service, and for optimizing overall system performance to minimize delays and associated costs. Traditional network and system management tools will not indicate there is a problem; therefore conventional network-based system monitoring solutions should not be relied on as the only solution for detecting IVR transaction problems.
In a recent survey of contact center managers, 44% said that they had experienced a serious outage in their contact center within the past twelve months. 32% had experienced a serious failure within the last six months. These statistics aren't surprising, given the complexity of today's integrated contact center operating environment. Many of these outages could have been prevented by the use of automated test systems as part of a comprehensive Contact center Quality Assurance process, including In-Service testing of contact center network connections, systems and applications.
The benefits resulting from improved application and system reliability in contact centers can be significant. In a contact center receiving 1,000 calls an hour, a 30-minute outage can potentially mean 500 customers who are negatively impacted. If a web site is down or overloaded and difficult to reach, a provider could be negatively impacting similar numbers of customers and might not even know it. Even a brief outage can translate into hundreds of thousands of dollars in lost revenue if the provider is an airline reservation center or brokerage firm. It's simply too easy today for the customer to contact a provider's competition. In addition to measuring the cost of lost customer transactions, a further consideration is the cost of losing a customer.
It would, therefore, be desirable to provide a method of providing voice application testing and monitoring to a contact center manager by way of a web interface such that the manager can be continuously aware of the status of their voice applications, and can be made aware at remote locations.
SUMMARY OF THE INVENTION
The present invention provides for VAT and VASIC testing performance metrics generated from the testing which are posted to a web site. This allows the contact center manager to view data, graphs, reports, and alert information in real-time, and further allows the manager to remotely configure and schedule alerting and testing of the voice application as well as allowing the manager to select an immediate retest of the VAT and VASIC, all of which can be accomplished via a web browser from any web-accessible computer.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will be more fully understood from the following detailed description taken in conjunction with the accompanying drawings, in which: Figure 1 is a block diagram of a contact center; Figure 2 is a screen shot of the web interface of the present invention; Figure 3 is a screen shot of a first sample of data provided via the web interface;
Figure 4 is a screen shot of a second sample of data provided via the web interface;
Figure 5 is a screen shot of an alert setup; Figure 6 is a screen shot of theretest now function ; Figure 7 is a screen shot of graphing and CTI information gathered in real-time during test calls;
Figure 8 is a screen shot of detailed Agent information aggregated to verify call routing ;
Figure 9 is a screen shot of service level thresholds that can be set and tracked by users via the web interface;
Figure 10 is a screen shot showing the dynamic update of information; and Figure 11 is a screen shot showing comparisons across multiple sites.
DETAILED DESCRIPTION OF THE INVENTION Referring now to FIG. 1, a prior art contact center 1 is shown. The contact center includes VAT and VASIC hardware and software. The contact center is
connected to the public switched telephone network 2 (PSTN). The PSTN is known to be the worldwide telephone system that provides telephone call connections, including telephone connections to the contact center 1. The contact center 1 can include a private branch exchange 4 (PBX) usually combined with an automatic call distributor (ACD). The PBX 4 is known to be a sub-system that can route incoming telephone calls to intended call recipients, or agents. The ACD is known to comprise a sub-system that can provide call queuing and automatic wait handling of incoming telephone calls. The PBX/ACD 4 can be coupled to one or more interactive voice response systems 5 (IVR). The IVR 5 is well recognized to be a system that provides voice queries to a telephone caller. Voice queries typically direct the telephone caller through a series of selections that can be chosen by the telephone caller via button pushes on the telephone keypad.
Within the IVR queries, the telephone caller can be directed by the IVR 5 to select an option that connects the telephone caller, via the PBX /ACD 4, to one of a group of agents 6. The agents 6 can have access to agent telephones, of which agent telephone 7 is representative of all agent telephones. The agents 6 can also have access to agent computers, of which agent computer 8 is representative of all agent computers.
The PBX/ACD 4 is further coupled to a bus 15 that can be provided to couple together the PBX/ACD 4, the agent computers 8, a computer telephony integration (CTI) server 9, an application server 11, a database server 12, a web server 13, and an email server 14. The bus 15 can correspond to an Ethernet local area network.
The IVR 5 can, among the IVR selections offered, request that the telephone caller enter "identifying information," for example an account number, by button pushes on the telephone keypad or by voice responses from the telephone caller. Identifying information can also be automatically provided by the PBX/ACD 4 without entry by the telephone caller with a variety of methods, including dialed number identification service (DNIS) and automatic number identification (ANI). The identifying information is passed through the PBX/ACD 4 to the bus 15. The CTI 9 receives the identifying information and coordinates the identifying information with "caller data," for example account history associated with the telephone caller, contained in the database server 12. An application program in the application server 11 can automatically provide a display
of the caller data in a "screen pop" to the agent disposed upon the agent computer 8. Alternatively, the application program can reside within the agent computer 8.
When a contact center has no CTI 9, or if the screen pop is delayed by system data flow bottlenecks, the agent can manually identify the telephone caller using the agent computer 8 by manually entering the identifying information via the keyboard of the agent computer 8.
The contact center 1 can also be accessed via the Internet 3, for example by a web user who accesses a web page associated with the contact center. The web user, via the Internet 3, connects to the web server 13 for web page access. The web user can also be an email user, in which case the email user connects to the email server 14 via the Internet 3. While web page access and email access have been described herein, the invention is not limited to only these specific Internet applications. A variety of Internet applications can access a variety of servers within the contact center 1.
Various testing systems have been provided to test functions associated with the contact center. For example, the Hammer IT™ from Empirix, Inc. of Waltham, Massachusetts, can be used to simulate telephone callers in a public switched telephone network (PSTN) having one or more telephone callers who access the contact center either sequentially or in parallel. The Hammer IT™ system provides a "virtual telephone caller system" having "virtual telephone callers" that can exercise and test the responses of the one or more IVR systems. The virtual telephone caller system can also be used to test the agent telephone functions of the contact center, providing a "virtual agent telephone system" having "virtual agent telephones." The virtual telephone caller system can also be used to test FAX functions of the contact center.
Various testing systems have also been provided to test the agent computer function of the contact center. For example, the E-test™ system from Empirix Inc. can be used to simulate the computer functions of the agent computer, providing a "virtual agent computer system" having "virtual agent computers." The E-test™ system can also provide a "virtual web user system" having "virtual web users" that include simulations of people who access web pages on a web server within the contact center, people who send/receive email associated with an email server within the contact center, and people who send/receive FAX information associated with a FAX system within the
contact center. The virtual telephone caller systems, virtual agent telephone systems, virtual agent computer systems, and virtual web user systems will hereafter be referred to as "virtual test systems."
Reliability, speed and consistency of VAT and VASIC applications are becoming increasingly important factors in the success of contact center operations. Yet even as customers have come to expect very high levels of performance, contact center infrastructure has become increasingly complex, requiring more components to work together seamlessly to ensure service availability and high Quality of Experience (QoE) for end users. Today's contact centers incorporate sophisticated call routing and call handling systems, such as ACD, CTI and IVR. Supporting these systems is a significant challenge because these applications often undergo continuous change. And each change introduces the potential for configuration errors that can disrupt customer service. Automated testing reduces the risk of deployment failure and potential customer problems - and provides contact center managers with confidence that their voice system can handle the expected customer traffic.
The present invention provides a means for a contact center manager to interact with the automated testing of VAT and VASIC applications just the way a customer would: dialing into the contact center, listening to the responses and then dialing or speaking through the VAT prompts. Along the way, the test application tracks valuable performance metrics at every step of the call transaction, from the switch to the backend databases and out to the agent. If, at any point, the correct response from the VAT and VASIC systems is not received, or the response time exceeds a pre-established limit, the appropriate technical resources can be notified and via the web interface can review test results, performance measurements and other data to help localize and analyze the problem.
The present invention can be used in the monitoring system and carrier performance, and detecting outages and slowdowns early so that corrective action can be taken before problems affect customers. Detailed failure and response time data can
be used to precisely drill down into a failure, at any time and from any place, substantially reducing the time it takes to identify, diagnose and resolve problems.
The web interface lets the contact center manager establish specific service levels at every step in the call flow, and specify the person to be notified should a problem arise. The method of notification can vary based on time of day, day of week, or type of problem detected. Once a notification has been sent out, the web interface gives immediate access to current and historical performance data and summary reports, which can be used to diagnose and fix urgent problems.
The present invention gives contact center managers the tools they need to track problems, analyze trends in carrier and system performance, and introduce interactive improvements that reduce call charges and personnel costs while improving overall quality and efficiency. The present invention further provides contact center managers the performance data they need to plan current and future capacity requirements and enforce service level agreements with either internal or third party application developers or system integrators.
Referring now to Figure 2, a sample control panel for qualifying a contact center application is shown. This network monitoring control panel is available via a web browser, and provides a single interface to monitor the real-time status of voice applications across all contact centers. The web interface allows the user to drill down to examine detailed performance results. In this example the user has selected a view of the "Time to Greet" parameter for a contact center application. The graph 20 shows the time to greet (in seconds) for the past twelve hours. A monitoring status box 30 shows pass, fail and alert numbers for the last hour, the last 24 hours and the last 72 hours.
A status box 40 shows details regarding failures that have occurred in the last twelve hours. The first failure 42 shows that a failure occurred in the Account Transfer portion of the application, that the failure occurred listening to the PIN verify prompt, and that the application failed because the response time exceeded the error threshold. Similarly, the failure data for the second failure is shown. This error also occurred during the account transfer portion of the application. This failure occurred listening to the Account Verify prompt, and this failed because the response time exceeded the error threshold.
Referring now to Figure 3, the performance results for a test call into a contact center is shown. The graph 50 shows an emulation of a customer calling in to check an account balance. This graph shows that the call failed at the point where the call flow was accessing a database for a balance inquiry. The wrong prompt was played, and the prompt was captured 60 so the responsible person can play the incorrect prompt to aid in determining why the wrong prompt was played.
Referring now to Figure 4, a sample technical report is shown. The technical report provides detailed performance data for every step in the call flow to help determine cause and seriousness of the failure. In this example, the upper graph 70 shows a wide variation in database response times with a recurring pattern. The lower graph 80 reveals that the database takes over ten seconds to respond to over twenty percent of all phone calls.
Figure 5 shows a screen shot of the alert setup feature as described above. Alerts can be set up for various technical contacts, various delivery methods (e-mail, phone, pager, etc.), destinations (e-mail addresses, phone numbers, pager numbers) as well as start and end times. In the example shown, a first individual (box 100 - John Smith) is to be alerted by e-mail (box 110) at e-mail address
[email protected] in the event a problem is encountered. The alerting period starts at 12:00 AM Sunday (box 130) and ends at 11:59 PM Saturday (box 180). The alerting function for this individual can be turned on or off (box 150). An individual configuration screen 160 is also shown for adding individuals into the alert schedule.
Referring now to Figures 6-11 various screen shots of different aspects of the present invention are shown. Referring to Figure 6, a screen shot of a particular test result is shown. This shows that the correct CTI information is being delivered to the right agent at the right time for a special call. This display shows that over the last 12 hours, the "time to connect" has averaged between 1.2 and 1.8 seconds. Figure 7 is a screen shot showing the verification of CTI information and routing protocols in aggregate. This information is useful in identifying and diagnosing performance issues. Figure 8 shows a summary of Agents and their related performance metrics. It can be seen from this example that certain agents are handling more calls than other agents, whereas the calls handled by the agents show be about equal. Figure 9 is a screen show
of the "retest now" feature. This feature is used to immediately launch a test. The contact center manager may want to perform this action to confirm a fix or to check if a problem still exists. Referring now to Figure 10, a screen shot of the results of an ASR test call are shown. This shows the dynamic nature of calls, as at 10:59:01 the arrival time for flight 226 was 11 :02, while at 11 : 15:47 the arrival time for the same flight was changed 10 11 :10. Figure 11 shows a valuable part of the present invention wherein metrics from different contact centers can be compared. In this example, the "time to connect" metric is being compared across contact centers in four different locations.
Even the best-designed contact center can drop calls, give out the wrong prompts, or send calls to the wrong agent. There are dozens of ways for hidden errors in VAT and VASIC systems to frustrate customers and rack up unnecessary costs. Unless contact center managers monitor their center's technical performance, they can't know what's wrong or how to fix it. The present invention provides the contact center manager a solution to track and measure every aspect of a contact center's applications. The present invention helps establish performance benchmarks, send out alerts the instant that problems occur, and strengthen customer relationships by enhancing quality of experience for every caller, and is accessible from anywhere via a web browser.
The presently described VAT and VASIC testing methodology is applicable for both onsite and remote testing. The present invention is also useful for functional, regression, and load testing, as well as monitoring of production systems.
The present invention allows contact center managers who are responsible for application systems to easily view test results and performance data, while also being able to configure and schedule testing and alerting via a web-browser through an easy- to-use user interface, in their office, within their corporation, or from any web- accessible computer.
Having described preferred embodiments of the invention it will now become apparent to those of ordinary skill in the art that other embodiments incorporating these concepts may be used. Additionally, the software included as part of the invention may be embodied in a computer program product that includes a computer useable medium. For example, such a computer usable medium can include a readable memory device, such as a hard drive device, a CD-ROM, a DVD-ROM, or a computer diskette, having
computer readable program code segments stored thereon. The computer readable medium can also include a communications link, either optical, wired, or wireless, having program code segments carried thereon as digital or analog signals. Accordingly, it is submitted that that the invention should not be limited to the described embodiments but rather should be limited only by the spirit and scope of the appended claims. All publications and references cited herein are expressly incorporated herein by reference in their entirety.