%202.png)
Most guides to branching and skip logic assume a web form: pages, a progress bar, a back button. None of that exists in a WhatsApp or SMS conversation, where questions arrive one at a time and every jump has to feel like part of the same conversation. This guide defines skip logic, branching logic and display logic on their own terms, walks through an eight-step process for building them into a chat survey, and covers the mistakes that break conversational flows before they ship.
A chat survey has no pages, no progress bar and no back button. That is not a limitation to design around. It is the reason a conversational survey can route respondents more precisely than a web form ever could, provided the logic behind the scenes respects how a real conversation actually moves.
Quick answer: skip logic jumps a respondent forward past irrelevant questions based on an earlier answer. Branching logic is the broader design, built from skip logic and display logic, that sends different respondents down entirely different question paths. In a chat survey, every jump needs a short conversational transition, because there is no page turn or progress bar to hide it. Keep branches shallow, two to three questions deep, test on the real channel, and reach for AI-adaptive probing only when a fixed rule genuinely cannot cover a free-text answer.
What is skip logic?
Skip logic, sometimes called question routing or conditional branching, is the simplest form of survey logic: if a respondent answers X, jump them to question Y and skip everything in between. It is always linear. Respondents move forward only, like a highway with off-ramps where everyone travels the same road but some bypass certain exits.
In a chat survey, asking "Have you used our app in the last 30 days?" and getting a "No" might jump a respondent past five feature questions straight to a general satisfaction question. Skip logic is the right tool whenever a survey is mostly linear, with a handful of questions that only apply to certain groups.
What is branching logic?
Branching logic is the broader concept. Where skip logic creates a simple bypass, branching logic creates entirely different paths through a survey, more like a tree with one trunk splitting into branches that may split again or reconverge at the end. Branching logic uses skip logic and display logic as its tools; it is the architecture that results, not a mechanism in its own right.
A common example: after a satisfaction question scored 0 to 10, promoters (9 to 10) get routed to a referral request, passives (7 to 8) get a feature improvement question, and detractors (0 to 6) get an open-ended "what went wrong?" probe. Three different conversation paths from a single starting question.
What is display logic?
Display logic controls whether a specific question appears at all, without changing the overall flow. Based on a condition, a question is shown or hidden in place, and the respondent never knows it existed. In a web form this is useful for inserting conditional follow-ups without rearranging question order. In a chat survey, display logic is harder to tell apart from skip logic, since every question is delivered sequentially anyway: hiding a question simply means the conversation moves on to the next visible one.
How the three work together
Skip logic and display logic are mechanisms. Branching logic is the outcome you get when you combine them. One way to picture it: skip logic tells someone to turn left instead of right at an intersection, display logic decides whether they even see that road, and branching logic gives them an entirely different map.
For researchers designing quantitative research studies, skip logic alone often covers the routing needs. Branching becomes worth the added complexity once a study is segmenting respondents into groups that genuinely need different question sets, not just a shorter path through the same one.
Why chat surveys handle logic differently
Most existing guides explain skip logic for page-based web forms and stop there. A conversational survey delivers questions one at a time inside a real chat thread, adapting dynamically based on previous responses, and that changes what good logic design actually requires.
No pages or sections
Traditional skip logic often works at the page level. Chat surveys have no pages, so every skip is question to question. This is more granular, which simplifies design but means every single transition needs its own thought.
No back button, and that is an advantage
Allowing backward jumps risks logic loops where answers conflict with an earlier path. Chat surveys solve this by design: there is no back button in a WhatsApp conversation, so respondents move forward only, eliminating an entire category of logic bugs.
No progress bar to confuse
In a web form, a static progress bar can mislead a respondent on a short branch into thinking they have far more left than they do. Chat surveys avoid this entirely: there is no visible progress indicator, so a skipped question is simply invisible, and every respondent experiences a conversation of an appropriate length.
Sequential flow demands natural transitions
A skip that jumps from question three to question twelve might go unnoticed on a fresh web page. In chat, an abrupt topic change feels like a conversation partner suddenly switching subjects. The message after a skip needs to acknowledge what the respondent just said before moving on, which is what keeps a chat survey feeling human rather than automated.
Limited question types shape the conditions
Chat interfaces do not support matrix grids or drag-and-drop ranking, so logic conditions typically rely on multiple-choice selections, rating scales or keyword-detected text. Quick-reply buttons produce structured responses that map neatly to logic rules; free text is far harder to route with a static rule.
Answer piping is expected, not optional
Weaving something a respondent already said into the next question is a nice-to-have in a web form. In a chat survey it is expected: if someone gives their name and the next message opens with a generic greeting, the conversational illusion breaks immediately.
How to set up branching and skip logic in a chat survey
Define the outcome before writing questions
Start with the decision the survey will inform, not the questions to ask. This focus determines which branches are actually needed and heads off the most common mistake: engineering logic for questions that should not be in the survey at all.
Map the logic on paper first
Draw the flow before building it, whether it uses skip logic, branching, or both. If the survey's flow cannot be sketched on a whiteboard, it is probably too complex for a chat format.
Place screening questions early
Because a chat survey cannot skip whole pages, a qualifying question needs to sit right at the start. If someone does not qualify, route them to a polite close immediately rather than sending questions that will only produce unusable data.
Keep branches shallow
Aim for two to three follow-ups per branch and no more than three or four choices at any decision point. Deep branching creates confusion for respondents and makes analysis significantly harder; it is always possible to expand later based on real response patterns.
Write conversational transitions
For every skip or branch point, write a short message that bridges the topic change naturally rather than jumping silently. A shipping question followed by an abrupt product-quality question feels like a glitch; the same jump with "Thanks for that, switching gears a bit, I'd love to hear about the product itself" feels like a conversation.
Use quick-reply buttons for logic triggers
Buttons produce clean, structured responses that make logic conditions reliable. Free text introduces ambiguity, a "yeah" or a "sure" instead of a clean yes, so use buttons for any question that actually triggers a rule.
Test every path on the real channel
Every branching path needs testing before launch, and critically, on the actual channel rather than only inside the survey builder. Timing, message length, button rendering and conversational flow all behave differently on a phone screen than in a desktop preview.
Soft launch before full distribution
Share with a small subset first, roughly 50 to 100 respondents, and watch closely for technical issues, confusion points and drop-off patterns. Some branching errors that looked fine in testing only surface at scale, once unexpected answer combinations appear. Survey templates are a reasonable starting point to build logic on top of rather than starting from a blank canvas.
Common mistakes
- 01Circular logic. A rule accidentally sends a respondent backward to a question they have already answered, creating a loop. In chat this is worse than in a web form, since the bot keeps repeating the same questions and the respondent has no way out except leaving the conversation. Fix it by ensuring every rule points forward and tracing every path after any structural edit.
- 02Conflicting logic on multi-select questions. If a respondent selects two answers that each route somewhere different, most platforms default to the first applicable rule, which can produce unexpected routing. Avoid skip logic on multi-select questions where possible, or define a clear priority order for conflicting conditions.
- 03Orphaned questions. A question no logic path can reach, usually left behind after a question is deleted or conditions become mutually exclusive. After any structural change, verify that every question is reachable through at least one path.
- 04Over-engineering. The biggest mistake is not choosing the wrong type of logic; it is using branching where skip logic would suffice. Fifteen branching paths that could have been three skip conditions are a nightmare to maintain and analyse, and in chat, every unnecessary branch means more transitions to write and more fragmented data.
- 05Priming bias from qualifier wording. The question that routes respondents into a branch also primes them. Asking "Have you experienced any issues with checkout?" puts someone in a different mental frame than "How would you describe your shopping experience today?", even though both produce a branch. Choose qualifier wording carefully, since the conversational intimacy of chat can make priming effects stronger.
Use cases for branching logic in chat surveys
- NPS and CSAT follow-ups. Route promoters to a referral request, passives to a feature improvement question, and detractors to an open-ended probe about what went wrong.
- Respondent screening and disqualification. A simple qualifying question with skip logic routes ineligible respondents to an early, polite close, saving their time and keeping the data clean.
- Product feedback segmentation. Different tiers get different questions, upgrade barriers for free users, feature satisfaction for paid users, support and integration for enterprise users, which is especially clean in chat where quick-reply buttons present tier options directly.
- Multi-language routing. An early preference question routes respondents to the correct language version automatically, which matters in markets where the audience speaks several languages.
- Diary studies and longitudinal research. Across a multi-day diary study, branching can adapt a later prompt based on what a participant reported earlier, using the ongoing conversation for natural continuity that a fresh survey link never has.
When static branching is not enough: AI-adaptive probing
Static branching rules can only route on structured answer choices, whichever button a respondent tapped or rating they selected. When someone types a free-text answer, static logic cannot meaningfully react to what they actually said. This is where AI-adaptive probing comes in: an AI-moderated interview decides what to ask next based on the substance of a response, not just which option was selected, so a signal of frustration can be probed for cause and context rather than routed down a fixed path.
Research comparing conversational survey formats with adaptive probes against traditional static surveys has found the conversational approach yields richer, more detailed responses, consistent with what practitioners report anecdotally: that a conversational format lowers the barrier to sharing honest, nuanced feedback. AI-adaptive probing does not replace study design; researchers still need to set the discussion guide and interpret the results, but it closes a gap static branching structurally cannot reach.
Data analysis considerations for branched chat surveys
Branching creates unequal sample sizes across paths. If most respondents follow one branch and a small share follow another, comparing the two groups directly requires care.
- Tag every response with the branch path it came from during export; this is essential for meaningful analysis later.
- Expect smaller sample sizes in sub-branches. Branching improves completion by cutting irrelevant questions, but it fragments the data, so plan sample size with a sample size calculator per branch rather than for the study as a whole.
- Design branches that reconverge on shared closing questions where possible, giving every respondent a common data set for overall metrics alongside the branch-specific detail.
Key numbers to know
Branching logic typically cuts survey length by 20 to 40% for most respondents while improving completion by eliminating irrelevant questions. The channel choice compounds that advantage: WhatsApp-native surveys average around 35% response on Yazi's own platform, against a 15 to 25% range for email and roughly 6% for phone, with drop-out on well-designed chat surveys typically under 3%. Shorter, more relevant surveys on a channel people already use produce better data on both counts.
The practical rule
Use the simplest logic that gets the job done. Skip logic covers most surveys on its own. Reach for branching only when respondents genuinely need different question sets, not just a shorter path through the same one. And in chat specifically, treat every jump as a conversational moment, not just a routing rule: acknowledge what was said, keep branches shallow, and test on the channel respondents will actually use.
Good logic is invisible to the respondent. They should simply feel like they were asked exactly what was relevant to them, in an order that made sense, without ever noticing the questions they were spared.
Frequently asked questions
What is the difference between skip logic and branching logic?
Skip logic is a mechanism that jumps a respondent forward past irrelevant questions based on an earlier answer. Branching logic is the broader design approach that uses skip logic, and display logic, to create multiple distinct paths through a survey. Skip logic is one tool; branching is the blueprint built from it.
Can I use skip logic on open-ended questions in chat?
Not effectively with static rules. Open-ended text does not map cleanly to predefined routing conditions. Keyword detection is fragile, so for structured logic triggers in chat, quick-reply buttons are far more dependable, and AI-adaptive probing is the more reliable option when a free-text answer genuinely needs to drive the next question.
How many branches should a chat survey have?
Keep it to three or four major branches at most, with no more than two to three follow-up questions per branch. Chat surveys thrive on brevity and natural flow, and every additional branch adds complexity to testing, transitions and analysis.
How do I prevent circular logic in a chat survey?
Make sure every logic rule points forward to a question the respondent has not already answered. Chat surveys have a built-in advantage here, since there is no back button, but a misconfigured rule can still point to an earlier question and create a loop, so trace every path from start to finish before launch.
Should I test chat survey logic differently than web survey logic?
Yes. Testing inside the survey builder is necessary but not sufficient. Logic has to be tested on the actual messaging channel, because message timing, button rendering, character limits and conversational flow all behave differently on a phone than in a desktop builder.
When should I use AI-adaptive logic instead of static branching?
Reach for it when a survey includes open-ended questions where the follow-up genuinely needs to depend on what the respondent said, not just which option they tapped, or when the study needs interview-like depth without the time and cost of a human moderator on every conversation.
How do I handle data analysis when respondents take different paths?
Tag every response with its branch path during export, account for unequal sample sizes across branches, and where possible design shared closing questions that every branch reconverges on, so there is still a common data set for top-line metrics.
What question types work best for logic conditions in chat surveys?
Multiple choice with quick-reply buttons, single-select rating scales and yes or no questions. These produce clean, structured responses that map reliably to logic rules. Avoid using multi-select questions as logic triggers unless a clear priority order is defined for conflicting selections.
Skip logic, branching and AI-adaptive follow-ups, native to a WhatsApp conversation.
See how Yazi handles question routing, conversational transitions and adaptive probing without a single dropped thread.
Book a Demo →
