Issue with Amazon Yes & No intents

I have an interaction block where I want a user to make a simple yes/no choice. I’m using the Amazon built in YesIntent and NoIntent but it only recognizes the NoIntent. When I say yes, it does to the else output.

Am I missing anything?

I was shocked to make the same discovery a while ago myself–the Amazon Yes and No intents aren’t reliable. So much for sophisticated machine learning.

I wound up building my own custom yes and no intents.

I was doing some testing and what I realized is that I have a slot that is used to catch a user’s input (I’m using the Amazon.Book type so they can say anything) and it’s conflicting with other utterances. I.e. the yes/no utterance. Does anyone have ideas for how to get around this?

Hi @porterhaus! So you have a custom intent in a capture block with “absolutely” in it, this intent will take the lead on the default Amazon.Yes intent. Same for the “again” and “again please”. As explained in the Utterance Conflicts, Amazon will ignore built-in intents in this case.

Hi @Nicolas, the custom intent was created by the capture block which expects an Amazon.Book type for the slot. There doesn’t seem to be a place where I could override the utterances or something similar.

Hey! Did this issue ever get resolved? I’m working on the same thing right now, and with AMAZON.Book type. It’s a simple enough flow. The prototype in Voiceflow works, but when I upload to the Alexa Dev console, it doesn’t seem to register “yes”, and it registers “no” as “know”. In the Alexa Dev console, if I go into the built-in Yes and No Intents, I am able to add alternatives, like “yeah”, “yup”, or “nah” and “nope” and those register, whereas neither “yes” or “no” themselves work. I’m not using capture intents, as you can see. I have one Slot which I’ve named “name”, and one variable which I’ve named “favorite_book”.

UPDATE: I figured it out. Essentially, because of the potential ambiguities of an utterance that maps to the AMAZON.Book intent, I was creating a whole mess of Utterance Conflicts (12 to be exact) that was causing my custom intent to override the YesIntent. What I had to do here was specify in the flow that both the YesIntent and the NoIntent could be accessed immediately after the “yes/no” question. Once I added extra intent blocks, everything worked perfectly fine.
This page on Utterances from the Alexa Developer Docs helped immensely in figuring out what the issue might be. I’m guessing that this will happen for anyone who is attempting to use built in Slot-Types that have potential ambiguity. I have not tested this yet, but I am guessing that this may happen with any slot type that has to do with Books, Movies, and perhaps even Music (mostly song titles / album titles / band names). If I have time to test this out, I will.

1 Like

can you show the setting in “Yes or No” choice block?

For the record, here is the Yes or No choice block. I have updated my prior post to confirm what was happening and how I resolved the issue. Thank you (as always!) for your help and very quick responses.

I just checked this. you are right. but I wonder why you put Intent block? I guess it might works somehow but solve conflicts in ADC?

1 Like

It seems to solve the utterance conflicts in ADC and prevent the override. I added the Intent block because, as it says in the docs, it all(ows) your project to handle an intent from anywhere inside your project. I interpreted this to mean that it would, in a sense, override any sense of ambiguity that would cause the built-in intents to error out. If I’m not mistaken, this might happen with any of the built-in intents (not just yes/no). I haven’t tested it out, but I wouldn’t be surprised if “stop”, “cancel” or “play” would break down as well.

Screen Shot 2020-02-25 at 2.16.37 PM

1 Like

for my end, still conflicts even if I put intent blocks. IMO, intent block does not overide this because there’s no any changes in ADC’s conversational model with or without intent blocks. only thing to solve this is to fix ambiguous utterance using built-in slot types.

1 Like

I know this is a long time ago, but I’m running in this problem.

@kgirlkris Interesting fix. Could please you should how you did this under the current version of VF? Intent blocks, currently, can only be linked to something after it, not before, so I’m not understanding how you added an Intent block to work with your Choice block. Am I missing something?

@kun432 Do you still stand by your conclusion that the only way to resolve this is to edit the utterances?

@porterhaus Good digging… did you ever solve this in some way?