Account Tier Detection Prompt Template

This prompt is for platform engineers building SaaS routing middleware that must classify a customer's account tier from structured or semi-structured metadata. It ingests account fields, contract snippets, or entitlement payloads and returns a normalized tier label with a confidence score. Use it when downstream workflows, queue assignments, feature gates, or SLA enforcement depend on accurate tier detection, and when tier signals are spread across CRM fields, contract text, support entitlements, and provisioning metadata rather than residing in a single clean database field.

The ideal user is an infrastructure or platform engineer who has already attempted deterministic tier resolution and found it brittle. Common triggers include: account tier stored inconsistently across systems acquired through mergers, tier encoded in human-readable contract language rather than machine-readable fields, entitlement data that requires interpretation of legal or commercial terms, or environments where the canonical account database is known to be stale or untrusted. In these cases, an LLM-based classifier can normalize messy, multi-source signals into a structured output that downstream systems can consume reliably.

Do not use this prompt when account tier is stored in a single, well-maintained database field with strong data governance. A deterministic lookup or simple rules engine will be faster, cheaper, and more auditable. Similarly, avoid this prompt for real-time latency-sensitive paths where sub-100ms responses are required unless you have validated that your model serving infrastructure meets those targets. For high-throughput streaming pipelines, batch the classification step or use a cached tier resolution layer that re-evaluates only when account metadata changes.

This prompt is also not a replacement for contract review or legal interpretation of entitlements. It classifies tier from available signals but does not resolve contractual disputes or interpret novel legal language. When the prompt returns low confidence or conflicting signals, the correct next step is escalation to a human reviewer or a manual override queue, not blind acceptance of the model's best guess. Wire the confidence score into your routing logic with explicit thresholds: high-confidence results can route automatically, medium-confidence results should log for audit, and low-confidence results must trigger human review before any SLA-bound action is taken.

This prompt template is designed to be pasted directly into your system instructions or a classification node within your routing middleware. It accepts account metadata, contract fields, or support entitlement strings and returns a normalized tier label with a confidence score. The prompt is structured to handle missing data gracefully, avoid hallucinating tiers, and produce output that downstream dispatch logic can consume without additional parsing.

textCopy
You are an account tier classifier for a SaaS routing system. Your job is to read the provided account metadata and return exactly one normalized tier label with a confidence score.

## INPUT
Account Metadata:
[ACCOUNT_METADATA]

## TIER TAXONOMY
Use ONLY the following tier labels:
- enterprise
- premium
- standard
- freemium
- trial
- partner
- unknown

## CLASSIFICATION RULES
1. If the metadata contains explicit tier fields (e.g., "plan": "enterprise", "support_level": "premium"), use that value after normalizing it to the taxonomy above.
2. If multiple tier signals conflict, prefer the most recent contract or entitlement field and note the conflict in the evidence field.
3. If no tier information is present, return "unknown" with confidence 0.0.
4. If the account is in a downgrade grace period, classify as the higher of the current and previous tier and set the `grace_period` flag to true.
5. If the account is a child account in a hierarchy, resolve the effective tier from the parent if parent metadata is provided. Document the inheritance chain.
6. Do not infer tier from company name, employee count, or revenue unless those fields are explicitly labeled as tier determinants.

## OUTPUT SCHEMA
Return ONLY valid JSON matching this schema:
{
  "tier": "<normalized_tier_label>",
  "confidence": <float 0.0 to 1.0>,
  "evidence": ["<field_name>: <value>", ...],
  "grace_period": <boolean>,
  "inheritance_chain": ["<account_id>", ...] | null,
  "fallback_reason": "<reason if tier is unknown, else null>"
}

## CONSTRAINTS
- Do not return tiers outside the taxonomy.
- If confidence is below 0.7, set tier to "unknown" and explain why in fallback_reason.
- Never fabricate account metadata. Only use what is provided.
- If the input is empty or malformed, return tier "unknown" with confidence 0.0 and fallback_reason "empty_or_malformed_input".

To adapt this template, replace [ACCOUNT_METADATA] with the actual payload from your account service, CRM, or contract store. The metadata can be a JSON object, a flattened string of key-value pairs, or a concatenation of relevant fields. Ensure the taxonomy labels match your internal routing constants exactly. If your system uses different tier names, update the taxonomy list and the normalization logic in the classification rules. The output schema is designed to be parsed by a downstream validator before any routing decision is made.

Before deploying, wire a post-processing validator that checks the returned tier against your allowed enum and rejects any response where confidence is below your operational threshold. Log every classification with the evidence array and fallback_reason to build an audit trail for misclassification debugging. For high-stakes routing—such as enterprise escalations or SLA-bound queues—require human review when confidence is below 0.85 or when grace_period is true. This prompt is a classification node, not a decision engine; the routing logic that consumes its output should own the final dispatch, retry, and escalation paths.

This prompt is designed to be called synchronously within a request processing pipeline—typically after authentication and before queue dispatch or tool authorization. The application layer should fetch the account object, contract metadata, and any support entitlement flags from your internal services, then inject them into the [ACCOUNT_METADATA] and [ENTITLEMENT_CONTEXT] placeholders. Do not pass raw database rows or unredacted PII; the prompt needs structured fields like plan_code, contract_tier, support_level, account_status, and entitlements_array. If your system uses a feature-flag service or a billing API to determine entitlements, resolve those flags first and pass the resolved boolean map rather than asking the model to interpret raw feature gate responses.

Wrap the LLM call in a thin service function that enforces a strict JSON schema on the output. The expected shape includes tier (enum: enterprise, premium, standard, freemium, trial, unknown), confidence (0.0–1.0), evidence_fields (array of field names used), and fallback_applied (boolean). Validate this schema immediately after the model responds. If parsing fails, retry once with a repair prompt that includes the raw output and the schema. If the retry also fails or returns tier: unknown with confidence below your threshold (we recommend 0.7 as a starting point), route the request to a human review queue and log the full prompt context and failed output for later diagnosis. For high-traffic systems, consider caching tier determinations per account ID with a short TTL (e.g., 5 minutes) to avoid redundant LLM calls on burst requests from the same customer.

Model choice matters here. This is a classification task with a constrained output schema, so a smaller, faster model (e.g., Claude Haiku, GPT-4o-mini, or a fine-tuned open-weight model) is usually sufficient. Reserve larger models for cases where the account metadata is messy, unstructured, or contains free-text contract notes that require reasoning. Instrument the call with latency and token-usage metrics, and set a timeout (500–800 ms is reasonable for synchronous routing). If the model exceeds the timeout, apply your configured fallback tier (typically the most restrictive tier the account could have based on cached data) and flag the request for async review. Log every routing decision with the account ID, determined tier, confidence, model used, latency, and whether a fallback was applied—this audit trail is essential for SLA compliance disputes and for tuning your confidence thresholds over time.