SLA Policy Matrix template.

What's inside — the exact file

This is the complete template, not a sample. The rows are worked examples — replace them with your data (and delete them before any platform import).

What this template is for

SLA policies fail in the design meeting, not in Zendesk — teams either copy another company's numbers or promise targets their staffing can't honor. This matrix lays out first-reply, next-reply, and resolution targets across all four priorities plus a VIP lane, so the negotiation happens on one page before anyone builds a policy.

The pre-filled numbers are deliberately conservative starting points, not benchmarks: edit them against your actual ticket volume and coverage hours. The structure — including the business-vs-calendar-hours column that most SLA arguments secretly hinge on — is the part to keep.

How to use it, step by step

1. Pull your current reality first. Before setting targets, measure current first-reply and resolution times by priority. A target with no baseline is a wish; Explore's SLA and reply-time dashboards give you the baseline.
2. Set targets you can hit on a bad week. Calibrate to realistic staffing, not best-case. An SLA you breach weekly trains everyone to ignore SLAs entirely — hitting 95% of a modest target beats hitting 60% of an aspirational one.
3. Decide business vs. calendar hours per priority. Urgent tickets usually deserve calendar-hours targets (customers don't stop being down at 5pm); low priorities run on business hours. This column is where support cost and customer expectation actually meet.
4. Define the VIP lane by criteria, not vibes. The applies_to column should name a concrete condition — an organization tag, a contract tier field — that a trigger can evaluate. 'Important customers' isn't implementable.
5. Write the breach escalation before the breach. Who gets notified at 75% of target, who at breach, and in what channel. An SLA without an escalation path is a report, not a policy.
6. Build it in Zendesk and verify with test tickets. Recreate the matrix in Admin Center's SLA policies, then run test tickets through each priority to confirm targets attach and clocks pause correctly on pending.

What each column means

Common mistakes to avoid

• Copying enterprise-SaaS SLA numbers into a 5-person support team — targets must reflect your coverage hours and volume, or they're theater.
• Setting only first-reply targets: customers judge the whole conversation, and next-reply is where slow support actually hides.
• Running urgent priorities on business hours — a Friday 6pm outage with a Monday clock is how you lose accounts.
• No escalation wiring, so breaches appear in monthly reports instead of in someone's notifications while there was still time to act.

Questions, answered

Which Zendesk plan do SLAs require?

SLA policies are available from Suite Growth/Professional tiers — as of July 2026, plan gating for the full SLA feature set sits at Suite Professional and up. Check current plan docs, or run our Zendesk Plan Finder for your specific setup.

Should internal teams get SLAs too?

Yes — internal service desks benefit from the same structure, usually with softer targets on business hours. The matrix works identically; only the numbers and escalation paths change.

What hit rate should we aim for?

Healthy teams run 90–95%+ achievement. Consistently at 100%? Targets are probably too soft. Below 85%, either staffing or the targets need to move — the matrix is where you renegotiate honestly.

This is a Market Disrupt worksheet, not a vendor file. Import-format templates follow each platform's documented layout as of July 2026 — platforms evolve, so validate against current documentation before a large import.