User Intent Disambiguation Between Similar Options Prompt Template

This prompt is designed for support and commerce assistants that must distinguish between two or more closely related user intents. Instead of re-listing every possible option and forcing the user to re-read a menu, this prompt generates a differential clarification. It identifies the single distinguishing factor between the top candidate intents and asks a targeted question about that factor. Use this when your intent classifier returns multiple high-confidence matches, when the cost of acting on the wrong intent is high (e.g., initiating a return vs. an exchange, or canceling a subscription vs. pausing it), or when you need to reduce decision fatigue in customer-facing chat.

The ideal workflow places this prompt after an intent classification step that produces a ranked list of candidate intents with confidence scores. You should only invoke it when the top two or three candidates are within a configurable confidence threshold (e.g., within 10% of each other) and the cost of a wrong action is non-trivial. The prompt requires the candidate intent labels, their brief descriptions, and the user's original message as inputs. It does not require the full conversation history, but including the last assistant turn can help avoid repeating information the user has already seen.

Do not use this prompt when the user's request is unambiguous, when there are more than three viable candidate intents (at which point a broader menu or triage flow is more appropriate), or when the distinguishing factor requires domain knowledge the user is unlikely to possess. For example, asking a customer to distinguish between ACH return code R01 and R02 is a failure mode—the clarification must be framed in terms the user can answer. Similarly, avoid this prompt in high-urgency scenarios where the delay of a clarification turn is worse than making a safe default assumption with a disclosure. In those cases, pair the assumption with an opt-out mechanism rather than blocking on user input.

This prompt template is designed for support and commerce assistants that must distinguish between two or more very similar user intents. Instead of re-listing all possible options and forcing the user to read a menu, this prompt instructs the model to identify the single most critical distinguishing factor and ask a targeted question about it. This reduces decision fatigue and keeps the conversation moving forward efficiently.

codeCopy
SYSTEM:
You are an intent disambiguation assistant. Your goal is to resolve ambiguity between closely related user intents with a single, precise question. Do not re-list all options. Instead, identify the one distinguishing factor that separates the top candidate intents and ask a question that directly targets that factor. Frame the question to be easily answered with a short phrase or a single selection.

USER INTENT CANDIDATES:
[CANDIDATE_INTENTS]

USER MESSAGE:
[USER_INPUT]

CONVERSATION HISTORY:
[CONVERSATION_HISTORY]

INSTRUCTIONS:
1. Analyze the user's message and conversation history against the provided intent candidates.
2. Identify the top two most likely intents that are easily confused.
3. Determine the single most important piece of information that would differentiate them.
4. Generate a concise clarification question that asks for that specific piece of information. Do not ask an open-ended "How can I help?" question.
5. If the user's intent is already clear and unambiguous, output "INTENT_CLEAR: [Intent Name]".
6. If the user's message is unrelated to all candidates, output "UNRELATED".

OUTPUT FORMAT:
If clarification is needed, output ONLY a JSON object with the following keys:
- "clarification_question": The single question to ask the user.
- "target_differentiator": A brief label for the distinguishing factor (e.g., "order_type", "account_access_level").
- "candidate_intents": An array of the two intent names being disambiguated.

If the intent is clear, output ONLY: "INTENT_CLEAR: [Intent Name]"
If the message is unrelated, output ONLY: "UNRELATED"

CONSTRAINTS:
- Do not output any text outside the specified JSON format or the clear/unrelated signals.
- Do not suggest actions or provide solutions. Only ask the clarifying question.
- The question must be answerable in a few words.

To adapt this template, replace the placeholders with your application's specific data. [CANDIDATE_INTENTS] should be a structured list of your system's possible intents, each with a name and a brief description. [USER_INPUT] is the latest message from the user, and [CONVERSATION_HISTORY] is the formatted history of the current session. The output format is designed for a programmatic harness: parse the JSON to extract the question and display it to the user, or route the INTENT_CLEAR and UNRELATED signals to the appropriate downstream logic. Before deploying, test this prompt with a golden dataset of ambiguous and unambiguous inputs to ensure the model correctly identifies the differentiating factor and does not default to a generic, unhelpful question.

This prompt is designed to be called as a mid-dialogue intervention, not a standalone classifier. It should be triggered when your primary intent classifier returns two or more candidate intents with confidence scores within a configurable ambiguity threshold (e.g., top two scores within 0.15 of each other). The prompt expects a structured input containing the user's original utterance, the list of ambiguous candidate intents with their descriptions, and the conversation history for context. The output is a single clarification question that highlights the distinguishing factor between the top candidates, avoiding a re-listing of all options. This keeps the user experience focused and reduces decision fatigue.

To wire this into an application, implement a pre-call validation layer that checks the input schema before sending the request. The [AMBIGUOUS_INTENTS] array must contain at least two intents, each with an intent_name and description field. The [CONVERSATION_HISTORY] should be a serialized list of prior user and assistant turns. On the output side, parse the model's response against a strict schema: {"clarification_question": string, "distinguishing_factor": string, "options": [{"label": string, "maps_to_intent": string}]}. If the output fails schema validation, implement a single retry with the validation error message appended to the prompt as a correction instruction. If the retry also fails, fall back to a static clarification template that lists the top two intent names and asks the user to choose, ensuring the conversation never dead-ends. Log every disambiguation event—including the ambiguous intents, the generated question, and the user's eventual choice—to a structured logging system for later eval and prompt refinement.

For model choice, a fast, cost-effective model (like GPT-4o-mini or Claude Haiku) is usually sufficient, as this is a low-latency, structured generation task. Avoid using this prompt for intents that differ by a critical safety or permission boundary; in those cases, route to a dedicated safety classifier first. Never expose the raw maps_to_intent field to the user, as it leaks internal system logic. The user should only see the label text. Finally, build an eval harness that measures two key metrics: option framing bias (whether the clarification question subtly favors one option) and resolution rate (the percentage of disambiguation turns that result in a clear user selection without a follow-up clarification). Run this eval suite against a golden dataset of known ambiguous utterance pairs before any prompt update is deployed.