When I submit a skill for certification, there is no way to know when it is going to go live. It may go Live off-hours or when I am not available.

This causes several issues.

1) I can't promote my skill ( Can't tell my users my skill will be available on xx/xx)

2) I can't be available to monitor after initial deployment. (monitor logs, have support ready etc..)

3)I don't know when to turn on any backend API's, Systems etc. (If I have version 1.0 of let's say a lambda function on arn xxxx. I have no way of knowing when to deploy version 1.5 that contains new features etc.)

In summary, process should be as follows:
1) Receive notification that my skill has passed certification (yayyyy) press this button to make it Live.
2) I prepare all my backend systems, send out any communications.
3) Everything is ready time to press the big red button. We are now live.

Currently, it’s impossible to get any data about the flash briefings usage at all. It’s crucial to know at least number of unique listeners and number of plays during some period of time.

For the custom skills we are able to count the requests and sessions ourselves, since we host the backend for a skill, but still, there are a lot of tricky points, for example we are not able to distinguish requests from the certification team, so we count them as usual requests from Alexa users.

I think that's a super basic functionality that really breaks the experience for 3rd party tools users.

Please consider, thanks.

The current flash briefing content (per provider) is a 'one size fits all approach'. Everyone gets the same NPR briefing, for example.

There are many use-cases where user-specific information could be very powerful in the flash briefing, often in concert with interactive skills. Some examples:

* A sport team skill that (in the flash briefing) reminds you of your game time this weekend (or of changes), without you ever having to touch a calendar

* A retailer skill that (in a flash briefing) advises of significant deals, relevant to your buying history or explicit 'watch list'.

I think this would take flash briefing content 'to the next level'.
Please consider!

Right now if I want to get a publishing status of a skill (live, dev, certification), I need to manually go to the SMAPI and ask for that. If you have 3 or 4 thousands of skills that you want to keep up to date, it’s about 5 thousands of requests to SMAPI every half an hour or even more often.

So, to reduce the number of requests and waiting time for users drastically, it’s crucial to have some kind of an event system to be notified when the skill has changed its status from dev to certification or from certification to live for example.

Please consider, thanks.

Problem:

When an audio streaming skill is actively streaming/playing, users of the skill have to re-open the skill in order to issue additional commands. This creates a very awkward user experience, for example:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, ask AnyPod to play the oldest episode"

<oldest episode starts playing>

"Alexa, ask AnyPod to fast forward 3 minutes"

<episode fast forwards>

"Alexa, ask AnyPod to <etc>"

--

Solution 1:

Ideally this interaction would go like this:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"AnyPod, play the oldest episode"

Having "AnyPod" (the skill's invocation name) substitute in as an alternate wake word would be great. But of course you'll never do that in a million years, until in a few years from now when you actually do. So how about this as a compromise in the meantime:

-------------

Solution 2:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, play the oldest episode"

This will require some clever engineering to determine whether the user is said something that maps to a valid intent within the active audio streaming skill's invocation model - and if not, handle the request the same way they are currently handled. That seems reasonably doable.

It does create potential problems where an audio streaming skill may have an intent that conflicts with the invocation name of another skill -ie, the user may wish to open another skill but find that the audio streaming skill "hijacked" their request because the invocation name for the other skill triggered an intent in the audio streaming skill. But, that problem is solvable a few different ways - put greater restrictions on the intents that can be accessed in this scenario, for example:
a "catch all" intent with nothing but a custom slot could not be allowed

any intent with words matching the invocation name of existing skills would not be allowed (they would be allowed during normal skill usage, but not in this more restricted context)

PROBLEM: Forcing a user to remember a skill name is counter-intuitive, bad experience and leads to low adoption rates.

Examples :
Alexa, tell Agent NEO to find my Home Value
Alexa, tell Harmony to turn on my TV
Alexa, ask AllRecipes for a Pasta Recipe

Proposed Solution:
Alexa, find my home's value (Alexa knows that the skill Agent NEO that the user has enabled, can handle this intent)
Alexa, turn on my TV (Alexa knows that the skill Agent NEO that the user has enabled, can handle this intent)
Alexa, find a Pasta Recipe (Alexa knows that the skill AllRecipes that the user has enabled, can handle this intent)

All Alexa has to do to achieve this is, scan through the intent handlers of the skills the user has installed. Then simply pass the command to the correct skill. This is so much smoother than having to tell Alexa to tell a skill name to do something.

Google home introduced this feature a few months ago and it works so seamlessly.

Using timer trigger for this will help. Currently, you can only achieve this by defining a specific time.

This is especially useful for devices that would normally be set to the default position of "on" and I don't want to forget that I temporarily turned it off.

Alternatively, you could give us the ability "if off, turn on in 'x' minutes".

Also useful because default position in most switches is 'off' after power outage. Right now, I'm running a 'turn on' once per hour in case of power failure.

I'd really like to get it down to 10 minutes but that's simply too much manual config with no easy copy/paste.

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