Introduction
The heart of the AI product concierge is its dialog with the customer. If this part is sloppy, no matter how smart the recommendation engine underneath, you end up with "an AI that makes off-target suggestions."
In this article I explain, for the concierge AI on an EC site selling motorcycle gear, how we designed a question flow that never misses what matters and how we managed conversation state. A free-form conversation that still reliably gathers the necessary information — striking that balance was the crux of the design.
Deciding what to ask
Defining the interview fields
First we listed out the items we'd want to know at minimum to make a good recommendation. It's a way of putting into words what a veteran salesperson confirms at the start of a conversation.
We split these into required fields and nice-to-have fields, and let the AI move on to recommendations once the required ones are filled. The trick is not forcing every field to be completed.
The judgment not to over-ask
The hardest part of interview design was where to draw the line on how much to ask. More information raises recommendation accuracy, but every added question makes the customer feel it's a hassle and leave.
A barrage of questions drives people away
Even in a store, being peppered with questions feels uncomfortable. Online, the bar to walking away is even lower. We built "the courage to wrap up with the minimum" into the design.
So once the required fields are in, the AI decides to move to the recommendation phase, and the remaining information is filled in gently through the post-recommendation conversation.
Managing conversation state
Tracking completeness with state
The hard part of an interactive interview is not losing track of "how far we've gotten." An LLM can re-read prior statements each time, but relying on that alone leads to asking the same thing twice or missing something.
So we gave the interview-field completeness an explicit state. Each turn, we update the state with the information read from the answer and make the still-empty fields candidates for the next question.
The API design that updates state
The dialog is controlled by several APIs with divided roles. By reading and writing state on each turn of the conversation, we advance the interview reliably, not at the mercy of the LLM's whims.
Initializes the session and returns an empty state and the first question
Receives the user's utterance, updates completeness via update-state, and generates the next question
Reflects the use case, preference, budget, etc. extracted from the utterance into state
Once required fields are met, moves to generation, converting state into search conditions
Keeping state as a separate concern means the code side always knows "what has been asked and what remains." It also made debugging and improvement easier.
Bracing for extraction wobble
Because customers speak freely, vague expressions like "I'm going on a trip this weekend" also come in. We let the LLM interpret this and convert it to the use case "touring," but naturally there's wobble.
As a countermeasure, we gave extraction results a notion of confidence and avoided committing state while things are ambiguous. When unsure, the AI inserts a confirmation — "So this is for long-distance touring, correct?" — preventing a recommendation from proceeding on a mistaken premise.
Polishing the dialog experience
Not making it Q&A ping-pong
Returning questions mechanically one by one feels no different from filling out a form, and it's dry. So we had the AI add a little empathy or supplement to the customer's utterance before moving to the next question.
Just repeating "What's your budget?"
"For long-distance touring, comfort really matters. Do you have a rough budget in mind?"
Just one small line creates the feeling of "I'm being listened to." This is the LLM's strong suit, so we leaned into it.
Being resilient to mid-way drop-off
Even if a customer drops off mid-dialog, we keep state tied to the session so they can resume from where they left off next time. Just not making them start over changes the experience dramatically. It's a plain but effective touch — not wasting what we've already heard.
Conclusion
In designing the interview dialog, I focused on three things.
- Clarifying the fields — separate required from optional and define what should be asked
- State management — hold completeness explicitly to prevent misses and duplicate questions
- Service-likeness — don't over-ask, add empathy, and stay resilient to drop-off
Next, how do we turn these gathered requirements into recommendations? The knowledge base and RAG mechanism for grounded recommendations is covered in "Product Master × RAG for Grounded Recommendations," and the full system picture in "AI Product Concierge — Interactive Diagnosis & Recommendations."