Customer Impact Severity Scoring Prompt

This prompt is designed for support engineers and operations platform builders who need to assess the real-world blast radius of a customer-reported issue. The job-to-be-done is translating unstructured ticket text, incident notes, and customer descriptions into a structured, defensible impact severity score. The ideal user is someone integrating AI into a support triage or incident management pipeline where downstream actions—such as SLA selection, engineering escalation, or status-page updates—depend on an accurate estimate of how many users are affected, for how long, and whether they can work around the problem.

Use this prompt when you have a concrete issue report and need a consistent, evidence-backed severity assessment that considers three core dimensions: user scope (count or percentage of affected users), duration (how long the degradation has persisted), and workaround availability (whether users can still accomplish their core task). It is appropriate for B2B SaaS platforms, internal operations tools, and customer-facing support systems where overestimating severity wastes engineering time and underestimating it risks SLA breaches and customer churn. The prompt expects input that includes the issue description, any available telemetry or user reports, and the business function context so it can reason about criticality.

Do not use this prompt when the input is a vague user complaint with no supporting evidence, when the system requires a binary 'escalate or don't' decision without nuance, or when the downstream workflow is purely sentiment-based routing. This prompt is also not a replacement for real-time monitoring alerts; it assesses reported impact, not system health metrics. For high-stakes production incidents where a wrong severity call could cause significant revenue loss or regulatory exposure, always pair this prompt's output with a human review step and log the evidence, score, and reviewer decision in an audit trail. If you need a multi-factor composite score that also weighs revenue risk, compliance exposure, or customer tier, combine this prompt with the Multi-Factor Priority Rubric or SLA Tier Assignment prompts from the same pillar.

This prompt template is designed to produce a deterministic, evidence-backed severity score for customer-impacting issues. It forces the model to reason about user count, duration, workaround availability, and business function criticality before assigning a score. The template uses square-bracket placeholders so you can swap in your own input data, severity scale, output schema, and domain-specific constraints without rewriting the core reasoning structure.

textCopy
You are a customer impact severity assessor for a production support platform. Your job is to analyze an incoming issue report and produce a severity score based on four dimensions: number of affected users, duration of impact, workaround availability, and business function criticality.

## INPUT
[INPUT]

## SEVERITY SCALE
[SEVERITY_SCALE]

## OUTPUT SCHEMA
You must return a valid JSON object with exactly this structure:
{
  "severity_score": <integer or string matching the scale>,
  "user_impact": {
    "estimated_affected_users": <integer or range>,
    "user_segment": <string describing which users are affected>,
    "evidence": <quote from input supporting user count estimate>
  },
  "duration_assessment": {
    "impact_start": <ISO 8601 timestamp or "unknown">,
    "estimated_duration_minutes": <integer or null>,
    "duration_confidence": <"high" | "medium" | "low">,
    "evidence": <quote from input supporting duration estimate>
  },
  "workaround_availability": {
    "workaround_exists": <true | false>,
    "workaround_description": <string or null>,
    "workaround_coverage": <"full" | "partial" | "none">,
    "evidence": <quote from input supporting workaround assessment>
  },
  "business_criticality": {
    "affected_function": <string>,
    "criticality_tier": <"revenue-generating" | "compliance-mandated" | "internal-operations" | "customer-facing-non-revenue">,
    "revenue_at_risk_estimate": <string or null>,
    "evidence": <quote from input supporting criticality assessment>
  },
  "scoring_rationale": <string explaining how the four dimensions combined to produce the severity score>,
  "missing_information": <array of strings listing what information was unavailable that would improve confidence>,
  "confidence_level": <"high" | "medium" | "low">
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Extract all available evidence from the input before scoring.
2. If user count is not explicitly stated, estimate from context and mark confidence accordingly.
3. If duration is unknown, do not guess a specific number. Use null and set duration_confidence to "low".
4. A workaround that restores partial functionality is "partial" coverage, not "full".
5. Map the business function to exactly one criticality_tier from the provided enum.
6. If any dimension has insufficient evidence, list it in missing_information.
7. The severity_score must be justified by the scoring_rationale field.
8. Do not inflate severity when evidence is thin. Default to lower severity when uncertain.

Adapting the template: Replace [INPUT] with the raw ticket body, incident description, or structured issue payload. Replace [SEVERITY_SCALE] with your organization's severity definitions (e.g., SEV1 through SEV5 with explicit criteria for each tier). Replace [CONSTRAINTS] with domain-specific rules such as "any compliance-mandated function affected is minimum SEV2" or "user count below 10 caps severity at SEV4." Replace [EXAMPLES] with 2-4 scored examples that demonstrate edge cases your team cares about, including both clear-cut and borderline scenarios. The output schema is intentionally verbose to force evidence citation; trim fields only if your downstream system cannot consume them. Before deploying, run this prompt against a golden dataset of 20-30 previously scored issues and compare model-assigned severity against human-assigned severity to calibrate the scale and constraints.

This prompt is designed to sit behind an API endpoint or queue consumer that receives a support ticket payload and returns a structured severity assessment. The harness must enforce a strict contract: the prompt expects a ticket body, optional customer tier metadata, and a defined output schema. Before calling the model, validate that the input contains enough text to assess impact—reject or flag tickets shorter than 50 characters, as they lack the signal needed for reliable user-count and duration estimates. Strip any PII that isn't required for severity assessment, such as customer names or email addresses, to minimize data exposure in the model call.

Wire the prompt into a retry wrapper with a maximum of two attempts. On the first failure—whether a malformed JSON response, a missing required field, or a validator rejection—call the model again with the same prompt but append the validation error message as additional context. If the second attempt also fails, log the raw output, flag the ticket for human review, and assign a default severity score of SEV3 with a note that automated scoring was unavailable. This prevents silent failures from blocking the triage queue. For model choice, use a model with strong structured output support and low latency, such as gpt-4o or claude-3.5-sonnet, and set temperature=0 to maximize deterministic scoring. If your platform supports structured output modes, enforce the JSON schema directly at the API level rather than relying solely on the prompt's format instructions.

Log every scoring decision with the ticket ID, the raw prompt, the model response, the parsed score, and any validation errors. This audit trail is essential for calibrating the prompt over time and defending priority decisions during incident reviews. Implement a human review gate for any ticket scored as SEV0 or SEV1—these represent widespread customer impact or revenue-critical function degradation and should never be dispatched without a human confirming the assessment. For lower severities, route directly to the appropriate queue but sample 5% of SEV2 scores for manual spot-checking to detect drift. Avoid wiring this prompt directly into customer-facing status pages; the output is an internal triage signal, not a user-ready explanation.