SLA Management

SLAs are structured along three dimensions. Tier Differentiation: SLAs vary by customer plan tier — enterprise accounts may have a 1-hour first response SLA while SMB plan accounts have a 4-business-hour SLA. Ticket Priority Differentiation: Critical (P1) tickets have aggressive business-hours or even 24×7 SLAs; Low (P4) tickets have multi-day targets. Metric Scope: most SLAs cover First Response Time (commitment to acknowledge the ticket) and Resolution Time (commitment to fully close the ticket). Some enterprise contracts also include Uptime SLAs (product availability, often 99.9% or 99.95%) with financial penalties (service credits) for breaches. Product Ops works with the Sales team to define standard plan SLAs that are operationally achievable, and drafts the contract language for enterprise-specific SLA customizations.

Real-time SLA monitoring prevents breaches through early warning, not post-hoc reporting. Key monitoring practices: an "SLA at risk" queue in the helpdesk surfacing tickets within 30 minutes of breach threshold, with a dedicated daily driver responsible for ensuring zero tickets cross the line; automated Slack alerts to the team lead when a ticket reaches 50% and 80% of its SLA timer; a live SLA dashboard (typically in Zendesk Explore or a connected BI tool) showing current-period compliance rates by channel, team, and priority level; and intraday volume monitoring to anticipate and prepare for backlog spikes before they become SLA breaches. The goal is a culture where a breach is an event that triggers a debrief, not a normal occurrence.

SLA breach management has an immediate response and a long-term improvement component. Immediate: when a ticket breaches SLA, the agent must proactively contact the customer before they notice — send a personalized update acknowledging the delay, explaining the reason briefly (without excessive blame), and providing a revised target time with high confidence. Never let a breached ticket sit silently. Long-term: every SLA breach should be logged with a root cause classification (volume spike, routing failure, insufficient staffing, complexity underestimate, missing knowledge). Monthly, Support Ops reviews the breach log to identify systemic causes — five breaches in the same category signal a process or staffing gap requiring structural intervention, not individual coaching.