A customer support SLA is the speed promise your support team makes: when we will reply, and when we will fix the problem. Without a clear SLA, every agent works to their own rhythm. One ticket gets answered in minutes, another is forgotten for days, and the customer calls again, messages on WhatsApp again, and finally writes a complaint. This guide explains what an SLA means for tickets and chats, the difference between first response and resolution time, how to set priorities and business hours, how to design escalations, and ends with a sample policy you can start from today.
What a customer support SLA really is
An SLA (Service Level Agreement) started life as a contract between a company and its client. In day-to-day support it is a set of written time targets applied to every request that comes in: a support ticket, a complaint, a WhatsApp chat or an e-mail. The point is not to publish nice promises on your website. The point is that the system itself tracks time on every request, shows who is about to be late, and warns the right person before the customer gets upset.
A good SLA has four parts:
- Time targets: first response time and resolution time.
- Priorities: a full outage is not the same as a question about last month's invoice.
- Business hours: does the timer run around the clock or only during working hours?
- Escalation: when time runs out, who is told, when, and what they must do.
First response time vs resolution time
The most common mistake is writing "we reply within X" without defining what a reply is.
First response time
The time from the moment a request arrives until an agent sends the first real reply. An automatic "we received your request" is not a first response; it is an acknowledgement. A first response contains something useful: a clarifying question, a step towards the fix, or an expected time. It is what tells the customer that a person is on it.
Resolution time
The time until the problem is actually solved and the ticket closed. It depends on the issue: a data change may be done the same day, while a technical fault needing another team may take longer. That is why resolution targets are usually longer than first response targets and vary by priority.
Pausing the clock
If you asked the customer a question ("please send your order number") and they have not answered, it is not fair to count that time against your team. A sensible SLA policy pauses the timer while the status is "waiting on customer" and resumes it as soon as the customer replies.
Setting priorities
Start with four priorities and define each with examples from your own business:
- Urgent: the customer's service is completely down, or there is a financial or legal risk. For a delivery company, a high-value shipment is lost; for a clinic, a patient's booking for today was cancelled by mistake.
- High: the problem affects the customer's work but a workaround exists.
- Normal: a question, a change request or a minor issue.
- Low: a suggestion or a non-urgent information request.
Do not leave the priority to the agent's judgement every time. Define rules (request type, customer tier or channel), let the priority follow them, and let the supervisor adjust when needed.
Business hours and holidays
If your team works Sunday to Thursday during set hours, Cairo time, it makes sense for the SLA timer to count business hours only. A ticket that arrives on Thursday night should not look "late" on Friday morning.
- Define working hours per team (support may differ from sales).
- Set the weekly days off and public holidays.
- If urgent issues must be covered outside hours, give them a separate policy with longer hours and a clear on-call rota.
- State your working hours in the automatic acknowledgement so customers know what to expect.
Escalation steps that actually work
Escalation turns an SLA from a document into a working system. A simple ladder:
- Early warning to the assigned agent well before the deadline, so they can still make it.
- Alert to the team leader if the deadline passes without a reply or fix.
- Alert to a manager if the delay continues, or straight away for urgent tickets.
- Reassignment to an available agent if the owner is absent or on a break.
Make each step run once per ticket; alerts that repeat every few minutes get ignored. Show them in the in-app notification bell, not in a side chat group everyone has muted.
SLAs for chats: WhatsApp is not e-mail
Someone writing on WhatsApp expects a faster answer than someone sending an e-mail, so do not use one set of targets for every channel:
- Chats (WhatsApp, Messenger, Instagram, website chat): shorter first response targets, tracked in the shared inbox, which has SLA timers per conversation.
- E-mail: somewhat longer targets; convert to a ticket if the issue needs follow-up.
- Calls: the call is live, but if the issue is not solved on the call, open a ticket immediately so the SLA starts.
If a WhatsApp chatbot answers repeated questions, let it collect the basics (order number, issue type) before handing over, so the agent's first reply is useful straight away.
How to write an SLA policy: a sample
The table below is an illustration only, not market data or a fixed recommendation. Change the times to fit your team size and work, start with targets you can really meet, then tighten them gradually.
| Priority | Example request | First response (example) | Resolution (example) | Escalation |
|---|---|---|---|---|
| Urgent | Customer's service is down | Within one business hour | Within one business day | Team leader, then manager |
| High | Issue with a workaround | Within a few hours | Within two business days | Team leader |
| Normal | Question or data change | Within one business day | Within a few business days | Agent warning |
| Low | Suggestion or info request | Within two business days | As planned | None |
Next to the table, write down:
- Scope: which channels and which customers the policy covers.
- Business hours: days and times in Cairo time, plus holidays.
- Clock pauses: "waiting on customer", and "waiting on a third party" if you want.
- Ownership: agent, team leader, manager.
- Review: for example every quarter, based on reports.
Alerts and reports: measuring the SLA
An SLA you do not measure is just words. Track:
- Compliance with first response and resolution targets per priority and per team.
- Tickets at risk now: a live list of tickets past or near their deadline.
- Recurring causes of delay: a certain issue type, team or time of week.
- Satisfaction after resolution: pair the SLA with a CSAT survey to see whether speed matters to your customers.
In Klamna you build these reports yourself with the report builder on the tickets source, filter and group by priority or team, and schedule them by e-mail. For the wider set of numbers to watch, read our guide to call center KPIs.
Common SLA mistakes
- Promising more than the team can deliver: a very short target with a small team breaks in the first week.
- Counting "received" as a first response: the numbers look good while the customer is still waiting.
- Closing tickets early to improve resolution time, so customers reopen as new complaints.
- Escalations that repeat until everyone ignores them.
- One policy for every channel.
- No review: the policy is written once and forgotten.
Run your SLA in Klamna
The Klamna ticketing system has SLA policies tied to business hours, clock pauses, escalation steps that run once per ticket, and alerts in the notification bell. Tickets live inside the CRM, so the customer's calls and chats are on the same screen. If you are building a support team from scratch, start with our customer service software guide.
Sign up for a free trial, or build your package on the pricing page. If you want help writing your first SLA policy, talk to our team.