SLA Tier Assignment Prompt for Incoming Requests

This prompt is for operations engineers building request ingress pipelines that must assign SLA tiers before any work begins. It takes a customer contract profile, request type, and business impact signals, then produces an auditable tier decision with rationale. Use it when your system needs deterministic, explainable tier assignment that respects contractual obligations and can be reviewed by humans or downstream automation. This is not a general priority scorer or a sentiment-based urgency detector. It assumes you have structured contract data and request metadata available at ingress time.

The ideal user is an infrastructure or platform engineer integrating AI into a production request pipeline where SLA tier assignment is a gating step. Required context includes a structured customer profile (tier, contract clauses, service hours), a request type taxonomy, and business impact metadata (e.g., revenue at risk, user count affected). Do not use this prompt when you lack structured contract data, when the request type is unknown, or when the business impact cannot be quantified. In those cases, route to a human triage queue or a separate ambiguity detection prompt first.

Common misuse includes applying this prompt to sentiment analysis, general urgency scoring, or customer satisfaction prediction. This prompt does not infer tier from tone, history, or relationship health. It operates on explicit contractual and operational signals. If your pipeline needs to detect customer frustration or predict churn risk, use a separate sentiment or risk classification prompt upstream. The SLA tier assignment should be the final routing decision, not an early-stage guess.

Before deploying, ensure your contract data is normalized into a machine-readable schema. Inconsistent tier naming, missing service hours, or ambiguous request type mappings will produce unreliable tier assignments. Test the prompt against a golden dataset of known contract-request pairs with expected tier outcomes. Pay special attention to edge cases where a customer has multiple active contracts, where the request type spans tier boundaries, or where business impact signals conflict with contractual minimums. These cases should be flagged for human review rather than silently assigned.

After reading this section, proceed to the prompt template to copy and adapt the core instruction. Then review the implementation harness for validation, retry, and logging patterns that make this prompt production-safe.

This prompt template is designed to be the core decision engine in a request ingress pipeline. It takes structured inputs about a customer's contract, the nature of their request, and the potential business impact, and returns a deterministic, auditable JSON decision. The primary goal is to enforce contractual obligations consistently, ensuring that high-value customers with premium SLAs are never inadvertently deprioritized. Use this template as a starting point; you will need to adapt the [SLA_TIER_DEFINITIONS] and [ESCALATION_RULES] to match your organization's specific service catalog and operational policies.

textCopy
System: You are an SLA Tier Assignment Engine. Your task is to assign a single SLA tier to an incoming request based on the provided context. You must be precise, deterministic, and strictly adhere to the defined rules. Your output must be a single, valid JSON object.

Input Data:
- Customer Contract: [CUSTOMER_CONTRACT_JSON]
- Request Details: [REQUEST_DETAILS_JSON]
- Business Impact Signals: [BUSINESS_IMPACT_SIGNALS_JSON]

SLA Tier Definitions:
[SLA_TIER_DEFINITIONS]

Assignment Rules:
1. First, check if the request type in [REQUEST_DETAILS_JSON] matches any criteria in the [ESCALATION_RULES] for a forced tier (e.g., 'SEVERITY_1_INCIDENT'). If a forced tier applies, assign it immediately and cite the specific rule in your rationale.
2. If no forced tier applies, determine the base tier from the customer's contract in [CUSTOMER_CONTRACT_JSON].
3. Evaluate the [BUSINESS_IMPACT_SIGNALS_JSON] against the [SLA_TIER_DEFINITIONS]. If the impact signals justify a higher tier than the base tier, you may upgrade the tier. You must never downgrade a tier below the customer's contracted base tier.
4. If any input data is missing, ambiguous, or contradictory, do not guess. Assign a special tier of 'TRIAGE_REQUIRED' and set the confidence to 'low'.

Output Schema:
{
  "assigned_tier": "string",
  "confidence": "high|medium|low",
  "rationale": "A concise, step-by-step explanation referencing the specific contract clause, rule, or impact signal that determined the tier.",
  "escalation_triggered": "boolean",
  "missing_data_fields": ["string"]
}

To adapt this template, start by replacing the [SLA_TIER_DEFINITIONS] placeholder with a structured description of your tiers, including response and resolution time targets. The [ESCALATION_RULES] placeholder should contain a list of conditions that override standard contract routing, such as a major security incident or an executive escalation. When wiring this into an application, the [CUSTOMER_CONTRACT_JSON] and [REQUEST_DETAILS_JSON] placeholders should be populated programmatically from your CRM and ticketing systems. The final critical step before deployment is to run this prompt against a golden dataset of historical requests to ensure its tier assignments are consistent with past manual decisions and contractual obligations.

Integrating the SLA Tier Assignment Prompt into a production system requires treating it as a deterministic classification step within a broader request ingress pipeline. The prompt should be invoked after initial request parsing and authentication but before the request is dispatched to a fulfillment queue. At this stage, the application layer must assemble the required inputs: the customer's contractual SLA tier from your entitlements service, the request type extracted from the payload or API endpoint, and any business impact signals such as revenue at risk, affected user count, or declared severity. These inputs should be passed into the prompt's [CUSTOMER_TIER], [REQUEST_TYPE], and [BUSINESS_IMPACT] placeholders. The model's output—a structured JSON object containing the assigned SLA tier, a confidence score, and a rationale—must be validated before it can influence queue priority, response time targets, or escalation behavior.

The implementation harness should enforce strict validation on the model's output. Use a JSON schema validator to confirm that the assigned_tier field matches one of your defined SLA levels (e.g., critical, high, standard, low) and that the confidence field is a float between 0.0 and 1.0. If validation fails, implement a retry loop with a maximum of two additional attempts, appending the validation error to the prompt context on each retry. If the model consistently fails to produce a valid tier or returns a confidence score below your operational threshold (e.g., < 0.7), the harness must escalate the request to a human review queue rather than defaulting to a lower tier. This is critical because under-tiering a high-impact request can breach contractual SLAs. Log every assignment decision—including the input signals, model output, validation result, and final tier—to an immutable audit store. This log becomes your evidence trail for SLA compliance reporting and for debugging tier assignment drift over time.

For model choice, prefer a fast, cost-effective model with strong instruction-following and JSON mode support, such as GPT-4o-mini or Claude 3.5 Haiku, since this is a classification task with low reasoning complexity but high throughput demands. Do not use a general chat model without structured output constraints. Enable the model's native JSON mode or supply a tool definition with a strict schema to minimize parsing failures. If your pipeline processes requests asynchronously, batch SLA assignments where possible to amortize API call overhead, but ensure that each request's assignment is independent and idempotent. Never cache or reuse tier assignments across different requests, even from the same customer, because the business impact and request type may change the outcome. Finally, monitor the distribution of assigned tiers in production. A sudden shift toward critical or low assignments without a corresponding change in input signals may indicate prompt drift, model behavior change, or an upstream data quality issue in your entitlements service.