Reasons:

1. Because it's so natural for people to do! And Alexa is a product for people.




2. Users quite often start to speak while Alexa is still speaking or just finished speaking and haven't yet turned on its mic.
   There is a blue light, but sometimes users speak to Alexa when it's outside of their view site. Alexa is designed to be for eye-busy experience, and eyes might be busy while interaction.




3. Alexa is actually listening to users all the time while it's speaking - but now it only detects a wake word. So why don't allow a full intent there?




4. Short input is missed sometimes - as users finish speaking BEFORE Alexa starts to listen.
   Users are not happy, so devs are not happy neither.




5. When Alexa is talking it means that users want it to talk, so it's normal NOT to use wake word.

I have a skill that faces problem of people start speaking "too early" for Alexa. And I end up adding more and more "synonyms" into my model to handle this case, e.g. for Rihanna I needed to add {hanna, anna, na}. It seems like an artificial thing that needs to be taken care. And short input as "Abba" is often completely missed with no way to recover.

If you as a dev also face this problem or just think it's fair to have such feature, please upvote!

I would like to fall asleep to Forensic Files but don't want it to play all night long and currently, the 'Alexa, set a sleep timer for ***' doesn't work for that. There's no way to turn the videos off after a specific amount of time except to wake up and tell Alexa to turn it off. Since this comes from Amazon Prime Video, there should be no reason that this can't be incorporated. I can set a timer for pretty much anything else, But Video! I've seen lots of requests for this. I imagine there are a lot of people who don't post who would want it as well.

There should be a way to nest directives into reprompt actions, so that whenever a re-prompt situation occurs, instead of just plain text, a new directive can be sent to either change intents, or open the microphone for user input again or activate colors, gadgets, etc to get the user's attention.

Example:

User: Alexa open ticket purchase
Alexa: Okay. what is the name of the airport you are going to?

(User thinks to themselves ... what is that airport name .. shoot I have to look online as 6 seconds pass by...)

Alexa: (reprompt) What is the airport's name?

(User scrambles to find the name in their files)

(6 seconds passes...)

(Alexa skill closes...)

(User curses at the box and contemplates throwing it out the window...)

User: Alexa open purchase tickets

Alexa: What airport are you going to?

(User realizes they're going to repeat themselves again and starts looking up alternative ways of buying tickets that dont involve Alexa...)

What SHOULD happen is this:

User: open purchase ticket
Alexa: What airport are you going to?
User: (wait 6 seconds as user looks for the airport name)
Alexa: Please say which airport you want to travel to. (reprompt)
User: (wait 6 more seconds looking for name of airport)
Alexa: No rush... (reprompt directive allowing for the user to figure out what the airport is)
Alexa: ... (reprompt directive allowing for the user to figure out what the airport is)

(User finds the name of the Airport)

User: Its Los Angeles Airport!
Alexa: Great. When do you want to leave?

Everything works out, ticket sale completes. Nobody destroys any Echo devices.

This also addresses about 100 different use cases on the feature request forums from being able to dictate speech to catchAll intents to raw messages in JSON requests to changing the Alexa wake word to creating a unique platform within the Alexa platform. I am pretty sure this is a must-have that can be implemented by copying and pasting (no new code writing really)

I am building what amounts to a knowledge management app (what I would consider a major application opportunity for voice in the enterprise) for a Fortune 500 company prototyping Alexa as a front end to access information (APL submenus to navigate) from multiple subcategories of information. In order to accomplish this seamlessly a given skill needs to call another skill (ala Skill Connections) without returning control to the original skill. Per support, this apparently can not be done currently (Skill Connections returns control to the "requesting" original skill and does not cede control). Please consider adding what seems to be this rather simple functionality.

As a developer, I would like a field on an incoming intent request payload that tells me whether that request was the result of a barge-in or not.

Rationale:
Today, there is no way to know whether an incoming intent in a live session was the result of the user completely listening to the previous response, or the result of the user doing a barge-in by invoking their wake word. There are several use cases where this information would be useful, but the two most important are:

1. If you were giving instructions to your user at the end of your response, and they barged in, it is likely that they did not hear the information that you think you gave them. Ergo, you should repeat it at a later time.


2. If users are regularly barging in to your responses for a given interaction, that tells you that your responses are too wordy and probably need to be shortened to provide a better user experience.