Support SLA in Practice: How to Set Deadlines You Can Actually Meet

Almost every company that serves customers has an SLA written down somewhere. "We reply within 24 hours." The number usually came out of a meeting, not from historical data, which is why it gets broken every week without anyone noticing.

An SLA isn't a marketing promise: it's an operational commitment, and it needs three things to exist. A deadline calibrated to what the team can already do, a clock that counts the right time and an alert that arrives before the breach. This article covers all three.

An SLA is three clocks, not one

The most common mistake is boiling everything down to a single number. In practice, customers judge service at different moments, and each one deserves its own deadline.

First response

This is the time between the customer's message and the first human or automated reply with real content. It's the most important clock, because it defines the perception of being abandoned. A quick reply saying "got it, I'm looking into it, I'll be back by 4 p.m." buys more patience than a solution that arrives silently six hours later.

Next response

This is the time between each new customer message and the team's reply, already inside the conversation. Almost nobody measures this one, and it's where service dies: the ticket gets a reply within ten minutes when it's opened and then disappears for two days along the way.

Resolution

This is the time until the problem is closed. It's the hardest to meet because it often depends on another area, a vendor or a fix that lands in a development queue. That's why it should never be the only deadline you track.

Calibrate from history, not from wishes

Before promising any number, measure what happens today. Take the last two or three months of support and answer: what was the average first response time? And the time of the slowest case?

Use the time that covers most cases, not the average. If half of tickets get an answer in five minutes and the other half in eight hours, the four-hour average describes no real customer. Look at the number that covers nine out of ten cases.

Then apply a reality discount. If today nine out of ten cases get a reply in four hours, don't promise two. Promise four, meet it for two months and only then tighten. An SLA that starts out too tight creates a perverse effect: the team learns to close tickets to stop the clock, and the metric improves while the customer gets worse service.

The clock must stop when the ball is in the customer's court

This is the difference between an SLA the team respects and one the team ignores. Half of all support cases stall waiting for something from the person who asked: the order number, a screenshot, confirmation that it's OK to restart the system.

If the resolution clock keeps running while the conversation waits on the customer, the indicator becomes fiction. The agent knows the deadline will be missed for a reason that isn't theirs, stops looking at the number and the SLA loses its function as an alert.

So the rule is simple: when a case enters a waiting-on-customer state, the resolution deadline freezes and starts again when they reply. The first response clock, on the other hand, never freezes: it's entirely the team's responsibility.

Deadlines by channel and by priority

An email and a WhatsApp message carry different expectations. People who write by email accept waiting a few hours; people who send a message expect minutes. Using the same deadline for both channels means being slow on one and needlessly strict on the other.

The same goes for priority. A system outage and a question about issuing a boleto (Brazilian bank slip) can't share the same deadline. Two or three tiers are enough:

Situation	First response	Resolution
Service down, impact on several customers	15 minutes	4 hours
Problem that stops one customer from working	1 hour	1 business day
Question, adjustment request, ordinary request	4 hours	3 business days

The numbers in the table are a starting point, not a recipe. What matters is the structure: few tiers, clear criteria for classifying cases and deadlines the team can defend in a meeting with the customer.

What to do when the deadline is breached

Every SLA gets breached now and then. What separates a mature operation from a mess is what happens in the minutes that follow.

1. Warn before, not after. A useful alert arrives while there's still time, at around 80% of the deadline consumed. An alert that fires together with the breach is just a record of failure.
2. Escalate to people, not to a queue. The alert has to reach a person with a name, usually the team supervisor. A notification sent to a whole group is a notification for nobody.
3. Separate what was breached because of the process. If the same type of ticket always breaches, the problem isn't the agent: that topic needs a different path, more people or a permanent fix.

When a ticket needs to become another area's work

A good share of support cases don't end in support. "The report shows the wrong value" becomes a product fix; "I need a new screen" becomes a project request. As long as that handoff happens by internal message, the customer is left without a forecast and support is left without an answer.

The healthy path is to turn the ticket into a task for the responsible team, keeping the link to the original case. Whoever handles support keeps seeing the progress and can give an update without asking in the hallway. This is the logic of keeping support and projects on the same base, instead of two systems that don't talk to each other.

Three mistakes that bring down any SLA

Measuring only the average. It hides exactly the cases that generate complaints. Also track the worst case of the week.

Promising 24 hours for everything. A single deadline treats urgency and simple questions the same way, and the customer with an urgent problem is the one who complains.

Leaving intake disorganized. A request that arrives half-complete consumes hours of back and forth before anyone actually works on it. An intake form with the right fields saves more SLA time than any dashboard.

Where to start this week

Pick one channel and one deadline: first response. Measure what happens today, define the number that covers nine out of ten cases and make it visible to whoever handles support. Only after that clock has been respected for two or three weeks should you add the resolution deadline.

Once the deadlines are in place, the reports by agent and by period stop being decoration and start answering practical questions: can we handle this volume with the current team? Which topic needs a permanent solution? And, if your support lives on WhatsApp, it's also worth reading how to organize support there without it turning into a mess.