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.
Related
I have a bot that should collect feedback.
For example:
Bot: Leave your feedback
User: Everything is great!
My idea was to use a fallback intent for this. But the problem is that the bot has many other intents that can react to this input.
For example, if a user writes the word - email to a user in feedback, another intent is triggered.
How can you implement the preservation of the input in this case?
Create an intent to collect this free form feedback. You will need to trigger this intent with an event or based on earlier user input with training phrases like "I want to tell you something" or "provide feedback", etc.
Once they are in this intent, you can use a parameter with #sys.any as the entity in a parameter to collect that feedback.
Here is what that looks like:
In that example there is a default response configured and you could customize the response or even enable fulfillment to send the input to a Cloud Function or webhook for processing, etc.
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.
I’m coding a bot using PHP-BotMan for complexity reasons and using Dialogflow query api to extract and manipulate the informations from the response. I saw examples and hints from people here and on dialogflow forum suggesting using context or events, some of them mixing both. What is the better way to handle this?
The flow of the application is:
user messages bot
bot queries (text or/and #event?) dialogflow
internally process a reply or return dialogflow slotfilling* request
text response bot reply user with last reply or asking to fill slot
Also, how can I be sure that a slotfilling process is finished with “actionIncomplete” only having two values, NULL or TRUE? The dialogflow query response doesn’t show wich slotfilling parameters are required or not…
Thanks for the help!!
slotfilling is when dialogflow sends a text response requesting required parameters to finish an intent, adding those replied values to the context
I was trying something similar to your scenario, here are few points i found helpful:
When Slotfitting with webhook, i can't use the "Required" params field since i have to control the input parameters via webhook (query database to provide options). Which means actionIncomplete field is not useful anymore.
I personally prefer to use context as it can add/remove params which gives you more control.
Hence the dialog was designed to use webhook to check all required params before move on to next conversation flow. and pop quick replies menu to ease and restrict possible input from users.
HTH.