The biggest mistake people make with contact center testing is not to perform testing at all. They choose to roll the dice and assume that the implementers and integrators will stitch together a set of solutions that work together correctly.
To assume that the solutions have been unit tested to the point that they work as intended is often a losing proposition. Even though it's in the best interest for the implementers to ensure everything works, it still requires a delicate dance with people on the other side of the table during the integration process.
Would You Trust an Untested System?
Look at it this way. Would you board an airplane that had never actually gone on a test flight? A rational person would not put his or her trust in a plane that hadn't been fueled up, loaded with the appropriate weight, flown for the intended distance, and landed successfully.
Let's apply that same logic to technology deployments and ask ourselves, "How many projects go live merely on the basis of how it feels to sit in the passenger seat?" And, "how many get turned on based solely on whether the engine turns on when we flip the switch?"
Just like properly testing an airplane, performing an end-to-end test of the total contact center environment is critically important. That includes testing the contact center under the same conditions that customers will experience during actual use. When people do test the contact center environment, they often don't create realistic usage scenarios. They perform unit testing and component testing, but that isn't the kind of traffic that real customers will create when they try to use the system to perform actual tasks.
Generating a limited amount of test calls or browser sessions will not provide the appropriate peak traffic levels that would happen in the real world. Instead of testing from a purely functional perspective, it would be wise to go for a realistic test flight to make sure that the system flies and lands successfully.
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. One challenge is getting enough people to generate the telephone calls or browser sessions that would accurately reflect real customer 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.
Stress testing can be performed to try and break something, but that isn't an appropriate approach simply because it is easy to break a complex entity. Returning to our airplane analogy, it would be like deliberately flying an airplane on an empty tank and watching it plummet to Earth.
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 a supersonic jet. Likewise, not every entity is built to handle a Black Friday-like surge in retail traffic. Breaking a system only proves that it is breakable, and not that it works according to expectations.
Test to Gather Useful Data
Instead of deliberately breaking the environment, you can continuously collect data from the inside out about how the contact center holds up during stressful periods. 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 smoothly. That's how you can ensure that your contact center stays airborne, and that your environment doesn't crash and burn.
