What is SLA: a guide to support deadlines.

An SLA is the time commitment a team makes to the people who depend on it. "We respond within 1 hour and resolve within 1 business day" is an SLA. The name stands for Service Level Agreement, and it shows up in IT contracts, call centers, building maintenance and any operation that receives requests and needs to return an answer.

This guide explains the concept from start to finish: what goes into an SLA, how to define your first one, how to measure it and what to do when the deadline is missed. If you already know the concept and want the day-to-day routine of calibrating deadlines, the post SLAs in customer service, in practice complements this text.

What an SLA is

An SLA answers three questions: what is being promised, in how much time, and how it will be measured. An agreement that doesn't say how it will be measured is just an intention. "Fast service" is not an SLA. "First response within 2 business hours, measured from the moment the ticket is opened to the first message from an agent" is.

An SLA can exist between the company and the customer, in which case it becomes a clause in a contract or proposal. It can also exist between two areas of the same company, such as support and the development team, in which case it's an internal agreement. In both cases, the function is the same: turning expectation into a number you can check.

SLA, SLO and SLI without overdoing it

Three acronyms show up together, and it's worth knowing the difference without turning it into bureaucracy.

• SLI (service level indicator): what you measure. Example: the time between ticket opening and first response.
• SLO (service level objective): the internal target for the indicator. Example: 90% of tickets with a first response within 1 hour.
• SLA (service level agreement): the formal commitment to the customer, normally backed by an SLO and with a consequence if it isn't met, such as a discount or a plan review.

In a small company, it's common to use the word SLA for everything, and there's no problem with that. What matters is having a clear indicator, a defined target and someone watching the number. The distinction gains weight when the company starts having contracts with penalties: then it makes sense for the SLA with the customer to be looser than the internal objective, to leave a safety margin.

First response time and resolution time

A customer service SLA almost always has two clocks, and mixing them up is the cheapest mistake to avoid.

First response time

The interval between the customer asking and the company giving its first substantive reply. It measures attention: the customer knows they were seen. An automatic reply like "we received your message" normally doesn't count, because it says nothing about the problem. What counts is a reply from a person, or from an AI agent, that acknowledges the request and states the next step.

Resolution time

The interval until the request is closed. It measures effectiveness. It's the hardest deadline to meet, because it often depends on another area, a supplier or a fix that goes into the development queue. That's why the resolution deadline is always longer, and many companies define it by priority, not by type of issue.

There's also a useful third deadline: the next response, the time between each new customer message and the team's reply. It prevents the ticket that gets answered quickly at opening and then sits idle for days.

Business hours or 24×7

The first decision in the agreement is when the clock runs. There are two models.

Business hours. The deadline only counts during service days and hours, for example Monday to Friday, 8 a.m. to 6 p.m. A ticket opened on Friday at 5 p.m. with a 4-business-hour deadline expires on Monday at 11 a.m. This is the model for most small and medium companies, because it fits the team's schedule.

24×7. The deadline runs all the time, including at night, on weekends and on holidays. It makes sense for critical services, such as a payment system or an electronic security operation with monitoring. It requires on-call duty, schedules and cost, and so it usually applies only to the highest priority tier.

The mixed model is the most realistic: critical priority 24×7, everything else in business hours. The text of the agreement needs to state which days, which hours, the time zone and how holidays are handled. A customer who writes at 11 p.m. and reads "response within 1 hour" understands what's written, not what you meant.

Priorities and the deadline matrix

A single deadline for everything treats a system outage and a billing question the same way. The priority matrix solves this: each ticket gets a tier, and each tier has its own deadlines. Two to four tiers are enough. More than that, and the team wastes time arguing about which tier a ticket belongs in.

Priority usually comes from crossing two criteria: impact (how many people or how much of the business stops) and urgency (how much the problem gets worse over time). An example matrix, for a support company in business hours:

The numbers are an example, not a recommendation. What you copy from the table is the structure: a clear classification criterion, deadlines that shrink as severity grows, and a rule for who decides the tier. Having the person handling the ticket decide on the spot keeps every customer from asking for "urgent."

