Tips for Using Built-in Intents for Your Skill

What built-in intents are

Built-in intents cover thousands of utterances for a pre-built intent, such as Help, Stop, Cancel, and many more. They are ready to use and can be added as needed to your skill without requiring any additional sample utterances to be added, although they can be if desired. The built-in intents include a variety of sample utterances to serve basic skill functions, such as stopping, cancelling, shuffling or selecting. All built-in intents will start with the prefix AMAZON..

How built-in intents work

In order for a built-in intent to be triggered, it must include an exactly matching sample utterance. This is in contrast to custom intents, which can also be triggered even if there is no exactly matching sample utterance. It is therefore crucial to follow tokenization and formatting best practices for sample utterances if you choose to add them to a built-in intent. Be sure to include apostrophes and accents as required by local language rules.

However, there are two exceptions to this, which are AMAZON.SelectIntent and AMAZON.FallbackIntent. These do not require exactly matching utterances, but can be triggered even if the user utterance is not actually covered.

When to use built-in intents

Using built-in intents can save time - you do not need to write the sample utterances for the intent yourself as they already contain plenty of different possibilities on how the user would express an intention. They cover common phrases to access the functionality that the intent allows for across skills.

For example, the built-in AMAZON.HelpIntent is automatically populated with sample utterances relating to common ways of requesting help from a skill (e.g., "help", "how do I use this skill"), and likewise AMAZON.RepeatIntent allows for ways to ask the skill to repeat content.

Built-in intents make it easier for users to work with your skill in a more consistent, user-friendly way. Additionally, your skill benefits from future updates to built-in intents that help improve recognition by adding in extra utterances for these intents.

There are a wide range of built-in intents available for developers to make use of. Because most of these built-ins are available for each marketplace, they can be easily used for localization of multilingual interaction models across several marketplaces. For a full list of available built-in intents, see Standard Built-In Intents

When not to use built-in intents

Keep in mind that using built-in intents is not always the most straight-forward solution, especially in cases where you prefer the natural language understanding model of your skill to catch utterances that are not contained as part of the sample utterances of the built-in intent. For example, if you expect a wide-variety of alternate phrases specific to your skill (such as “repeat mathematics quiz game”), these utterances may not be supported by the built-in, in this case AMAZON.RepeatIntent, which is meant to capture more general, widely-used commands.

Extending built-in intents

What it means to extend a built-in intent

By default, the built-in intents come pre-loaded with a variety of general sample utterances that align with the function of that intent. While built-in intents perform well when users use more generic requests, such as “stop” or “stop this” which are covered by AMAZON.StopIntent, more specific utterances that could be unique to your skill, such as "stop the quiz" or "stop asking questions", may not be included by default.

Extending built-in intents with unique sample utterances

Built-in intents can be extended with unique sample utterances that are utilized by your skill only, if desired. Use this option for skill-specific user requests. For example, “next bedtime story” contains the invocation name of a skill and is unlikely to be covered by the AMAZON.NextIntent. This is also true for sample utterances that might not be a typical request for a specific intent, such as “no thanks that’s it” for AMAZON.StopIntent.

Extending built-in intents to exactly match a sample utterance and capture a user’s utterance

Yes, even small deviations between the original sample utterance and the actual user utterance (such as an additional word at the end of an utterance e.g., “please” or an incorrectly written sample utterance) can cause the utterance to not hit the intent. Therefore, ensure there are no typos in any extended utterances and that they are all formatted correctly to capture all possible user utterances you can think of.

When built-in intents should not be extended

Extending built-in intents for Long Form Audio (LFA) skills, such as to play radio stations or podcasts, has limited benefit. Extended built-in utterances can't reach an LFA skill while audio is playing. For example, if a user requests to play audio from a radio skill, the audio starts, and then the skill closes. If the user then says "stop playing good morning radio", an extended utterance to AMAZON.StopIntent within the skill, the request doesn't work. Only utterances already contained within built-in intents work at this stage. However, every LFA skill has a certain amount of time in which the skill remains open before the audio starts playing. During this window of time, extended built-in intents can increase coverage of user requests.

In similar fashion to custom intents, built-in intents that have been extended with additional sample utterances should not overlap with utterances covered by other built-in intents.

Avoid utterance conflicts between built-in intents by not extending a built-in intent with a sample utterance that is included by default in another built-in intent that you are using in your skill. For example, a skill may have “cancel” as an extended sample utterance to AMAZON.StopIntent. The problem here is that "cancel" is already covered by AMAZON.CancelIntent, which may also have been included. Now, if a user says "cancel", this will create a conflict across intents and may lead to the utterance not routing to the correct intent.

