Communications Blog • 5 MIN READ

3 Reasons your Contact Center Testing is Broken & How to Fix it

Would You Trust an Untested System?
Would you board an airplane that had never actually gone on a test flight? Where the decision to put the plane into service was based solely on how it feels to sit in the passenger seat and whether or not the engine turns on when we flip the switch? A rational person would not put their trust in a plane that hadn't been fuelled up, loaded with the appropriate weight, flown for the intended distance and landed successfully. Several times!

 
View our on-demand webinar about bulletproofing your contact center customer experience.


Applying the same logic to Contact Center technology deployments, let's ask ourselves how many projects go live merely on the basis of the system taking calls into the IVR and popping a representative set out to agent desktops, but without the system actually running through its paces at full scale.
 

Reason: Not Undertaking Contact Center Testing

The biggest mistake that end-users make with contact center deployments is to not conduct any formal testing at all. They choose to roll the dice and assume that the implementors and integrators have stitched together a set of individually tested components that results in a solution that works as intended. Unit testing is essential, of course, but it's not sufficient to guarantee the integrated solution will hold together in the real world. Even though it's in the best interests of the integrators and implementors to ensure everything works together when integrated, it's complicated and takes some time. But just like properly testing an airplane, both common sense and best practices dictate that a formal end-to-end test of the total contact center entity be conducted.

Fix: Start doing Contact Center Testing



Reason: Testing from a Purely Functional Perspective...

When people do test the contact center environment, they often don't create realistic usage scenarios. They perform unit testing and functional testing, but the activity generated isn't representative of the traffic that real customers will create when they use the system to perform actual tasks. Testing piece parts against APIs that are stubbed out confirms component functionality but doesn't tell you if they can handle volume and velocity. Generating a limited amount of test calls or browser sessions will not provide the appropriate peak traffic levels that happen in the real world. Instead of testing from a functional perspective, go for a test flight to make sure that the system actually flies and lands successfully.

Fix: Use Technology to Generate Real-World Traffic
The best way to go about testing your contact center environment is to consider your expectations about real-world customer interactions. It's impossible to get enough people to generate the telephone calls or browser sessions that would reflect real-world usage. That's why it's critical to use technology to generate the anticipated volume and velocity of interactions in the environment. The key is to rev the system up to the level that you expect it to work and push it to those limits to make sure it will continue to function as expected.

 
 

Reason: Testing to Break the System...

Stress testing can be performed to try and break something, but that isn't appropriate simply because it is easy to break a complex entity. Returning to our airplane analogy, it would be like deliberately putting the airplane into a stall and watching it crash. People build contact centers with clear expectations around capacity, performance, and the velocity of interactions that it should be able to handle. It wouldn't make sense to buy a two engine Cessna and expect it to perform like an SST. Likewise, not every entity is built to handle a Black Friday level of rush in retail traffic. Breaking a system only proves that it is breakable, and not that it works according to expectations.

Fix: Test to Gather Useful Data

Instead of deliberately breaking the system, exercise it with traffic representative of actual expectations in a way that allows you to continuously collect data from the inside out about how it holds up during stressful loads. You will obtain the kind of information necessary to identify issues as they develop and help you to figure out the root cause. After uncovering the root cause, you can then make tweaks to the applications, networks, routers, or the service data that are required to get everything running in sync and then re-test to confirm you've nailed it!


Once you're ready to go to the next level, view our on-demand webinar about bulletproofing your contact center customer experience.

Topics: Communications

Subscribe to our blog

Stay up to date with the latest
Collaborate, Transact and Infrastructure
industry news and expert insights from IR.