alexa phone call hash/pound sign available? - alexa

I use Alexa at home, and now it has the option to place phone calls for free within the USA or Canada.
This is initiated by saying, for example, "Alexa, call 1-XXX-YYY-ZZZZ"
However sometimes you get to an automated menu that wants a number and then either a "#" or "*" symbols. I tried saying "asterisk", "pound", and "hash" but none of these were recognized.
Is there a way to enter these symbols when using Alexa calling?

If you follow this link
https://www.amazon.com/gp/help/customer/display.html?nodeId=202136300
It mentions
Note: Alexa Calling does not currently support calls to the following
types of numbers:
Emergency services numbers (e.g. “911”)
Premium-rate numbers (e.g. “1-900” numbers, or toll numbers)
N-1-1 numbers / abbreviated dial codes (e.g. “211,” “411,” etc.)
International numbers (numbers outside of the US, Canada, and Mexico)
Dial-by-letter numbers (e.g. “1-800-FLOWERS”)
I guess Alexa does not support calls with an automated menu.

Related

How to call multiple intents at once when the slot value is shared by multiple intents?

For example, I have a skill that tells the user about food interactions with medications. The user tells Alexa which medication they want to know about.
Each intent corresponds to a different medication interaction (e.g., grapefruit juice, antacids, etc.). Under the GrapefruitDrugs slot-type, I have several slot values (all of them are drug names). When the GrapefruitIntent is called, it gives the user a warning about this interaction. The problem is that I have other slot-types that share the same drugs and their warnings also need to be communicated to the user.
'Drug X', however, will interact with both grapefruit juice AND antacids. So the slot-type AntacidDrugs also has 'Drug X' listed as a slot value. I want both intents to be called.
How do I make sure that both intents get called? I've looked into chaining intents, however I have yet to see an example other than one that links an intent to the LaunchRequest.
Intents are here just to point out what kind of sentence you have received on your webhook. Webhook can be on lambda or can be your custom server (e.g. Java, PHP, NodeJs …). In any case, here is your code and logic. Here you know at what state your conversation is and how should given intent be interpreted.
So in some conversation states you will react the same for two intents, while in some cases you might interpret the same intent in two different ways.

Alexa - Using a slot right after the invocation for skill-internal routing

I have skill with an Invocation like this: "Alexa, ask SuperDuperEvent".
But I want to be able to do this: "Alexa, ask SuperDuperEvent location". Where location is going to be a city.
Because my Skill is heavily location based I need to know the location that is requested before anything else happens. Is this possible?
Is it possible to start the skill with a location, too? Like so: "Alexa, start SuperDuperEvent location".
Is this at all possible with creating a new skill for every location?
I want to avoid using this type of dialog:
User: "Alexa, start SuperDuperEvent"
Alexa: "What location do you want to know about?"
User: "Brussels"
Alexa: "What do you want to know about the SuperDuperEvent in Brussels?"
This is probably the way to go, but it does not feel fluid or engaging.
Cheers
Yes, you can do it if you have the intent location defined. You can find more information at https://developer.amazon.com/docs/custom-skills/understanding-custom-skills.html
The only problem that I see is that the invocation name is only one word. Surely it will not pass the certification process.
As you can see in the developer console:
Invocation name requirements
Your invocation name should be two or more words, and can contain only lower-case alphabetic characters, spaces between words, possessive apostrophes (for example, "sam's science trivia"), or periods used in abbreviations (for example, "a. b. c."). Other characters like numbers must be spelled out. For example, "twenty one".
Invocation names cannot contain any of the Alexa skill launch phrases such as "launch", "ask", "tell", "load", "begin", and "enable". Wake words including "Alexa", "Amazon", "Echo", "Computer", or the words "skill" or "app" are not allowed. Learn more about invocation names for custom skills.
Changes to your skill's invocation name will not take effect until you have built your skill's interaction model. In order to successfully build, your skill's interaction model must contain an intent with at least one sample utterance. Learn more about creating interaction models for custom skills.

How can I make Alexa differentiate between "four" and "for"?

Let's say I have a skill that can be invoked like so:
Alexa, activate profile number 4 using pin 1 2 3 4.
4 and 1 2 3 4 are AMAZON.NUMBER and AMAZON.NUMBER_SEQUENCE slots. I figured the "number 4" would be enough context.
In debugging, it looks like Alexa reads this as:
Alexa, activate profile number for using pin one two three four.
Is there a way to make sure Alexa differentiates between that homophone?
Currently, the only solution I can think of is to not include that utterance and just go with:
Alexa, activate fourth profile ...
That is common example Amazon employees use in every workshop to show how important to properly design voice interfaces. The context is matter. Because by saying "for miles" it can have a different meaning in the context. It could be:
four miles
for miles
for isles
four isles
Alexa cannot understand it without context. And you should create the context around your intents.
So, back to your problem.
If you want to capture numbers, you add AMAZON.NUMBER type to your slot. Using that Alexa will capture numbers from the user.
There is also an AMAZON.FOUR_DIGIT_NUMBER type you can find the use of.