Also, although Alexa prioritizes custom intents over the built-in intents, ideally sample utterance overlaps across a custom and built-in intent should be avoided. For example, “play” has been added to a custom intent in their skill named StartNewGameIntent. However, built-in intent AMAZON.ResumeIntent has been included in the intent schema as well, which already includes the utterance “play”. By adding this to StartNewGameIntent, the developer has prevented that utterance from resuming an ongoing game and has instead mapped it to starting a new game (because in an utterance conflict across a custom and built-in intent situation, the custom intent is prioritized by the device).

Required built-in intents

Users must have a way to exit the skill. Due to the many and varied ways that customers may request this, AMAZON.StopIntent is required to be included.

Additionally, AMAZON.CancelIntent and AMAZON.HelpIntent are also required to be utilized. AMAZON.CancelIntent allows for multiple ways to cancel interactions with the option to use this to stay in the skill or exit, depending on your skill (see Implement the Built-In Intents), whilst AMAZON.HelpIntent allows for users to ask for help on how to use the skill (see the Available Standard Built-In Intents).

Another required Built-in Intent is AMAZON.NavigateHomeIntent. If your skill uses the AudioPlayer interface or has a multimodal (visual / on screen) component, there are additional intents that you are required to include. Making use of other all built-in intents is optional. If you do not include any other built-in intents, creation of custom intents and sample utterances will be required if you wish to include that particular functionality.

AMAZON.FallbackIntent is also on the way to being required for all skills starting later this year, so it is good to include it as well to avoid future skill building issues.

List of built-in intents

Under Available standard built-in intents you can find a full list of all built-in intents, a description of their purpose as well as a short list of utterances they cover.

How to use AMAZON.FallbackIntent

AMAZON.FallbackIntent works differently from other built-in intents. It is designed to capture requests that your skill can't handle and provide a helpful re-prompt for customers. By optimizing the design of your interaction model with AMAZON.FallbackIntent, in-scope utterances are more likely to route to the correct custom intents, while utterances that your skill cannot handle will be directed to the FallbackIntent.

  • AMAZON.FallbackIntent helps skills handle unexpected utterances, or when a customer says something that doesn’t map to any intents in your skill. It allows skills to respond gracefully to an 'out-of-domain' request to an Alexa skill, and provide a specific handler for AMAZON.FallbackIntent to provide additional instructions or sample utterances on what the skill does, therefore reorienting users. Please note, however, that performance of this built-in intent will get better the more robust the rest of the interaction model is (and vice versa).

  • Creating a custom intent for a fallback function can produce undesirable results and over-sensitivity from the device in terms of routing out-of-domain requests to this intent. Instead, developers should use AMAZON.FallbackIntent and adjust the sensitivity (low, medium or high) of the intent by testing to see which suits the skill best (available for en-XX and de-DE)

  • You can also extend AMAZON.FallbackIntent with custom sample utterances, which will route those specific utterances to AMAZON.FallbackIntent. Please note that adding sample utterances to AMAZON.FallbackIntent does not impact the statistical model it uses.

For more tips, see the Alexa Design Guide.

How to use AMAZON.SelectIntent

AMAZON.SelectIntent lets users indicate that they want to select a particular item, such as an item on a list. Unlike the other standard built-in intents, AMAZON.SelectIntent uses four (AMAZON built-in) slots that collect information about the item the user wants to select. These are built-in slots which possess a unique slot name that can be referenced in the backend code in order to receive a unique identifier for that specific list item that a user has selected.

These are:

  • AMAZON.Anaphor (slot name: “Anaphor”) - returns words such as "this", "that", and "it" that represent an item.
  • AMAZON.Ordinal (slot name: “ListPosition”) - captures ordinal positions and converts them into numbers (“fourth” => 4, “third” => 3)
  • AMAZON.RelativePosition (slot name: “PositionRelation“) - captures words the represent the relative position of an item in a list, such as "top", "bottom", or "last"
  • AMAZON.VisualModeTrigger (slot name: “VisualModeTrigger”) - captures words that indicate the user is expecting a visual response, such as "show" or "display"

Note that you may get a value for VisualModeTrigger in combination with any of the other AMAZON.SelectIntent slots. For instance, the utterance "show the first item" would return 'show' in VisualModeTrigger and '1' in ListPosition. For more examples, visit Example: IntentRequest with the ListPostion and VisualModeTrigger slots.

  • Avoid using these slot types in other (custom) intents. You might run into issues during skill model building when you try using them with slot names other than the mappings listed above.

  • Be aware there is a high chance for this intent to be triggered by a user utterance even though it might not be an exactly covered sample utterance of the intent.

Was this page helpful?

Last updated: Nov 28, 2023