What Is an SLA in Customer Support? Targets and Setup

What is an SLA in customer support?

An SLA, or service level agreement, is a stated commitment on how fast a support team responds to customers and resolves their issues. In a help desk it becomes a target on each ticket, with a timer that shows whether the team met it. Freshdesk's documentation puts the purpose simply: clear expectations for how quickly the team should respond and resolve.

Without one, "we answer quickly" means whatever each agent thinks it means, and a manager hears about a slow case when the customer complains.

The term covers two different things, so decide which one you are writing. A contractual SLA sits in an agreement with a customer and may carry consequences if you miss it, such as service credits. An internal SLA is a target your team sets for itself, and customers may never see the number. Most growing teams should begin with the internal kind, because you can adjust it freely while you learn what your team can sustain.

Before you put response times in a contract, ask a lawyer to review the wording, including what counts as a breach and what any penalty would be. Your obligations depend on the contract and on local law.

Which targets should a growing team set first?

Set a first response target and a resolution target for each priority level, and leave the rest until those two hold. Help desks offer more metrics than a small team can act on. Zendesk lists seven, including three separate ways to measure resolution, and advises choosing only one of those three.

These are the targets worth understanding, in the order most teams need them:

First response is the time from ticket creation to the first reply. Zendesk measures it to the first public comment from an agent. Write the same into your own rule, so an automatic "we received your message" does not count.
Resolution is the time from creation until the case is solved. A fast first reply says little if the case then sits open for a week, so report this one separately.
Next reply is the time to answer each later message from the customer. Add it once first response is steady, because this is where a case tends to go quiet after a good opening.
Periodic update is a set gap between agent updates. It suits long cases such as a delayed shipment, where the customer needs news even when you have no fix yet.

What first response and resolution times are reasonable?

A reasonable target is one your team already reaches on most tickets, tightened over time. No outside number can tell you what your staffing allows, and published figures vary widely.

JetBrains' YouTrack documentation shows a sample policy with a first reply in 1 hour and resolution in 1 day for urgent tickets, counted around the clock. Its other levels use business hours: high at 1 hour and 2 days, normal at 2 hours and 3 days, low at 3 hours and 7 days. IT Process Maps offers a much tighter example for IT incidents, running from an immediate response and 1 hour to resolve for critical cases, to 1 day and 1 week for very low ones. It says plainly that the table is only an example, and a small customer support team would struggle to staff those numbers.

The draft below is a starting point to adjust, not an industry standard. All times are working hours and working days:

Urgent: first reply in 1 hour, resolved in 1 working day. For example, customers cannot pay or place orders.
High: first reply in 2 hours, resolved in 2 working days. For example, a large delivery is stuck or a main function has stopped working for one customer.
Normal: first reply in 4 hours, resolved in 3 working days. For example, a wrong invoice or a product question that needs checking.
Low: first reply in 1 working day, resolved in 7 working days. For example, a change request or a how-to question.

How should you set ticket priorities?

Set priority with two questions: how much damage does this cause (impact), and how fast does that damage grow (urgency)? IT Process Maps defines impact as the extent of the problem and the potential damage, and urgency as how quickly a resolution is required. Crossing the two gives a priority. PagerDuty gives them equal weight and warns against working through issues in the order they arrive.

Three or four levels are enough for most teams. Zendesk and Freshdesk both use four named levels. Check your draft against your real staffing too: a 1-hour target needs someone watching the queue through all your working hours, including lunch, prayer breaks and shift changes.

A few rules keep the labels honest:

Write two or three examples from your own business under each level. "A van rep cannot print invoices" tells an agent more than "major issue".
Decide who sets priority. An agent or a rule should set it, and a customer's choice on a form is a suggestion.
Allow changes with a note, so a ticket can move up when a problem spreads and you can see who moved it.
Decide how large accounts are treated. A big customer can raise the impact of a case, but if everything from that customer is urgent, the label stops meaning anything.
Check the spread every month. If most tickets end up urgent, your definitions are too loose.

How does escalation work when a target is at risk?

Escalation moves a ticket to someone who can unblock it, and it should start before the deadline passes. There are two kinds. Functional escalation brings in a colleague with the right skills or permissions, such as accounts for a billing error. Hierarchical escalation raises the case to a higher level of authority, such as a supervisor who can approve a refund or press a supplier.

Some help desks separate the warning from the alert. In Freshdesk, reminders warn agents between 5 minutes and 4 hours before a breach, and escalations notify chosen people once a target is missed. PagerDuty's advice for top-priority issues is to define who responds and how quickly, then escalate if the issue is not resolved in that time.

A small team can run a simple ladder:

