Customer Experience

Create Customer-Escalation Triage

Turn verified incident evidence and supplied severity rules into a reviewable customer-escalation level, reason, and ownership path.

Quick facts

Best for
Owners · Founder-operators
Prompt type
Quality
Expected result
An evidence-backed triage level and reason with explicit Unknowns, ownership, stop conditions, and a named-human approval checklist.
Time saved
20-30 minutes per escalation review
Required inputs
INCIDENT FACTS · CUSTOMER IMPACT · APPLICABLE POLICY · SEVERITY RULES · CURRENT OWNERSHIP · APPROVED RESOLUTION OPTIONS · ESCALATION OWNERS
Works with
ChatGPT + Claude

What this prompt does

  • Maps supplied incident facts and customer impact to the exact severity criteria the business provided.
  • Keeps unsupported classifications Unknown and prepares a named-owner escalation recommendation for human review.

When to use

  • When a customer issue needs consistent severity triage before a support or operations owner decides the response path.

When not to use

  • Do not use it to issue compensation, admit fault, select an unapproved exception, contact a customer, route a live ticket, or change a support record.
  • Do not place unauthorized support data or unnecessary personal, sensitive, or confidential data in an AI system.

The prompt

#CONTEXT:
Create a review-only customer-escalation triage assessment. Use only the supplied incident evidence, policy, severity rules, ownership, and approved options. The output is decision support, not authorization to act.

#INPUTS:
- Verified incident facts with evidence references: [INCIDENT FACTS]
- Customer-reported and independently verified impact: [CUSTOMER IMPACT]
- Current applicable policy with source and effective date: [APPLICABLE POLICY]
- Approved severity levels, criteria, and stop conditions: [SEVERITY RULES]
- Current ticket, account, and operational ownership facts: [CURRENT OWNERSHIP]
- Resolution options already approved for consideration: [APPROVED RESOLUTION OPTIONS]
- Named escalation owners and their documented authority: [ESCALATION OWNERS]

#INSTRUCTIONS:
1. Separate verified facts, customer-reported statements, conflicts, and Unknown items. Cite the supplied evidence for every verified fact.
2. Do not invent, infer, or fabricate policy, eligibility, customer facts, outcomes, severity rules, owner authority, fault, or liability.
3. Compare the evidence with each supplied severity rule. Recommend a triage level only when an exact rule is satisfied; otherwise mark the level Unknown and identify the missing evidence.
4. Explain the triage reason using the matched rule and evidence. Do not treat a customer's frustration, tone, identity, or unsupported claim as proof of severity or fault.
5. Identify the named owner whose supplied authority covers the recommended path. If ownership conflicts or is missing, preserve the conflict and recommend human reconciliation.
6. List only supplied approved resolution options as context. Do not choose, issue, promise, or imply a refund, credit, compensation, retention offer, discount, exception, or outcome.
7. Recommend internal next-review questions, evidence to collect, and a proposed escalation path. Do not route, assign, close, resolve, or update a live ticket, system, account, or record.
8. Use only authorized support data and authorized customer data in an approved AI workspace or approved AI vendor. Minimize the data and redact or omit unnecessary personal, sensitive, or confidential data. Follow company retention and vendor policy.
9. Do not send, publish, contact, notify, or deliver any external communication. A named human owner must approve every external communication, sending action, and customer contact before action.
10. A named human owner must approve every refund, credit, or compensation decision before action. A named human owner and legal counsel must approve every admission of fault or liability before action. A named human owner must approve every retention offer, discount, or policy exception before action. A named human owner must approve every ticket, system, account, or record change or mutation before action.

#RESPONSE FORMAT:
## Evidence, conflicts, and Unknowns
| Item | Status | Supplied evidence | Conflict or missing evidence |
|---|---|---|---|

## Recommended triage level and reason
- Level: [SUPPLIED LEVEL OR UNKNOWN]
- Matched rule: [EXACT RULE OR UNKNOWN]
- Evidence-based reason
- Confidence and evidence limits

## Ownership and escalation recommendation
| Proposed review step | Named owner | Supplied authority | Stop condition |
|---|---|---|---|

## Human approval checklist
- Severity and evidence verified
- Ownership authority verified
- Customer communication separately approved
- Any refund, credit, compensation, admission, offer, exception, or live change separately approved

Input checklist

  • INCIDENT FACTS
  • CUSTOMER IMPACT
  • APPLICABLE POLICY
  • SEVERITY RULES
  • CURRENT OWNERSHIP
  • APPROVED RESOLUTION OPTIONS
  • ESCALATION OWNERS

Example input

Fictional example — INCIDENT FACTS: Juniper Facilities ticket JS-104 says a scheduled onboarding session did not start; calendar log shows the host link failed at 10:02 ET. CUSTOMER IMPACT: Customer reports six staff members waited 25 minutes; attendance count is not independently verified. APPLICABLE POLICY: Support policy v3, effective July 1, 2026. SEVERITY RULES: Level 2 when a scheduled delivery is blocked for one customer with no safety or data exposure; Level 1 requires safety, security, or multi-customer impact. CURRENT OWNERSHIP: Support owns intake; Operations owns delivery incidents. APPROVED RESOLUTION OPTIONS: Manager follow-up and rescheduling review; no credit approved. ESCALATION OWNERS: Omar, Operations Director, owns Level 2 delivery reviews.

Expected output structure

  • An evidence-backed triage level and reason with explicit Unknowns, ownership, stop conditions, and a named-human approval checklist.

Customize this prompt

  • Replace generic severity labels with your current, versioned incident rubric.
  • Add regulated escalation triggers only after the responsible professional approves the exact language.

Guardrails

  • Do not invent, infer, or fabricate policy, eligibility, customer facts, outcomes, severity rules, authority, fault, or liability; unsupported items remain Unknown and conflicts remain unresolved.
  • A named human owner must approve every refund, credit, or compensation decision before action.
  • A named human owner and legal counsel must approve every admission of fault or liability before action.
  • A named human owner must approve every retention offer, discount, or policy exception before action.
  • A named human owner must approve every external communication, sending action, or customer contact before action.
  • A named human owner must approve every ticket, system, account, or record change or mutation before action.
  • A named human owner must approve every payment or financial decision before action.
  • A named human owner must approve every deletion, closure, suspension, termination, revocation, deactivation, or archive action before action.
  • A named human owner must approve every promise or commitment before action.
  • Use only authorized support data and authorized customer data in an approved AI workspace or approved AI vendor; minimize data, redact or omit unnecessary personal, sensitive, or confidential data, and follow company retention and vendor policy.
  • The assistant must provide triage decision support only and must not take a customer, financial, legal, ticket, or system action.

NEXT STEP

Next step

Get practical AI workflows in your inbox.