Use a Dialog Model to Manage Ambiguous Responses


In addition to simplifying the code for collecting slot values, a dialog model gives Alexa a better understanding of the user's place within the overall interaction. Alexa keeps track of where the user is in the dialog and can use this contextual information to determine how to handle user responses that would otherwise be ambiguous.

This document provides an overview of how this works and explains some use cases you may want to employ in your skill.

You can create a dialog model with the developer console.

This document assumes you are familiar with the concepts around interaction models (intents, slots, and sample utterances) and dialog models (required slots, prompts, and Dialog directives). For details about these topics, see:

About Dialogs and Ambiguous Responses

To begin a dialog, the user invokes an intent configured with required slots. As the user interacts with the skill and provides the needed slot values, Alexa knows where the user is within that dialog flow and can use this information to better determine how to route the user's responses.

This is especially useful when you consider interactions in which users say words like "yes" and "no", since these words are often used in conversation and are ambiguous if you do not consider the context around the words. For example, the response "yes" could have several different meanings in a skill dialog, such as:

  1. The response to a confirmation prompt for a slot value.
  2. The response to a confirmation prompt for the overall intent.
  3. A slot value for a boolean-like custom slot type.
  4. A response to a question asked outside the dialog, intended to trigger the built-in AMAZON.YesIntent.

Alexa keeps track of the user's place within the dialog to handle each of these scenarios. For instance, when the user is in a dialog, if that dialog is currently at the "ask for slot confirmation" step (Dialog.ConfirmSlot), then the "yes" response is routed to slot confirmation. If the user is completely outside the dialog, the "yes" response is assumed to be intended for the separate AMAZON.YesIntent instead.

The remaining sections of this document provide examples of scenarios in which your skill can take advantage of this understanding.

Use Built-in Yes and No Intents in a Skill with a Dialog Model

The dialog model identifies the steps to collect all the information needed to fulfill a single, specific intent. A skill might also use the built-in AMAZON.YesIntent and AMAZON.NoIntent for yes/no interactions outside of the dialog. Alexa routes "yes" or "no" responses to these intents when the user is not within a dialog.

For example, consider a skill for planning trips that uses a dialog model for the PlanMyTrip intent. This dialog collects slot values for the starting city (fromCity), destination city (toCity), date (travelDate), and other variables. The dialog is configured to require slot confirmation for the fromCity slot.

This skill could also include AMAZON.YesIntent and AMAZON.NoIntent to get yes/no responses completely outside of the dialog:

User: Ask Plan My Trip to start a new trip leaving from Seattle. (This invokes the PlanMyTrip intent and fills the fromCity slot with the value "Seattle".)

Alexa: You said you are leaving from Seattle, right? (Confirmation prompt for the fromCity slot.)

User: Yes. (Because the user is in a dialog currently requesting slot confirmation, this "yes" response is used to confirm the fromCity slot value.)

…(additional steps within the dialog to collect and confirm the remaining slots for the PlanMyTrip intent. Once the dialog is complete, the skill fulfills the user's request by sending the final response for PlanMyTrip.)

Alexa: I've saved your trip. Do you want to create another trip? (Since the previous dialog was complete, the user's response to this question is outside the dialog and not related to the PlanMyTrip intent.)

User: Yes. (Since the user is not within a dialog at this point, this response invokes AMAZON.YesIntent.)

Skill handles AMAZON.YesIntent appropriately…

Use a Custom Yes/No Slot to Collect Boolean Values

In some scenarios, you may need to get a yes or no value from the user during a dialog in order to collect a boolean-like value. The built-in AMAZON.YesIntent and AMAZON.NoIntent intents are not useful for this, since the dialog model is tied to a specific intent and cannot change intents.

In this case, you can define a custom slot type with relevant values ("yes," "sure," "ok," "of course," and so on) and collect the yes/no value in a slot. When you use this slot within a dialog, Alexa can distinguish between the different steps of the dialog (slot elicitation, slot confirmation, or intent confirmation) to correctly route the "yes" or "no" reply.

Include synonyms in the slot type definition for better coverage of words users might say:

{
  "types": [
    {
      "name": "YES_NO_SLOT",
      "values": [
        {
          "id": "TRUE",
          "name": {
            "value": "yes",
            "synonyms": [
              "yep",
              "yeah",
              "I do",
              "yes please",
              "you know it"
            ]
          }
        },
        {
          "id": "FALSE",
          "name": {
            "value": "no",
            "synonyms": [
              "nope",
              "I do not",
              "no thank you"
            ]
          }
        }
      ]
    }
  ]
}

In the above sample type definition, any of the affirmative responses such as "yep" sends your skill:

  • The value the user spoke: "yep"
  • The canonical value: "yes"
  • The defined ID: "TRUE"

See Define Synonyms and IDs for Slot Type Values (Entity Resolution) for more about defining synonyms and getting back resolved slot values. See Slot Object for details about how the slot data is represented to your skill in the JSON.

During the conversation with the user, Alexa keeps track of the steps within a dialog to route "yes" and "no" values appropriately:

…Earlier steps to begin the interaction and collect the value "Seattle" for the fromCity slot.

Alexa: You said you are leaving from Seattle, right? (Confirmation prompt for the fromCity slot.)

User: Yes. (Because the user is in a dialog currently requesting slot confirmation, this "yes" response is used to confirm the fromCity slot value.)

Alexa: Do you want to buy trip insurance for this trip? (Slot elicitation for a boolean-like buyInsurance slot, configured with the custom YES_NO_SLOT type.)

User: No. (User's response is used to fill the buyInsurance slot.)

Skill interaction continues…

Single-slot Utterances for an Intent

In many skills, it may be very natural for users to invoke an intent by stating a single slot value with no additional phrase around it. In this case, Alexa can route the utterance depending on where user is within the dialog.

For example, assume that the PlanMyTrip intent has been configured with utterances such as:

{toCity}
i want to go to {toCity}
plan a trip to {toCity}
...(many more)

In this case, the user could invoke the skill like this:

User: Tell Plan My Trip Chicago

Because the user is not yet in a dialog, Alexa resolves the utterance "Chicago" as a value for the toCity slot and invokes the PlanMyTrip intent, with toCity filled in. The dialog continues from there.

In contrast, if the user is already in a dialog and is at a slot elicitation step, the same single-slot utterance is resolved to fill the slot and does not invoke an intent:

User: Tell Plan My Trip Chicago (Skill launches and invokes the PlanMyTrip intent with "Chicago" as the value for toCity.)

Alexa: From which city are you starting your trip? (Slot elicitation prompt for the fromCity slot.)

User: Seattle (This ambiguous utterance matches an utterance for the PlanMyTrip intent, an utterance for the fromCity slot, and an utterance for the toCity slot. Because the user is currently in the slot elicitation step for fromCity, Alexa uses this value to fill fromCity.)


Was this page helpful?

Last updated: Nov 28, 2023