I was just wondering about the best way to handle when a users intent cannot be understood multiple times.
e.g. In the case of a chat bot a user may enter an intent that cannot be understood multiple times, after the third time I would like the chat bot to call a webservice.
What is the best way to handle this scenario? Possible scenarios I have come up with are:
1) Each time the default fallback intent is called we call a web service that keeps track of the number of times the default fallback intent has been called for the current user and on the third time call another service.
2) Chain multiple default fallback intents together in DialogFlow and on the call to the third fallback intent we make the call (Is this even possible or a good idea?)
3) Keep track of the number of times the default call back is called within DialogFlow (By using an Entity I believe) and then on the third attempt we call the Web Service.
Any recommendations or ideas happily received as I am new to DialogFlow
If you mean "Followup Intent" in (2), this would be a bad idea. Just about anything involving chains of Followup Intents are a bad idea.
I'm not sure how you would pull off (3), to be honest. Dialogflow itself has very little ability to include logic of this sort.
The best approach is (1) - for everything, call your fulfillment webhook and have it handle the logic. Typically, you want to count consecutive times the user hits the Fallback Intent, rather than the total times you do so. You can keep this counter in a short-lived Context.
(Libraries such as multivocal keep track of the counter for you, as an aside, and let you use it in responses or in other logic handling.) (Disclaimer, I'm the lead developer for multivocal.)
Related
I'm currently working on building a chatbot and I saw the Dialogflow tool that can provides a lot of help in this topic, so my question if it's usable to have multiple contexts at once and also to be able to call my NLP model (stored in an API) many times? Or do I have to build my own platform for that since Dialogflow can't be call multiple webhooks at once?
Example:
I have a model to classify the initial intent,
I have a regression model to do something else if the intent is XXX.
First, remember that an Intent represents what the user says or does and not how you react to that.
Within that, yes, it is perfectly feasible to have multiple Contexts active at once. The lifespan of a Context determines how many rounds of the conversation it will be active for. All of the Input Contexts for an Intent must be active for that Intent to be considered for matching.
While Dialogflow only lets you register one webhook for all of the Intents, it provides information to that webhook about which Intent was triggered (along with which Contexts are active, parameter values, etc). Based on that, or any other information you wish, you can choose which code or handler to execute. In this way, you can certainly make multiple calls to other APIs if that makes sense - as long as you return within the timeout period (5-7 seconds).
So I have a flow prepared.
User: I would like to book an appointment
Bot: Sure. Does 3pm works for you?
User: Yes
Bot: Great. Appointment has been set. (Response from Fulfillment)
Bot: Anything else you need help with? Yes | No (How to achieve this)
I have tried triggering followupEvent but that won't display any response till the chain of intent is complete.
When the followupEventInput parameter is set for a WebhookResponse,
Dialogflow ignores the fulfillmentText, fulfillmentMessages, and
payload fields. When Dialogflow receives a webhook response that
includes an event, it immediately triggers the corresponding intent in
which it was defined.
I have End Intents ready for response for Yes and No. But need help in triggering it.
An intent shouldn't be used as a step in your flow or be tied to a single response, its intended to represent a category of phrases your user might say to complete a certain goal in your conversation. Since the was this helpful isn't triggered by any user phrase, but more as a trigger for the user to continue the conversation shows that it shouldn't be a separate intent.
Having the was this helpful phrase be available to multiple intents is a good choice so it can be used throughout your conversation, but I would recommend saving this phrase in a file, an API or a CMS and retrieving the response via code.
I'm not a PHP developer, but I expect it to be along the lines of: responseService.getResponse("requestFeedbackPrompt");
This allows you to retrieve the was this helpful phrase throughout your code, without making the mistake of making a seperate intent for it, as this will create problems later on with keeping state.
If you would decide to go with a single intent for this, you will quickly see that it will become difficult to maintain track of context, states and which step of the conversation you are in as multiple intents will go through this generic intent.
What would you do if you need a different variant of the was this helpful response, with the single intent, you will end up creating an intent for each variation and you will have to align the conversation flow and state accordingly every time.
If you use the service, you just call responseService.getResponse("OtherFeedbackPrompt);`
Hi have something similar in one of my bots. I have taken a different approach to those mentioned.
My bot asks if there's anything it can help with at the end of a an acknowledgement fulfilment.
The customer then has the option to respond with Yes or No.
Within the page that asks the question I have created routes.
One route for Yes and another for No.
The Yes route directs customers back to the point where they can start making selections. The No route provides a fulfilment to the customer and ends the session. I have used Yes and No intents for these.
I have created 5 intents in a Dialog flow. After completion of first intent, it should automatically go to the second intent without the use of the training phase. Is there any possibility to do that?
This probably isn't what you want to do. Remember that Intents capture what the user says or does and not how Dialogflow should respond.
If you want to do a series of things when the user says one thing, then you can do all those things in your fulfillment webhook. Your webhook is where you actually do something based on what the user has said, and this can be handled in one function call or several calls that you make from your Intent Handler.
There are two possibilities either you can use contexts or if you want to handle sequence from webhook service you can use events.
For webhook solution,
Give each Intent a specific event and action.
In your webhook request you will get action of your intent and you can trigger next event based on current action. => Dialogflow
For context solution
You can add Follow up intents for your each intents, Follow-up-intents
I'm designing a helpdesk chatbot in dialogflow and currently training it with existing data from my ticketing system. What is the best practice for handling inputs that contain multiple intents? Here is an example with the intents in bold:
"Hi, my name is John Doe and I'm a first year student. I want to know where to register for classes and also reset my enterprise password. Please help."
So is the solution to ask people to keep things simple up front? I think currently dialogflow will point the user to one of the intents above, but i'm not sure how it decides which intent to match with.
You will probably have one intent for each feature that your bot offers, i.e. RegisterClass, ResetPassword etc. In that case there is no good* way to handle the case where someone asks for two things at once, your users will have to limit themselves to one request at a time. You can however use a fallback intent to explain this at runtime. This intent would be triggered if a users utterances matches none of the other intents and could give the user a quick explanation like
"Sorry, I didn't get that. Please tell me what you would like to do,
e.g. 'register a class' or 'change my password'"
This would keep a natural conversation going and alleviate the need to "train" users specifically for your agent.
*You could of course add combined intents like RegisterClassAndChangePassword, but that would become very clumsy and most likely not work reliably. You could also try to parse the request in your backend, but then you would essentially circumvent Dialogflow's core feature.
I'm a bit confused about how to handle the following scenario:
The user triggers the FooBarIntent whose fulfillment requires a linked account from a third party.
I manually call the signin helper from my fulfillment code.
The user authorizes my agent, Actions on Google sends the helpers response with the signin status to Dialogflow, where a SignIn intent picks it up and passes it to my fulfillment service.
Now how do I proceed with fulfilling the original FooBarIntent? I thought this would somehow be handled seamlessly, but the signin helpers response is an entirely new webhook request with no information about the original request. It seems that I could store that information in a context, but that seems rather clumsy. Am I missing something here, or do I really have to tell the user something like "thanks for logging in, now please ask your original question again"?
Saying "Now please ask your original question again" is certainly the wrong approach to take - you have that part correct.
You're also correct that there is no automatic re-triggering of the original Intent. While this seems odd, it is simply because Intents represent what the user has said - not what you're going to be replying with. Both the user's initial statement and their sign-in acknowledgement are separate things that the user has said, and you may wish to handle each differently.
As you suggest - one thing that makes sense to do is to respond to the initial thing they said before you got the results from the helper. In these cases, saving the Intent or Action name and parameters in a context when you request the helper can let you pick back up afterwards. (There are other possible behaviors, however, that could make sense. Consider, for example, if you request sign-in as part of the welcoming intent. Since the user never gets past this first step, you don't need to keep track of the state.)
This pattern of saving the state when you take a detour to get the sign-in is one that is directly supported by the multivocal library, for example. With multivocal, you specify the requirements necessary before an Intent or Action handler is triggered (such as requiring the user to be authenticated). It takes care of meeting those requirements and then making sure the conversation continues where you left off to take the detour.