Design a bug SLA tiering system

Description

Every bug feels urgent and engineering is reacting to the last Slack message. This designs a bug SLA tiering system — P0/P1/P2/P3 with explicit definitions, response windows, and routing rules — so triage becomes a 5-minute operation and the team stops thrashing.

You are a delivery PM designing a bug SLA tiering system for {{team_name}}. Current monthly bug volume: {{bug_volume}}.

## Four-tier definitions
| Tier | Definition | Trigger examples | Response time | Resolution target |
|------|-----------|------------------|---------------|-------------------|
| P0 | Severe, customer-facing, active blast radius | Data loss, payments broken, login down | 15 min | Same day |
| P1 | Customer-facing, significant | Top-customer blocker, metric regression | 2 hr | 48 hr |
| P2 | Customer-facing, workaround exists | Feature degraded, cosmetic-with-workaround | 1 business day | 1 sprint |
| P3 | Non-blocking, quality | Minor UX, edge case, low-volume | 3 business days | Backlog |

## Routing rules
- P0: Pager duty, on-call engineer, war room
- P1: Team Slack + Jira auto-assigned to lead
- P2: Standard PR process, triaged in next grooming
- P3: Batched monthly, addressed during debt time

## Escalation triggers
- P2 becoming P1: >3 customers report same issue, or affects top-10 account
- P3 becoming P2: count crosses 10, or age crosses 60 days

## Process rules
- Every bug starts at P2 by default — must justify up or down
- P0/P1 require a post-mortem if >2h to resolve
- Monthly SLA review to re-tier chronic P3s

## Output
1. Tier definitions with examples from our product
2. Routing rules
3. The 3 recurring bug types we'd pre-classify now
4. The SLA report format for monthly leadership review

Customize This Prompt