Build a support escalation decision tree

## Role

You are an escalation architecture specialist designing decision trees that remove subjective judgment from high-pressure support situations. Your system must enable first-day hires to make correct escalation decisions 90% of the time without managerial intervention.

## Context

Support teams face two critical failures: premature escalations that waste senior resources, and delayed escalations that cause churn. Agents under ticket volume pressure abandon complex frameworks and make inconsistent calls. Existing guidelines fail because they rely on subjective interpretation and assume experience agents lack. You need binary decision logic that works when clarity matters more than experience.

Business context: {{business-context}}

## Task

Generate a complete escalation decision tree for {{issue-types}} that guides agents through step-by-step logic to determine whether to resolve at current tier, escalate, or route to specialized workflows within {{support-tier-structure}}.

Before building, consider:
- What measurable trigger conditions indicate escalation necessity?
- What diagnostic questions eliminate ambiguity?
- What handoff protocols prevent customers from feeling abandoned?
- What resolution attempts must be exhausted before escalation is justified?

Build specific decision paths for each issue type—not generic categories.

## Output

For each issue type, provide:

**1. Initial Diagnostic Sequence**  
Binary YES/NO questions to categorize severity and scope with no subjective interpretation required.

**2. Tier-Appropriate Resolution Attempts**  
Specific fixes with measurable success/failure criteria.

**3. Escalation Trigger Conditions**  
Objective, measurable criteria that mandate escalation using quantifiable thresholds: dollar amounts, time elapsed, attempt counts, system status indicators.

**4. Handoff Protocol**  
Exact information format, required data points (ticket ID, account age, previous attempts, error messages), and destination team within the support tier structure.

**5. Customer Communication Script**  
What agents tell customers during handoff to maintain trust.

**Tree Construction Rules:**
- Maximum 4 decision points before reaching resolution or escalation
- Every branch ends in clear action: resolve, escalate to a specific tier, or route to a named team
- No dead ends
- Use indented text format for visual scanning under pressure

**Example tree structure:**

```
ISSUE TYPE: Payment Failure
│
├─ STEP 1: Has customer attempted payment 3+ times in past 24 hours?
│  ├─ YES → Is transaction amount over $500?
│  │  ├─ YES → ESCALATE TO: Tier 2 Payments
│  │  └─ NO → Attempt standard retry protocol
│  └─ NO → Guide through single retry with cleared cache
│
└─ ESCALATION TRIGGER: 3+ failed attempts OR amount >$500 OR payment gateway error code 5xx
   → ESCALATE TO: Tier 2 Payments Team
   → REQUIRED INFO: Transaction IDs, error codes, payment method type, account age
   → TELL CUSTOMER: "I'm connecting you with our payments specialist who can access detailed transaction logs. They'll reach out within 2 hours with a resolution."
```

**Escalation Cheat Sheet**

After all decision trees, create a one-page quick-reference table with the top 5 most common escalation scenarios:

| Trigger Condition | Destination | Required Info | Customer Message |
|-------------------|-------------|---------------|------------------|
| 3+ contacts on same issue in 7 days | Tier 2 General | Ticket IDs, timeline | "Connecting you with a senior specialist who will own this to resolution." |
| Transaction amount exceeds $1,000 | Payments Team | Transaction ID, amount, method | "Transferring to payments specialist for high-value transaction review." |
| System shows conflicting account data | Technical Escalation | Screenshots, account ID, error messages | "Our technical team will investigate the data inconsistency within 4 hours." |
| Customer explicitly requests manager | Tier 2 or Team Lead | Full interaction history, customer tone notes | "I'm connecting you with my team lead who can review your full account history." |
| Outage affects 10+ customers | Incident Response Team | Affected feature, user count, start time | "Our incident team is actively working on this. You'll receive updates every 30 minutes." |

Format this table for agents to reference in seconds during live interactions.

**Enforce these criteria:**

1. **Eliminate subjective language** – Replace "use judgment," "if serious," "customer seems unhappy" with measurable binary criteria (e.g., "Has customer contacted us 3+ times about this issue? YES/NO").

2. **4-decision-point maximum** – Agents under pressure abandon long paths.

3. **Measurable or binary triggers only** – Use quantifiable thresholds or YES/NO questions.

4. **Exact handoff requirements** – Specify system/method and data points.

5. **Customer-facing language** – Include what agents say so customers don't feel transferred into a void.

6. **Edge case routing** – Account for "customer refuses solution" or "system shows conflicting data."

7. **Avoid escalation bottlenecks** – Distribute based on issue type across the support tier structure.

8. **Include de-escalation paths** – Show when initially flagged issues can resolve at current tier after diagnostics.

9. **Make cheat sheet genuinely quick** – Top 5 triggers only, one-line descriptions, no paragraphs.