What an SLA actually is
An SLA, or service level agreement, is a commitment about how quickly your support team will respond to and resolve a customer request. It sounds simple. In practice, most SLA policies fail for one reason: someone picked a number that sounded good in a sales conversation, and nobody checked whether the team could actually hit it.
Key takeaways
- An SLA is a commitment about how fast your team responds to and resolves a support request, not just a number on a slide.
- Response time and resolution time are different metrics, and mixing them up is the most common SLA mistake teams make.
- The teams that hit their SLAs consistently set targets from real historical data, not from what sounds good in a sales deck.
An SLA has two halves, and confusing them is the single most common mistake. Response time is how long it takes for a human to acknowledge a ticket. Resolution time is how long it takes to actually close it. A ticket can get a reply in five minutes and still take three days to resolve. Both numbers matter, and good SLA management means tracking them separately instead of blending them into one vague promise.
An SLA is also not the same as a KPI. A KPI is something you track to understand performance. An SLA is a promise, often a contractual one, with consequences attached when it is missed. That distinction matters most at renewal time, when an enterprise customer pulls up the contract and checks whether your team held to it.
The metrics that make up a good SLA policy
Most SLA policies fall apart because they use one target for every request, regardless of how urgent it actually is. A password reset and a production outage are not the same problem, and treating them the same means either your urgent tickets wait too long or your easy tickets get more attention than they need.
Priority tiers
The fix is to tier requests by severity and set a different response and resolution target for each tier. A typical structure looks like this.
| Priority | Example | Response target | Resolution target |
|---|---|---|---|
| P1, Critical | Service is down for a customer | 15 minutes | 4 hours |
| P2, High | A core feature is broken | 1 hour | 1 business day |
| P3, Normal | A question or a minor bug | 4 business hours | 3 business days |
| P4, Low | A feature request or general question | 1 business day | Best effort |
Business hours vs. around the clock
Decide upfront whether your targets run on business hours or 24/7 coverage, and say so explicitly in the policy. A four hour resolution target means something very different for a customer who files a ticket at 4pm on a Friday if your SLA clock pauses over the weekend versus keeps running. Enterprise customers will ask this question directly, so have the answer ready before they do.
Why SLA management matters more as you grow
A five-person support team can run on instinct. Everyone knows every open ticket, and urgent problems naturally get attention first. That stops working long before you reach fifty tickets a week.
Enterprise deals often require it
Once you are selling to mid-market and enterprise buyers, an SLA stops being a nice-to-have and becomes a line item in the contract. Procurement teams ask for it during the sales process, and legal will hold you to it after signature. Missing a contractual SLA is not just a bad week, it is a risk to the renewal.
Breaches compound if nobody sees them coming
Without a system tracking SLA status in real time, the first sign of a breach is often the customer escalating, or worse, quietly not renewing. A ticket that is two hours from breaching should look different in a queue than one that just came in. Managers need to see the at-risk list before it becomes the missed list.
It gives you a real answer to how support is doing
Response time, resolution time, and SLA compliance rate together give leadership an honest picture of support performance, not a vibe. That answer matters at board meetings and quarterly reviews just as much as it matters to the agent working the queue.
How to set SLA targets you can actually hit
The point of an SLA is not to sound impressive. It is to make a promise your team can keep every single time, because a policy you hit 60% of the time is worse than no policy at all.
- Start from your real historical data, not a guess. Pull the last three months of first-response and resolution times before you set a single target. If your current average resolution time is nine hours, promising four hours on day one is a plan to break your own SLA.
- Build in a buffer, not a stretch goal. A target you hit 95% of the time under normal load is a real SLA. A target you hit only when nothing goes wrong is a liability.
- Tier by customer plan, not just severity. Enterprise accounts on a premium plan often expect faster targets than a starter-tier customer for the same issue. Most help desks let you layer a customer-tier SLA on top of a priority-tier SLA.
- Set the escalation path before you need it. Decide who gets notified when a ticket is most of the way to breach, not just when it actually breaches. By the time a ticket has missed its SLA, the chance to fix it quietly is gone.
- Review the targets quarterly. Team size changes, ticket volume changes, and a target that was realistic in January can be unrealistic by June. Treat the policy as a living document, not something you set once and forget.
Getting SLA management running in your help desk
You do not need a perfect policy on day one. You need one that is honest about what your team can currently deliver, backed by a system that flags problems before they become breaches.
- Pull three months of ticket data. Look at actual first-response and resolution times, broken down by whatever priority levels you already use informally.
- Set two to four priority tiers. More than four gets confusing for agents to apply consistently. Start simple.
- Write the targets down and publish them internally, even before you show them to customers. Your team should know the rules before anyone is held to them.
- Turn on real-time tracking and escalation alerts. A ticket approaching breach should surface automatically, not depend on someone remembering to check.
- Review compliance monthly for the first quarter. Adjust targets that are consistently missed instead of leaving a broken promise in place.
WeldDesk tracks SLA status on every ticket in real time and flags tickets before they breach, not after. It connects to WeldFlow so a breach risk can automatically create a task or notify a manager, and to WeldAgent so routine first responses go out immediately even when the queue is heavy. WeldDesk is included in the WeldSuite complete software suite at $28 per seat per month, and enterprise plans are themselves backed by a 99.999% uptime SLA.
Sources
- Wikipedia: Service-level agreement https://en.wikipedia.org/wiki/Service-level_agreement
- Wikipedia: ITIL https://en.wikipedia.org/wiki/ITIL
Frequently asked questions
What is an SLA in customer support?
An SLA, or service level agreement, is a commitment about how quickly a support team will respond to and resolve a customer request. It usually sets separate targets for response time and resolution time, often tiered by how urgent the request is.
What is the difference between response time and resolution time?
Response time is how long it takes for a human to acknowledge a ticket. Resolution time is how long it takes to actually close it. A ticket can get a fast reply and still take days to resolve, which is why a good SLA policy tracks both separately.
How do you set SLA targets for different customer tiers?
Most help desks let you layer a customer-tier SLA on top of a priority-tier SLA, so an enterprise account on a premium plan gets a faster target than a standard customer for the same severity of issue.
What should happen when an SLA is breached?
The ticket should escalate automatically, usually to a manager or a senior agent, and the breach should be logged so the team can see whether it was a one-off or part of a pattern. The more useful moment to catch is actually before the breach, when a ticket is close to missing its target.
Do mid-market and enterprise companies need a formal SLA policy?
Yes. Once you are selling to mid-market and enterprise buyers, an SLA is often a contractual requirement written into the deal, and procurement teams will ask about it during the sales process rather than after signature.
See it all work together
WeldSuite brings CRM, helpdesk, accounting, mail, projects and more into one connected platform. Change something once and it shows up everywhere.
Keep reading
What Is a Help Desk? A Guide for Customer Support Teams
A help desk gives your support team a shared place to receive, track, and resolve customer requests. Here is what it is, what it tracks, and how to choose the right one.
SalesWhat Is a CRM? A Guide for Business Teams
A CRM gives your team one shared place to track customers, deals, and conversations. Here is what it is, what it tracks, and how to pick the right one.
IntegrationsWhat Is Business System Integration? A Guide for Growing Teams
Manual data entry between tools does not scale. Here is what system integration actually does, the difference between one-way and two-way sync, and how to choose the right approach as your team grows.