sla-management

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