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.

• About Dialogs and Ambiguous Responses
• Use Built-in Yes and No Intents in a Skill with a Dialog Model
• Use a Custom Yes/No Slot to Collect Boolean Values
• Single-slot Utterances for an Intent
• Related Topics

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:

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:

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:

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:

Related Topics

• Define the Dialog to Collect and Confirm Required Information
• Dialog Interface Reference
• Interaction Model Schema

Last updated: Nov 28, 2023