Escalation Fatigue Analysis Prompt for Review Queues

This prompt is designed for operations leads and trust and safety engineers who are responsible for the health of human review queues fed by automated guardrail systems. Its primary job is to analyze a structured dataset of escalated items—each containing a reviewer outcome, a timestamp, and the originating detection rule—and produce a fatigue risk assessment. You should use this prompt when you observe symptoms of reviewer overload: declining throughput, a rising backlog, or an alert-to-action ratio that has fallen below an acceptable threshold. It is a diagnostic and planning tool, not a real-time operations console. The output is meant to justify engineering work, such as tuning detection thresholds, deprecating noisy rules, or requesting additional headcount, by connecting raw queue data to business impact.

The prompt assumes you already have a clean, structured dataset exported from your review queue system. Required fields for each record include escalation_id, detection_rule, escalation_timestamp, reviewer_outcome (e.g., actioned, dismissed), and review_duration_seconds. The analysis will segment this data by time window and rule, calculate fatigue indicators like the ratio of dismissed to actioned alerts, and identify specific rules that generate high-volume, low-value work. It will then produce a concrete set of recommendations for threshold adjustments, rule deprecation, or routing changes. Do not use this prompt for real-time violation detection, individual case adjudication, or any workflow where a decision must be made on a single live escalation. It is a batch analysis tool for operational improvement.

Before running this prompt, ensure your dataset is complete and representative. A partial export that omits dismissed alerts will produce a dangerously optimistic assessment. After receiving the output, treat the recommended threshold changes as hypotheses to be tested in a staging environment or with a shadow review queue before deployment. The next step is to take the identified low-value rules and the suggested threshold adjustments into your detection engineering workflow. Avoid the temptation to use this analysis to set hard service-level agreements (SLAs) for reviewers without considering the qualitative context of why certain alerts are dismissed; the data shows correlation, not necessarily root cause.

This prompt template is designed to be the core analytical engine for an Escalation Fatigue Analysis workflow. It ingests structured escalation data and applies your organization's specific policies to produce a standardized risk assessment. The output is intended to be consumed by an operations lead or an automated dashboard, not an end-user, so it prioritizes structured data and actionable recommendations over conversational prose. Before using this template, you must have a dataset of escalation records that includes timestamps, outcomes, and severity classifications.

textCopy
You are an escalation quality analyst. Your task is to analyze the provided escalation data and produce a fatigue risk assessment based on the policies defined below.

[POLICIES]
- Low-Value Escalation Definition: [DEFINE_WHAT_CONSTITUTES_A_LOW_VALUE_ESCALATION, e.g., 'Any escalation that was dismissed by a human reviewer in under 60 seconds or was classified as NO_ACTION_TAKEN']
- Fatigue Risk Thresholds:
  - High Risk: [DEFINE_HIGH_RISK_CONDITION, e.g., '>20% week-over-week increase in total volume AND >15% low-value rate']
  - Medium Risk: [DEFINE_MEDIUM_RISK_CONDITION, e.g., '>10% week-over-week increase in total volume OR >10% low-value rate']
  - Low Risk: [DEFINE_LOW_RISK_CONDITION, e.g., 'All other conditions']
- Optimization Goal: [DEFINE_OPTIMIZATION_GOAL, e.g., 'Reduce low-value escalations by 20% without increasing the miss rate for true positives']

[INPUT_DATA]
```json
[INSERT_JSON_ARRAY_OF_ESCALATION_RECORDS_HERE]

[OUTPUT_SCHEMA] Produce a single JSON object with the following structure. Do not include any text outside the JSON object. { "assessment_timestamp": "string (ISO 8601)", "analysis_window": { "start": "string (ISO 8601)", "end": "string (ISO 8601)" }, "volume_trends": { "total_escalations": "integer", "week_over_week_change_pct": "float", "trend_direction": "string (INCREASING | DECREASING | STABLE)" }, "low_value_analysis": { "low_value_count": "integer", "low_value_rate_pct": "float", "top_3_low_value_patterns": ["string", "string", "string"] }, "fatigue_risk_assessment": { "risk_level": "string (HIGH | MEDIUM | LOW)", "contributing_factors": ["string"], "rationale": "string" }, "threshold_optimization_recommendations": [ { "current_threshold": "string", "proposed_adjustment": "string", "expected_impact": "string", "risk_of_change": "string" } ] }

[CONSTRAINTS]

• Base all analysis strictly on the [INPUT_DATA] provided.
• If the data is insufficient to calculate a metric, use null for the value and state the reason in the rationale.
• Recommendations must be specific and actionable, referencing the policies in [POLICIES].
• Do not invent data or trends not present in the input.

To adapt this template, start by replacing the placeholders in the [POLICIES] section with your organization's specific definitions. The [DEFINE_WHAT_CONSTITUTES_A_LOW_VALUE_ESCALATION] placeholder is the most critical, as it directly shapes the low_value_analysis and the resulting risk level. The [INPUT_DATA] placeholder expects a JSON array of objects, where each object should represent a single escalation event with fields like timestamp, outcome, and severity. Ensure your application code serializes this data correctly before inserting it into the prompt. The [OUTPUT_SCHEMA] is rigid; your downstream application should validate the model's response against this exact JSON structure and trigger a retry or a human fallback if parsing fails, as a malformed output in this context could obscure a critical fatigue risk.

This prompt is designed to operate as a scheduled batch analysis job rather than a real-time call. Wire it into a cron or workflow orchestrator that runs daily or weekly against your review queue database. The prompt expects aggregated alert data—volume counts, severity distributions, reviewer action rates, and timestamps—so the application layer must pre-compute these statistics from your ticketing system, SIEM, or internal review tool before calling the model. Do not stream raw individual alerts into the prompt; the model is analyzing patterns, not adjudicating single cases. The output is a structured fatigue risk assessment, which your application should store as a time-series record for trend comparison over weeks.

Build a validation wrapper around the model call that checks the JSON output against a strict schema before accepting it. Required fields include fatigue_risk_score (0-100), low_value_escalation_patterns (array of objects with pattern name and count), and threshold_recommendations (array of objects with current threshold, proposed threshold, and justification). If the model returns malformed JSON, missing fields, or values outside expected ranges, retry once with a repair prompt that includes the schema and the raw output. After two failures, log the incident and alert the operations team—do not silently accept a partial analysis. For high-severity findings (risk score above 70), route the output to a human reviewer before publishing recommendations to the broader team.

Model choice matters here. Use a model with strong reasoning capabilities and a large context window, such as Claude 3.5 Sonnet or GPT-4o, because the prompt processes aggregated statistics and must synthesize patterns across multiple dimensions. Avoid small or quantized models that may struggle with the structured output contract or produce shallow pattern analysis. If you are running this in a regulated environment, ensure that the model call and its output are logged immutably for audit purposes. Never feed raw PII from individual alerts into the prompt—aggregate and anonymize at the application layer. The next step after implementing this harness is to build an eval suite that compares the prompt's fatigue assessments against actual reviewer burnout surveys or turnover data to calibrate the risk score over time.