Ask a Question

Getting here

Automate → Workflows, open a workflow, click + on the canvas, then pick Ask a Question under Add Steps.

Before you start

• An owner, admin or agent can add this step and save the workflow. Publishing that workflow — the thing that makes it run on live conversations — is an owner or admin action.
• Building and running workflows depends on your plan; see pricing.
• Nothing outside Inchat has to be connected. The step sends on the conversation's last-interacted channel.

Set up

1. Open the workflow and click + where the question belongs.
2. Pick Ask a Question.
3. Write the Question Text.
4. Choose a Question Type: Text, Multiple Choice, Number, Date, Phone, Email, Website/URL, Rating or Location. Leave Multiple Choice with no answers listed to capture whatever the customer types instead of offering choices.
5. For Multiple Choice, add up to 20 answers; each can have extra accepted spellings (aliases).
6. Optional: write text under If the reply matches nothing to re-ask; leave it empty to wait silently instead.
7. Optional: turn on Save Response As to write the answer to a contact field, a variable, or (multiple choice only) a tag.
8. Optional, under Advanced Settings: turn on Add Timeout Branch and set how long to wait, and Add Message Failure Branch for when the question itself cannot be sent.
9. Save the step, then publish the workflow.

Fields

Question Text

The message sent to the customer.

Question Type

Text, Multiple Choice, Number, Date, Phone, Email, Website/URL, Rating (2–10 stars) or Location.

Limits: A non-multiple-choice type with no options still validates the shape of the reply (e.g. a real number) before accepting it as the answer.

Choices

Up to 20 answers for Multiple Choice, each with an optional list of other accepted spellings (aliases). Typed replies are matched ignoring case, spacing and full-width characters; a number like "2" picks by position.

Limits: Sent as buttons — WhatsApp shows up to 3 as buttons and the rest as a pick-list; Messenger shows them all. An unrecognised reply is re-asked, never guessed by a model.

If the reply matches nothing

Text resent on an unrecognised reply, while attempts remain.

Default: empty — waits silently instead of re-asking

WhatsApp pick-list label

The button label that opens the list, when there are more than 3 choices on WhatsApp.

Default: Select

Limits: Up to 20 characters. Unused on fewer than 4 choices, or on other channels.

Save Response As

Three independent switches: write the answer to a Contact Field, keep it as a Variable for later steps, or (Multiple Choice only) Tag the contact with the option chosen.

Add Timeout Branch

How long to wait for an answer before giving up and moving on.

Default: off in the drawer, but the question still expires — see How it works

Limits: 60 seconds to 7 days; the drawer's own default once turned on is 7 days.

Add Message Failure Branch

A path to run if the question itself cannot be sent (no channel, a closed window, a provider error) — separate from the customer never answering.

Default: off — a send failure leaves the workflow with no arm to follow

How it works

• The step pauses the run: nothing after it in this flow happens until the customer answers, the deadline passes, or the attempt limit is used up on unrecognised replies.
• While it waits, the customer's NEXT reply is claimed as the answer, not treated as an ordinary inbound message: the AI does not answer it, and no Message received-triggered workflow fires on it. It is still an inbound message to every OTHER live workflow that has its own exit rule watching for one — a payment chase with "exit on inbound reply" still exits on it, the same as any other inbound would trigger that exit. Only the workflow that asked the question is exempt from its own exit rule on this reply; a live workflow with no such exit rule configured is unaffected either way.
• Multiple Choice with at least one answer matches deterministically: normalised case, spacing and full-width characters, a bare position number ("2" for the second choice), or any alias you listed — never a model's best guess. An answer that matches nothing is re-asked (if you set retry text) or waited on silently, and does not count against the attempt limit's final failure until attempts run out.
• Leaving Multiple Choice with no answers listed switches the step to free-text capture: whatever the customer sends next is taken as the answer outright, with no matching at all.
• A non-multiple-choice type with no options (Number, Date, Phone, Email, URL, Rating, Location) still checks the reply is a valid one of that shape before accepting it; an invalid reply counts as an unrecognised attempt the same way a Multiple Choice mismatch does.
• The step always has a deadline, whether or not Add Timeout Branch is turned on: with it off, the question still expires after 1 day by default (or sooner still, if the messaging window would otherwise close first) — it simply runs no extra steps when it does, rather than waiting forever. Turning the toggle on and leaving the amount at its default asks for 7 days instead.
• On a windowed channel, a deadline that would land after the messaging window closes is pulled back to end just inside the window instead — a fix for the fairly common case (fixed after a real incident) where the default timeout and the window length were identical, so an unanswered question and a closed window landed in the same instant and the customer heard nothing at all when the run tried to continue with a free-form message.
• If the customer's reply reopens the window before the (pulled-back) deadline, the next unrecognised attempt restores the deadline back toward what you actually authored, capped by the now-later window edge — a stuck questionnaire is not held open longer than it was authored to be, but it is also not left artificially short once the customer is clearly still talking.
• The deadline is checked two ways: the moment the customer's next message arrives (if it is late, that message is not treated as the answer), and by a background sweep that runs roughly once a minute so a question with nobody left to reply still resolves in reasonable time.
• A message that looks like an automated away-reply is ignored rather than treated as an answer or counted as an attempt — the question is left exactly as it was, still waiting for the customer's own reply.
• The recorded answer is exposed to later steps as answer.key (the option chosen), answer.text (what they actually sent) and answer.status (matched / unmatched / unanswered / captured), so a Condition step can branch on any of the three.

When it fails

