The caller must always be able to dial 0 or to say "operator" to queue for a human. [PeterK] What if nobody's available? What if they're less qualified than your IVR? What if nobody's ever available (e.g., you're speech-enabling web content, not replacing humans.) Why shouldn't your IVR transfer to an agent when certain business or performance indicators are met, *before* the caller even thinks to ask for a person?

An accurate estimated wait-time, based on call traffic statistics at the time of the call, should always be given when the caller arrives in the queue. A revised update should be provided periodically during hold time. [PeterK] Sure. Or destroy the queue by offering superior automation immediately. Not just a speech-app replacing a person, but a deeply integrated tool that will help the caller get in, accomplish their task, and get out.

Callers should never be asked to repeat any information (name, full account number, description of issue, etc.) provided to a human or an automated system during a call. [PeterK] Of course they shouldn't. CTI wasn't invented yesterday, and there's no longer any excuse for not integrating your disparate sets of data. Get with the program. In fact, don't ask ANY information that's available in your backend. If you need to confirm it, confirm it. If you don't, tell your lawyer to get stuffed. When your IVR has captured additional information, pop that to the agent. Go the next step and tell the agent what they should do next with the caller. Predict necessity. Use your SMEs to find out what it is.

When a human is not available, callers should be offered the option to be called back. If 24 hour service is not available, the caller should be able to leave a message, including a request for a call back the following business day. Gold Standard: Call back the caller at a time that they have specified. [PeterK] "Gold Standard"? What is this, a freaking car wash? Can I just pay for the Silver package instead? Are you going to embarrass me if I go for the Bronze? Call backs are fine to offer, but this is hardly a hard-metal standard. Fix the problem now. Resolve the issue. Use every means available. Call backs should be saved for worst-case scenarios.

Speech applications should provide touch-tone (DTMF) fall-back. [PeterK] I, er, agree. Not only that, offer SMS & Email fall-back. If you can't understand this URL/follow the instruction/speak into the mouthpiece, then let's use other avenues of communication to resolve the issue.

Callers should not be forced to listen to long/verbose prompts. [PeterK] Long does not equal verbose, and verbose does not equal long. I think what Mr. English is trying to say is, "needlessly long." Good advice. "Overzealously brief" is just as bad, maybe worse. Any designer should continually consider the grey-matter limitations suffered by the average caller. Don't tell me to write shorter prompts when my caller is paying to hear Beowulf.

Callers should be able to interrupt prompts (via dial-through for DTMF applications and/or via barge-in for speech applications) whenever doing so will enable the user to complete his task more efficiently. [PeterK] Callers should be able to answer any question when they're ready. They also should be given the proper information before being asked a question. They should be able to interrupt with an agent-request at any time, but maybe not with the answer at any time. Use Hotword technology. Tune your grammars and build decoy paths. Use tuning tools and constantly work on your worst performing dialogues. "Turn bargein on" is not a panacea.

Do not disconnect for user errors, including when there are no perceived key presses (as the caller might be on a rotary phone); instead queue for a human operator and/or offer the choice for call-back. [PeterK] I can't believe anybody on this list would disconnect a call simply because there were too many NMs. Oh wait, I don't think gethuman humans understand the difference between a NM and a NI. Tell you what, if you NI on me a couple times in a row I'm going to play some global handling: "Hello, are you there?" <crickets> "Hello? Uhm, are you... there?" <crickets>. Yes, I've got this running in million-minute apps. Yes, it works, and if the crickets continue I AM going to hang up, just like a person would. If you're dead, my carbon-based agent doesn't want to talk to you either.

Default language should be based on consumer demographics for each organization. Primary language should be assumed with the option for the caller to change language. (i.e. English should generally be assumed for the US, with a specified key for Spanish.) Gold Standard: Remember the caller's language preference for future calls. Gold Standard: Organizations should ideally support separate toll-free numbers for each individual language. [PeterK] The first sentence of this so golden standard assumes somebody's suggested deploying an app with an unpopular language as default. Granted, I made a minor error when I first launched a Starbucks store locator in Seattle using Nuance's secret Mangbetu language pack, but it seemed like a great idea at the time. Live and learn. Why are separate phone numbers a GOLD STANDARD? Why not build a language detector at your first dialogue? Yeah, you'll have to build some custom dictionaries and fiddle with your language pack. Get over it. This is hard work and we're being paid to come up with better answers, not easy ones.

All operators/representatives of the organization should be able to communicate clearly with the caller (i.e. accents should not hinder communication; representatives should have excellent diction and enunciation.) [PeterK] Finally off the hook! We employ professional voice talents, not buttsinseats.