An IVR system can be one of the most reliable pieces of equipment in the inbound call center.
But don’t be too confident; regular IVR testing is the only way to make sure you’re delivering the best, most affordable service.
There are three kinds of IVR testing you should do regularly:
- Capacity – Can your IVR handle a high volume of traffic?
- Functionality – Does every part of your system work as it should do?
- User Experience – How can you improve IVR to make is better for customers?
#1 IVR Testing for Capacity
This is the most fundamental type of IVR testing – making sure the system infrastructure won’t collapse under pressure.
There are four key types of capacity tests:
- Load testing (testing general use)
Can the IVR system sustain the level of use you expect it to get? The IVR is one part of an ecosystem of call tools. Load testing ensures that they all work at expected call volumes.
- Soak testing (testing prolonged use)
Can the IVR system handle call volumes over time? Some capacity issues aren’t apparent right away – so what bugs come to light after a few hours?
- Spike testing (testing sudden increases)
Can the IVR system deal with a sudden wave of inbound contacts? All kinds of external events can drive calls. Spike testing makes sure your IVR stays with you when that happens.
- Stress testing (testing high volume)
Can the IVR system survive a very high volume of incoming calls? With the entire system in use, does any part of the system give way?
These tests all ask the same fundamental question: can the IVR system handle the extremes of call volume?
How do you test this?
The only reliable way to test capacity is to throw calls at it and see what happens. Obviously, you don’t want to wait for real periods of high call volume to do that test.
Luckily, there are a number of tools which simulate incoming call volumes. Using these tools, you can run any kind of capacity test to ensure maximum uptime from your system.
#2 IVR Testing for Functionality
You’ve tested your IVR’s infrastructure; now you can get into some more detail.
There are a lot of ways for even a stable IVR system to fail. This is especially true when an inbound call center has used (and added to) the same system for several years.
There are some typical problems to look out for:
Do any of the IVR pathways lead to… nowhere? Sometimes a caller goes through several menus only to end up at one which provides either unsuitable options or no options at all.
Does a caller’s selection help them progress through menus? This is a similar problem to cul de sacs but often harder to spot. Your basic IVR pathway should be A to B to C to resolution. A roundabout does something like A to B to C to A again.
- Pathway duplication
Do you need every menu option that you offer? For example, a call center might spend years automating more and more non-technical queries. Eventually, almost all agent calls are technical – but separate pathways still exist for ‘service’ and ‘tech support’, creating longer IVR interactions and inconsistent reporting.
- Poor audio
Can callers clearly hear the IVR prompts? This is as basic as it gets! There are a few ways audio gets disrupted. Sometimes it’s a network issue, with high network traffic interrupting IVR. More often the problem is a voice actor stumbling on a word, or temporary messages recorded on the call center floor.
The question you’re answering with this kind of IVR testing is, ‘can a caller efficiently address their query?’
(Another way to avoid these pitfalls is to adopt conversational IVR services – IVR that ‘talks’.)
How do you test this?
If you want to be thorough, the good old fashioned test is to call up and go through every IVR pathway. If you want to check audio quality, that’s certainly the only way.
However, depending on the IVR service you use, you may be able to view the layout of your IVR pathways. It may still be a very complex process, involving hundreds of pathways though.
You might want to focus on problem areas as they emerge, by studying the parts of IVR journeys where callers typically hang up or ‘zero out’.
#3 IVR Testing for User Experience
After part 1 and part 2, you know have the basic requirements for a usable IVR system.
The final type of IVR testing focuses on the user experience.
This can be a little harder to define. But the basic questions are, ‘does our IVR system represent our brand well? Is it intuitive or frustrating? Does it make allowances for different kinds of customers?
Key problem areas to focus on are:
- Long pathways
How many menus does a caller need to go through before they get what they need? IVR design is not easy and this is why. You need to get from the query to the correct page in the fewest possible menus – ideally 3 or fewer.
- Long menus
Will the caller have forgotten the first option by the time they’ve heard the last one? Set a hard limit of 5 options per menu – stick to 3 where possible.
- Poorly explained voice interface
Do callers understand how to use your voice recognition? The tech has come a long way but can still confuse some users. Let them know what they need to do with messages like: ‘You can say things like “I want to check my balance” or “there’s a problem with my bill.”
- Lack of IVR integration
Can your IVR access customer data like a live agent? An IVR – integrated with CRM and other systems – should know who’s calling, as well as having some context for their query. The caller shouldn’t need to repeat information they’ve shared with your business already.
Unlike IVR testing for functionality or capacity, UX testing doesn’t have an end goal. It’s an ongoing process of making IVR service better all the time.
How do you test this?
User experience is a broad category. Your best option is to define key elements which will be easy to measure. The length of pathways and menus is easy to discover by going through your IVR.
Likewise, it’s straightforward to check that your scripts make sense and represent the brand in a positive light. By understanding the elements that make up UX, you’ll easily be able to find methods to improve them.
Integration is perhaps the most important element systems.
There are a few ways to approach integration. For example, babelforce uses APIs to connect systems, because that enables our users to build simple automations without coding.