I recently presented some training to a group of IT folks who were trying to improve the performance of an existing IVR. Completion rate was only 40%, not high enough to justify the expense of the system. The task seemed easy enough. The caller enters some identifying information, then data about amount of miles driven, fuel used, perhaps a vehicle number, all numeric.
I had started by preaching the importance of writing good scenarios - descriptions of customer behavior in the context of their environment and their tasks. Then I presented some general guidelines for designing prompts. This is harder than it appears because there are often contextual factors that make a suggested prompt worthless in a given case, so every guideline must be wrapped with disclaimers.
Back to the problem with the existing IVR. After cautiously making a few suggestions about prompting I asked the participants to back up and describe the scenario in detail. Then it became clear. The caller was a cashier standing at a check out counter talking to a driver. The driver supplied the information, who sometimes had to pull out a notebook to get the information. Two obvious problems. One, if the system is converted to speech then you'll get a lot of sidetalk recognition errors, where the caller isn't speaking directly to the IVR, but to someone else. Two, speech timeout values are by default pretty short. If you don't have the information the IVR is asking for close at hand, the IVR goes into its Silence error routines.
These are nice design issues and potentially solvable, but not unless you understand the context and the likely outcomes of the caller's behavior. In this case, not having information at hand and needing to talk to someone during the call. An expert can look pretty silly and helpless if he's offering recommendations without understanding the scenario.