How do IVRs end up so horrible?
It’s hard to believe we’re almost four decades on from the original Periphonics and IBM IVR solutions, yet somehow making it increasingly harder for the customer to navigate. Of course, some of this is intended to increase self-service or drive digital deflection but much of it is just poor VUI design. Maybe I’ve got time to just unpick a few threads as to why this is happening and maybe on a later post talk to some of the very cool stuff happening with managing customers calling.
The greatest challenge when designing an IVR is to ensure that it doesn’t get left to grow literally from requirements. The problem here is that requirements rarely, if ever, have business logic, complexity or priority locked into them. Developers and designers take them literally as a list of functions that must be delivered against.
Now the problem is exacerbated by the fact that the IVR only has a handful of “viewable” menus. To make everything “fit” into a series of prompt options the designer must start with an overgeneralisation of categories to the point where they are often indistinguishable from one another.
To explain, I’ll use banking as an example.
It seems sensible to have insurance as a menu option as that would seem to be clear and differentiate these calls from other banking enquiries. Great. But, these only represent fewer than 3% by volume of contacts. Even if we planned to send insurance to a banking CSR with the intention of transfer we would hardly affect the average rate of call transfer at all. For this call type the CSR would identify quickly that this is a transfer call and not waste time trying to diagnose the issue (something they do when the enquiry may carry similar terms to those calls they do handle). So why did we waste time putting this in the main menu? Because taken literally, and by hierarchy, it made sense.
The trouble is that what seems obvious to a designer adds little to no value to the actual business. The issues lies in the fact that the business aren’t working on the project at the right level, it’s in the hands of the designer. The result becomes the logical to the naked eye, not a fit-for-purpose design for the business.
What is needed is ongoing collaboration and challenge. To build an effective IVR each step (question/prompt to answer) needs to be challenged on “what would need to be different to avoid this question altogether?”. In almost all cases there is an answer, but it is the business that will be able to resolve this challenge, not the designer.
In a recent case study we had to deal with the complication of customer term about their “new card” being distinguished between a replacement and a new application. The prompting could have gone into the differences with the caller but what we did instead was swing the replacement card conversation into the team that looked after new applications. The enquiry was so easy to manage that it built call volume to a team that required high availability, and didn’t interfere with their primary work. Everyone was happy – and no questions required.
The solution – more upfront knowledge transfer, engagement of the people who can provide the business intellectual property, and the preparedness to work hard and find innovative solutions to the challenges and focus on delivering a better customer experience – ALWAYS.
About Flare Design: Flare are leaders in open speech customer experience and business process design. We bring a complete end-to-end view of the impacts, pitfalls and mitigating strategies of open speech implementations, change and the impact on staff. In the last 10 years, we have been fortunate to work on many of the major speech implementations and have contributed to the significant turn around in customer perception and press adoption of speech recognition systems.