Implementing a Traditional IVR Can Be a Painful Journey

Implementing a traditional IVR can be a painful journey. If you are implementing an IVR, either on premise or through a managed service that depends on cradle-to-the-grave system development and traditional language tuning, you are in for an experience that you are not likely to enjoy. The bottom line is that it is a lot of work and often does not deliver on the promises of the business case that supported it. Let’s take a walk through the painful journey of a traditional IVR implementation.

SCOPE

Before a project even begins, you will need to develop a set of detailed scope documents to define the exact functionality and specifications for the application, often putting you through what we call “analysis paralysis.” Worst of all, you will likely do the detail design in a tool like Visio. Can you imagine defining a Visio document for a dynamic webpage or website? Why doom your project from the start to a rigid, linear design document? The capabilities of the system should allow for the Voice User Interface (VUI) to have the same flexibility as a Graphical User Interface (GUI). In other words, the caller directs the flow of the call, not the IVR.

A precise definition of scope is necessary because your project team or IVR vendor will use it to estimate implementation costs. The problem is that most companies cannot predict their exact needs, continuing to realize the need for changes well after development has started. If the scope is to “Take orders” or “Make plan changes,” then it is recommended that you start simple and plan to constantly iterate using a proven AGILE methodology. What you don’t want however, is to be “change ordered to death;” excessive change orders will inhibit the project team from delivering on the scope the callers are telling you they really want.

CODING

During coding, the developers almost certainly will use VXML, a standard language commonly used for IVRs. But the functionality of VXML is extremely limited and, worse yet, VXML is not a development language (it has not been updated since 2007). It is a variation of a data exchange format and was never intended to be as flexible as today’s conversational requirements demand. The technical design of most IVR solutions provided by the major telephony infrastructure vendors all severely limit the functional capabilities. Using VXML, like building designs in Visio, is yet another decision made early on that will likely doom the project and deliver a solution that falls short of aspirations.

In fact, most traditional IVRs are linear and have a very rigid flow that is hard for callers to navigate. This makes for a bad customer experience, one where callers are forced to choose options that do not apply to their situation or “zero out” to speak with a live agent – defeating the purpose of implementing an IVR in the first place. A good system has dynamic conversation flow, and should also be designed to engage the caller up front and reduce the propensity for them to eject. The biggest problem with caller adoption of voice self-service is that the American psyche is conditioned to think that all IVRs are atrocious. You have to engage the caller very early on and demonstrate that you have provided something that is not “your father’s IVR” (homage to the former Oldsmobile commercials).

THE VOICE

Next, you need to choose the voice that your IVR system will use to communicate with callers. Traditional IVRs require human voice talent, which is both expensive and time-consuming. It is also inflexible, making it hard to quickly change messaging or flow. Imagine the process you would need to go through to update your store hours or change product information. How about making changes in an emergency? Voice talent is slow and clunky when it comes to these types of changes. In addition, we live in a “Siri world” now where synthetic voices are used in everything from smartphones to car washes. People respond to the system based on the capabilities, not the silky smoothness of the voice. People resist voice self-service because it often does not work, not because the voice is synthetic.

THE FLOW

A good IVR will use natural language to greet the caller with an expression like, “How may I help you?” This open-ended question provides maximum flexibility, but also requires significant effort to anticipate and code all of the possible caller responses. After that, however, most IVRs switch to directed dialog, where acceptable responses are often limited to “yes” or “no,” for example, or perhaps a number or word. The flexibility and variability of natural language is lost and callers become frustrated and confused due to the inconsistent experience. A good IVR will use natural language everywhere, allowing the caller to control the flow.

LAUNCH

Congratulations! Your IVR has been launched. And it works! At this point, a conventional IVR runs exactly like it did the day it was implemented. Isn’t that great! But, like I mentioned earlier, it also means any changes to your business, product offering, contact center structure, or customer services are not reflected in the IVR, even if you roll out changes to the live agents in your call center. The system needs to be tuned regularly to react more naturally to humans. However, most IVR providers and project teams only do this once during the development phase above, or they might tune the system for 90 days after launch. After that, not much happens. The IVR should be considered a living, breathing thing – just like a call center agent – and it should learn something new every day, making it seem like the most experienced agent in the center.

If changes are implemented, they are often bolted to the side of the core application, giving your IVR a Frankenstein-like feel. Furthermore, those changes are only made at the behest of the dreaded change order. As a result, companies often wait until there is a buildup of issues before they begin going through this whole process again. This leads to what we call “completion rate atrophy,” the slow decline in the IVR’s ability to complete calls successfully without being transferred to a call center agent.

That’s your painful IVR journey: arduous, frustrating, and filled to the brim with change orders. Here at SmartAction, we think that journey is terrible. We never want our clients to go through it. SmartAction’s revolutionary artificial intelligence, cloud-based service model (not software) does not suffer from any of these issues. We constructed this service from the ground up, building a clearly better mousetrap. Let us show you.

About the Author: Tom Lewis, Chief Executive Officer

Tom has over 25 years of experience focused primarily on customer experience and contact center operations and technology. Prior to joining SmartAction, he was a Principal at Deloitte Consulting where he was the national leader of its Customer Operations Practice. The focus of Tom’s career has been helping organizations improve their customer facing operations, especially as it relates to contact center service, sales and support.