User Impact Assessment Prompt for Bug Classification

This prompt is designed for product and support teams who need to estimate the blast radius of a bug before it enters the engineering backlog. The core job is to convert a bug description—often a mix of user reports, support tickets, and system alerts—into a structured impact assessment that answers three questions: how many users are affected, whether critical workflows are blocked, and what the revenue or churn risk looks like. The ideal user is a triage lead, product operations manager, or support engineer who has access to both the bug narrative and some form of user analytics context (e.g., event counts, feature adoption data, or customer tier information). Without that context, the model can only infer impact from language cues, which is unreliable for business decisions.

You should use this prompt when a bug has been confirmed as reproducible and you need a consistent, evidence-backed impact level before assigning severity or routing to an engineering team. The prompt expects two concrete inputs: a [BUG_DESCRIPTION] that includes the symptom, affected feature, and any known reproduction conditions, and an optional [USER_ANALYTICS_CONTEXT] containing relevant metrics such as daily active users on the affected flow, customer segments impacted, or revenue tied to the feature. The output is a structured impact level (e.g., critical, high, medium, low) with supporting notes on user segments and revenue risk. Do not use this prompt for initial bug report ingestion or reproduction step extraction—those are separate upstream tasks. Do not use it when the bug is purely speculative, lacks any reproduction evidence, or when you have no user analytics context and the decision carries financial or regulatory risk. In those cases, the output should be treated as a hypothesis requiring human validation, not a triage decision.

The primary failure mode of this prompt is overconfident impact estimation from weak signals. If the [USER_ANALYTICS_CONTEXT] is missing or stale, the model may default to plausible-sounding but ungrounded impact claims. To mitigate this, the implementation harness should validate that every impact claim in the output references either a specific analytics data point or an explicit insufficient_data marker. A second failure mode is conflation of user impact with technical severity—a bug that blocks one enterprise customer's payment flow may be critical even if user count is low. The prompt template addresses this by separating user-segment notes from the final impact level. After generating the assessment, route critical and high impact outputs for human review before they lock the severity field in your ticketing system. For medium and low outputs, log the assessment with the evidence snapshot so triage decisions remain auditable.

The following prompt template is designed to be copied directly into your AI harness, IDE, or orchestration layer. It accepts a bug report and optional user analytics context, then returns a structured impact assessment. All placeholders use square brackets and must be replaced with real values before execution. The template is intentionally strict about output format because downstream routing and prioritization systems depend on consistent, machine-readable impact levels.

textCopy
You are a bug triage specialist assessing user impact for incoming defect reports.

Your task is to analyze the bug report below and estimate how many users are affected, whether the bug blocks critical workflows, and what the revenue or churn risk might be.

## INPUT
Bug Report:
[BUG_REPORT]

Optional User Analytics Context (user counts, feature usage, segment data, revenue data):
[USER_ANALYTICS_CONTEXT]

## OUTPUT SCHEMA
Return a single JSON object with exactly these fields:
{
  "impact_level": "critical" | "high" | "medium" | "low" | "unknown",
  "affected_user_segment": "string describing which user segment is affected, or 'unknown'",
  "estimated_affected_user_count": "number or range as string, or 'unknown'",
  "blocks_critical_workflow": true | false,
  "critical_workflow_name": "string or null",
  "revenue_risk": "high" | "medium" | "low" | "none" | "unknown",
  "revenue_risk_rationale": "string explaining the revenue risk assessment",
  "churn_risk": "high" | "medium" | "low" | "none" | "unknown",
  "churn_risk_rationale": "string explaining the churn risk assessment",
  "confidence": "high" | "medium" | "low",
  "evidence_summary": "string citing specific details from the bug report or analytics that support the assessment",
  "missing_information": ["list of strings describing what additional data would improve this assessment"]
}

## CONSTRAINTS
- If [USER_ANALYTICS_CONTEXT] is empty or unavailable, set affected_user_segment, estimated_affected_user_count, revenue_risk, and churn_risk to 'unknown' and explain in evidence_summary that analytics data was not provided.
- Do not invent user counts, revenue figures, or segment names that are not present in the input.
- If the bug report describes a complete inability to use a core feature, blocks_critical_workflow must be true.
- If the bug report is too vague to determine impact, set impact_level to 'unknown' and list specific missing details in missing_information.
- Confidence must reflect how much evidence supports the assessment, not how severe the bug is.

