<!-- Escalation policy · from Chapter 29 of The Product 360 Handbook -->

# Escalation policy · [Product or portfolio] · v[n] · [Date]

**Policy owner:** [Name]   **Approved by:** [Name]   **Last tested (tabletop):** [Date]

## When to escalate (any one trigger is enough)
- Customer-visible impact, including any customer action taken on a wrong AI output
- A second team is needed to resolve it
- Unresolved after [time] of concentrated work
- A proposed change to the plan of record (goal, date or resources)
- Budget or usage-cost variance above [threshold]
- Security, privacy or regulatory exposure
- An enterprise customer threatening churn
- A disagreement between owners unresolved after [time]

Escalating early is expected. Nobody is judged for escalating against a trigger.

## Levels
| Level | Who (role and name) | Response time | Can decide |
|---|---|---|---|
| 1 | [PM and engineering lead] | [time] | [scope] |
| 2 | [Group PM or director] | [time] | [scope] |
| 3 | [VP of Product, with peer VPs as needed] | [time] | [scope] |

## The escalation packet (one page, required)
1. What happened, and the impact, with evidence
2. What has already been done
3. Options (at least two), with tradeoffs
4. Recommendation
5. The specific ask, and by when

## Handoff
State explicitly who owns the issue now, and confirm acknowledgment in writing.

## Closure
- The Approver decides; everyone commits, including those who disagreed.
- The decision goes into the decision log; the risk register is updated.
- For customer-visible incidents, a correction-of-error narrative goes to the next monthly product review.
