Sla Management

---
name: sla-management
description: >-
  Design and manage customer support SLAs — service level agreements, ticket
  priority matrices, first response time targets, resolution time targets,
  escalation paths, business hours configuration, and SLA performance
  dashboards. Use when defining support SLAs, building tier-based service
  levels, designing escalation policies, or measuring SLA compliance.
  Triggers on: "SLA design", "support SLAs", "escalation path", "ticket
  priority matrix", "first response time", "SLA compliance".
license: MIT
compatibility: Claude Code, Codex, GitHub Copilot, Cursor, Gemini CLI, OpenCode, Goose, Hermes, Jesse, Windsurf, Zed
metadata:
  version: "1.0.0"
  author: LeadMagic
  category: customer-success
  tags: [sla, support, escalation, ticket-priority, first-response, resolution-time, service-level]
  related_skills: [support-tool-stack, cs-playbooks, headless-support, cs-analytics-dashboards, customer-onboarding]
  frameworks:
    - "ITIL 4 — Service Level Management practice"
    - "Zendesk — SLA Policy Design Guide"
    - "Intercom — SLA and Business Hours Configuration"
    - "HDI — Support Center Certification Standards"
---

# SLA Management

## Overview

SLAs are promises. Breaking them breaks trust. The mistake: setting SLAs based
on what sounds good ("we respond in 1 hour!") instead of what's operationally
sustainable. When the team misses the SLA 50% of the time, customers learn the
promise is empty. This skill covers SLA design by ticket priority, customer
tier, and channel — plus escalation paths, business hours configuration, and
the dashboard to track it all.

## Authoritative Foundations

- **ITIL 4 — Service Level Management practice** — Service Level Management practice
- **Zendesk — SLA Policy Design Guide** — SLA Policy Design Guide
- **Intercom — SLA and Business Hours Configuration** — SLA and Business Hours Configuration
- **HDI — Support Center Certification Standards** — Support Center Certification Standards

## When to Use

Trigger phrases: "design support SLAs", "set up SLA policies", "ticket priority
matrix", "escalation policy", "first response time target", "SLA compliance
dashboard", "support tiers by plan", "business hours setup", "after-hours
support", "ticket routing rules", "escalation path"

## Step-by-Step Process

### Phase 1: SLA Architecture

**Two types of SLAs (implement both):**

1. **First Response Time (FRT):** Time until a HUMAN acknowledges the ticket.
   Auto-replies DON'T count. "We're on it" = response. Auto-responder = not.

2. **Resolution Time:** Time until the issue is resolved. "Resolved" = customer
   confirms it's fixed, OR 72 hours of silence after proposed solution.

**Priority matrix (4-level standard):**

| Priority | Definition | Examples | FRT | Resolution |
|---|---|---|---|---|
| **P1 — Critical** | System down, security incident, data loss, revenue blocked | Can't log in, billing failed for all users, API down | 15 min | 2 hours |
| **P2 — High** | Major feature broken, workflow blocked, no workaround | Export failing, campaign can't send, integration down | 1 hour | 8 hours |
| **P3 — Normal** | Question, minor bug, configuration help, workaround exists | "How do I set up X?", report looks wrong | 4 hours | 24 hours |
| **P4 — Low** | Feature request, cosmetic bug, nice-to-have | "Add dark mode", typo on page | 8 hours | 5 days or "Deferred" |

**Criteria for P1 (be strict — P1 inflation kills credibility):**
- System-wide outage or critical path broken
- Security incident or data breach
- Revenue blocked (payments failing, subscription broken)
- Data loss or corruption
- >25% of customers affected

**Criteria for P2:**
- Major feature broken for multiple customers
- Workflow blocked with no workaround
- Integration critical path broken
- <25% of customers affected but impact is high

**Never P1:**
- One customer's feature request (even if they're your biggest)
- Cosmetic issues ("button is the wrong shade of blue")
- "This is urgent for me" (urgency ≠ impact — unless revenue is genuinely blocked)

### Phase 2: Tier-Based SLAs

**Service levels by plan (if you offer tiered support):**

| Plan | P1 FRT | P2 FRT | P3 FRT | Channels | Dedicated CSM |
|---|---|---|---|---|---|
| **Free** | Best-effort | Best-effort | 24 hours | Email, KB | No |
| **Starter** | 1 hour | 4 hours | 8 hours | Email, Chat | No |
| **Growth** | 30 min | 2 hours | 4 hours | Email, Chat, Phone | No |
| **Enterprise** | 15 min | 1 hour | 2 hours | All + Slack | Yes |

