SLA Tier Assignment Prompt for Incoming Requests

This prompt is for platform engineers and support operations teams who need to map incoming customer requests to the correct SLA tier before the request enters a queue. The prompt takes a customer's contract entitlements, account metadata, and the request content, then returns a deterministic SLA tier with a justification, first-response deadline, and escalation path. Use this when your routing middleware must respect commercial agreements and when a wrong tier assignment creates contractual risk or customer dissatisfaction. This prompt assumes you have already extracted the customer identifier and can look up their contract data before invoking the model.

The ideal scenario is a multi-tenant SaaS platform where different customers have different support tiers—Basic, Premium, Enterprise—and each tier carries distinct response-time obligations. Before invoking this prompt, your system should resolve the customer ID from the incoming request (via API key, session token, or email domain) and retrieve the corresponding contract record from your CRM or billing system. The prompt then combines that structured entitlement data with the unstructured request body to produce a tier assignment that is auditable and consistent. Do not use this prompt when you lack reliable contract data, when the request volume exceeds your model's latency budget for synchronous routing, or when the SLA tier is already determined by a deterministic rules engine that doesn't require natural language reasoning.

Avoid using this prompt for real-time, sub-100ms routing decisions where a simple lookup table suffices. If your customer base has only one SLA tier, or if tier assignment is purely a function of a single database field with no ambiguity, the model adds latency and cost without benefit. Similarly, do not use this prompt when the request content is irrelevant to tier assignment—for example, when all Enterprise customers get the same SLA regardless of what they ask. In those cases, a direct database lookup is faster, cheaper, and more reliable. Reserve this prompt for environments where contract entitlements interact with request content in ways that require reasoning: a Premium-tier customer reporting a complete outage might need escalation beyond their standard SLA, while an Enterprise customer asking a how-to question might not need the full Enterprise response commitment.

Before deploying, validate the prompt against a golden dataset of at least 50 labeled examples covering all tier combinations, edge cases like expired contracts or grandfathered entitlements, and ambiguous requests where the severity is unclear. Log every tier assignment with the input context, model output, and final routing decision so you can audit SLA compliance over time. If the model's tier assignment conflicts with a human reviewer's judgment more than 5% of the time, investigate whether your contract metadata is incomplete or whether the prompt's severity-assessment instructions need refinement.

This prompt template is designed to be wired directly into a support platform's intake pipeline. It forces the model to act as a deterministic router, not a creative assistant. The core instruction is to map a customer's request and their associated contract metadata to a specific SLA tier, producing a structured JSON object that downstream systems—like queue dispatchers, alerting tools, and escalation workflows—can consume without further parsing. The prompt explicitly forbids inventing contract terms and requires an 'UNCLEAR' tier when data is insufficient, preventing silent misrouting.

textCopy
You are an SLA tier assignment system. Your only job is to map the incoming customer request to a single SLA tier based on the provided contract entitlements and issue criticality.

You must follow these rules exactly:
1. Use ONLY the provided [CONTRACT_ENTITLEMENTS] and [ISSUE_CRITICALITY] to determine the tier.
2. Do not invent, assume, or infer any contract terms, support levels, or customer statuses that are not explicitly stated in the provided data.
3. If the provided information is insufficient to determine a tier with high confidence, you MUST set the tier to 'UNCLEAR' and explain exactly what information is missing.
4. Your output must be a single, valid JSON object conforming to the [OUTPUT_SCHEMA].

[INPUT]
Customer Request: [CUSTOMER_REQUEST_TEXT]

[CONTEXT]
Contract Entitlements: [CONTRACT_ENTITLEMENTS]
Issue Criticality: [ISSUE_CRITICALITY]

[OUTPUT_SCHEMA]
{
  "sla_tier": "string (one of: 'CRITICAL', 'HIGH', 'MEDIUM', 'LOW', 'UNCLEAR')",
  "justification": "string (a concise, evidence-based reason for the tier assignment, citing specific contract terms or criticality markers)",
  "first_response_deadline": "string (ISO 8601 datetime or 'N/A' if UNCLEAR)",
  "escalation_path": "string (the named team or protocol for this tier, or 'N/A' if UNCLEAR)"
}

[CONSTRAINTS]
- The 'justification' field must be a factual summary, not a recommendation or apology.
- If tier is 'UNCLEAR', set 'first_response_deadline' and 'escalation_path' to 'N/A'.
- Do not include any text outside the JSON object.

To adapt this template, you must replace the placeholders with data from your application layer. [CUSTOMER_REQUEST_TEXT] is the raw, unmodified body of the request. [CONTRACT_ENTITLEMENTS] should be a structured text block containing the customer's specific support plan, SLA targets, and any account-specific overrides, fetched from your CRM or account database. [ISSUE_CRITICALITY] is a pre-assessed label (e.g., 'System Down', 'Feature Bug', 'General Inquiry') that should be determined by a separate classification step before this prompt is called. The [OUTPUT_SCHEMA] can be extended, but the sla_tier enum values must match your downstream routing logic exactly. For high-stakes environments, implement a validation layer that checks the JSON schema and, if the tier is 'UNCLEAR', automatically triggers a human review task instead of routing to a standard queue.

This prompt is designed to be a deterministic step in your request ingestion pipeline, not a standalone chatbot interaction. It should be called after customer identification and before the request is dispatched to a processing queue. The core integration involves resolving the requester to a [CUSTOMER_ACCOUNT_DATA] object via your internal account API, loading the [SLA_DEFINITIONS] from a configuration service or feature flag, and assembling the final prompt with the raw [REQUEST_CONTENT]. The model's output is a structured JSON object that must be programmatically validated before any routing decision is made.

To integrate, build a small service or middleware function that executes the following sequence: First, call your customer account API with the authenticated user's ID to fetch their current tier, contract entitlements, and any special SLA overrides. Second, retrieve the active SLA definitions from your configuration store—these should map tier names to response time targets and escalation paths. Third, inject these into the prompt template along with the raw request text. After receiving the model's JSON response, validate the tier field against a strict enum of your known SLA tiers (e.g., PLATINUM, GOLD, STANDARD). If the tier is UNCLEAR or the JSON fails schema validation, do not route the request automatically. Instead, push it to a manual triage queue and log the failure with the full input snapshot, model output, and validation error for immediate review.

For high-throughput production systems, implement two key optimizations. Cache the [SLA_DEFINITIONS] and customer tier lookups aggressively, as these change infrequently and a live API call on every request adds unnecessary latency. Use a read-through cache with a time-to-live (TTL) aligned with your SLA update cadence. Additionally, log every assignment as an immutable audit record containing the input request snapshot, the resolved customer tier, the model's raw output, the final routed queue, and a timestamp. This audit trail is critical for debugging misroutes, demonstrating SLA compliance to customers, and providing a dataset for future model fine-tuning or evaluation.

Avoid wiring this prompt directly to a customer-facing response. The output is a machine-readable routing instruction, not a message to the end user. If the model returns a justification, treat it as internal metadata for auditors and support agents, not as a public explanation. Finally, set a low timeout and a single retry for the model call; if the model is unavailable or times out, fall back to a default routing rule based solely on the customer's contracted tier rather than blocking the request pipeline.