Currently, there is no way to accurately do automated testing of how user audio resolves (in terms of intents and slots) for a given skill.

At present, this testing is more-or-less done manually. There are several use cases where automation would be vitally important. Given:

-When testing a large skill, it is extremely cumbersome to manually test a wide array of sample utterances for every change we make to the voice model. This discourages iterative design.
-The overall Alexa voice model is constantly shifting. This is a good thing, but often this results in changes to how our skills launch utterances, one-shots, etc are resolved, and right now we have no way to do this testing on a regular, automated cadence.
-Testing a skill across a variety of voice types (varying gender, age, accent) is not something that we see done today, because the effort to manage something like that is considerable.

And, on a point unrelated to test automation, it would also be beneficial if we could have our users who are struggling with misfiring intents send us an audio clip of their voice and let us send that to this endpoint to see what's happening. Trying to reproduce a user's accent/pitch/prosody as a developer is (often comical, but) not particularly helpful.

All of these cases could be resolved by:
1. An endpoint within the SMAPI or some other similar REST service; which,
2. Accepts as a POST request an audio file in a specified format;
3. Along with whatever request metadata might be relevant; as well as
4. A parameter in the path or body that specifies the id of the skill under test; and
4. Returns a JSON object with the exact Alexa request that would've been made to the specified skill

Ideally this API could also have a mechanism for dealing with things like sessions and dialog management (and how the intent resolution may change in that state), but the 90% case could be easily covered by a simple "isNewSession" flag that lets us emulate both one-shots and open session requests.

It's worth noting that we've actually tried (with some success) to solve this problem on our own - to middling success - via AVS. The functionality just does not exist for this to be addressed by third parties, unfortunately. A description of our feeble attempt can be found here: http://www.3po-labs.com/blog/a-proof-of-concept-and-its-roadmap

Request:
Amazon to send a follow-up email to users who used a skill that invoked account linking option so that they can complete the account linking from an email link instead of just in the Alexa phone app.

The current process is too disjointed. The user has to break off their voice session in order to fiddle about on the Alexa app. Conversion of account linking is terrible.

With this request implemented the user would be reminded about account linking at a later date via their email and could complete it whilst in a mode that is more appropriate to what they're currently doing (i.e. they're on their phone rather than in the middle of a voice experience).

Ideally the email would give the developer the ability to include a short paragraph to explain the benefits of account linking.

Thanks.

Allow developers to be able to define callbacks for user interruptions.

At the moment, as soon as Alexa start responding to the user, he must listen to the full response or quit the app.
There's no option to suppress current response and stay in the app.

Consider an example:
Alexa: I found three news articles related to your query. Article #1: [title of the article] Article #2: [title of the article] Article #3: [title of the article]

Assume that the app allows the user to then listen to the full article. He needs to wait for the full message to be read before he can interact.

It would be much more interactive and real-life like if the user could interrupt and ask "Read me this article", and that would activate a callback function, that the developer would be able to define.

Currently, the only way to have this functionality is to force users to wait until the end of the message and then say something like "Read me the second article".

That callback function would receive as argument the user command plus the word/sentence that was being spoken when the user interrupted, which would allow for faster interactions.

In follow up mode, Alexa continues to listen for a while after the skill closed (session is ended) and detects if there's a relevant follow up request for the user. This is designed to relieve the user from having to say, "Alexa....."

It's logical to assume that if the user makes a request in follow-up mode that can be handled by the previous skill (e.g., they ask for another stock price fact after having just used 'my great stock price skill', they would expect that skill to return the response.

This is not how it works now. Even the the user doesn't have to say "Alexa...", still Alexa doesn't "remember" what has just going on. This leads to an inconsistent and aggravating user-experience.

Alexa should default to the last used skill in follow up mode when the user makes a relevant request.

Interpret-as tag allows you to have the device speak characters, numbers, addresses, etc.

One thing I noticed however is it doesn't respect case. I was wondering if something can perhaps be added to address this? If you echo out the below ssml you will just get a-b-t-h back. Ideally it would say Capital A, lowercase b, Capital T, lowercase h. I have a skill that echos back password values that are generated with different case. Right now I have to pass this into a function and do this mapping on my own, would be nice if it was something built in.

<speak> <say-as interpret-as="characters">AbTh</say-as>. </speak>

Creation of an "AMAZON.ExtendedHoldIntent" type intent.

To the user, the device clearly indicates to be in a waiting state by graying out or blanking the screen.
A mauve to white to mauve triangle wave flashes on the hardware LED(s) as the indicator.
"(wake work +), I'm back / okay / continue etc." re-triggers the previous speech directive and prompt etc.
AWS modifies the Lambda’s context.
The Alexa Skill triggers the lambda with previous attributes and is not a new session.
Amazon decides how best to handle the Lambda compute use time increase, or which maximums are allowable.

Creation of a "Audio Recorder" Interface:

"Alexa call 555-1212" does part of this already.
The Echo firmware needs to be updated.

The directive to the hardware contains some new additional fields.

The directive is received containing an S3 target and credentials.
The creation of an "AMAZON.RequestAudioRecordBeginIntent" intent could serve to satisfy as proof of user intent by the utterance keyword(s) and require mandatory re-confirmation.
The echo initiates the opening of the microphone with an indicator to the user, and begins storing the audio on the hardware. The wake word engine triggers a truncating of the audio, starting the from EOF, backwards to the wake word + "stop".
A green to white to green triangle wave flashes on the hardware LED(s) as the indicator.
The permissions settings include specific consent to allow captured audio for that skill.
AWS modifies the Lambda’s context.
The Alexa event endpoint receives its payload, but its behavior is limited to ‘write’ to the target storage endpoint specified in the new directive type. The Alexa Skill triggers the lambda with previous attributes and is not a new session.