SLA policies in customer support, explained

A service level agreement (SLA) is a promise about how fast you'll respond to and resolve requests. An SLA policy is how your helpdesk enforces that promise on each ticket. Most policies have the same parts:

• Conditions: which tickets the policy applies to, for example by customer, channel or request type
• Targets: time limits for the first reply, later replies and resolution, usually set per priority
• Hours: whether the clock counts business hours or calendar hours
• Pause rules: which statuses stop the clock
• Breach actions: reminders before a target is missed and escalations after

Order matters when you have several policies. Zendesk runs triggers first, then compares the ticket against its SLA policies from the top of the list down and applies the first one whose conditions are met. Put specific policies, such as one for enterprise customers, above general ones. Zendesk also requires the ticket's priority to be set in the default system priority field; a custom priority field won't match a policy.

Zendesk defines next reply time as the time between the oldest unanswered customer comment and the next public agent comment. It also offers a periodic update metric, which measures the time between public agent comments. For resolution, Zendesk has three metrics and recommends picking only one per policy: requester wait time (time in New, Open and On-hold), agent work time (time in New and Open) and total resolution time (the whole lifecycle from creation until the ticket is solved).

Freshdesk sets first response, every response and resolution targets per priority inside each SLA policy. In Jira Service Management, each SLA is a named timer: you define when it starts, pauses and stops, then add goals that use JQL to choose which requests they apply to, with time targets written like 4h 30m.

Business hours count only time inside your working schedule; calendar hours count every hour of every day. Zendesk lets you choose business or calendar hours for each priority within a policy. Freshdesk asks whether each SLA should use the business hours you've set or calendar hours (24x7). Jira Service Management attaches a calendar to each goal, with a time zone, working days and hours, and holidays.

A 4-hour business-hours target on a ticket created late on Friday may not come due until Monday. That's fair to your team, but it isn't what the customer experiences, so use calendar hours for any priority where you promise round-the-clock coverage.

Pausing is the other half. Time spent waiting on the customer usually shouldn't count against you, and each tool handles it differently:

• Zendesk: requester wait time pauses in Pending; agent work time pauses in Pending and On-hold; total resolution time doesn't pause on any status change until the ticket is solved.
• Freshdesk: the Pending status pauses SLA timers, and you can turn the SLA timer off for any status, including custom ones such as Waiting on Third Party. Tickets with the timer off show as On Hold, and when the customer replies the ticket moves back to Open and the clock resumes.
• Jira Service Management: an SLA can have pause conditions, for example while you're waiting for the customer to respond, alongside its start and stop conditions.

An SLA is only useful if someone acts before it's missed. Set a warning before the deadline and an escalation after it:

• Zendesk: build an automation with the condition Hours until next SLA breach to notify a team or person when a ticket is close to breaching. Automations run once an hour, so the alert can arrive up to an hour before or after the threshold, never at the exact moment. Zendesk's example adds a tag in the same automation so it fires only once per ticket.
• Freshdesk: each SLA policy can remind agents from 5 minutes to 4 hours before a first response or resolution target is due, and escalate when a target is violated to the assigned agent or other people you choose, such as a team lead. Both are set in Admin > Workflows > SLA Policies.
• Any tool: send breach alerts where your team actually looks, such as a Slack channel, and not only to email.

• Zendesk: create SLA policies with conditions and per-priority targets, choose business or calendar hours for each priority, and order the list so specific policies come first. Add an automation for near-breach alerts.
• Freshdesk: in Admin > Workflows > SLA Policies, set first response, every response and resolution targets per priority, choose business or calendar hours, then add reminders and escalations. Decide in your ticket status settings which statuses turn the SLA timer off.
• Jira Service Management: create each SLA with start, pause and stop conditions. Multiple start conditions work as OR, and the SLA stops as soon as any stop condition is met. Then add goals that select requests with JQL, set a time target and pick a calendar.

Whatever the tool, start with one policy and a few priorities, run it for a few weeks, then compare actual first reply and resolution times with the targets before tightening them.

TascaLab sets up SLA-related automation on top of Zendesk, Freshdesk and Jira: routing that sets priority so the right policy applies, breach alerts to Slack, and scheduled SLA reports. Relevant one-time prices are Ticket Routing & Categorization ($775), Automated Reports ($700) and Custom Automation (from $1,200). Projects include basic documentation, 30 days of post-launch support and no hidden fees, and most take 1–3 weeks. Start with a free 30-minute Health Check call.