• The question itself cannot be sent (no channel to send on, the messaging window is closed, a provider error): with Add Message Failure Branch off, the contact simply leaves the workflow — nothing is waiting and nothing runs after it. With it on, that branch's steps run instead.
• An unrecognised reply, with attempts remaining: the retry text (if any) is resent and the step keeps waiting — this is not a final failure, and nothing downstream runs yet.
• Every attempt used up on unrecognised replies: the answer settles as unmatched, and the steps under If the reply matches nothing run (the same arm a single bad reply would have used for its retry text, now run as the terminal outcome) followed by whatever comes after the question in the flow.
• The deadline passes with no reply at all: the answer settles as unanswered, the Add Timeout Branch steps run (empty if the toggle was off), followed by whatever comes after the question.
• An away-message-looking reply arrives: it is ignored — not consumed, not counted as an attempt, not treated as an answer. The question is untouched and still waiting.
• The workflow was deleted, the workspace's plan no longer includes automation, or the merchant stopped the flow AND ticked the "abandon waiting questionnaires" box in the stop dialog: the questionnaire is dropped, a system note says so on the thread, and the customer's reply is handled as an ordinary inbound message — which the AI may now answer. A thread held by a person, or with the AI paused, does NOT drop it: the reply is not taken, a note says the question is still waiting, and the flow resumes once the thread is released. A plain stop, or a stop-and-republish WITHOUT ticking that box, does none of this — see Limits: the question keeps waiting and resumes against the version the customer was actually shown.
• The reason and the outcome are visible in the workflow's Activity tab, under Execution log, on this step's line.

Limits

• The timeout, when set, is clamped between 60 seconds and 7 days; turning the toggle on with no amount changed defaults to 7 days. Leaving the toggle off does not mean an infinite wait — the question still expires after 1 day by default, just with no extra steps attached to that expiry.
• The attempt limit is 1 to 10, defaulting to 3; only unrecognised replies count against it — an ignored away-message reply does not.
• Multiple Choice offers at most 20 answers; each can carry up to 10 aliases.
• It pauses only THIS run, and it claims the customer's next reply for itself: the AI does not answer it, and no fresh Message received flow starts from it. Any OTHER live workflow with its own "exit on inbound" rule still exits on that reply, exactly as it would on any inbound — the asking workflow alone is exempt from its own rule. A live workflow with no such rule is unaffected. A human agent can still act on the thread at any time; automation is what stands down.
• A send failure with no Add Message Failure Branch authored simply drops the contact out of the workflow — there is no default fallback path to fall through to, unlike a mid-flow send whose failure the run just continues past.
• A question's continuation is bound to the exact workflow version the customer was shown, not to whatever the workflow looks like now — editing and republishing the workflow while a question waits means the eventual answer resumes against the OLD version, not the edit.

Best practices

• Always give a question either a way out (a timeout branch) or a reason it cannot go unanswered forever — a silent customer otherwise leaves the run paused for a full day by default before anything else happens on this thread.
• Keep Multiple Choice under about 3 options if the channel matters — WhatsApp only renders up to 3 as tappable buttons before falling back to a pick-list.
• Add aliases for the ways people actually type an answer (numbers, single letters, the local-language word) rather than relying on the button label alone — typed replies are common even when buttons are shown.
• Use free-text capture (no options) only for answers that truly cannot be enumerated — a phone number, a company name — since it accepts the very first reply outright with no validation beyond the question's own type.

Use cases

• Ask which product tier interests the customer, with 3 buttons and aliases for common typed answers, tagging the contact with whichever they pick.
• Ask for an email address (kind: Email) to save into a contact field before continuing to a quote step.
• Ask a satisfaction rating at the end of a flow, with no timeout branch needed since the flow simply ends if nobody answers.

FAQ and troubleshooting

Does the AI keep answering this thread while the question is open?

No. Only this workflow run is technically paused, but the customer's next reply is claimed as the answer to this question — the AI does not answer it, and no fresh Message received flow starts from it. A different live workflow with its own "exit on inbound" rule still exits on that reply, same as it would on any message; a live workflow with no such rule keeps running regardless. A human agent can still act on the thread at any time.

I left Add Timeout Branch off. Does the question wait forever?

No. It still expires — 1 day by default, or sooner if the messaging window would otherwise close first — it just runs no extra steps when it does, since no timeout branch was authored. Use the toggle if you want something to happen on timeout.

What happens if the customer keeps giving answers that don't match any option?

Each unrecognised reply, while attempts remain, resends your retry text and waits again. Once the attempt limit is used up, the answer settles as unmatched and the retry text's arm runs as the final outcome, followed by whatever comes after the question.

Can I branch on whether the customer answered at all?

Yes — a Condition step after this one can read answer.status (matched / unmatched / unanswered / captured) as well as answer.key and answer.text.

Related

• Condition — Split the run into up to twelve lanes plus a None lane, checked top to bottom — the first lane whose conditions all pass wins, and Condition tests one field against one value at a time.
• AI Reply — Hand this one turn to the thread's AI agent — the same generation and confidence gate as an inbound auto-reply — then continue the flow with what it decided.
• Wait — Pause the run for a set duration or until a time of day, optionally held to business hours or to a daily window so a customer is never messaged in the middle of the night.
• Quote / confirm order — Compute a price quote from a fixed, built-in product-and-shipping catalog collected by earlier Ask a Question steps, then optionally record the order and send the customer a receipt.
• Workflows: how a flow runs — A workflow is one trigger, optional conditions and an ordered list of steps; only a published workflow runs, and this article explains how a run starts, forks, pauses, fails and stops.