Business Criticality Assessment Prompt for Requests

This prompt is designed for enterprise platform teams that need to classify incoming requests by business criticality before routing them to the correct queue, team, or SLA tier. The core job-to-be-done is mapping a request to a business function from your service catalog, determining whether that function is revenue-generating, compliance-mandated, or internal-only, and producing a criticality tier with a revenue-at-risk estimate. The ideal user is a platform engineer or product manager building an internal triage system where the cost of misrouting a checkout-flow outage to a low-priority queue is measured in dollars per minute.

Use this prompt when your triage system must distinguish between a customer-facing transaction failure and an internal wiki request, and when downstream routing logic depends on that distinction. It requires a well-defined service catalog as context, including business function names, revenue impact classifications, and compliance obligations. Do not use this prompt for operational severity scoring—deciding whether a P1 incident is a SEV1 or SEV2 based on technical symptoms like error rates or latency. Pair it with an incident severity classification prompt when both business impact and technical severity dimensions are needed for a complete routing decision.

Before implementing, ensure your service catalog is stable enough to serve as grounding evidence. If business functions change weekly, the prompt's output will drift and misroute requests. Also avoid using this prompt for real-time incident response where seconds matter; the model inference latency, even when optimized, is better suited for asynchronous triage of tickets, forms, or queued requests. Start by running a batch of 50 historical requests through the prompt and manually reviewing the criticality tier assignments against your expected outcomes to calibrate your eval thresholds.

The following prompt template is designed to be copied directly into your AI orchestration layer. It instructs the model to act as a business operations analyst, evaluating a request against a provided service catalog to determine its criticality tier. The prompt uses square-bracket placeholders for all dynamic inputs, ensuring a clean separation between the static instruction set and the live data injected at runtime. Before using this template, you must have a defined service catalog with business functions mapped to criticality levels and, optionally, revenue data to ground the financial estimates.

textCopy
You are a business operations analyst for a large enterprise. Your task is to assess the business criticality of an incoming request by mapping it to the company's service catalog and estimating the potential revenue impact.

**Request Details:**
[REQUEST_BODY]

**Service Catalog:**
[SERVICE_CATALOG]

**Instructions:**
1.  **Identify the Business Function:** Analyze the request to determine which business function from the service catalog is primarily affected.
2.  **Map to Criticality Tier:** Based on the identified function, assign a criticality tier using the definitions in the service catalog (e.g., Tier-0: Revenue-Generating, Tier-1: Compliance-Mandated, Tier-2: Internal Operations, Tier-3: Non-Critical).
3.  **Estimate Revenue-at-Risk:** If the function is revenue-generating, provide a structured estimate of the revenue at risk. Use the [REVENUE_DATA] to ground your estimate. If no revenue data is provided, state your assumptions clearly.
4.  **Provide Justification:** For every decision, cite the specific line item from the service catalog or the piece of evidence from the request that supports your conclusion.

**Output Format:**
Respond with a single, valid JSON object conforming to this exact schema. Do not include any text outside the JSON object.
{
  "criticality_tier": "string",
  "affected_business_function": "string",
  "justification": "string",
  "revenue_at_risk_estimate": {
    "amount": "number | null",
    "currency": "string | null",
    "time_period": "string | null",
    "assumptions": "string"
  },
  "confidence_score": "number (0.0 to 1.0)"
}

**Constraints:**
- Do not guess the business function. If the request is ambiguous, set the `confidence_score` below 0.5 and state the ambiguity in the `justification`.
- If the request does not map to any function in the catalog, set the `criticality_tier` to "Uncategorized" and the `confidence_score` to 0.0.
- The `revenue_at_risk_estimate.amount` must be a number, not a string. Use `null` if not applicable.
- Base all financial estimates strictly on the provided [REVENUE_DATA]. If no data is provided, you must state "No revenue data provided" in the `assumptions` field.

To adapt this template for your production environment, start by replacing the [SERVICE_CATALOG] placeholder with a structured representation of your actual business functions. This could be a JSON object, a markdown table, or a list of key-value pairs. The criticality tier definitions (Tier-0, Tier-1, etc.) inside the prompt should be updated to match your organization's internal taxonomy. The [REVENUE_DATA] placeholder is optional but crucial for grounding the financial estimate; it should contain relevant account ARR, contract value, or transaction volume data. If you cannot provide this data at runtime, you should modify the assumptions constraint to enforce a disclaimer, preventing the model from hallucinating financial figures. Finally, integrate a post-processing validation step in your application code to verify the JSON schema and check that the confidence_score is a valid float, as this is a common point of failure.

This prompt is designed to sit behind an internal API or request intake form, not in a customer-facing chat window. The primary integration point is a classification middleware that receives a user-submitted request and a service catalog snapshot, calls the LLM, and then uses the structured output to route the request to the correct queue, assign an SLA tier, and optionally flag it for human review. The prompt expects two inputs: [REQUEST_TEXT] (the raw user request) and [SERVICE_CATALOG] (a JSON or markdown list of business functions with their criticality tiers, revenue linkage, and compliance tags). Without a well-maintained service catalog, the model will guess at business function mappings, and the revenue-at-risk estimates will be unreliable.

Validation and retry logic is essential before the output touches any downstream system. The prompt instructs the model to return a JSON object with a criticality_tier (one of revenue_generating, compliance_mandated, internal_only), a business_function mapped to the catalog, and a revenue_at_risk_estimate with a confidence band. Your harness must validate that: (1) the criticality_tier is in the allowed enum, (2) the business_function exists in the provided catalog, (3) the revenue_at_risk_estimate includes both a low and high value and that low <= high, and (4) the confidence field is a float between 0 and 1. If validation fails, retry once with the error message appended to the prompt as [PREVIOUS_ERROR]. If the retry also fails, route the request to a human triage queue with the raw input and both failed attempts attached. Do not silently default to internal_only—a misclassified revenue-generating request costs real money.

Model choice and latency matter here. This is a synchronous classification step that gates downstream routing, so aim for a fast, cost-efficient model that follows JSON schema instructions reliably (e.g., GPT-4o-mini, Claude 3.5 Haiku, or a fine-tuned open-weight model if you have sufficient labeled data). If your service catalog is large (100+ entries), consider using a retrieval step before the prompt: embed the user request, retrieve the top 5 most relevant catalog entries, and include only those in [SERVICE_CATALOG] to keep context small and latency low. Log every classification result—including the model, latency, input tokens, output tokens, validation status, and final criticality tier—to a structured logging table. This log becomes your audit trail and your dataset for future fine-tuning or eval calibration.

Human review gates should be configured based on confidence thresholds and revenue exposure. If the model returns confidence < 0.8 or the revenue_at_risk_estimate.high exceeds a configurable dollar threshold (e.g., $50,000), route the request to a review queue before committing to an SLA tier. The review interface should show the original request, the model's classification, the matched catalog entry, and a one-click override. Track override rates by business function to identify catalog entries that need clearer descriptions or model retraining. Finally, run the eval harness described in the testing section weekly against a golden dataset of 100+ labeled requests to detect drift in classification accuracy before it affects production routing.