**Enterprise SLA add-ons:**
- Dedicated CSM with direct phone/Slack
- Uptime SLA (99.9% = ~43 min downtime/month)
- Proactive monitoring (you alert them, not vice versa)
- Quarterly business reviews included
- Incident post-mortems within 5 business days

**Uptime SLA (if you offer one):**
```
Uptime SLA: 99.9% (43 min downtime/month)
Credit: 5% of monthly bill per 30 min of downtime beyond SLA
Max credit: 100% of monthly bill
Exclusions: planned maintenance (announced 48 hrs), force majeure, customer-caused
```

### Phase 3: Escalation Paths

**3-tier escalation model:**

```
TIER 1: Support Agent (L1)
  Handles: P3, P4, common P2s with known solutions
  Tools: Macros, KB, basic troubleshooting
  Escalates to L2 when: Unknown cause, needs technical investigation, >30 min on ticket

TIER 2: Technical Specialist / Senior Agent (L2)
  Handles: Complex P2s, escalated P3s, initial P1 triage
  Tools: Logs, internal tools, product expertise, can file bug reports
  Escalates to L3 when: Bug confirmed (not config), needs engineering, security incident

TIER 3: Engineering / Security / Executive (L3)
  Handles: Confirmed bugs, security incidents, P1 outages, enterprise escalation
  Response: PagerDuty/Opsgenie on-call rotation
  SLA: Acknowledged within 5 min, initial fix/rollback within 30 min

DIRECTOR / VP ESCALATION:
  Customer contacts VP CS or CEO directly via LinkedIn/Twitter
  → VP acknowledges within 1 hour, assigns to L3, manages customer comms
```

**Escalation triggers (automated in help desk):**
- P1 ticket created → auto-page L3 on-call
- P2 ticket unresolved for 50% of SLA → auto-escalate to L2
- P3 ticket unresolved for 75% of SLA → auto-escalate to L2
- Customer replies with negative sentiment → auto-flag for manager review
- Enterprise customer + P2 or higher → auto-notify CSM

**Escalation communication template:**
```
Subject: [ESCALATED] Ticket #1234 — [Issue Summary]

This ticket has been escalated to [L2 / L3] due to:
- Time elapsed: X hours (SLA is Y hours)
- Complexity: requires [engineering / security / executive] involvement

Current status: [what's been tried, what's known, what's next]

Next update: within [timeframe]

[Link to incident channel / war room if active incident]
```

### Phase 4: Business Hours and Coverage

**Standard business hours:**
```
Primary: Monday-Friday, 9am-6pm [timezone]
Coverage: Monday-Friday, 6am-6pm [timezone] (staggered shifts)

After-hours: P1 only (on-call via PagerDuty)
Weekend: P1 only (on-call via PagerDuty)
Holidays: P1 only (rotating on-call, announced 2 weeks prior)
```

**What "business hours" means for SLAs:**
- FRT clock PAUSES outside business hours for P2-P4
- FRT clock NEVER pauses for P1 (24/7/365)
- Ticket submitted Friday 5:30pm P3 → clock starts Monday 9am
- Ticket submitted Friday 5:30pm P1 → clock starts immediately

**Global coverage (if 24/7 for P2+):**
```
Americas: 9am-6pm ET
EMEA: 9am-6pm CET
APAC: 9am-6pm SGT

Overlap: 2-hour handoff windows between regions
```

### Phase 5: SLA Performance Dashboard

**Track these 6 SLA metrics:**

| Metric | Target | Red Flag |
|---|---|---|
| P1 FRT Compliance | 100% | <95% — system failing |
| P2 FRT Compliance | 95% | <90% — staffing or process issue |
| P3 FRT Compliance | 90% | <85% — too many tickets per agent |
| P1 Resolution Compliance | 95% | <90% — escalation process broken |
| P2 Resolution Compliance | 90% | <80% — complexity or staffing gap |
| Overall SLA Compliance | 90% | <85% — systemic issue |

