Choose Slot Elicitation Order in Alexa Conversations

Overview

As a user moves through a skill, ACDL elicits—that is, requests—the information it needs to call the API. In a recipe skill, for example, Alexa might ask the user for an ingredient or a dish name. By default, Alexa elicits information in random order. That works fine for simple skills, such as reminders and grocery lists. For skills that require open-ended, two-way interactions, however, the data must be gathered in a specific sequence. Alexa Conversations Description Language (ACDL) lets you define the order in which Alexa elicits information from users.

Slot types and values

When you build your skill in the developer console, you provide sample conversations called dialogs. These dialogs show a typical request and the expected response for each argument, or slot. Slots are fields that represent the inputs users supply as they respond to questions, choose from available options, and make corrections ("Alexa, I want barbecued ribs, not barbecue bibs!").

Slots are categorized by type, such as phone numbers (AMAZON.PhoneNumber) and dates (AMAZON.DATE). Many slot types categorize lists of things, such as countries (AMAZON.Country), genres (AMAZON.Genre) and even desserts (AMAZON.Dessert). Built-in slot types like these are preceded by AMAZON[dot].

You can define custom slot types or extend built-in slot types. The Pet Match skill, for instance, has custom slot types for the user to indicate the size, energy, and temperament of the dog they want.

"I want a {size}, {energy}-energy, {temperament}dog."

The user's preferences are the values that fill the argument slots. These values are needed to call the API.

I want a small, low-energy family dog.

Alexa Conversations has a built-in dialog simulator that expands your sample dialogs into thousands of variations. These alternatives train the dialog management model so that Alexa can respond naturally during real-world conversations.

Slot elicitation policy

You can apply a policy to your skill to determine slot elicitation order. This policy is a list of rules that determine the sequence in which required arguments are collected from the user at runtime.

The dialog policy engine executes these actions. It evaluates each API request against attributes like skill scope, user group, and keywords. If there's a match, the policy engine retrieves the rules from a database and applies them to the skill. Conditionality and confirmation policies, if any, take priority and are executed first.

Copied to clipboard.

[
   ...
   {
     [
        {"policyName": "Conditionality"}
     ]
   },
   {
     [
        {"policyName": "Entity confirmation policy"}
     ]
   },
   {
     [
        {"policyName": "EnsureArgOrder"}
     ]
   },
   {
     [
        {"policyName": "Request args policy"}
     ]
   },
  ...
]

Policy application is not context dependent. In other words, you can't assign different slot elicitation sequences to variable conditions like weather forecast, number of diners, or price range. You can, however, apply a separate policy to each API you call, as in the following use case. The first portion of the dialog calls a flight API, and the latter portion calls a weather API.

Speaker Speech or Action

User

"Alexa, book me a flight out this afternoon, and get the weather for my trip."

N/A

Here you specify the elicitation order src (AMAZON.Airport -> source city), dst (AMAZON.Airport -> destination city), date (AMAZON.DATE -> date), time (AMAZON.TIME -> time).

Alexa

"Sure. What's your departure city or airport?"

User

"SEATAC."

Alexa

"And what's your destination?"

User

"St. Louis, Missouri."

Alexa

"OK. Traveling round trip from Seattle–Tacoma International Airport to Lambert–St. Louis International Airport. What's your return date?"

User

"On Tuesday."

Alexa

"Got it. What time?"

User

"Sometime after 6:00 that evening."

Alexa

"OK, I've found a flight for you. Would you like to hear the details?"

User

"Yes."

N/A

The user selects a flight, and the flight API is called. Then the conversation resumes.

User

"Alexa, what's the weather going to be like?"

Alexa

"Which weather forecast would you like to hear? You can say 'Seattle' or 'St. Louis.'"

User

"St. Louis."

Alexa

"Sure. For what day?"

User

"Tomorrow and Tuesday."

Alexa

"Tomorrow in St. Louis the high will be around 98 degrees Fahrenheit, with a low of 77. On Tuesday you can expect more of the same, with a high in the mid-90s and a low in the mid- to upper 70s."

For the preceding dialog, you define a custom list slot type called ReturnedWeather. It contains the properties cityName (AMAZON.US_CITY), date (AMAZON.date), highTemperature, and lowTemperature.

EnsureArgOrder policy

To indicate slot elicitation order, declare an EnsureArgOrder policy and include the policy type in the policies argument of the skill() action. Policy types are defined in the core Alexa Conversations dialog library. If you don't apply a policy, Alexa Conversations will elicit slot values in the default random order.

Validation

At build time, the compiler checks for conflicts in the dialogs you provide. Be sure the slot order you specify is consistent with your dialogs. Any mismatch will create a validation error. For example, if you designate a slot order of [cityName, date] for getReturnedWeather, your sample dialog must be in the same order, as shown in the following code snippet. A cyclic sort order will also generate a validation error.

Copied to clipboard.

WeatherActionPolicy = EnsureArgOrder{arguments =
               [getReturnedWeather.arguments.cityName, getReturnedWeather.arguments.date]}
skill(.., policies = [weatherActionPolicy, ...])

Example: Define slot elicitation order

Alan and Priyanka decide to use the Alexa Skills Kit to build a Pizza Bot. They begin with four different sort orders, which correspond to their four sample dialogs. They condense those lists into the following single, acyclic sort order.

{crust}
{size}
{sauce}
{veg_topping}
{meat_topping, cheese} || {cheese, meat_topping}

No sequential preference was indicated for meat or cheese in any of their original four lists. In the final list, then, meat and cheese can be requested in either order—that is,{meat_topping, cheese} or {cheese, meat_topping}.

This slot order is used to make sure the right dialogs are generated at build time. In addition, the dialog policy engine follows this sequence at runtime to determine which slot to elicit next. Here, then, is how a user dialog might sound:

Speaker Speech or Action

User

"Alexa, order a pizza."

Alexa

"Okay, what kind of crust would you like? The options are thin crust, pan style, and Chicago deep-dish style."

User

"Chicago."

Alexa

"What size? You can choose small, medium, large, or extra large."

User

"Extra large."

Alexa

"OK. What kind of sauce? You can say regular or extra sauce."

User

"Regular."

Alexa

"And what toppings would you like?"

User

"Pepperoni and green peppers."

N/A

Alexa Conversations calls AddCustomPizzaApi(crust="Chicago", size="Extra-large", sauce="Regular", toppings=["Pepperoni", "Green peppers"]).