Guide
The conversation — follow-ups, branches, and the check at the end
Your questions are the skeleton. What a respondent actually gets asked depends on what they say, and four things shape it: follow-ups, branches, whether a question is required, and the check at the end.
Follow-ups on a vague answer
After each answer Acquainto reads it against the question and everything already said, and asks one clarifying question if the answer is too vague to be useful, or contradicts something earlier.
A follow-up may only narrow the question that was already asked. It reuses that question’s own wording and the respondent’s own words. It may not introduce a category, an example, or a sub-topic your question did not already name — if it cannot narrow without inventing something, it accepts the answer instead. An intake that asks for things nobody configured is worse than one that takes a vague answer.
One per question. If a question has already been clarified once and the reply still reads as vague, the answer stands. A question that needs a third phrasing is usually a question that needs rewriting.
A follow-up does not add a question. It lands as more detail on the same question, and the field it arrives under in your data is the same one. A “Follow-up” note marks it in the conversation, so the respondent knows why they’re seeing the same question again.
The exception: a question that asks for something specific
Six of the question types ask for an answer in a particular shape: email address, phone number, date, money amount, number and web address. Respondents answer them by typing, exactly as they would an open question — there is no special box and no picker. What changes is what happens to the answer.
The check is a plain format check rather than a judgment, so it is instant and
costs nothing. It is also more forgiving than it looks: “sure, it’s
ana@example.com” is a valid answer to an email question, and a budget question
takes 1500 as readily as $1,500.
Then the answer is tidied into one shape before it reaches you. 3 March 2026
and 3/3/26 both arrive as 2026-03-03. $1,500.50 arrives as the number
1500.5, with the currency alongside it, so a column of them adds up.
acme.com arrives as https://acme.com.
Two things it will not do:
- It will not invent a country code. A phone number typed without one arrives as the digits the respondent entered, marked as not confirmed dialable, rather than as a number we guessed at.
- It will not guess an ambiguous date.
3/4/2026means two different days depending on where the respondent lives, so it asks which one they meant.
On a required question, an answer it cannot read is asked for again — every time, with no limit. On an optional question, it is accepted as written: somebody answering “Your email, if you’d like updates” with “I’d rather not” has answered, and asking again would be badgering them for something you said was optional.
What a choice option stores
You type the wording respondents read. We store a value alongside it, derived
from that wording in lowercase — “Blocking my work” is stored as blocking my work. That stored value is what your webhook, API and exports carry, and what
a branch matches on.
The wording is translated for a respondent reading in another language. The stored value never is — it is the same key in every language, so a branch and everything you have built downstream behave identically whoever answers.
It is fixed the moment the option is created. Rewording the option later changes what respondents read and not what you receive, on purpose: a branch, and whatever you have already built downstream, are both keyed to the stored value, and silently moving it under them is the kind of break that shows up as a branch that quietly stops firing rather than as an error.
If your own system needs a particular key — a CRM that expects P1, a pipeline
keyed on codes you do not control — tick Set my own stored value for each
option on the question. Every option then needs a value, and they have to be
different from each other.
After a tap, respondents read your wording exactly
Most questions are reworded slightly as they are asked, so each one refers back to what the respondent just said and the intake reads as a conversation rather than a list. A question that follows a tapped option is not. The respondent gets your wording, character for character, and the same is true after a skipped question.
There is nothing to gain from rewording there — the only thing available to refer back to is the label they just tapped, which is still on their screen — and dropping it takes seconds off those turns. The practical consequence for you: on an eflow that is mostly options, what you type in the question box is what respondents read. Write it to stand on its own.
If the respondent is reading in another language, “your wording exactly” means a translation of your wording — the same question, in their language, rather than a reworded one. We translate an eflow’s questions and option labels once per language, keep the result, and reuse it for everyone after that. Edit a question and only that question is translated again.
Branches
Branches come off a single-select question, and only after you tick Allow branching from this question’s answer on it. Each option then gets an Add branch for ”…” control: a branch is a set of questions asked only of respondents who chose that option. Branches can nest.
No other question type can open a branch — not multi-select, not a rating scale, and not any of the typed or open text questions.
Someone who did not take a branch never sees its questions, and never sees a gap where they would have been.
This matters for your data: a branch question’s field is absent from the responses of everyone who went the other way. That is normal, not an error. The Response fields table on the Integrations tab marks each of these with the path that reaches it — Only asked after: ….
Required, and skipping
Each question has a Required checkbox in the editor.
- Optional — the respondent gets a Skip question control in the footer,
beside the privacy link. Skipping is recorded as a real answer of “skipped” rather than as
missing data, and the field arrives in your integrations with a
nullvalue. Optional questions are marked Optional in the editor list. - Required — there is no skip control, and the conversation cannot finish until the question is answered. This is enforced in the conversation itself, not just hidden in the interface: a required question that somehow arrives skipped is asked again, and the skip is refused. If you are using a question as a consent or eligibility gate, required means required.
The check before it sends
Every conversation ends with a review screen, headed Quick check before it goes. It lists every answer with a Change control beside each one, and the line under it says: Change anything that looks wrong — sent to [your organization] only when you confirm.
The conversation itself collapses behind a Show conversation link at the top of it, so the list starts at the top of the card and the send button is in view without scrolling. Nothing is hidden — one press puts the whole transcript back.
Five things about it are worth knowing:
- It is always there. There is no setting to switch it off, on any plan or any channel. It is the one moment in every conversation where the respondent is shown, rather than told, what is about to be sent and to whom.
- Nothing reaches you until they press it. Looks right, send it is what completes the conversation and what fires your integrations. The line under the button says what the button cannot be undone by: Answers can’t be changed after you send them.
- An answer they change here is marked as changed. One the respondent edited on this card reads Edited, and it comes through to you the same way as any other, with the change recorded.
- Change gives back the control the question was asked with. A rating comes back as the rating row, end labels and all, with the number they chose already on it; a choice question comes back as its options, with the earlier pick ticked. Nobody has to remember what 6 meant on a scale they can no longer see, and a multi-select stays a multi-select instead of becoming a text box. Only typed answers get a text box. Tapping here moves the selection and nothing more — the change is saved when they press Save, and Cancel puts the original answer back.
Using Acquainto already? The same guides are in the product under Help & support, with the ones that only make sense signed in.