**Dashboard structure:**
```
SLA PERFORMANCE — [Month Year]

OVERALL: 92% SLA Compliance (↑3% MoM)

BY PRIORITY:
| Priority | Tickets | SLA Met | Compliance | Trend |
|---|---|---|---|---|
| P1 | 3 | 3 | 100% | — |
| P2 | 45 | 42 | 93% | ↑5pp |
| P3 | 320 | 291 | 91% | ↑2pp |
| P4 | 180 | 165 | 92% | ↑1pp |

BY AGENT:
| Agent | Tickets | SLA Met | Compliance |
|---|---|---|---|
| [name] | X | X | X% |

BREACH ANALYSIS (tickets that missed SLA):
- Top reason for breach: [understaffed on weekends / too many tickets / complexity]
- Action: [hire weekend coverage / add L2 capacity / document complex issues]
```

## Output Format

```
SLA POLICY — [Company]

Last Updated: [date]
Owner: [name, title]

PRIORITY MATRIX:
| Priority | Definition | Examples | FRT | Resolution |
|---|---|---|---|---|
| P1 | ... | ... | ... | ... |
...

TIER-BASED SLA:
[Table by plan tier]

ESCALATION PATHS:
L1 → L2 trigger: [criteria]
L2 → L3 trigger: [criteria]
Director/VP escalation: [when, how]

BUSINESS HOURS:
- Hours: [timezone, schedule]
- After-hours: P1 only (on-call via [PagerDuty/Opsgenie])
- Clock behavior: P2-P4 clock pauses outside hours. P1 clock never pauses.

SLA COMPLIANCE TARGETS:
- P1 FRT: 100%
- P2 FRT: 95%
- Overall: 90%

BREACH REMEDIATION:
- For customers: [communication, credit if applicable]
- Internal: [post-mortem, process fix, staffing adjustment]
```

## Implementation Checklist

- [ ] P1 definition is strict — system-down or revenue-blocked only
- [ ] FRT clock pauses for P2-P4 outside business hours (documented)
- [ ] P1 clock never pauses (24/7/365)
- [ ] Escalation triggers automated in help desk (not manual "hey can you look at this?")
- [ ] On-call rotation documented for L3 (PagerDuty/Opsgenie)
- [ ] Enterprise SLAs documented in contract/order form
- [ ] SLA dashboard live with weekly review cadence
- [ ] Breach analysis performed monthly (root cause + fix)
- [ ] Business hours and holiday schedule published for customers

## Quality Check

Before delivering, verify:

- [ ] Output matches the user's stated request
- [ ] Named frameworks or sources are reflected in the recommendation
- [ ] The deliverable is specific enough for an agent to execute
- [ ] Any assumptions, risks, or dependencies are explicit
- [ ] No unsupported claims, invented facts, or private/internal references are included

## Common Pitfalls

1. **Overpromising SLAs.** "We respond in 15 minutes to everyone" with a 2-person
   team = broken promise within 24 hours. Fix: Set SLAs your team can meet 95%+
   of the time. Underpromise, overdeliver.

2. **P1 inflation.** "The dashboard font is ugly" marked P1 by an enterprise
   customer. 6 months later, every ticket is P1 and the on-call team is burned
   out. Fix: Strict P1 criteria. CEO-approved before anyone overrides priority.

3. **No after-hours clock pause.** P3 ticket at 11pm Friday with "4-hour FRT"
   means SLA breach at 3am Saturday. Fix: P2-P4 clock pauses outside business
   hours. Communicate this clearly to customers.

4. **Auto-replies counting as FRT.** "We've received your request" is not a
   response. Customers know this. Fix: FRT = HUMAN acknowledges and begins
   working. Auto-responders are courtesy, not SLA compliance.

5. **No escalation automation.** Agent forgets to escalate at 50% SLA. Ticket
   sits for days. Customer escalates to CEO on Twitter. Fix: Automated
   escalation triggers in help desk. No human memory required.

6. **SLA breaches without follow-up.** A breached SLA without customer
   communication is a churn event. Fix: Auto-notify manager on breach.
   Template for customer communication. Post-mortem for root cause.

## Execution Artifacts

- `references/framework-notes.md` — Named frameworks and reference tables
- `templates/output-template.md` — Deliverable shell for agent output
- `scripts/check-output.py` — Lightweight deliverable validator

## Related Skills

- `support-tool-stack` — Intercom, Zendesk, Front, Help Scout setup
- `cs-playbooks` — Onboarding, health scoring, CSQLs, churn intervention
- `headless-support` — AI agents, KB, self-serve, ticket deflection
- `cs-analytics-dashboards` — CS metrics, NPS, CSAT, health scoring
- `customer-onboarding` — Structured onboarding, time-to-value