Premium vs Standard Routing Decision Prompt

This prompt is designed for platform and routing engineers who need to embed commercial logic directly into their AI dispatch middleware. Its core job is to classify an incoming customer request into a premium, standard, or basic routing tier by evaluating structured account attributes (like accountTier, isTrial, isInGracePeriod) against the characteristics of the request itself (like requestType or priority). The output is a deterministic, auditable tier assignment that downstream systems—such as queue routers, agent assignment logic, and SLA timers—can act on without further interpretation. Use this when your routing logic must respect contractual segmentation and you need a traceable record of why a request was routed a certain way.

The ideal implementation context is a synchronous API or middleware function where latency is not the absolute primary constraint. The prompt requires a pre-assembled [INPUT] object containing both the customer profile and the parsed request intent. It is not designed to perform intent detection or account lookup itself; those steps must be completed upstream. The prompt's value is in applying nuanced policy, such as honoring a grace period for a recently downgraded premium account or routing a trial user's technical emergency to a standard queue instead of basic self-service. A concrete example: an account with "tier": "premium" but "isInGracePeriod": true and "isTrial": false should still receive standard routing for non-critical issues, a subtlety a simple if/else rules engine might miss without explicit maintenance.

Do not use this prompt for real-time, latency-sensitive routing where a sub-50ms response is required; a simple rules engine or a cached lookup table is a better fit. It is also unsuitable for multi-intent requests that require decomposition before classification—sending a single message containing both a billing dispute and a technical outage will produce an ambiguous tier assignment. In such cases, use an intent decomposition prompt first. Finally, avoid this prompt when the routing decision depends on real-time operational data like current queue depth or agent availability; those variables belong in a post-classification dispatch layer, not in the tier assignment logic itself. The next step after understanding this boundary is to review the prompt template and its required input schema.

This prompt template is designed to be pasted directly into your system prompt or user message field. It instructs the model to act as a deterministic routing classifier, consuming structured account context and an unstructured user request to produce a single, auditable routing decision. Before using it, you must replace every square-bracket placeholder with the actual values, schemas, and constraints that match your production environment. Do not send the prompt with unresolved placeholders to the model; the output will be unreliable.

codeCopy
SYSTEM:
You are a deterministic routing classifier for a SaaS platform. Your only job is to analyze the provided [ACCOUNT_CONTEXT] and [USER_REQUEST] and output a single JSON object that assigns the request to exactly one routing tier: premium, standard, or basic.

Follow these rules strictly:
1. Base the routing decision on the account's current tier, contract status, and any explicit SLA guarantees found in [ACCOUNT_CONTEXT].
2. If the account is in a trial or grace period, apply the routing rules defined in [GRACE_PERIOD_POLICY].
3. If the [USER_REQUEST] indicates a severity or business impact level, use the [SEVERITY_MAPPING] to adjust the tier upward if necessary. Never downgrade a tier based on severity.
4. If the [ACCOUNT_CONTEXT] is missing, incomplete, or contradictory, output a routing tier of "standard" and set a `routing_confidence` score of 0.0 with a `fallback_reason`.
5. Do not invent account details. Only use the provided [ACCOUNT_CONTEXT].

USER:
ACCOUNT_CONTEXT:
[ACCOUNT_CONTEXT]

USER_REQUEST:
[USER_REQUEST]

OUTPUT_SCHEMA:
{
  "routing_tier": "premium" | "standard" | "basic",
  "routing_confidence": 0.0 - 1.0,
  "applied_policy": "string",
  "fallback_reason": "string | null",
  "evidence_summary": "string"
}

CONSTRAINTS:
[CONSTRAINTS]

To adapt this template, start by defining your [ACCOUNT_CONTEXT] structure. This should be a JSON object containing fields like account_tier, contract_status, grace_period_end_date, and entitlements. The [GRACE_PERIOD_POLICY] and [SEVERITY_MAPPING] placeholders should be replaced with explicit rules, such as 'trial accounts with a severity of critical route to premium.' The [CONSTRAINTS] block is where you enforce business logic, for example, 'enterprise accounts always route to premium regardless of severity.' After adapting the prompt, run it against a golden dataset of known account-request pairs to verify that the model respects your tier boundaries and does not hallucinate entitlements. For high-stakes routing, always log the evidence_summary and fallback_reason fields for auditability, and consider a human review step for any decision with a routing_confidence below 0.85.

This prompt is designed to sit inside a routing middleware layer—the decision point between request ingestion and downstream dispatch. It should be called after account resolution and before queue assignment. The prompt expects structured account attributes and request characteristics as input, and it returns a routing tier label plus supporting evidence. Treat this as a deterministic classification step: the output must be machine-readable and auditable, not conversational.

Integration pattern: Wrap the prompt in a thin service function that assembles the [ACCOUNT_ATTRIBUTES] and [REQUEST_CHARACTERISTICS] blocks from your account service, contract store, and ticket system. Call the LLM with temperature=0 and a JSON mode or structured output constraint. Validate the response against a strict schema: routing_tier must be one of premium, standard, or basic; confidence must be a float between 0.0 and 1.0; evidence must be a non-empty array of strings. If validation fails, retry once with the validation error injected into the prompt as additional [CONSTRAINTS]. If the retry also fails, log the failure and route to a human review queue with the raw LLM output attached. Never silently default to a tier—misrouting a premium account to standard support is a revenue-risk event.

Model choice and latency: Use a fast, cost-efficient model for this classification task (e.g., GPT-4o-mini, Claude Haiku, or an equivalent small model). The prompt is structured enough that larger models rarely improve accuracy for standard tier detection. Reserve larger models for edge-case resolution when confidence falls below your threshold. Observability: Log every routing decision with the input hash, output tier, confidence score, model version, and latency. This creates an audit trail for SLA compliance and lets you detect drift—for example, if trial accounts start routing as premium after a contract schema change. Fallback chain: If the primary model call fails entirely (timeout, rate limit, service error), fall back to a deterministic rules engine that checks explicit tier flags in the account metadata. The prompt is the primary path; rules are the safety net, not the other way around.

Edge-case handling: Trial accounts, grace-period downgrades, and custom contracts are the most common failure sources. Wire a pre-check that inspects account_status and grace_period_end before calling the prompt. If the account is in a known edge state, inject that context explicitly into [ACCOUNT_ATTRIBUTES] rather than hoping the model infers it. For custom contracts with bespoke entitlements, include a custom_terms field in the input block and add a post-prompt validation: if the model returns standard but custom_terms contains premium entitlements, flag for human review. Next step: After routing tier is determined, pass the decision to your queue dispatcher along with the confidence score. Downstream systems should use the confidence score to adjust SLA timers—low-confidence premium assignments might still get premium treatment but with a shorter escalation window.