Tips for Using Built-in Slots for Your Skill

Built-in slot types

Built-in slot types are slot types which, like built-in intents, are pre-made and maintained by Amazon. They are populated with categorized lists of slot values, such as Cities, Countries, Numbers, etc. There are a wide variety of different built-in slot types, each pertaining to a different category or theme.

Built-in slot types can be used to cover slot values for broad categories like dates or Animals without having to manually create a list of values yourself. This allows you to build skills and sample utterances more quickly than manually creating slots. For example, rather than attempt to cover all the different ways a user could refer to a date (e.g. “today”, “tomorrow”, “last tuesday”, “july the fourth”, etc.), instead use AMAZON.DATE to cover all of these variants and more. Instead of creating a custom slot to cover available destinations in a flight skill, you could make use of AMAZON.Country. As well as saving on slot building time, built-in slot values are created and maintained directly by Amazon teams. Some built-in slot types like list slot types can be extended with additional custom slot values if required.

The three main categories of built-in slot types, as well as best practices for each, are discussed below. For a full list of available built-in slot types, see Slot Type Reference.

Best practices for built-in slot types

  • All built-in slot types should be used in the correct context. In other words, the content in the built-in slot type should include the type of user input that you’re trying to cover. For example, on the surface, AMAZON.City may seem appropriate to use in a skill that covers towns and cities within the marketplace coverage area. However, on closer inspection, AMAZON.City contains cities from around the world, and very few localized towns. AMAZON.City would therefore not be the correct slot to use in this context, and would likely not be able to resolve user requests correctly. Carefully read the descriptions of slots on the Slot Type Reference page before using them in your skill.
  • A built-in slot type may not be the best option for your skill, even if there is a built-in that could cover your use case. It may be better to use a custom slot if only a few values are required. For example, if your skill gives users four options to choose from, and asks them to select “one”, “two”, “three”, or “four”, using AMAZON.NUMBER is not ideal because this slot covers all possible inputs of numbers, and, for your skill, you only need to cover one through four. Therefore, a custom slot is a better option here and may increase the accuracy of the skill. Before selecting any built-in for use, determine if you need a very limited selection of values, or a very wide selection of values. If the answer is limited, create a custom slot, unless there is a built-in that would cover these limited values such as AMAZON.Month. If the answer is a wide range of values, opt for the built-in (if there is a contextually relevant slot available to cover your use case).

Built-in slot types: sub-types

List slot types

List slot types are finite lists of values that cover a particular theme or topic (e.g. AMAZON.Country contains a list of all the countries in the world, while AMAZON.Animal contains an extensive list of animals). List slot types range in size from catalogs that cover many thousands of values like AMAZON.Movie, to much smaller catalogs such as AMAZON.DayOfWeek.

List slot types should be used when values within a slot can be covered with a finite number of terms, or when the topic is too extensive to be covered with a custom slot. For example, rather than creating a list of all countries around the world for your skill, you should instead make use of AMAZON.Country, which is ready made for this use case.

For a complete list of available list slot types for each marketplace, see Slot Type Reference.

Points to Consider

  • Extend the built-in to increase coverage of your slot type. Use this functionality to ensure coverage of values that you want to ensure are 100% required of the skill. e.g. In a pizza delivery skill utilizing AMAZON.Food to cover toppings, consider extending the slot with toppings that you want to ensure are covered.
  • Use sample utterance profiler to check whether values are covered. Use the utterance profiler to see whether the slot is recognizing user input correctly, and to check the skill provides a correct response. For more information on the utterance profiler, visit the Test the Design of the Interaction Model for Your Skill page.
  • Check the availability state of a slot before using it within the interaction model of your skill. Not all slots are available in all marketplaces. Be sure to check the availability state of a list slot type before attempting to utilize it in interaction models across multiple marketplaces. The availability state of the built-in slot types is located on the Slot Type Reference page.
  • Avoid using slots on a deprecation path. List slot types on a deprecation path lack ongoing support, and are no longer maintained. Check the availability state of list slot types on the Slot Type Reference page.

Numbers, dates, and times slot types

These slots cover situations when you require a slot where user input is less predictable, and cannot be covered with a finite list of slot values. For example, there is a wide variety of customer phrasing that users could say to invoke a date (“today”, “tomorrow”, “next week”, “fourth of july”, etc). Utilizing AMAZON.DATE will ensure all these phrases are covered and are resolved consistently to a date format.

For a complete list of available list slot types for each marketplace, see Slot Type Reference.

Points to Consider

  • Unlike list slot types, these slot types cannot be extended.
  • Know the difference between AMAZON.NUMBER and AMAZON.FOUR_DIGIT_NUMBER. Both of these slots can cover the same usage (e.g. “1234“ is covered by both slots). If used in different intents be sure that sample utterances using them are distinct. See the Design the Sample Utterances & Intents for Your Skill page for more information on overlapping slot values.
  • Use the sample utterance profiler to check whether values, such as dates, are resolved into the correct format and delivering them to users in the correct way.

Phrase slot types

Phrase slot types allow for input from a user with fewer constraints on format and content. Unlike list slot types or Numbers, Dates, & Times slot types, they have no set definition or criteria. As such, they should only be used in cases where user input is far less predictable. For example, instead of covering sample utterances like “why is the sky blue” and “why is grass green”, you may want to use search query to cover the less predictable part with an utterance such as “why is {Query}”. Visit the Slot Type Reference page for more information on how to implement Phrase Slot Types within your skill.

Points to Consider

  • Phrase slot types must be used in conjunction with a carrier phrase (words outside of the slot) in the sample utterances of the skill. Ensure a wide variety of carrier phrasing is covered to ensure the slot type works with as many user phrasings as possible.
  • They cannot be combined with other slot types. Your skill could not have a sample utterance that uses both the SearchQuery slot and the AMAZON.DATE slot (e.g. “remind me to {SearchQuery} on {Date}”), or any other slot, custom or built-in. Phrase slot types must be used as the only slot within a sample utterance.
  • Similarly, phrase slot types can only use once per sample utterance (e.g. “search for {SearchQuery1} and {SearchQuery2}”) is unacceptable. Instead, aim to put a phrase slot type at the end of any sample utterance using it, after all carrier phrasing in the utterance (e.g. “search for {SearchQuery}”).
  • Only use AMAZON.SearchQuery if the intended slot value cannot be covered by a built-in slot type or you can create a custom slot type. For example, don’t use AMAZON.SearchQuery to cover countries (use AMAZON.Country instead). AMAZON.SearchQuery should only be used to cover instances where user input is likely to be too broad to cover with any other slot.