There is nothing as scary as testing against a production system. The number of possible “what if” scenarios include everything from system crashes and software failures, to faulty reporting and annoyed agents. Yet, running test calls through production is the only way to monitor all aspects of the customer experience. So is there a way to safely validate the production system without the risk of causing a career-ending situation?
The answer is yes. It is actually very easy to run test calls through production without reporting nightmares, ghost calls, or landing test calls on active agents—as long as you know what precautions to take. Let’s address those three issues one at a time.
1. Test Calls Impacting Production Reporting
If you are responsible for tracking call volumes and trunk utilization for a large company, there is nothing more annoying than seeing unexplained calls arriving from the same number over and over, with each call acting strangely and disconnecting before service is complete. You might have experienced this unintended outcome if you have deployed Cyara Pulse to monitor production.
The solution is twofold: ANI spoofing and report filtering. ANI spoofing is a Cyara capability that allows Pulse calls to appear to originate from any valid phone number. Simply designate a fixed set of phone numbers that will be used for all test calls, enabling you to exclude all calls arriving from these numbers from the production call reports. In terms of data manipulation, this process is not especially difficult. Now we come to the forgiveness part.
The team that manages the trunk utilization and call tracking reports typically goes through their standard reporting process on a schedule. Informing them that they need to modify the report generation process in order to accommodate a new monitoring application might not be welcomed. Why? Because someone will need to change the reporting process so that all spoof calls are discarded from the reports. This is where senior management may need to step in and request the reporting team add the necessary filters so that production reports continue to be accurate and the testing process can operate as it needs.
Once the reporting process has been modified, the testing impact is minimal. I always advise creating spoof lists of at least ten numbers, and 20 is even better. Assigning a couple of spoof numbers to each testing group allows you to track testing volumes within each group while production reporting easily filters out the test calls.
2. Abandoning Calls in the Midst of Call Routing or Queuing
Here we go again, annoying the production reporting folks with test calls. This time, the test calls exit the IVR as part of the final step in the IVR application and then disconnect. Sadly, the disconnect frequently happens after the call routing process has already started—or worse, the call has already landed in a queue. Either way, the disconnect produces a “ghost call,” a call that disappears without completing delivery to an agent. Ghost calls are a tracked item in the production area, and an increased numbers of these calls would be cause for investigation.
So how do you test a production IVR and disconnect the call before it routes or lands in a queue? You barge in.
Cyara has a testing capability that allows a caller’s prompt reply to be supplied by the caller in the midst of hearing the complete prompt: the BargeIn tag.
The BargeIn tag allows the Cyara test case to simulate customers making a menu selection prior to hearing the complete IVR prompt. In our case, we want to have the call end after a specific number of seconds.
Using the BargeIn tag as part of the last step in a Cyara test case, along with an empty “reply” field, will cause the call to disconnect as soon as the BargeIn is executed. Unlike other approaches to ending calls based on timing, the BargeIn method does not trigger call failures when the time limit is reached. On the contrary, reaching the time limit is a necessary part of the process.
For more information about the BargeIn tag, you can review the sample BargeIn test case that is a part of the test case samples Cyara loaded to every hosted account on the Portal.
3. Preventing Test Calls from Reaching Active Agents
If you are testing call delivery to a Cyara Virtual Agent, you need to make sure Virtual Agents are isolated from active ones, and that only test calls are able to reach Virtual Agents.
Thankfully, there is a solution for this requirement as well. First, keep in mind that Cyara’s Virtual Agents are “real” agents from the standpoint of the telephony system and the CTI services. Knowing that, you need to connect Cyara Virtual Agents to designated test call queues. Cyara Virtual Agents follow the login process and connect to the assigned queues just like active agents do. In fact, Cyara Virtual Agents are active agents in every way, except that they are connected to test queues instead of production queues.
Once the Virtual Agents have been configured, the next step is to get test calls routed to test queues so that Virtual Agents can receive the calls. The ideal model is to permit all calls—test and production—to navigate your production IVR. The spoofed ANI will filter calls so the reporting remains accurate. Bypassing the production IVR invalidates the testing outcomes, as it is the production IVR that is one of the monitoring targets.
There are a couple of ways to get calls to land in the test queues, all of which involve recognizing them as test calls.
Option A: Identify and reroute test calls
Comparing the ANI of the arriving calls to the list of ANI spoof numbers can quickly highlight which arriving calls are test versus live calls. IVRs can do that lookup easily, though this does involve code changes (and that puts us back to the forgiveness process.)
Assuming the test calls are identified and tagged as test calls at some point in the IVR process, the second step is to properly route the call to a correct queue. Here again, changes to existing code comes into play. Whether the change is to the IVR scripting or to a call routing application, something needs to examine the call, see that it is a test call and drop the call into the appropriate queue.
Option B: Build a parallel system for testing
This is the option that some customers prefer, choosing to create test systems that operate in parallel to their production system. These test IVRs run the same applications and the same data services as production, but are strictly for testing. The routing scripts are designed specifically for test calls, and the queues will never be accessed by active agents.
Both models provide the means for validating the complete customer experience. And once deployed, the testing process produces minimal to no impact on any production systems.
Routing calls to Virtual Agents is the only way to fully test the customer experience process from end-to-end.
Testing production is an activity all companies should embrace. It is important to address areas that represent business risk resulting from the testing process, and understand how to mitigate that risk. Addressing the three major areas of risk addressed above should bring about a universal acceptance of the testing process and produce higher quality experiences for all your customers.
If you have specific questions about testing your production system with Cyara, don’t hesitate to contact us or reach out to your Customer Success Manager.