Deadline by channel

The channel also changes expectations. Someone who sends an email accepts waiting a few hours. Someone who sends a WhatsApp message expects minutes. A single deadline for both leaves the team slow on one channel and too strict on the other. A section on WhatsApp comes later.

How to define a small company's first SLA

A small company doesn't need a ten-page document. It needs a number the team can meet and the customer can understand. The path below fits in a week.

1. Choose one channel and one deadline. Start with the channel where most requests come in and the first response deadline. It's what the customer feels most and what's easiest to measure.
2. Measure what happens today. Take the last few weeks of service and calculate how long each first response took. If there's no record, write it down for two weeks, even in a spreadsheet.
3. Look at the common case, not the average. Sort the times and find the value that covers nine out of ten cases. The average misleads: if half of the replies go out in 5 minutes and the other half in 8 hours, the four-hour average describes no real customer.
4. Promise a little less than the history. If today nine out of ten cases get a reply within 4 hours, promise 4. Meet it for two months and only then tighten it. An SLA that's too tight teaches the team to close tickets just to stop the clock.
5. Write it in one sentence. "First response within 4 business hours, Monday to Friday, 8 a.m. to 6 p.m." No adjectives, with a unit and a schedule.
6. Make the deadline visible to the people handling tickets. A deadline that lives in a contract and not on the agent's screen isn't met, it's remembered afterward.
7. Only then add the resolution deadline. Once the first response has been stable for two or three weeks, add resolution and then the priority matrix.

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

A good share of tickets stall waiting for something from the person who asked: an order number, a screenshot, confirmation that they can restart the equipment. If the resolution clock keeps running during that wait, the indicator measures the customer's delay, not the team's. The agent notices, stops looking at the number and the SLA loses its function as an alert.

The rule is simple. When the ticket goes into a waiting-for-customer state, the resolution deadline freezes and resumes when they reply. The first response deadline doesn't freeze: it's entirely the team's responsibility. Write this rule into the agreement, so nobody discovers the pause only when arguing over a breach.

Measurement and reporting

An SLA without measurement turns into opinion. The minimum tracking fits in four numbers.

• Percentage met: of all tickets in the period, how many stayed within the deadline, per clock (first response and resolution).
• Worst case: the ticket that went furthest past its deadline. The average hides exactly the cases that generate complaints.
• Volume by priority: if everything comes in as critical, the matrix isn't working.
• Breaches by cause: lack of people, an issue that depends on another area, a poorly described request. Without the cause, the number leads to no decision.

A one-page monthly report is enough: the percentage met, the worst case, the three topics that breached the most and one decision for the following month. The reports by agent and by period help answer whether the volume fits the current team and which topic calls for a permanent fix instead of more effort.

A percentage target, not 100%

Promising 100% compliance is promising what nobody delivers. Prefer targets like "95% of tickets within the deadline in the month." That makes it clear that an occasional breach is expected and that the trend is what matters.

Internal SLA and customer SLA

The two coexist and don't need to have the same number.

The customer SLA is what's in the contract or proposal. It should be a deadline the company meets with room to spare, because it's what triggers a discount or a loss of trust.

The internal SLA is the agreement between areas: support hands the ticket to development, and development commits to giving an update within a set number of hours. It's shorter than the customer's deadline, to leave room to maneuver. If the customer has 1 business day for resolution, the internal team works with 6 business hours for analysis and the rest for the fix and delivery.

When the request leaves customer service and becomes another team's work, ideally the link to the original ticket is kept. The person handling it follows the progress without asking in the hallway and can give the customer an update. That's why it makes a difference to have support and projects in the same system, and not in two systems that don't talk to each other.

What to do when the deadline is missed

Every SLA is missed from time to time. What separates an organized operation from a mess is what happens in the minutes that follow.