## EXAMPLES
Example 1:
Bug Report: "Users on the enterprise plan cannot submit purchase orders. The Submit button does nothing. This started after today's deploy."
Analytics: "Enterprise plan: 340 active accounts, $2.1M MRR. Purchase order feature: 78% of enterprise accounts use weekly."
Output:
{
  "impact_level": "critical",
  "affected_user_segment": "Enterprise plan accounts",
  "estimated_affected_user_count": "340",
  "blocks_critical_workflow": true,
  "critical_workflow_name": "Purchase order submission",
  "revenue_risk": "high",
  "revenue_risk_rationale": "$2.1M MRR from enterprise segment; purchase orders are a core billing workflow used by 78% of these accounts weekly.",
  "churn_risk": "high",
  "churn_risk_rationale": "Enterprise accounts unable to complete billing workflows have high churn risk, especially if the issue persists beyond one business day.",
  "confidence": "high",
  "evidence_summary": "Bug report explicitly states enterprise plan and purchase order submission failure. Analytics confirm 340 accounts and high feature usage.",
  "missing_information": []
}

Example 2:
Bug Report: "The settings page looks weird sometimes."
Analytics: (empty)
Output:
{
  "impact_level": "unknown",
  "affected_user_segment": "unknown",
  "estimated_affected_user_count": "unknown",
  "blocks_critical_workflow": false,
  "critical_workflow_name": null,
  "revenue_risk": "unknown",
  "revenue_risk_rationale": "No analytics data provided and bug report lacks specificity about affected users or workflows.",
  "churn_risk": "unknown",
  "churn_risk_rationale": "Insufficient information to assess churn risk.",
  "confidence": "low",
  "evidence_summary": "Bug report is vague with no reproduction details, user segment information, or analytics context.",
  "missing_information": ["Which settings page is affected", "What 'looks weird' means specifically", "How many users reported this", "Browser or device details", "Whether any workflow is blocked"]
}

To adapt this template for your own triage pipeline, replace the [BUG_REPORT] placeholder with the raw text from your bug tracking system, support ticket, or user report. Replace [USER_ANALYTICS_CONTEXT] with structured data from your analytics platform—include active user counts per segment, feature adoption rates, and revenue attribution where available. If your analytics system provides this data programmatically, inject it as a pre-formatted JSON block rather than raw query results to keep the prompt focused. The output schema is designed to feed directly into a severity classification prompt or an escalation decision prompt, so keep the enum values consistent across your prompt chain. Before deploying, run this prompt against your golden dataset of historical bug reports where impact was manually assessed, and measure agreement between the model's impact_level and the historical label. Flag any case where the model assigns 'critical' but the historical label was 'low' for human review—these are the most expensive misclassifications in production.

This prompt is designed to sit inside a triage automation pipeline, not as a standalone chat interaction. The typical integration point is immediately after a bug report has been structured (via the Bug Report Ingestion prompt) but before severity classification and routing. The harness should call this prompt with the structured bug description and any available user analytics context, then use the output to influence downstream priority scoring and escalation decisions. Because the output directly affects customer-facing response SLAs, the harness must validate the response schema strictly and never pass an unvalidated impact level to downstream systems.

The implementation requires a schema-constrained API call with response_format set to JSON and a defined schema for the output. The expected output shape includes: impact_level (enum: critical, high, medium, low, unknown), affected_user_segment (string or null), revenue_risk (enum: immediate, potential, none, unknown), blocking_workflow (boolean), rationale (string), and confidence (float 0-1). Wrap the call in a retry loop with at least two attempts using exponential backoff. On the first failure, log the raw response and retry with a stricter instruction appended. On the second failure, default impact_level to unknown, set confidence to 0, and route the bug to a human review queue with the original prompt context attached. Never silently accept a malformed impact assessment.

For logging and observability, capture the prompt version, model ID, input context length, output schema compliance status, and the final impact_level value in your tracing system. If confidence falls below 0.7, flag the assessment for human review regardless of schema validity. When user analytics context is unavailable (common for B2B products without telemetry), the prompt should still produce an assessment based on the bug description alone, but the harness must mark the affected_user_segment field as unknown and reduce the weight of this assessment in automated routing decisions. Do not use this prompt's output as the sole trigger for customer-facing notifications or SLA penalty calculations without human confirmation when confidence is below 0.8 or the bug is classified as critical.