Amazon Connect with Lex contact flow timeout

Question

I have a contact flow that is using a pre-recorded voice prompt with a lex bot for voice rec. This is the main menu verbiage:

“Thank you for calling. If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen to the following menu options. For billing questions, say “billing”. To report a missed pickup, say “missed pickup”. If you are a current customer with recycling or other account questions, say “other”. If you are not a current customer, and have questions, say “sales”. To hear the menu again, say “repeat menu”. For all other questions, please remain on the line.”

I have set the error handling in the Lex bot to speak "Sorry, I'm having a hard time understanding you. Let's try using the keypad instead to make sure we route your call properly."

This is working when an utterance is not matched or an invalid option is spoken or pressed. However, I cannot figure out if it's possible to allow the lex bot to timeout like in a normal DTMF contact flow and send the caller to the next step in the menu without playing the error handling in from the Lex bot.

Is this possible?

Answer 1

That's the thing, Lex is not meant to be used this way. It MUST have an input to process, and if it reaches Lex's timeout, then it will always return an error and deliver the error handling response.

So you will have to get fancy in the Connect Flow to catch the Lex error message, and turn it into your own handling of it. But it will be hard to know whether Lex is erroring because it didn't understand, or because the user chose not to respond.

Therefore, I would personally avoid building the bot in a way that allows the user to remain silent. The user must direct Lex every step of the way and have easy ways of backing out of an unwanted action.

Remember that Lex is much more powerful than the old automatic call systems, so trying to force Lex into that old system won't work well. Depending on how you design your bot, you can make the conversation much much more natural, accepting a very wide range of responses and directing those into proper actions.

---

Tips:

Things may have changed more recently, but when I was building Lex/Connect, it was not possible for the user to interrupt a playback message. So I had to also avoid what you are trying to do in the welcome message:

If you would like to use your keypad to select the menu options, say “keypad”, otherwise please listen...

Naturally, a user who does want to use the keypad will try to immediately say "keypad" and probably get frustrated by having to listen to the rest of the playback message. So I design every playback message to be short, deliver information first, and always end on the question. Often breaking the conversation up into more branching points to make the questions as specific as possible.

Don't worry about going back and forth with the user too many times. It gives the user comfort knowing they are on the right path to what they want and are able to control the conversation in smaller steps. They will get stressed, having to listen to long list of options and remembering what they are while figuring out which one best applies to them.

So make each question as clear as possible and avoid spoonfeeding options. It feels less natural to explicitly state to the user what they should say:

To report a missed pickup, say “missed pickup”.

That is unnatural.

A good middle ground would be asking one question with a list of options and pausing between each option. The user will understand that these are responses they should make, but won't feel unnaturally pressured into exact phrases. For example:

Would you like to, check your billing, report a missed pickup, ask about sales, or something else?

That is natural.

We are comfortable handling those types of questions because we often do that when speaking with humans. You may even want to use a question mark instead of commas so that the playback voice uses a questioning intonation with each option. It looks less natural in written form, but would probably sound more natural.

Last tip: Don't design your bot based on your experience talking with bots. Design your bot based on your experience talking with humans.