1. Warn before the breach. A useful warning arrives while there's still time, for example when 80% of the deadline has been used. An alert that fires at the same time as the deadline is just a record.
2. Escalate to a person. The warning must go to someone with a name, normally the team supervisor. A notification sent to a whole group is nobody's notification.
3. Talk to the customer before they ask. A short message with the reason and a new estimate is worth more than a solution that arrives silently.
4. Record the cause. Every breach needs a cause: lack of capacity, external dependency, poorly described request, wrong priority.
5. Look for the pattern. If the same topic always breaches, the problem isn't the agent. That type of request needs a different path, more people or a permanent fix.
6. Apply the agreed consequence. If the contract provides for a discount or credit, apply it without waiting for the customer to ask.

Common mistakes when building an SLA

• Promising 24 hours for everything. A single deadline treats urgency and questions the same way, and the customer with an urgent problem is the one who complains.
• Copying another company's SLA. The deadline must come from your team's history, not from a competitor.
• Measuring only the average. It hides the serious cases. Also track the worst case of the week.
• Letting the clock run while waiting for the customer. It distorts the measurement and demotivates the team.
• Counting an automatic reply as the first response. The metric improves and the customer is still left without an answer.
• Closing a ticket to stop the clock. It happens when the deadline is too tight. The number improves and satisfaction drops.
• Forgetting the intake. A request that arrives half-described burns hours of back and forth before anyone works on it. An intake form with the right fields saves more SLA time than any dashboard.
• Not reviewing. The team grows, the product changes, the channel changes. Review deadlines every quarter.

SLAs on WhatsApp

WhatsApp brought a new expectation: people who write there want a reply in minutes, not hours. That calls for three precautions.

Define service hours. The message arrives at any time, but the team doesn't answer at any time. An automatic message outside business hours, saying when they'll get a reply, avoids the feeling of being abandoned.

Treat the conversation as customer service, not a chat. If the conversation sits loose on one person's phone, there's no deadline, no queue and no report. Each conversation needs an assignee, a status and a deadline. The post WhatsApp for support without the mess covers this organization.

Use shorter deadlines than email. For the same topic, the first response on WhatsApp is usually a matter of minutes, while on email it can be hours. Define a deadline per channel and measure them separately.

A WhatsApp conversation that requires work from another area, such as a fix or a quote, should become a ticket or task, keeping the link to the original conversation. That way the customer keeps a single point of contact, and the team works with a deadline and an assignee.

Who needs an SLA

Any operation that receives requests and returns answers benefits from a deadline agreement, even an informal one. Some Brazilian examples:

• A managed IT company that serves several clients on monthly contracts and needs to prove it met what was agreed.
• An electronic security company that handles maintenance tickets for cameras and alarms, with a visit deadline by priority.
• A condominium management company that receives requests from residents and needs to respond and resolve on time.
• An HR or finance team that serves other departments internally and wants predictability without fights.

In every case the format is the same: ticket, priority, deadline, measurement. What changes are the numbers and the level of formality.

Before buying a tool

You can start with a spreadsheet and a written agreement. When the volume grows, the spreadsheet loses: the deadline doesn't show on the agent's screen, the warning depends on someone remembering and the report becomes manual work. That's when to use a ticketing system. If the question is between a free tool and a paid one, the post free ticketing system: is it worth it? compares the scenarios.

How to do it in Tasskee

Tasskee handles SLAs in two places, depending on the size of the operation.

Tickets. In /chamados there's a dedicated queue, dedicated statuses, deadlines and SLAs, and a public intake form so customers can submit requests without an account. The deadline travels with the ticket, and whatever needs another area becomes a project task. Tickets and forms are part of the Pro plan.

Customer Service. In /atendimento, the per-channel add-on brings together official WhatsApp, WhatsApp via QR Code and email, with an AI agent and conversations that turn into tickets or tasks. The SLA has three deadlines, per channel: first response, next response and resolution, with a default policy and another for a priority channel. The conversation badge shows how much time is left, warns when the deadline is getting close and, if it expires, the alert reaches the team supervisors. While the ticket is waiting on the customer, the resolution clock stops, and only a human reply counts as a response. There's a compliance report by channel, team and agent, and a satisfaction survey (CSAT) at the end of the conversation.

Customer Service is purchased together with Pro or Max, with a 14-day trial on any plan. Pricing is at /precos.