Customer Tier and Issue Severity Combination Prompt

This prompt is designed for SaaS platform engineers and support operations teams who need to combine customer tier metadata with issue severity to produce an entitlement-aware priority score. The core job-to-be-done is deterministic, auditable routing where a paying enterprise customer reporting a P1 outage must be prioritized differently than a free-tier user reporting the same technical severity. Use this prompt when your routing logic must respect commercial agreements, when priority must be reproducible for audit, and when you need explicit override conditions for VIP accounts, contract SLAs, or security-sensitive issues. The ideal user is an engineer or operations lead building or maintaining a support triage pipeline, incident management system, or automated ticket router where customer entitlements directly shape queue ordering and escalation timing.

This prompt requires structured inputs: a defined customer tier taxonomy (e.g., Free, Pro, Enterprise, VIP), a severity classification schema (e.g., SEV1 through SEV4), and a tier multiplier table that encodes your commercial policy. The output is a tier-adjusted priority score with explicit components—base severity score, tier multiplier, final score, and any override flags. Before deploying, you must validate that your tier data is accurate and available at classification time; stale or missing tier data will silently produce incorrect priority assignments. Implement a pre-check that confirms tier metadata is present and recent, and route requests with missing tier data to a manual review queue rather than guessing. For high-risk domains, add a human approval step when the prompt applies a VIP override or when the final score crosses a threshold that triggers executive escalation.

Do not use this prompt for general sentiment analysis, for workflows where tier data is unavailable, or as a standalone replacement for a full incident management system. It is not designed to assess technical severity from unstructured text—pair it with a dedicated severity classification prompt upstream. Avoid using this prompt when priority must be determined by real-time operational factors like current on-call load or when the tier multiplier logic changes faster than you can update the prompt template. If your routing decisions have regulatory or contractual consequences, ensure every priority assignment is logged with the input snapshot, multiplier applied, and final score for audit review. Start by testing against a golden dataset of known tier-severity pairs with expected outputs before integrating into your production pipeline.

This template is the core of the playbook. It is designed to be copied directly into your application code or prompt management system. The prompt instructs the model to act as a deterministic scoring function, taking structured inputs for customer tier and issue severity and producing a single, auditable priority score. The square-bracket placeholders represent the dynamic data your system must inject at runtime. Do not modify the core logic of the prompt; instead, adapt the values you pass into the placeholders.

textCopy
You are a priority scoring engine for a SaaS platform. Your task is to combine a customer's account tier with the severity of their reported issue to produce a single, tier-adjusted priority score. You must follow the rules exactly and show your work.

**Input Data:**
- Customer Tier: [CUSTOMER_TIER]
- Issue Severity: [ISSUE_SEVERITY]
- Tier Multiplier Map: [TIER_MULTIPLIER_MAP]
- Severity Base Score Map: [SEVERITY_BASE_SCORE_MAP]
- Override Rules: [OVERRIDE_RULES]

**Instructions:**
1.  **Validate Inputs:** First, check if the provided [CUSTOMER_TIER] and [ISSUE_SEVERITY] exist in the respective maps. If a value is missing or unrecognized, return an error object as specified in the output schema.
2.  **Look Up Values:** Retrieve the base score for the [ISSUE_SEVERITY] from the [SEVERITY_BASE_SCORE_MAP] and the multiplier for the [CUSTOMER_TIER] from the [TIER_MULTIPLIER_MAP].
3.  **Calculate Raw Score:** Multiply the severity base score by the tier multiplier. The formula is: `raw_score = base_score * tier_multiplier`.
4.  **Apply Override Rules:** Check the calculated `raw_score` against the conditions in the [OVERRIDE_RULES]. If a rule's condition is met, replace the `raw_score` with the rule's `override_score` and note the rule's `reason`.
5.  **Determine Final Priority:** Map the final score (after overrides) to a priority level (e.g., P1, P2, P3) using the standard scale: 75-100 = P1, 50-74 = P2, 25-49 = P3, 0-24 = P4.

**Output Format:**
You must respond with a single, valid JSON object conforming to this schema:
{
  "priority_level": "string", // The final P1-P4 priority level
  "final_score": "number", // The final calculated score after overrides
  "calculation_steps": {
    "input_validation": "string", // 'valid' or a description of the error
    "base_severity_score": "number",
    "tier_multiplier": "number",
    "raw_score": "number",
    "applied_override": "string | null", // The reason from the override rule, or null
    "final_score": "number"
  },
  "error": "string | null" // A description of the error if input validation failed, otherwise null
}

To adapt this template, you must define the data structures for the placeholder maps. For example, [TIER_MULTIPLIER_MAP] could be a JSON object like {"enterprise": 1.5, "pro": 1.2, "standard": 1.0}. The [OVERRIDE_RULES] placeholder should be an array of rule objects, such as [{"condition": "raw_score > 80 && customer_tier == 'standard'", "override_score": 85, "reason": "Critical severity caps priority for all tiers."}]. Ensure your application logic serializes these data structures into a string format the model can parse before inserting them into the prompt. The strict JSON output format is critical for downstream parsing; always validate the model's response against the schema before acting on the priority.

This prompt is designed to be called synchronously within a ticket ingestion or triage middleware layer. The application must supply three structured inputs: the customer's tier from your account database, the issue severity from an upstream classifier or human selection, and any override flags from your business rules engine. Do not pass raw, unvalidated strings for tier or severity—the prompt's reliability depends on clean, enumerated inputs that match your internal service catalog and entitlement schema.

Implement a pre-call validation gate that checks: (1) [CUSTOMER_TIER] is a recognized value from your tier enum (e.g., free, starter, professional, enterprise, vip), (2) [ISSUE_SEVERITY] is a recognized severity level (e.g., SEV1 through SEV4), and (3) [OVERRIDE_CONDITIONS] is either none or a structured list of active policy overrides with timestamps. If validation fails, reject the request before model invocation and log the malformed input for triage. After the model returns, validate the output against the expected JSON schema: a tier_multiplier (float), base_severity_score (integer), adjusted_priority_score (float), override_applied (boolean), and rationale (string). Use a JSON Schema validator in your application code—do not rely on the model to self-correct without a repair loop.

For production deployment, wrap the prompt call in a retry wrapper with exponential backoff (max 3 attempts) for transient model errors or schema validation failures. On the second retry, append the validation error message to the prompt as additional context so the model can self-correct. If all retries fail, escalate to a human review queue with the original inputs, all failed outputs, and validation error logs attached. Log every invocation—inputs, outputs, retry count, latency, and final disposition—to your observability platform. This audit trail is critical for SLA compliance reporting and for detecting tier lookup failures where the application passed a stale or incorrect customer tier. For VIP customers (tier enterprise or vip), consider adding a post-processing rule that floors the adjusted_priority_score at a minimum threshold to guarantee expedited handling regardless of model output, and flag these cases for immediate human notification.

Model choice matters here: use a model with strong instruction-following and JSON output reliability, such as GPT-4o, Claude 3.5 Sonnet, or an equivalent. Avoid smaller, less reliable models for this task because tier multiplier misapplication or override omission can directly violate customer SLAs. If you must use a smaller model for cost reasons, add a secondary validation step that recalculates the expected adjusted_priority_score from the known tier multiplier and base severity using your business rules, and flag any discrepancy exceeding a 5% tolerance for human review. Do not use this prompt in streaming mode—the output must be complete and validated before the triage system acts on the priority score.