I want to respond with quick replies to webhookrequest(Dialogflow) using java spring. I had create a chatbot for Slack using Dialogflow. I want to add content as response which is dynamic which means I cant always go and add the content manually through Dialoglfow console. So I thought of using quick replies but how should I implement it with java spring?
I want it in this way:
U: what is the total cost
Bot: For which account:
1. ABC
2. PQR
3. XYZ
U: clicks option 1 ABC
Bot: Total cost for ABC is xxx
Related
I am trying to build a bot in Dialogflow.
Here is what I need:
customer: Hello
bot: hello, what's your name?
customer: John
bot: Please enter the first element.
customer: element1
bot: Did you finish?
customer: No
bot: Please enter the second element.
....
Please advise how can I implement it? I am trying to create an intent with action and prompt but the agent doesn't ask me "Please enter the first element".
I also need to make first, second .. a counter that updates with each iteration / question.
Can you please advise where can I find a guideline how to achieve this kind task?
So far I have created an agent and playing with intents.
One way would be to write some code for fulfillment (using webhook or even inline editor), analyze incoming messages in your code and generate answer.
If you don't want to write any code, it should be also possible to achieve this using Dialogflow's context to store some information and followup intents to continue asking for elements. But in case you would like to ask user for multiple elements - it could be hard to maintain in Dialogflow. I have created and tested sample bot this way with following intents:
Please note that I have removed default Welcome intent to not interfere with custom "hello" intent.
I am in the process of creating an agent that will handle call requests via speech. For example, here is what the flow looks like:
1). User says: I need to call John
2). The agent grabs John as the parameter and via fulfillment it queries a database for all the entries that contains John in a certain field. If there is more than one John, a follow up intent is triggered and sends a response asking which John is the desired one:
Agent says: There are several Johns, who do you wish to call? John Test, John Smith, John Pleis or John Schmidt?.
3). The user wants to get in touch with John Pleis.
User says: John Pleis
Here is where I'm having problem. Dialogflow is recognizing John Please, instead of John Pleis. How can I handle this?
Update
Here is how the intent looks:
-- INITIAL INTENT --
-- FOLLOW UP INTENT --
You should be able to address these by using your own Entity Types for the names instead of using the System Entity Type of #sys:any. This lets you specify the possible names that would be accepted and Dialogflow can work with the assistant to better understand what the user might be saying. This isn't perfect, but can improve phrase detection, and can provide you with some tools to help it out to make detection even better.
If your directory is relatively small (a few hundred people, perhaps), you can simply create Developer Entity Types up front for all the names. (There is even an API for managing these Entity Types, so you can automate it.)
If you have too many names, you may want to just create Developer Entity Types for the possible first names (or use the System Entity Type of #sys:given-name if that is suitable enough) and then, as part of your fulfillment webhook, populate a Session Entity Type with the possible names that match.
In either of these cases, you can also use entity aliases to help improve matching. So if you see that "John Please" is still matching, then you can set this up as an alias for "John Piels" and Dialogflow will report this as "John Piels" for that Entity.
I have created a bot using Dialogflow (api.ai) and integrated it with Facebook messenger. I want to get the parameter values from user: like city, date (today, tomorrow) by using the quick reply feature of messenger, where user is presented with select-box like options, and can tap on one of the options. The required parameter receives the user-tapped value, saving the user from typing it manually.
I cannot find anywhere in documentation any way to fill up parameter values (slots) using quick replies. There is an option to give quick replies in response section, but the response section is called on fulfilment, and if I take user input in response, then I have to create another follow up intent to process the user-response further, because the current intent gets fulfilled after response.
If I add quick replies in the response section, then I have to create multiple levels of follow-up intents. Ex: I take city input in one intent, and give two options to user (like New York, Delhi). Then I have to create two follow up intents, each for handling one reply (New York and Delhi), and then for each follow up intent, I will have to create more follow up intents to get more parameter inputs. Below is the flow diagram of this case. --->
This can get pretty complex when more levels are added! Amazon Lex has this feature of filling slots using quick replies. Can't I just fill up parameter values directly using the quick replies like Lex?
You don't have to go this far. There is a simple way of using entities & prompts in dialogflow.com. The workflow can be: Weather(intent)->quick reply(New york/Delhi)->City(intent) use entities here->quick reply(Today/Tomorrow)->Use different intents here for today & tomorrow as you will have different responses. You don't need to create different intents unless you have different responses. User says can have different parameters for which you can define different prompts as well. This will again reduce your complexity of creating follow-up intents. Let me know if you need more explanation on this.
I have a situation where I need to ask the city from the user inside a Messenger bot. The location pin works only on mobiles and hence the problem. A city like 'Springfield' has 41 results whereas some cities only have a few.
Currently, I am using the generic template as shown below to show the list of cities but this is obviously not the correct way. The generic template has a limit of 10 items it seems as per the tests I ran and sending quick replies asking "Is A your city | Yes | No" , "Is B your city | Yes | No" is pretty bad...
Any suggestions for this? Should I ask the country name if I have more than 1 result for the city names?
You can ask for zip code. I understand this will significantly reduce the number of possible cities. In response, you can send a message specifying a location. And to ask whether you have correctly guessed the place
For searching place by zip code you can use Google Maps Geocoding API
I am trying create similar view like in GMail. I know that GMail IMAP
have extension X-GM-THRID which I can use in FETCH command, but this
return me this same numbers of items and I must group them manually by
thread ID. Exists any faster way to group this? I am mean, can google
imap server return me list of messages grouped by thread id (like in gmail web interface)? To be more specific:
If I have this list (THREAD ID | TEXT)
12345 "hello"
12345 "hi"
12345 "what's up?"
67890 "are you there?"
67890 "no, I'm not"
I want get from server only:
12345 "hello"
67890 "are you there?"
Can I do that? Finally, I would have to group this by my self, but this solution is inefficient and slow (I have many messages to group)
Regards and sorry for my English.
The 'In-Reply-To' header of the child should have the value of the Message-Id header of the parent.
There is one another field in header 'References' which contains message ids of all its parent.
you can user either of them as per your requirement.
Years old, but:
The unsatisfying answer is: you can't --- IMAP only knows about messages, not threads, so you can only get thread information by looking at all the messages and aggregating.that.
What you can do is to fetch just the UID and X-GM-THRID fields, which is fast (about 40 bytes or so per message). Then you find the first message for each thread, then use UID FETCH to pull just those. By not fetching the entire message envelope until you know which messages to fetch you save a lot of bandwidth.