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!
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...
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...
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.