Build your agent
Advisor Mode
Advisor Mode turns an agent from a chatbot that answers whatever it's asked into an assistant that behaves like an experienced employee: before it advises, it makes sure it understands the visitor. When one short question would lead to a genuinely better answer, it asks that question first β otherwise it answers immediately. It works for every kind of business, because only the knowledge and the goal change, never the behaviour.
New agents are Advisors by default β they qualify before they answer out of the box. You can switch any agent to the plain standard chat (or back to Advisor) per agent under Agents β your agent β Settings β Advisor Mode.
Facts the visitor states about themselves
When a visitor names a hard constraint about themselves β today their shoe size β the assistant remembers it for the rest of the conversation, not just the message it was typed in. The constraint is restated to the model on every later turn, together with one rule: only recommend what the sources confirm is available in that size, say so plainly when the range is unknown, and never claim that size has no effect on availability, price or fit.
A product card is a buy button, so it gets a second, non-negotiable check. If the retrieved sources show the product's size range and the visitor's size falls outside it, the card is removed before the answer is sent β the visitor still reads about the product, but is not handed an order button for a size that cannot be ordered. The check is deliberately conservative: when the sources say nothing about sizes, the card stays. Suppressing products we merely cannot confirm would be a worse failure than the one this prevents.
The decision the assistant makes before every reply
There are no decision trees to build or maintain. Before each reply the assistant decides, silently, in the same step it uses to write the answer:
- Can I already answer this well from the site's content and what the visitor has told me so far? If yes, it answers immediately. Simple factual questions β opening hours, address, price, returns, contact details β are always answered on the spot, with no follow-up.
- Would exactly one short question make my advice materially better, and would the answer actually change what I recommend? If yes, it asks that one question and nothing else.
If the missing information isn't in the site's own content, the assistant never interrogates the visitor to cover for it β it answers honestly with what it has, or offers the next step. (That gap is also surfaced to you through Content gaps so you can add the missing content.)
Guardrails, so it never feels like an interrogation
- At most one question per reply β never two at once. This is enforced on the server, not merely requested in the prompt: if the model ever adds a second question β whether as a separate sentence or a second ask joined into the same sentence (“… and what are your goals?”) β it is trimmed before the visitor sees it, so a smaller model can't turn the conversation into a checklist.
- Every question has to earn its place: it is only asked when the answer would actually change the recommendation. That makes the flow adaptive rather than a fixed script β sometimes one question is enough, often two, occasionally three or four when the extra answer genuinely flips the pick. It never runs past four.
- It never re-asks something the visitor already answered.
- Factual questions bypass the funnel entirely.
Confident enough to recommend?
The assistant stops asking when it is confident, not when a counter runs out. Before naming a specific product it checks: "could any unanswered question change which item I'd pick?" To answer that, it looks at what actually separates the candidates β warmth vs. breathability, season, indoor vs. outdoor, intensity of use, capacity, duration, budget. If the visitor has never been asked about the dimension that most separates them, that becomes the next question.
This is what stops a premature pick. Knowing someone wants socks for work in size 43 is not enough to recommend thermal socks β warmth versus breathability was never established, and that single answer changes the whole recommendation. While it narrows, it keeps giving value rather than stalling: it names the category it is steering toward and asks the one differentiating question ("For work and everyday in size 43 I'd look at our allround socks β do you mainly need warmth for cold days, or breathability?"), and only commits to one specific product once no remaining answer would change it.
It also persists before it defers. If it can't answer something straight from its knowledge β "how about the size chart?" β it doesn't lead with "that isn't available, contact support". It first offers the move that solves the problem ("Which product are you looking at? I can point you to its size chart or product page") and only suggests contacting support as a genuine last resort. An experienced employee keeps trying to help before handing the visitor off.
Making the recommendation
Crucially, the recommendation follows qualification β it never precedes it. On a broad opener like “I’m looking for socks” the assistant does not dump a wall of product cards; it asks its single most valuable question first (“What will you mainly use them for?” with tappable chips like Work / Hiking / Sports / Everyday) and only shows products once it knows enough to tailor the pick. Showing the catalogue up front feels like a search box; asking first feels like an experienced salesperson.
Once it has enough to advise, the assistant is told to sound like an experienced advisor rather than a menu. Instead of naming a plan or product flatly, it:
- Leads with one clear pick β the single best fit β not a list of equal options.
- Explains why that pick fits what the visitor just told it (their size, traffic, use case, or budget). The reasoning is what makes it feel like a person who knows the catalogue, not a search box.
- Names one or two alternatives and the upgrade path, so the trade-off is visible and the visitor can grow into a larger option later.
- Quotes every figure exactly β price, plan name, quota β as the sources give it (“3,000”, never “3”).
A typical shape: “Based on your estimated 1,000–5,000 monthly visitors, I’d recommend the Growth plan. It includes 3,000 AI conversations per month, which comfortably covers a shop your size. If your traffic grows later, you can move up to the next plan.”
The Primary Goal
A business has several objectives overall, but the assistant should have one priority per conversation. The Primary Goal is that priority β what the assistant steers toward when a conversation could go several ways. Your visitor's explicit request always comes first; the goal only decides the direction when the visitor hasn't shown one.
Each goal steers toward an outcome the widget already delivers, so Advisor Mode adds no new visitor-facing UI:
- Inform visitors β a clear, complete answer with links to the most relevant pages.
- Generate qualified leads β an invitation to leave contact details, enriched by what the visitor shared.
- Recommend products β specific product cards that fit the visitor's needs.
- Book appointments β help booking a call or appointment.
- Support customers β resolving the issue, or handing off to a human when it can't be resolved.
An optional Extra guidance field lets you describe the goal in your own words (for example, "Our priority is helping visitors choose the right storage unit; if they're interested, guide them toward a reservation."). It's fed to the assistant, never shown to visitors.
Contextual quick replies
The tappable chips under a reply follow the conversation. While the assistant is qualifying, the chips are likely answers to the question it just asked β after "What kind of business do you run?" the visitor sees "A webshop", "A service business", "Something else" and can tap instead of typing. Once the assistant recommends, the chips become the natural next actions toward the agent's goal β "Book a call", "Talk to a human", or a relevant next step.
Every chip is written in the visitor's voice β the words a visitor would tap to reply β never a question the assistant asks back. Small models still slip one in occasionally ("Do you have a colour in mind?"), so the server keeps a hard backstop: in Advisor Mode any chip that reads as a question (ends in "?" or opens like one, in English or Dutch) is dropped before it reaches the widget, so a visitor never sees a question to "answer" back at the assistant. And when dropping them leaves the row too short β which happens most while qualifying, where the small model keeps writing questions β the server generates the answer buttons from the assistant's own reply with one small model call, so the visitor always gets tappable answers ("Voor werk", "Voor sport", "Dagelijks") instead of nothing. That generation runs only when the model's own chips fall short, and after the answer has already streamed, so it never delays the reply.
This needs no setup: the assistant chooses the chips per reply based on what it just did, and tapping one simply sends it as the visitor's next message.
Smooth handoffs to forms
When the assistant reaches a point where it needs structured details β the visitor's name, email, phone β and the visitor has agreed to share them, it does not ask for those fields in the chat. Instead it says a short line ("Perfect β pop your details in the form below and we'll be in touch.") and opens the lead form right there. Confirming interest is not new information, so re-typing the fields as a question would be an unnecessary extra step; handing over to the form the moment the visitor is ready feels like talking to an experienced employee. Booking a call works the same way β the book-a-call card opens instead of collecting a date and time in chat.
The same handoff covers a visitor who simply wants to reach you β "contact us", "get in touch", "take me to the contact form". The assistant opens the contact form directly rather than sending them off, and it will never hand out a page URL as "the contact page": if it doesn't have a real, unambiguous contact page in its knowledge, it opens the form instead of guessing a link (linking the wrong page β say, terms & conditions β is worse than opening the form).
Qualification capture
While the assistant qualifies a visitor, it is learning things worth keeping: what kind of business they run, what they're trying to achieve, which objection is holding them back. Advisor Mode records those question-and-answer pairs so they can inform reporting and follow-up. This is the one part of the conversation that cannot be reconstructed after the fact, so it is captured from the first day the mode is on.
- Each Advisor conversation gets one session β a record of the goal it pursued and, when the conversation converts, the outcome it led to. A submitted lead, a booked call, or a clicked call-to-action is stamped back onto the session automatically, so you can see which qualified conversations actually drove results β the attribution link between "what the assistant asked" and "what the visitor did". The strongest outcome wins: a booking is never overwritten by a later, lighter click.
- Each qualifying question the assistant asks, and the answer the visitor gives on the next turn, is stored as one turn.
Capture happens after the reply is sent to the visitor, so it adds nothing to how fast the chat feels. Every workspace's data is its own β isolated by the same tenant boundary as the rest of your content β and used for that workspace's own reporting and attribution.
Review it under Analytics β Advisor
(/app/analytics/advisor): every qualified session, the
questions the assistant asked and the visitor's answers, the outcome each
session drove, and summary stats β qualified sessions, conversion rate,
and leads / bookings / CTA clicks β filterable by agent, outcome and time
window.