An Utterance Is Handled by the Wrong Intent Handler

This could happen for a handful of reasons:

• Perhaps Alexa didn’t hear the utterance well.

• Your interaction model has two or more intents with the same or similar sample utterances.

• You’ve not defined an AMAZON.FallbackIntent or a corresponding handler for the fallback intent.

• The canHandle() function on two or more handlers is written such that it matches the same request.

• You’ve not registered the handler with the skill builder.

The simplest explanation is that Alexa misheard the utterance. In that case, try again, speaking as clearly as possible. Or, try testing it with ask dialog or the developer console, typing in the exact utterance.

If that still doesn’t work, then it’s possible your interaction model has multiple intents defined with similar sample utterances. You can use the ask smapi profile-nlu command to see which intent the utterance matches to. For example:

The response will tell you which intent was matched to the utterance as well as any other intents that were considered (if any).

If the utterance was not intended to be handled by any of your intent handlers, then perhaps you need to declare the AMAZON.FallbackIntent in your interaction model (and create a corresponding handler in the fulfillment code). Without declaring the fallback intent, all requests will be matched with the intent whose sample utterances are the closest to the given utterance, even if they’re not very close at all.

If you have a fallback intent declared, but it’s still not handling utterances you expect it to, then you may need to adjust the sensitivity in the interaction model. As a child of languageModel, add the following JSON:

The sensitivity level defaults to “LOW”, but can be set to “MEDIUM” or “HIGH” to increase the sensitivity of the fallback intent.

If the utterance matched to the correct intent but is still being handled by the wrong intent handler, then you should examine the canHandle() function of the handler that is handling the request and compare it to the canHandle() function of the handler you expected to handle the request.

Finally, another common mistake is either not registering the handler with the skill builder in the call to addRequestHandlers() or registering a handler with a less restrictive canHandle() function higher in the list of handlers given to addRequestHandlers(). When determining which handler to handle a request, the first handler whose canHandle() returns true in the list of handlers given to addRequestHandlers() will be used to handle the request. If your intended handler isn’t being registered or if it is registered after one whose canHandle() isn’t restrictive, then another handler will be given the job of handling the request.