From Need to Recommendation
Two or three questions about the need, one recommendation, one link to it. Here is how to build the sequence backwards, starting from the recommendations, so it does not fan out into twenty endings, why you ask about your customer instead of your product, and why one recommendation sells better than three options to pick from.
Why “which one is right for me?” is the most expensive question in your inbox
You do not sell one product, you sell three. Or four variants, or S, M and L. And almost every message that comes in boils down to the same question: which one is right for me? On the phone you answer it in ten minutes and you answer it well, because you ask two or three things back and then you know what this is about. In chat you answer it again every day, by hand, in fragments and usually late.
Someone who gets no answer still decides. They just decide on the wrong attribute, usually price, because price is the only thing that can be compared without help. Or no decision gets made at all. The field experiment by Iyengar and Lepper at a tasting stand shows how much choice can paralyse: with six varieties on the table 30 percent of visitors bought something, with 24 varieties only 3 percent did. A later meta-analysis puts that in context, the effect shows up mainly where the decision feels uncertain. Which is exactly when someone needs a recommendation.
And the decision that does get made often comes back. German online shoppers return 11 percent of their orders on average, according to Bitkom Research. In 67 percent of those cases the size was wrong, in 41 percent the product did not match the image or the description. Those are not product faults. They happen much earlier, at the exact point where nobody asked about the need, meaning what the thing was actually going to be used for.
What you do on the phone in ten minutes can be drawn out in advance. Not as text, but as a path: two or three questions with at most three tappable answers each, every answer opening the next step, and at the end one sentence with a name in it plus the link to that exact variant. It happens where your customer is asking anyway. In a Kantar survey of 11,056 adults across 22 markets, 72.4 percent said they are more likely to buy from a brand they can reach by message.
The mistake when building one is almost always the same: thinking forwards. You collect questions, chain them together and then notice that three questions with three answers each produce 27 paths, and there are nowhere near 27 recommendations to put at the end of them. The right way round is backwards. You first write down which recommendations are allowed to exist at all, and that list is the ceiling for everything else. Then you look for the questions that separate exactly those endings. Paths may branch, endings may not: nine of those 27 paths simply run into the same recommendation. And if you need a fourth and a fifth question just to tell two very similar variants apart, you are no longer clarifying a need, you are filtering, and filters belong in your shop. A chatbot sitting on your full catalog is allowed to stay open at that point and answer the questions nobody thought of in advance. A sequence is not. It knows its endings before the first question exists, and every question in it has exactly one job: to narrow the need down until a single ending is left.
How the sequence is built
Entry with a stated length
The trigger is a chat button on the product page, an ad or a keyword from a post. It starts with an approved template that includes an opt-in, because nothing opens the free window except a reply from your contact. So it asks for nothing yet, it only states what is coming: three questions, then a recommendation. That statement is not a courtesy line. Someone who does not know how long the path is assumes an open-ended one halfway through and drops out. Someone who knows the length answers the second question, because only one more follows it.
Write down the endings first, then look for the questions
Before a single node exists, the list of recommendations is fixed: three packages, four variants, S, M and L. Only then do you look for the attributes that decide between exactly those endings, and each attribute turns into a question. Working back to front keeps the tree small, because you never ask a question whose answer moves no switch. Every question you add has to justify itself in the same place: which two endings does it separate? If you cannot answer that, it does not belong in the sequence.
Ask about your customer, not about your product
“What do you need it for” can be answered, “which performance class do you need” cannot. Asking about product attributes demands exactly the knowledge whose absence made your customer write to you in the first place. So you ask about things they know about themselves: the situation they will use it in, how often, for whom, what bothers them about their current setup. One question per message, at most three tappable answers, so the choice fits on a phone screen at a glance. Across the whole sequence it stays at two or three questions, a recommendation needs no more than that.
The question that splits best goes first
The order decides how many questions your customer ends up answering at all. First comes the question that divides the tree most evenly, usually the one about intended use. Questions that only decide between two neighbouring recommendations sit further back, and only in the branch where they are needed. Someone who landed in the first track never sees the question from the second. That is the difference between a tree and a questionnaire: the questionnaire asks everyone everything, the tree asks each person only what their recommendation still leaves open.
Nine paths, three endings
A condition node reads the stored answers and assigns the contact to one recommendation. The work is not in the node, it is in the table behind it: which combination of answers lands on which variant. Two questions with three answers each produce nine combinations, and several of them lead to the same result. That is intended rather than sloppy, because an ending belongs to a variant, not to a path. On top of that you need a rule for conflicts, for the case where two answers point in different directions. Usually right: intended use beats preference, because a product that fits the use comes back less often than one that fitted the preference.
One recommendation, with a reason underneath it
At the end there is a sentence with a name in it, not a table with three columns. Anyone who is handed a choice again after answering three questions is exactly where they started, minus three answers. You already made the choice, that was the point of asking. Underneath the recommendation belongs the reason, and the reason is made of your customer’s own answers: because you use it daily and with two people, this is the one. That makes the recommendation checkable instead of merely asserted, and your customer can object while still in the chat rather than fourteen days later at the returns portal.
The buy button, the doubt exit and the follow-up
Below the recommendation sits one action button, and it leads to that exact variant, not to the overview page. The blueprint puts your product link in that spot, one per ending, and the purchase happens where your checkout already runs. Next to it sits a second, quieter exit for “I am not sure yet”, which leads to a comparison of the two closest variants or to you. Doubt is not a no, and a sequence with no room for it loses precisely the people who are one step from buying. Anyone who does not click runs into a wait and then a message that picks up the most common doubt about that one variant. Because you know which one was recommended, that follow-up is specific instead of generic.
Example scenario: an online shop with three firmness levels
An online shop sells mattresses in three firmness levels and two heights. The product page carries a comparison table and a chat button next to it. Almost every message that arrives through it says the same thing: which one is right for me?
The team answers by hand, with two or three questions back per chat, spread across the day. Someone who writes in the evening gets the first question back the next morning and decides for themselves in the meantime, usually on price. A share of the orders comes back, and the reason given in the return is exactly what the first question back would have asked.
A sequence of three questions now sits in front of the product page: sleeping position, weight range, back pain yes or no. Nine combinations run into three recommendations. At the end there is a sentence with a firmness level in it, the reason is made of the three answers, and below it sits the link to that exact variant. Anyone still unsure gets the comparison of the two closest levels and can object right there in the chat instead of dealing with packing tape later. In the morning the team no longer reads twenty identical questions, only the cases that genuinely fall outside the tree.
What you get
The decision tree as a visual blueprint
The full sequence at a glance: entry, the two or three questions with their answer options, the condition node, the endings and the purchase goal. Every node states the job it does and which information has to arrive there or go out from it. You set the wording, the frame underneath is finished.
The mapping from answer to recommendation
Which combination of answers lands on which variant, written out for every combination that can occur, plus the rule for when two answers point in different directions. This is the thinking that a self-built tree usually gets wrong. It comes as a table you can adjust when a variant is added or dropped from the range.
The question set with order and reasoning
Which attribute each question covers, why it sits where it sits, and how its three answer options need to be cut so they separate your endings instead of just keeping people busy. Plus the questions that appear in a single branch only, because that is the only place where anything is still open.
A buyer persona with over 50 data points
What drives your buyers, what worries them, where they hesitate and the route they take to a decision. From it you read off which attributes your customer knows about themselves and can therefore answer at all. The same material tells you which doubt attaches to which variant, and with that, what the follow-up message has to say.
The starting list for the build
One destination URL per recommendation, the comparison asset for the doubt exit, the tags for each track and the CRM fields for the handover. You know what needs to be on the table before the first click, rather than patching it mid-build.
More funnel blueprints
Price Range Instead of Price List
Three questions settle scope, timing and starting condition. Then a defensible range appears in the chat, instead of a bare number or a dodge.
View blueprintClear Out Objections
Asks at the decision point what is still holding someone back and puts a separate piece of proof behind every answer.
View blueprintAnswer the question properly once, not again every day
You get the decision tree as a blueprint: the endings, the questions between them, the mapping from answer to recommendation, buyer persona and asset list. You write the messages yourself, and the core takes under six hours to rebuild in your messenger tool. One-time payment, no subscription.
Build my funnel blueprintOne-time payment, no subscription. You get the complete strategy and overview first.