Before the deadline, the ticket owner gets a reminder early enough to act, such as 1 hour ahead on a 4-hour target.
At the deadline, the team lead gets an alert and decides whether to reassign the ticket, help with it or update the customer.
If an urgent ticket stays open well past its target, the manager or owner hears about it, and someone tells the customer what is happening and when the next update will come.
For billing or technical cases, name one person and one backup in each specialty, so escalations still land during leave and holidays.

When should the SLA clock run and when should it pause?

Run the clock during the hours you actually staff, and pause it only while you are waiting on the customer. Zendesk and Freshdesk both let you choose between business hours and calendar hours. In YouTrack's business-hours setup, goals count only during configured working days, hours and time zone, and a reply sent after hours carries over to the next working day.

Put your real working week into the calendar and add public holidays. If your hours change during Ramadan or Eid, enter that too. Teams that serve more than one country should check each holiday calendar. Then tell customers: an auto-reply that states your hours sets a fair expectation for the message that arrives at 10 at night. If you promise round-the-clock cover for urgent cases, someone has to be on call to keep that promise.

Pausing needs a tight rule, because a status that stops the clock can make the numbers look good while a customer waits. YouTrack's sample policy pauses timers when a ticket is Pending and resumes them when the customer replies. Zendesk's requester wait time also pauses in Pending but keeps counting in On-hold. That is a useful line to copy: waiting on the customer stops the clock, while waiting on your supplier or another department does not. Review a sample of paused tickets each month, and keep total time open somewhere in your reports.

How can a small team start with SLAs?

Start with one policy, one queue and a few weeks of real data. You can begin before you buy anything, though a spreadsheet stops working once someone has to read it line by line to find out what is overdue. When you compare help desks, check for targets per priority, business-hours calendars with holidays, pause rules, reminders and reports per priority.

These steps work in this order:

Bring requests into one place. If most arrive by WhatsApp, read how to answer from one number as a team first.
Give every ticket one owner, so each overdue case has a name on it.
Measure for two to four weeks with no targets, and record how long each priority really took.
Write a single page with your priority levels and examples, first response and resolution targets, working hours, pause rule and escalation names.
Set targets close to what you measured, even if they look modest. A target the team misses every day soon gets ignored.
Turn on reminders and escalation for urgent and high tickets first, then extend them once the alerts feel useful.
Review each week for the first month: the share of tickets that met each target per priority, every breached urgent ticket, and the reason behind each one.
Tighten targets every few months, and add a separate policy for a channel or customer group only when you need it. Freshdesk, for example, can apply policies by company, group or source.
Share targets with customers once you have held them for a few months.

How does Repzo handle this?

The help desk in Repzo Workstation has ticket queues with priorities and SLA timers, and its SLA policies set priority-based targets across seven metric types.

Tickets can come from web, email, chat, phone, social, portal and API sources. Work can be routed by priority, status, team and assignee. Workflows and SLA checks can escalate tickets, update assignments and alert the right teams, and automated reminders go out before an SLA breaks. Agents have canned replies, categories, tags and knowledge-base articles, and managers can track agent workload. An incident can be tracked against a root-cause problem ticket, which helps when one fault produces many tickets. The same system can run internal service desks with approval and escalation rules.

Conversations connect to this too. The omnichannel inbox enforces SLA policies on conversations and creates a ticket in one click. Fox AI, the assistant built into Workstation, drafts replies in the inbox and summarizes conversations and tickets. For review meetings, analytics and reporting covers ticket performance alongside the rest of your dashboards.

If your plan depends on a specific working-hours calendar or pause rule, ask our sales team to show it to you on your own setup before you decide.

Frequently asked questions

What is the difference between an SLA and a KPI?

An SLA sets a target on each ticket, such as a first reply within 2 hours. A KPI is a measure you watch across many tickets, such as the share of tickets that met their target this month. You can track SLA results as one of your KPIs.

What is a good first response time?

There is no single correct figure. JetBrains' sample policy ranges from 1 to 3 hours depending on priority, while IT incident examples go much lower. Start from what your team reaches today, then tighten it once you are meeting it reliably.

Do nights and weekends count toward an SLA?

Only if you choose that. Help desks such as Zendesk and Freshdesk let you count business hours or calendar hours. One pattern, used in YouTrack's sample policy, keeps urgent tickets on the 24-hour clock and everything else on business hours. Round-the-clock targets need someone on call.

What happens when an SLA is breached?

With an internal SLA, the ticket should escalate to a named person, the customer should get an update, and the case should go into your weekly review. With a contractual SLA, the contract sets the consequences, so check its wording and take legal advice if a dispute arises.

Should customers see our SLA targets?

Only after you have held them for a few months. Sharing your support hours and a first reply target is the safer place to begin, because some fixes depend on suppliers or other departments and you cannot always control how long they take.