When changes to your organization's website, IVR and other customer impacting communication technologies are made you would think comprehensive testing goes without saying. Yet time and time again we see contact center testing get cut from the rollout plan.
For any non-believers in testing, or those on the opposite fence who believe so stridently in testing you can't believe organizations would cut this crucial step, let's look back at some typical examples.
HealthCare.gov Cut Complete Contact Center Testing Phase
In October 2013 the US federal government “launched” HealthCare.gov. It was a technological failure resulting from the unsuccessful attempt to bring together many different pieces of functionality. Despite the development phase taking longer than expected, the team failed to change the launch date. Instead, it cut the time for testing out of the schedule. It skipped the complete testing phase. Team members kept their fingers crossed and hoped everything would work. Unfortunately, the move from development into production led to disastrous consequences. The various components didn't work properly when pieced together and the website was not able to handle traffic. Ultimately it cost a siege of negative press, overwhelming mistrust from the public and the job of the person responsible.
Statewide Healthcare Skips Website & Contact Center Testing
Where I live in Minnesota a statewide healthcare initiative was launched. Exactly like the HealthCare.gov team, state developers went live without testing the website or contact center. Local news organizations actually aired State officials saying they had cut out testing because they'd run out of time. They didn't realize the consequences it would have.
What Issues Can Contact Center Testing Pinpoint?
Website and contact center testing - before going live - can reveal all sorts of snags such as potential configuration problems or underlying balance issues within your environment.
In one instance a telecommunications environment using an IVR built to handle 600 concurrent telephone calls could only deliver 300 concurrent calls. The outside-in service provider's toll-free number circuits were maxed out at 300 calls. It's a classic mismatch where one person is responsible for public network connectivity and someone else is responsible for application development and configuration. It isn't either person's fault but it epitomizes why contact center testing is so critical. This is the kind of issue uncovered when you try to fill the system to capacity at the points where traffic enters and terminates.
Why Components Working Together is the Biggest Challenge
The challenge with building a complicated data processing or telecommunications environment is making sure all the components work together effectively. It involves integrating software and systems developed by many different people from disparate organizations, while also interacting with networks and databases. Each component can work perfectly on its own, but integration can lead to issues based on scale and the APIs in use.
Types of Contact Center Testing
There are a range of testing methodologies you should deploy ahead of “going live”. At a minimum we highly recommend StressTest™ load & performance testing, soak testing, and resilience testing. And once the systems in production, carrying out ongoing HeartBeat™ experience testing ensures that the system is delivering the experience intended 24x7.
Stress testing
Stress testing engagements are carefully constructed to gradually fill the target system with traffic all the way up to its design maximum to confirm functionality and performance are not compromised under high traffic conditions. The StressTest™ process remotely generates Virtual Customer® voice calls or web transactions that access and interact with your solution just like real customers. The important thing with a load test is that the traffic needs to be actual outside-in traffic so it exercises all the elements in the public telephone network or internet as well as the internal networks and system components. Whether they're voice, web, or WebRTC interactions, they should be an accurate representation of real-world usage, so you can have confidence your system will operate as intended in a real-world high load situation.
Soak testing
Soak testing is aimed at verifying a system's stability and performance over an extended period of time. It is crucial because underlying issues might not emerge immediately. Everything might seem great when you get a few users to try out a new telecom system or Web environment. What you really need to do is run the system at full load, at the rate you expect it to run at production. The system should experience this full load for a sustained period of time. That way you can be confident that there will be no surprises later.
Resilience testing
Resilience testing verifies High Availability (HA) system resilience in the face of compromised situations such as a network segment outage, a server or component failure, or a halted service. Ramp up traffic to full load and then disable a network segment or server, or terminate a critical service and observe how well the system handles the compromised environment. Does it gracefully degrade as defined in the Business Continuity plan, or does it crash hard? Just as important is restoring the system while observing how well the system recovers. Do any elements need an extra reboot to come back online? Do licenses migrate back to their production configuration? You need to be confident the system can weather whatever happens in the real world.
Health checks
Health checks prior to known peak traffic events are required because IVRs, websites, and their underlying infrastructure are constantly changing. A StressTest session that takes a system that's been idling well-below capacity for an extended period up to its design limit identifies issues that creep in under the radar and go unnoticed during low-traffic times. A health check ensures you won't blindly enter that peak traffic situation with your fingers crossed, hoping nothing has changed since the last time you experienced maximum call volumes.
For production environments, HeartBeat™ experience testing, continuously samples the availability, functionality, and performance of customer-facing technology and lets you know immediately when an issue is identified. HeartBeat test calls and interactions running against your customer-facing technology confirm that your technology is doing what it's supposed to be doing because it knows what to expect, unlike your customers who are just trying to get something done, and that's a key point about testing of all types.
It's important you use a controlled process with a protocol that knows exactly what the system is supposed to do whether load testing or carrying out these ongoing experience checks. knowing what's supposed to happen helps identify which components aren't working as intended and brings the issue to your attention in a timely manner so you can something about it before your brand is flamed on social media.
Key Takeaways from Failed Contact Center Tests
Remember, first you must verify all components are working together so people will be able to use them effectively and efficiently. Second, you must ensure that the technology is available 24 hours a day, seven days a week. As a result, users won't have to jump into a chat support session or out of an IVR and use valuable live agent time. Finally, it's a best practice to confirm capacity on a periodic basis – especially ahead of known peak traffic events - so you'll not be caught off guard.
Whether you're operating a self-service environment, either IVR or website, or providing live agent dependent on skills-based routing and CTI screen pop, you must make sure everything is properly balanced and integrated from end to end. All components should function exactly the way they're supposed to while under load. If you cut out load testing before you go live or experience testing once in production, you're effectively cutting away your safety net.
