No results found
Alexa Blogs
Interactions with Alexa rely on prompts, which coach the customer on what to say next. Prompts are the primary force guiding customers through a successful interaction, and so the words matter—a lot. As Amazon Alexa VUI Designer Alison Atwell says, “Words can signal subtle meaning to users.” But even if you understand the importance of writing for Alexa, it can seem like mysterious process. The good news is, there are concrete ways to harness the power of those subtle signals, just by taking a close look at the slot types in your code.
As most skill builders know, the Alexa Skills Kit provides a number of useful built-in slots, which contain well-designed, robust sets of valid slot values. What skill builders may not know is that there’s a tight relationship between what’s in the code and Alexa’s dialog. When your skill contains a prompt that isn't precise, customers can interpret the question in ways you didn't intend or predict. As a result, they can answer in ways that aren't included in your slot values. An imprecise prompt can shuffle customers off the happy path and into the weeds.
With some simple tweaks, you can fine-tune your dialog to reflect your code’s slot types. You’ll create precise language with the right subtle signals to set up your skill customers for success — and divert them from error states.
To illustrate how slots and prompts go in tandem, let’s look at some often-used built-in slots.
Where: Eliciting a Specific Location
Lots of skills need to elicit a location from customers, whether it’s a trip-planning skill, or a skill to help customers find things in their area, like doctors or movie theaters. But “where” is a broad concept, and customers can interpret it in multiple ways. Here’s an example:
Customer: “Alexa, ask Plan My Trip to plan a trip.”
Alexa: “Let’s go! Plan My Trip will help you plan your dream trip. Where do you want to go?”
Customer A: “Let’s go to Seattle!” (a city)
Customer B: “I want to visit Kansas!” (a state)
Customer C: “Take me to India!” (a country)
Customer D: “Anywhere but here.” (We may not be able to help Customer D.)
Let’s assume the Plan My Trip skill employs the AMAZON.US_CITY built-in slot in its code. In the scenario above, only Customer A has provided a valid slot value to move forward in the interaction; the other customers will likely hear an error message.
Now, let’s make a small improvement to the prompt. Instead of “Where do you want to go?,” we’ll change it to “What city do you want to visit?”
Customer A: “Let’s go to Seattle!” (a city)
Customer B: “I want to visit Topeka!” (a city in Kansas)
Customer C: “Take me to Mumbai!” (a city in India)
Customer D: “Um, can you recommend a city?” (Ideally, Plan My Trip could handle requests for a recommendation.)
Now, because the prompt was specific and expectations were clear, all of these customers understood what information they needed to provide. Each customer moves forward in the interaction instead of hearing an error message or getting re-prompted. Small changes can make a big difference.
Here are some suggested prompts for location slot types:
- AMAZON.US_CITY: What city?
- AMAZON.US_STATE: What state?
- AMAZON.Country: What country?
- AMAZON.Airport: Which airport?
What if you code your skill to employ multiple built-in slots? Your prompt can indicate that, too:
- AMAZON.US_CITY and AMAZON.US_STATE: Which city or state sounds good?
- AMAZON.US_CITY and AMAZON.Airport: What’s your departure city or airport?
When: Eliciting a Specific Time
Many skills require customers to specify time-based information, like a date or time of day — commonly found in travel skills, or skills where customers purchase tickets. Similar to “where,” when your skill tries to elicit a time, the word “when” can be vague.
Customer: “Alexa, tell Movie Tickets I want to see Star Wars.”
Alexa: “Alright! When do you want to see it?”
Customer A: “At 7 pm!” (a time of day)
Customer B: “Um, Tuesday, I guess.” (a day of the week)
Customer C: “How about July 6?” (a date)
Customer D: “As soon as possible!” (To help Customer D, the skill would need access to the soonest movie times, which is a subject for another post.)
Let’s suppose that the Movie Tickets skill is employing the AMAZON.Time built-in slot. In that case, only Customer A has provided a valid slot value. And again, a simple edit can keep all of these customers on the happy path.
Some suggested prompts for time-related slot types:
- AMAZON.DayOfWeek: Which day of the week?
- AMAZON.Month: What month?
- AMAZON.Date: What date?
- AMAZON.Time: What time?
It is possible to code your skill to accept or require multiple types of slots — for example, if the skill needed to collect both a date and a time. Developers can use dialog management to handle conditional data collection. In this case, a broadly worded prompt may work, because your dialog management set-up can elicit additional pieces of data if the customer doesn’t initially provide them.
How Long: Eliciting a Specific Duration
A more complex case occurs when a skill needs the customer to specify an end date or a duration. For example, in a skill where a customer is purchasing a subscription, the customer may need to specify how long they want to subscribe to the product or service.
Customer: “Alexa, tell Magazine Rack I want to get a subscription to Coders Weekly.”
In this case, there are two built-in slots that could be used: AMAZON.Duration, and AMAZON.Date. The slot your code employs depends on what data your back-end system needs to collect — which in turn affects your prompt.
If your back-end system is trying to collect an end date for the subscription, you’ll likely use AMAZON.Date. In this case, you’d want your prompt to explicitly ask for it: “What date do you want your subscription to end?”
If your back-end system aims to collect a duration for the subscription (and then calculates the end date from there),you’ll likely use AMAZON.Duration. In this case, your prompt might say “How long do you want to subscribe?” so that users can give answers like “six months,” or “one year.”
The way that slot type and prompt rely on each other is a perfect example of how design and development share common goals! Everyone wants the customer to succeed, and double-checking your prompts for alignment has a huge impact on a skill’s success.
