Revenue Impact Priority Estimation Prompt

This prompt is for business operations and support platform engineers who need to estimate the financial consequence of not addressing a specific issue, request, or incident. The job-to-be-done is translating an unstructured description of a problem into a structured, auditable revenue-at-risk estimate that can drive priority tier assignment, queue ordering, and escalation decisions. The ideal user is someone building or operating a triage system where priority must be grounded in commercial impact, not just technical severity or customer sentiment. Required context includes the issue description, account or customer metadata (such as ARR, contract value, or usage tier), and any known time-sensitivity markers. Without account-level financial context, the model will speculate, and the output becomes unreliable for real resource allocation decisions.

Do not use this prompt when the issue has no plausible revenue impact, when the system lacks access to account financial data, or when the priority decision is purely operational (e.g., a server is down and must be fixed regardless of revenue modeling). This prompt is also inappropriate for real-time incident response where seconds matter and a structured estimation step adds unacceptable latency. It is designed for triage queues, backlog grooming, and escalation review workflows where a 30-second estimation delay is acceptable in exchange for a documented, defensible priority rationale. If you need a simple P0-P4 severity score without revenue grounding, use the Support Ticket Priority Scoring Prompt instead.

The output includes a revenue-at-risk estimate with explicit assumptions, a confidence band, and a recommended priority tier. This structure forces the model to show its work rather than producing a single unjustified number. Before deploying this prompt into production, you must wire it to a source of truth for account financials—either a CRM lookup, a contract database, or a customer tier service. Without that grounding, the model will hallucinate revenue figures, and the priority decisions will be worse than useless because they will appear data-driven while being fabricated. The evaluation criteria in the full playbook include checks for hallucinated account data, missing assumption documentation, and confidence band calibration against actual revenue outcomes.

This prompt template is designed to produce a structured revenue-at-risk estimate for a given business issue. It forces the model to ground its analysis in provided account data, state its assumptions explicitly, and deliver a confidence band rather than a single speculative number. The output is intended to feed a priority scoring or escalation workflow, not to serve as a final financial forecast.

textCopy
You are a revenue impact analyst. Your task is to estimate the revenue consequence of not addressing the issue described in [INPUT].

You must base your estimate on the account data provided in [CONTEXT]. Do not invent revenue figures, contract values, or customer counts. If the provided data is insufficient to produce a grounded estimate, state that clearly and explain what additional data would be required.

Your output must conform to the following JSON schema:
[OUTPUT_SCHEMA]

Follow these constraints:
[CONSTRAINTS]

Use the following examples to calibrate your estimation approach:
[EXAMPLES]

If available, you may use the following tools to retrieve or validate data:
[TOOLS]

This task carries a [RISK_LEVEL] risk level. If the risk level is HIGH or CRITICAL, you must flag the output for human review and include a reviewer-ready evidence trail.

To adapt this template, replace each square-bracket placeholder with concrete content. For [OUTPUT_SCHEMA], provide a strict JSON schema that includes fields for revenue_at_risk, confidence_band_lower, confidence_band_upper, assumptions, data_gaps, and recommended_priority_tier. For [CONSTRAINTS], include rules such as 'Do not extrapolate beyond 90 days' or 'Use only named accounts from the provided CRM extract.' For [EXAMPLES], supply at least two worked examples showing correct estimation from sample account data. Before deploying, validate the output against a golden dataset of known revenue impacts and implement a retry or escalation path for outputs that fail schema validation or exceed acceptable confidence intervals.

The Revenue Impact Priority Estimation Prompt is designed to be called as a deterministic step within a broader triage or prioritization pipeline, not as a standalone chatbot interaction. The prompt expects structured input fields—account data, issue description, and business context—and returns a JSON object containing a revenue-at-risk estimate, assumptions, a confidence band, and a recommended priority tier. To integrate this into an application, you should build a harness that pre-fetches the required account data from your CRM or billing system, populates the [ACCOUNT_DATA] placeholder with real values, and validates the model's output against a defined schema before the priority score enters any queue or SLA engine.

The implementation should enforce a strict validation layer immediately after the model response. Parse the output JSON and confirm that the revenue_at_risk field is a numeric range with a lower and upper bound, that confidence_level is one of the allowed enum values (e.g., low, medium, high), and that the priority_tier maps to your internal tier definitions. If validation fails, implement a single retry by feeding the validation error message back into the prompt as additional [CONSTRAINTS] context. After one retry, if the output still fails validation, log the failure and route the item to a human review queue rather than silently defaulting to a generic priority. This prevents malformed estimates from corrupting downstream SLA calculations or resource allocation decisions.

For high-stakes workflows where revenue estimates directly influence executive escalation or contract penalties, add a human approval gate for any estimate where the confidence_level is low or the revenue_at_risk upper bound exceeds a configurable threshold. The harness should compare the model's output against a lookup table of known account values (e.g., monthly recurring revenue, contract value) to flag discrepancies. If the model's estimate deviates from known account data by more than a set percentage, suppress the automated priority assignment and escalate for manual review. This grounding check prevents the model from hallucinating revenue figures when account data is available but the model ignored it.

Model choice matters for this prompt. Use a model with strong structured output capabilities and low hallucination rates on numerical estimation tasks. GPT-4o or Claude 3.5 Sonnet are suitable defaults. Avoid smaller or older models that may conflate the revenue_at_risk field with generic sentiment or produce unparseable JSON. If you are routing this prompt through a model gateway, configure the route to prefer models with proven JSON mode reliability. Do not use this prompt with models that lack function-calling or structured output support, as the schema adherence requirement is non-negotiable for downstream automation.

Log every invocation with the input snapshot, raw model response, validation result, and final priority assignment. This audit trail is essential for debugging priority drift, calibrating confidence estimates against actual revenue outcomes, and demonstrating compliance during internal reviews. Store the assumptions array from the model output alongside the estimate so that future analysts can understand what the model believed when it produced the score. Without this logging, revenue-impact estimates become opaque and unactionable over time.