How should I display invalid options?

I've got a WinForms client-server app that displays various offers in a list. Every user (client) has a "rating". An offer consists of various data including a minimum and maximum rating. If a user's rating does not fall in that interval, he should not be able to take the offer.
Of course I could just perform some server filtering and send a list of offers prefiltered for each user to the client application. But that would surely, and rightfully, lead to confused requests "Why isn't this offer showing up? I know it exists, it shows up on [other user]'s screen."
How should I handle this? My favorite solution so far is to grey out the offer and add a tooltip "You can't take this offer because your rating is too high/low" while displaying greyed-out offers at the bottom of the list to leave the actually valid offers easily visible on top of the list.
A disabled option tells the user:
The action is possible.
Just not right now.
But the user can make it possible.
Unless there is some simple action the user can do to change his or her rating (e.g., by selecting some other controls in the same window), do not use disabling and do not show the offers. Disabling may confuse some users who will then hunt around the window for something to do to enable those offers. It’s a great idea to use a tooltip to explain disabled objects, but that’s not a standard and not all users will think to hover the mouse over a disabled option (Why should they? It’s disabled).
Including offers users can’t have, even when disabled, clutters your display, forces more scrolling, and distracts the users from the offers you actually want them to consider. Furthermore, showing unavailable offers can come across as taunting (“ha, ha, your rating isn’t high enough”) and may diminished the perceived value of the available offers by comparison, resulting in lower user satisfaction.
It seems unlikely to me that users are going to go around comparing the offers on their windows, but maybe you have user research saying they do. In any case, you should label the list of offers to make the criteria clear (e.g., “Offers available at your rating” may be sufficient).
If you want to encourage users to increase their ratings, then maybe include something advertising the benefits of an improved rating. For example you could have a link "-Improve your rating- by four points and get -five additional offers-." The first -link- tells users how to improve their rating, while the second lists the offers as a motivator. The latter link should only be there if the offers will still be available if the user actually succeeds in getting four more points.
That sounds like a good way to do it.
As a slight improvement, if it makes sense for your application, you might consider including the actual numbers in the tooltip, e.g.:
This offer requires a rating between 5 and 8. Your rating is 4.

Mobile Phone no. verification

I am designing a website.I want to validate the mobile no. entered by the user on the registration page, by sending a verification code to his mobile phone. Can anyone give me pointers to how should i proceed with it??
i Proudly recommend cognalys (note: I work for cognalys)
Because it provides an elegant API to verify international mobile numbers which can be integrated on any platform .
Step1 :
https://www.cognalys.com/api/v1/otp/?app_id=YOUR_OTP_APP_ID&access_token=YOUR_OTP_ACCESS_TOKEN&mobile=MOBILE
it will generate a missed call to the requested mobile number . And return a keymatch (to authenticate step 2 ) and otp_start ( the first five digits of the missed call number )
Step 2 :
https://www.cognalys.com/api/v1/otp/confirm/?app_id=YOUR_OTP_APP_ID&access_token=YOUR_OTP_ACCESS_TOKEN&keymatch=KEYMATCH&otp=OTP
Ask your user to enter the last five digit of the missed call number concatenate otp_start and last five digit for parameter otp and hit the API including keymatch
You are done ! . It uses a unique technique to verify mobile number
There are two options, depending on your budget.
Option 1 - buy an SMS gateway and install it on your server. You can then call an API from your server-side script that will send an SMS - you will need to supply the mobile phone number and the text content. This is the more expensive option unless you have a lot of volume.
Option 2 - use an SMS gateway service. In this case, someone else operates the gateway and you call their API to send messages. You normally buy "bundles" of texts to use this, so the cost depends on the number of texts you buy.
Uh, that really depends on what you're doing.
You can, for example, connect a phone to the server and send messages using a solution like gnokii or something like this. Or you can use one of email/www to SMS gates that are out there, on the internet.
On the other hand, you can reverse your usecase a bit. Instead of sending a confirmation code to the user (and, I guess, asking him to enter it back on your site) you can display a confirmation code to the user and ask to send a text message to the number you display.
This makes a user having to text you. First it lowers your expenses (if you pay for the message) and second, can prevent the evil users from trying to DOS your SMS system.
Probably the easiest solution is to use some webservice for sending SMSs.
For an example see this: http://www.codeproject.com/KB/cpp/SendSmsThroughWS.aspx

Resources