Writing good questions
How to write questions a shopper can answer in one breath, with good and bad examples from real ecommerce flows.
The question is the part of a flow you control most, and the part that decides whether the call works. Ask steps are spoken word for word, so write them the way you'd say them on the phone.
The rules
- One question, one answer. Each ask step captures one answer. If you need two facts, use two steps.
- Say what you already know. Read the order back before asking about it, so the shopper doesn't have to remember it.
- Make the expected answer obvious. A yes-or-no question should be answerable with "yes" or "no".
- Keep it short. If you can't say it in one breath, the shopper can't answer it in one.
- Read back what's easy to mishear. Addresses, names and dates get a confirm step before any action uses them.
- Ask for things, never secrets. No card numbers, OTPs, passwords or bank details, ever.
Good and bad, side by side
| Instead of | Write | Why |
|---|---|---|
| "Can you confirm your order and delivery address?" | "You ordered {items} for {order_total}. Did you place this order?" then, as a second step, "We'll deliver it to {address}. Is that right?" | Two facts, two steps, each a clear yes or no |
| "Is there any issue with your order?" | "Did you place this order?" | Open questions get long answers that don't fit a type |
"Please verify the details of order ID {order_id}." | "You ordered {items} for {order_total}, to pay on delivery. Did you place this order?" | Shoppers remember what they bought, not the order number |
| "What is your preferred delivery date and time slot?" | "Which day suits you for delivery?" (a choice of days), then "Morning or evening?" | One answer per step |
| "Why didn't you complete the payment?" | "What stopped you from paying? Was it the payment, the price, delivery, or something else?" | Offering choices makes a choice answer easy |
| "Would you like to provide an alternative address?" | "What's the right address, with the area and city?" | Asks for exactly what you need |
Choosing the answer type
| If you need | Use | Note |
|---|---|---|
| A decision | Yes or no | Branch on it: "no" can go to a different step |
| One of a few known options | Choice | Say the options in the question; list them in the step |
| A count or an amount | Number | |
| A day | Date | Stored in English ("Saturday") |
| Anything else, such as an address | Text | Follow it with a confirm step |
On the first question of a call, "Do you have a minute?", turn on end the call on no. A shopper who's busy gets your polite not-now line, and the run ends as not_now instead of carrying on.
Use inputs and earlier answers
Write {input_key} to use what the run brought ("{customer_name}", "{order_total}") and {answer_key} to use an earlier answer ("So the new address is {new_address}."). Amounts are read as rupees in words and order numbers digit by digit, so write {order_total}, not "₹{order_total}". RowCall won't publish a flow that uses a name it doesn't know.
Test it out loud
Simulate the flow and listen to every question. If a question sounds odd spoken, or you find yourself answering with more than a few words, rewrite it. See Simulate a call.
Next stepFlowsThe building block every call is made from.