Product Area Mapping Prompt for Incoming Requests

This prompt is designed for the ingress layer of a multi-product AI platform. Its job is to map an unstructured user request—such as a bug report, feature ask, support inquiry, or general question—to a single, defined product area from your stable taxonomy. The output is a structured classification that downstream systems use to dispatch tools, load product-specific context, and route work to the correct team. Use this prompt when misclassification carries a real cost: the wrong retrieval index gets queried, an irrelevant tool fires, or a critical issue lands in a low-priority queue.

Before deploying this prompt, you must have a documented, version-controlled product area taxonomy. The taxonomy should be mutually exclusive enough that a single input can be assigned a primary product area, even if secondary areas are noted. This prompt works best when your products have clear functional boundaries. If your platform has highly overlapping product surfaces—where a single feature could reasonably belong to three different teams—you will need to pair this prompt with a conflict resolution or disambiguation step. The prompt template includes placeholders for your taxonomy, output schema, and constraints, allowing you to adapt it without rewriting the core classification logic.

Do not use this prompt when the input is already structured and tagged with a known product area, or when you are operating in a single-product system where routing is unnecessary. It is also not a replacement for intent detection or priority scoring; those are separate classification tasks that should run in parallel or downstream. If you skip this prompt and route based on keyword matching or naive regex, expect silent misrouting, broken tool calls, and user frustration. Start here when you need a reliable, testable product classifier that can be evaluated against a labeled dataset before it touches production traffic.

This prompt template is designed to be pasted directly into your system instructions for a classification step that runs before any tool dispatch, context retrieval, or agent handoff. It maps raw user input to a single product area from your defined taxonomy, returns a calibrated confidence score, and explicitly abstains when the input falls outside all supported domains. The template uses square-bracket placeholders that you must replace with your actual taxonomy, routing rules, and output schema before deployment.

textCopy
You are a product area classifier for a multi-product platform. Your job is to read an incoming user request and map it to exactly one product area from the supported taxonomy. You must also provide a confidence score and explicit reasoning. If the request does not fit any supported product area, you must abstain rather than force a match.

## TAXONOMY
[PRODUCT_TAXONOMY]

Each product area has:
- **name**: The canonical product area label
- **description**: What types of requests belong here
- **boundary_rules**: Rules for distinguishing this area from similar areas
- **examples**: Representative requests that map to this area

## ROUTING RULES
[ROUTING_RULES]

## OUTPUT SCHEMA
Return a valid JSON object with exactly these fields:
```json
{
  "product_area": "string (canonical name from taxonomy, or null if abstaining)",
  "confidence": 0.0-1.0,
  "reasoning": "string (brief explanation of classification decision)",
  "abstention": true|false,
  "abstention_reason": "string (required if abstention is true, otherwise null)",
  "secondary_areas": ["string"] (other product areas the request partially matches, empty array if none)
}

CONFIDENCE GUIDELINES

• 0.9-1.0: Clear, unambiguous match to a single product area with strong signals
• 0.7-0.89: Likely match but some minor ambiguity or missing detail
• 0.5-0.69: Plausible match but significant ambiguity; consider flagging for review
• Below 0.5: Do not classify; set product_area to null and abstention to true

ABSTENTION RULES

Abstain when:

• The request does not match any product area in the taxonomy
• The request spans multiple product areas with no clear primary intent
• The request is too vague to classify with confidence above 0.5
• The request contains only greetings, off-topic content, or gibberish

CONSTRAINTS

[CONSTRAINTS]

EXAMPLES

[EXAMPLES]

INPUT

[INPUT]

To adapt this template, start by replacing [PRODUCT_TAXONOMY] with your actual product area definitions. Each entry should include a canonical name, a clear description of what belongs there, boundary rules that distinguish it from overlapping areas, and at least three representative examples. The boundary rules are critical: they prevent the classifier from oscillating between similar product areas when requests sit near category edges. Replace [ROUTING_RULES] with any additional routing logic, such as tier-based overrides, customer-specific mappings, or regulatory requirements that affect classification. Replace [CONSTRAINTS] with domain-specific constraints like "never classify billing disputes as technical issues" or "if the user mentions a specific API endpoint, prefer the API namespace product area." Replace [EXAMPLES] with at least five few-shot examples covering clear matches, boundary cases, multi-product references, and legitimate abstention scenarios. The [INPUT] placeholder should be replaced at runtime with the actual user request text.

Before deploying this prompt, validate that your taxonomy is mutually exclusive and collectively exhaustive for your supported domains. If two product areas have overlapping descriptions, the classifier will produce inconsistent results at the boundary. Test the prompt against a golden dataset of at least 50 labeled examples that include single-product matches, multi-product references, out-of-scope requests, and edge cases where two product areas are plausible. Measure precision, recall, and abstention accuracy. Pay special attention to false negatives in abstention: requests that should be classified but are incorrectly rejected. These failures silently drop valid user requests and are harder to detect in production than misclassifications.

Wire this prompt into a classification step that runs before any tool selection, context retrieval, or agent dispatch. Store the classification result, confidence score, and reasoning in your observability layer so you can trace routing decisions back to specific inputs. Set a confidence threshold for automatic routing versus human review: requests with confidence below 0.7 should typically be flagged for review rather than auto-routed. If your platform serves multiple tenants, ensure the taxonomy and routing rules are scoped per tenant to prevent cross-tenant information leakage through classification metadata.

This prompt is designed to be called by a routing middleware layer that sits between your ingestion endpoint and downstream product-specific handlers. The middleware receives an unstructured user request, constructs the prompt with the current product taxonomy and the user input, calls the model, and parses the structured classification output. The resulting product_area label and confidence score determine which queue, tool set, and context retrieval pipeline the request is dispatched to. Do not use this prompt directly in a user-facing chat interface; it is a machine-to-machine classification step that should be invisible to the end user.

Implement the harness with the following guardrails. Input validation: Sanitize and truncate the user input to a maximum token length before insertion into the [USER_INPUT] placeholder to prevent prompt stuffing and control cost. Output parsing: Expect a JSON object with product_area, confidence, and reasoning fields. Use a strict JSON schema validator after extraction. If parsing fails, retry once with a repair prompt that includes the raw output and the expected schema. Confidence thresholding: Route requests with confidence >= 0.85 directly to the product handler. Route requests with 0.60 <= confidence < 0.85 to a clarification queue where the system asks the user to confirm the detected product area. Route requests with confidence < 0.60 or a product_area of "unknown" to a human triage queue. Model choice: Use a fast, cost-efficient model for this classification step (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small model). The classification task requires taxonomy adherence and structured output but not deep reasoning. Logging: Log the raw user input, the assigned product area, confidence score, model latency, and the final routing decision. This log becomes your audit trail for misrouting investigations and taxonomy drift detection.

Before deploying, build a golden test set of at least 50 examples that cover clear product boundaries, overlapping products, out-of-scope requests, and edge cases where the user mentions multiple products. Run this test set against the prompt and measure precision, recall, and confidence calibration. Pay special attention to boundary cases between overlapping products—these are the most common failure mode in production. If you observe systematic misclassification between two specific products, add disambiguation rules to the taxonomy descriptions in the prompt or implement a secondary disambiguation prompt that fires only for that product pair. Wire the classification confidence and routing decision into your observability dashboard so you can detect taxonomy drift as your product surface evolves.