Whose IVR Design Is It Anyway?

No One Likes Surprises

With a checks and balances system in place, all stakeholders are well served, and no matter what the scope of an IVR design is, industry experts agree that consistency is key.

Vendors can use reviews to make sure everyone is up to date and has a clear understanding of each step in the IVR design. At Convergys, documents are reviewed internally at regular intervals. "By the time we get to the detailed design documents, no one is caught off guard by some complex, strange, out-of-the-ordinary requirements," Goss says. "The more internal reviews that we have on the document as we’re making it to the goal, the better chance we have at being successful."

Pelland agrees. "You have to review the design documentation internally before you show it to the customer or you're dead in the water, in my opinion."

Pelland gives an example of having an outside-the-box type of designer working with an IVR team. The design may be wonderful, but it may not be realistic for implementation. "If the designer brings his work to the client first, the client may love it, but then the developer has to tell them that it can't be built," Pelland says. "That creates silos. If you put something like that in front of a customer, you look horrible."

Additionally, all stakeholders need to be able to comprehend what's occurring, even though it's likely that very different words will be needed to explain it. "One inherent problem with detailed design documents or user interface specs is that [they have] multiple audiences," Goss explains. "It has to be basic enough and in plain English [so] that the business stakeholders on the customer side can understand it [and] see if it meets their requirements. But it also has to be technical enough that the developer doesn't have some pie-in-the-sky wording. For example, what does it mean to have a 'bad' account? If you don't write that in at least a somewhat technical way, the developer has no idea what you mean."

Cost Concerns

There may be some instances when organizations have to choose between cost savings or providing great customer service, or, as Hura asks, "Are they going to provide what they believe is the best possible service—or meet their other business or financial goals?"

Fluss acknowledges that extensively rebuilding an IVR is not cheap. "You're going down to the deep, most detailed level of applications. You're looking at almost every single utterance. You've got to analyze every place where customers are not happy."

Pelland has been involved in such projects, but says that organizations don't need to be forced to choose between service and cost. "Someone may say, 'Just give us something down and dirty,' but good UI doesn't have to cost a lot of extra money. I tell people that we can build a great UI with DTMF [dual-tone multi-frequency]. There are world-class DTMF solutions. You don't have to have speech if you're worried about money."

The Client Is Always Right

What happens when a team member realizes that a business stakeholder's request is not in their best interest? Does it become the team's responsibility to intervene and try to stop the client from making a poor decision? Hura says that's yet another juncture that requires clear communication.

“I give my clients full information and explain things to them,” Hura says. “[I say,] ‘Can I design this the way you requested? Yes. And here is the expected impact; this is what I think will probably happen. And here’s how this does or doesn’t correspond to what I understand your goals to be.’ Nothing is set in stone. Even if all the stakeholders initially agree on a project, the team needs to be nimble and ready to respond—even if they don’t agree with the client.”