Three Reasons Your Contact Centre Testing Is Broken and How to Fix It

Mike Burke takes us through the importance of contact centre testing and gives his advice on how to improve it.

Would you board an aeroplane 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!

Applying the same logic to contact centre 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 Centre Testing

The biggest mistake that end users make with contact centre deployments is not conducting any formal testing at all. They choose to roll the dice and assume that the implementers and integrators have stitched together a set of individually tested components that result 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 implementers to ensure everything works together when integrated, it’s complicated and takes some time. But, just like properly testing an aeroplane, both common sense and best practices dictate that a formal end-to-end test of the total contact centre entity be conducted.

Fix: Start doing Contact Centre Testing

Reason: Testing from a Purely Functional Perspective

When people do test the contact centre environment, they often don’t create realistic usage scenarios. Instead, 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 centre 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 aeroplane analogy, it would be like deliberately putting the aeroplane into a stall and watching it crash.

People build contact centres with clear expectations around capacity, performance, and the speed 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, 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.

Mike Burke

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!