What Is an SLA in Customer Support? Examples and How to Set One Up
What an SLA is in customer support, the three targets to set, a ready-to-use example by priority and how to apply and track SLAs in Hodhod.
In this article
"We'll get back to you soon" isn't a promise a customer can hold you to. A service level agreement, or SLA, is. It turns "soon" into a number: a reply within an hour, a fix within a day.
This guide explains what an SLA covers in customer support, how to choose realistic targets and how to apply and track them in Hodhod.
What is an SLA in customer support?
A service level agreement is a commitment about how quickly your team will respond to customer requests and resolve them. It can be a formal promise written into a contract (common with business customers) or an internal standard that you simply hold yourselves to.
Either way, a good SLA has three parts: what you measure, the target, and the situations it applies to.
The three targets most SLAs use
| Target | The question it answers | In Hodhod |
|---|---|---|
| First response time | How soon does a person reply to the first message? | "First Response Time" |
| Next response time | After each customer message, how soon is the next reply? | "Next Response Time" |
| Resolution time | How long until the issue is fully solved? | "Resolution Time" |
You enter each one as a number with a unit: minutes, hours or days. Turn on "Only during business hours" and the clock only runs during the hours you've set for the inbox, so the night doesn't count against you.
A ready-to-use example
Different requests deserve different promises. One simple approach is a policy per priority:
| Priority | First response | Next response | Resolution | Typical request |
|---|---|---|---|---|
| Urgent | 15 minutes | 30 minutes | 4 hours | Payment taken but order failed, account locked |
| High | 1 hour | 2 hours | 8 hours | Delivery problem, something broken for one customer |
| Medium | 4 hours | 8 hours | 2 days | How-to questions, order changes |
| Low | 8 hours | 1 day | 5 days | Feedback, feature requests |
These numbers are only a starting point, counted in business hours. Begin with what your team can really deliver today, hit it consistently for a month, and only then tighten it.
Who gets which promise?
Decide which requests fall under which policy. Common rules:
- By priority: urgent and high requests get the tightest targets.
- By customer: paying or VIP customers get a faster policy than free users.
- By topic: a payment problem is always more urgent than a product question.
- By channel: website chat usually needs faster replies than email-style follow-ups.
How to set up SLAs in Hodhod
- Create the policies. Go to Settings → SLA and add a policy: a name and description, the three targets and, if you want, "Only during business hours".
- Apply them automatically. Under Settings → Automation, add a rule whose action is "Add SLA". Choose the conditions that decide who gets it (for example, priority is Urgent, or a label such as "vip" is present) and pick the policy. A second rule using "Change Priority" can set the priority itself, for instance from a label like "payment-issue".
- Watch the timers. Conversations with an SLA show its status, and in the Tickets list a colored SLA badge marks the ones that are active, hit or missed.
- Review the results. Reports → SLA shows the hit rate, the number of misses and the conversations behind them, with the policy and agent for each.
Keeping SLAs honest
- Set internal targets tighter than what you promise customers. A promise of one hour with an internal goal of 45 minutes leaves room for a busy moment.
- Review misses, not just the rate. Look at the conversations that missed their deadline and ask what they had in common: a shift, a topic, a missing canned reply.
- Match staffing to the promise. An urgent target of 15 minutes needs someone watching the queue. The "Unanswered conversations" and "Agent workload" reports from 10 customer support KPIs show whether that's realistic.
- Update the SLA when the business changes. New channels, new hours or a new product line usually mean new numbers.
Writing your SLA for customers
If you share your SLA publicly, keep the wording simple and measurable:
We reply to every message within 1 working hour and aim to resolve most requests within 1 working day. Urgent issues such as payment problems are handled within 15 minutes during business hours (Monday to Friday, 9:00–18:00).
Avoid promises you can't track, and say clearly which hours count. Customers care less about the exact number than about knowing what to expect.
Common mistakes
- Promising too much, too early. Missing a promise is worse than making a longer one.
- One SLA for everything. A how-to question and a payment failure shouldn't share a deadline.
- Creating SLAs nobody applies. If conversations don't get the policy automatically, most will go untracked.
- Treating the SLA as the goal. Customers remember how they were helped, not that you answered at minute 59. Read SLA results next to CSAT.
To apply and track SLAs on your own team, request a free demo. Handling requests that need days? See ticketing with priorities and SLAs.
Frequently asked questions
What's the difference between an SLA and a response-time goal?
A goal is something you aim for; an SLA is something you've committed to, to customers or to the rest of the business, and measure. Many teams set goals first and promote them to SLAs once they hit them consistently.
Does my team need to work around the clock to use SLAs?
No. With "Only during business hours", deadlines count only during the hours set in the inbox's business-hours settings, so an SLA doesn't punish you for the night.
Do SLAs work for Telegram conversations too?
Yes. SLA policies are applied to conversations, so you can apply them to any inbox, including Telegram, with the conditions of your automation rule.
