We are try'ng to input phone number in an Intent in DialogFlow via voice
But we have big problems with voice interaction even with different people (let me say with a good and natural English)
Using type sys.phone-number we obtain weird result as for example
Original Number as reported on DialogFlow Interface 3 8 3 3 5 7 7 6 6 4 4 4
Result number in web hook 3 8 3 3 5 7 7 6 6 4 4 (missing last number)
Another example sometimes we use double7 to indicate 77 , and the double is total missing we obtain only one 7
Same behaviour with sys any sometimes apppear a 0 near a four and so on .
Percentage of error on some number is quite high, any hint or idea on how to improve this process? As far as i understand we can't do a training on this, nor on a general entity that could contain all possible number.
It seems from my point of view a fail in the voice recognition, may be there is somewehere (Dialgoflow or google action?) some parameter we can modify to improve the success rate?
Could be a godd idea input 100 or may be 1000 correct phone number in the training phase? (i don't think this is a solution the problem is not on the phrase but only in a part of the prhase that contain the number)
Any hint is welcome!!
Thank you
After a contact with the support center, it appears that for number with format
+39 393 XXXX XXX
i.e Telephone number with format from E.123 E.123 is a standards-based recommendation by the International Telecommunications Union , the best way to limit error is to use #sys.number-sequence, but this don't support plus sign, so we use #sys.any with some control, substituting every word before the first digit with a "+" , removing every letter and checking for validity of number with google library..
Doin'g some test it seems that using a phone with a good michrophone the % of right number recognized is the same with sys.any and sys.number.sequence (without using the "+").
The support told us the "double3" i.e. 33 in number (or every other digit) actually is not supported (some times it seems to work fine but not too much)
Related
I am building a voice commerce action for a big food chain and we expect to receive a massive load of orders via voice. The problem is that we haven't be able to figure out a safe way to capture the user's phone. We are currently trying with sys.phone-number and sys.any but it get the number wrong 90% of the time.
This solution is being deployed to Brazil with local number format xx-xxxxxxxx (2 numbers followed by 9 numbers - 0 to 9)
You may take the help of Regex. You can set a pattern and in the webhook check if the number matches your requirement else ask for input again.For example for a Bangladeshi contact number i have used my own custom entity using regex:
(01[3456789])(\d{8})
you can follow this example
I'm trying to allow users to say a dollar amount as input to a Bixby capsule.
So I made a concept of type money.Currency:
structure (Amt) {
role-of (money.Currency)
description (Amount to spend)
}
And then I gave some training examples using it:
[g:SomeGoal] I want to pay {[g:Amt] ($)[v:viv.money.PrefixSymbol:$](25.32)[v:viv.money.CurrencyValue]}
This works fine when the user enters their dollar amount in text, but it frequently fails if the user tries to speak the amount aloud to Bixby.
Example 1 (fails): The user says "I want to pay twenty-five dollars thirty-two cents." Bixby parses this as "I want to pay $25 32 cents" and populates the Amt field with just $25, leaving out the cents.
Example 2 (fails): The user says "I want to pay twenty-five thirty two." Bixby parses this as "I want to pay 2532" and populates the Amt field with $2532, again failing to fill in a value for the cents.
Example 3 (succeeds): The user says "I want to pay twenty-five point three two dollars." Bixby correctly parses this as "I want to pay $25.32" and fills in the Amt field with $25.32. This sounds very unnatural for English speakers though, and I do not think it will be easy to train users to speak this way.
Example 4 (sometimes succeeds): The user says "I want to pay twenty-five dollars and thirty-two cents." Bixby sometimes parses this correctly, other times as "I want to pay $25 in 32 cents" or other similar corruptions.
Anybody have suggestions for getting Bixby to consistently understand dollar amounts in natural language? I am okay with example 2 failing since it is ambiguous, but mainly I would like examples 1 and 4 to succeed consistently. I do have one idea for a workaround (a separate cents field that's manually added to the dollars field by an action), but I'd prefer to avoid that if possible since this seems like a common case that Bixby should be able to handle on its own.
Thank you for bringing this to our attention. I tried the following sentence "Pay one hundred dollars and 25 cents" multiple times and Bixby was able to transcribe it accurately every time.
But your use case (especially #1) is valid as some users tend to not use "and" to tie dollars and cents together. We will raise this internally with our team but I would suggest that you open a ticket with Bixby Developer Support so we can tie your ticket with the issue and keep you posted when its fixed.
Also, your workaround of using a second property to capture cents should work fine too. Let us know if you run into any issues.
Using the telephony integration in DialogFlow, when trying to capture an intent like (for example)
I'm looking for the number six
Where six is defined as #sys.cardinal or #sys.number
I would get it to recognize any single digit except 2 & 4.
For those the text would almost consistently read as "to" & "for" respectively.
This would happen both on the phone, and when testing on the Dialogflow console, pressing the little microphone icon and recording the input.
Why is it missing these numbers when it knows I'm expecting a number in that position?
What can I do to give it better hints?
If the exact phrase the user speaks is "I'm looking for the number two" I believe the agent will detect is as a number based on the context of the phrase.
If they just say "two" it may detect as "to" instead.
Will users only be able to provide a single digit here? If so, perhaps you can create an example for every number (given there are only 10 digits that wouldn't be too onerous).
However, if you're expecting the user to provide a string of numbers perhaps try a different data type for the parameter. The number-sequence type might be more suitable.
Okay, I am trying to figure out why dialog flow keeps adding dashes or extra numbers when I call my bot and the telephony. I can say 6 digit number and it either adds a dash of an extra number. I have used all the sys entities and a custom entity and it does this every time. It acts as if it wants a phone number. Is there a fix? And yes I have added definitions of how numbers I want back. The number I was asking for is 813637 but it adds numbers and/or dashes. I can add the screenshot to this to show you what I get back
Thanks
As per the Google documentation: https://dialogflow.com/docs/reference/system-entities
The description of #sys.number says the input is represented as Ordinal and Cardinal numbers.
However, as per my understanding you require it to be a Nominal Number. Also in your case i understand it is a sequence of numbers. In which case you should try using #sys.number-sequence.
Hope this works for you.
Do let us know how it goes in the comments.
We built an intent to detect user's last four digits of social security numbers. The training phrases capture #sys.number-sequence and #sys.number entities. We match the intent using voice (audio). When the digits are read out separately, #sys.number-sequence is matched. When we say forty five sixty seven (4567) or four thousand five hundred and sixty seven (4567), #sys.number is match. This works fine for most of the numbers. But we ran into the following two issues:
When we read "one one one one", none of the two entities is matched. The voice is actually transcribed as "one one one one". But it is not matched to a number sequence of 1111.
When we say "eighty two seventy five", #sys.number is matched, but only 82 is captured. The parameter value is 82 as opposed to 8275.
Appreciate it if someone could shed some light on these issues.
Well this could also be the issue of Speech to Text engine that you are using. But to check the Dialogflow, I built following Entity and Intent and I was able to capture 4 digits easily. I tested using Dialogflow's Mic option for voice commands.
Also, check out the other systems entities that you may use to capture numbers even though they are designed for something else like zipcode.
Hope the following example helps.
Entity
Intent