Why can two teams look at the same ticket and reach different conclusions?
Service Level Agreements are supposed to bring clarity. A ticket logged at 9am with a four-hour response SLA should be straightforward: respond by 1pm, job done. But in practice, support teams and their customers routinely disagree about whether an SLA was met, not because anyone is being dishonest, but because “how you calculate it” is far more complicated than “did you respond in time”.
Working out the numbers is simple enough. Agreeing on the definitions behind them takes far more thought, and it’s a step many teams skip. At Revo, we often see organisations go live with the out-of-the-box SLA models in their ITSM tool and never revisit whether they suit the business.
This post breaks down the main approaches to SLA calculation: where the clock starts, what you’re measuring, when it pauses and how priorities affect each of these. The aim is to help you make deliberate choices rather than inherit someone else’s assumptions.
Where Does the Clock Start?
The single biggest source of SLA disputes is the start point, closely followed by what really counts as “meeting” it. Most people assume it’s obvious, but there are a few different models in common use, each with its own pros and cons.
1. Log Time
The clock starts the moment a ticket enters the system, regardless of how it arrived or who logged it. A customer emails at 2am, your service desk tool creates a ticket automatically and the SLA starts at 2am.
This is the simplest model to measure and the hardest to argue with from the customer’s perspective. They submitted their issue; your clock is running. It’s also the model most likely to feel unfair to support teams. It penalises them for things outside their control, such as out-of-hours submissions, tickets created by integrations and spam or duplicates that take time to close.
Log time works best when your team has true 24/7 coverage and your ticket pipeline is clean.
2. Assignment Time
The clock starts when the ticket is routed to the team or agent responsible for resolving it. This is common in organisations with tiered support, where L1 triages and assigns before L2 or L3 ever touches a ticket.
The logic is sound: you can only hold a team accountable for time they controlled. If L1 sat on a ticket for six hours before assigning it, that’s an L1 problem and L2’s SLA shouldn’t absorb it.
The weakness here is customer experience. As far as they’re concerned, they submitted a ticket eight hours ago and nobody’s responded. They have no visibility into your internal routing, and “the clock hadn’t started for us yet” is a difficult message to deliver.
3. First Acknowledgement
Under this model the SLA is met when a human agent genuinely engages with the ticket for the first time. Some teams use this interchangeably with response SLA, though the two are distinct (more on that below).
This model rewards meaningful first contact over automated or perfunctory responses. It penalises teams who send a template acknowledgement to stop the clock without actually reading the ticket.
In practice, it can be hard to define “genuine engagement” in a way that’s measurable and consistent across agents.
4. Business Hours Adjusted
This isn’t so much a different start point as a modifier that can be applied to any of the above. The SLA clock only runs during defined business hours, typically the hours your team is staffed and contracted to respond.
A ticket logged at 4:45pm on a Friday, with a four-hour SLA and business hours of 9am–5pm, wouldn’t breach until 12:45pm the following Monday. From your team’s perspective, that’s fair. Customers may see it differently, especially if they’re in another time zone or the issue is affecting their business over the weekend.
Business hours adjustments are almost always the right call for standard support tiers. Where they become contentious is with high-priority incidents, where customers often expect response times that aren’t bounded by office hours.
Response SLA vs Resolution SLA: Measuring Different Things
Even once you’ve agreed on where the clock starts, you need to decide what you’re measuring. Response and resolution are fundamentally different commitments.
Response SLA measures how quickly you first engage with the ticket. It’s a measure of acknowledgement: “we’ve seen this, someone is working on it”. Response SLAs are generally easier to meet and easier to game. A quick “thanks for logging this, we’re investigating” stops the response clock without actually solving anything.
Resolution SLA measures how quickly the issue is closed. It’s a measure of outcome. Resolution SLAs are more meaningful to customers and harder to hit, particularly for complex issues with uncertain timelines.
Many organisations track both. A typical structure might be: acknowledge within one hour, resolve within eight hours for a P2 issue. The response SLA gives the customer confidence that their ticket hasn’t disappeared; the resolution SLA defines the actual service commitment.
There’s a third variant worth naming: next-response SLA, sometimes called “time to next reply”. Rather than measuring just the first response, this tracks how long the customer waits for support to reply each time they send a message. This is useful for measuring ongoing service quality rather than just initial responsiveness, but it adds significant measurement complexity. Agents can also feel surveilled by it in ways that can encourage the wrong behaviour.
The Pause Problem
Almost every support team eventually asks: what happens to the SLA clock when we’re waiting on the customer?
If a ticket requires information from the customer before it can progress, and the customer takes three days to provide it, those three days arguably shouldn’t count against the resolution SLA. Most teams handle this with a “pending customer” or “on hold” status that pauses the clock.
This is reasonable in principle, but it tends to cause two problems in practice.
Problem one: it can be abused. If agents control when a ticket moves to “pending customer”, there’s an incentive to use that status to pause a struggling ticket rather than to accurately reflect that you’re waiting on information. Unless you clearly define when a ticket can go on hold and check the rules are followed, your SLA metrics will look healthier than they are.
Problem two: it’s invisible to customers. The customer doesn’t see a paused clock; they see a ticket that’s been “in progress” for a week. Even if the SLA calculation is technically correct, the experience doesn’t match it.
The most effective approach is to:
- Define hold statuses tightly (what specifically triggers them, what evidence is required).
- Automate status changes where possible.
- Make sure your reporting distinguishes between “time to resolution” and “team-owned time to resolution”. Both numbers are meaningful so visibility of both is key to measuring success.
Cascading SLAs in Tiered Support
When a ticket moves between teams (L1 to L2, support to engineering, or one regional team to another), you need to decide whether a new SLA clock starts or the original one carries over.
Carry-over model: The original SLA follows the ticket throughout its journey. L2 inherits whatever time L1 has already consumed. This gives the customer a single, consistent commitment and prevents tickets from bouncing between teams with everyone claiming their own clock is fine.
The downside is that L2 can breach an SLA because of L1’s delays, which feels unfair if L2 operates well within their own norms. It can also create perverse incentives: L1 rushing to escalate before the clock runs out, rather than resolving what they can.
Restart model: Each team gets a fresh SLA clock when the ticket reaches them. This is fairer to individual teams and easier to use for internal performance measurement.
The downside is that total resolution time can balloon while every team technically meets their own SLA. A ticket that passes through three teams, each hitting their four-hour SLA, might take more than twelve hours to resolve, leaving the customer with no single commitment to hold anyone to.
Many organisations use a hybrid: the customer-facing SLA is a single carry-over commitment, while internal SLAs for each tier are tracked separately for performance management purposes. This is more administratively complex but gives you the most useful picture.
How Priority Tiers Interact With All of the Above
Priority levels add another layer of complexity, because they interact with every variable above. A P1 ticket logged at 11pm may have a two-hour response SLA, but if your business hours adjustment means the clock doesn’t start until 9am, it’s not really a two-hour SLA at all.
A few things to get right when designing your priority tiers:
- Make business hours rules explicit per priority. Many teams apply business hours adjustments to P3 and P4 tickets but not to P1 and P2, which is a sensible approach. This should be documented clearly, not left implicit in your tooling configuration.
- Define what triggers a priority change. Tickets often start at one priority and get escalated. When a P3 is upgraded to P1, does the SLA restart based on the new priority and the current time, or does it retrospectively apply to the original log time? Both are defensible, but you need to pick one consistently.
- Watch for priority inflation. If customers learn that P1 tickets get faster responses, you’ll see everything logged as P1. Your SLA metrics will look terrible and you’ll have no real signal on urgency. Clear, objective definitions of each priority level, ideally with examples, will reduce priority inflation considerably.
Choosing the Right Model
There’s no universally correct answer. The right SLA calculation model depends on what you’re trying to incentivise, what you’ve contractually committed to, and what your team can realistically measure and report on.
A few questions that help narrow it down:
- Do you have out-of-hours coverage? If not, business hours adjustment is almost always the right call for standard tickets. Committing to log-time SLAs without 24/7 staffing is setting your team up to fail.
- How mature is your triage process? If L1 triage is fast and reliable, assignment time can work well. If triage is inconsistent, log time creates a more honest picture of total wait time.
- What have you actually committed to? Your contractual SLAs and your internal SLAs don’t have to be the same thing. Internal SLAs can be stricter, building in a buffer before you breach a customer commitment, and can be calculated differently.
- What behaviour do you want to drive? SLA metrics shape how your team works. If you measure response SLA only, expect agents to prioritise quick acknowledgements. If you measure resolution SLA, expect more focus on actually closing tickets. Neither is wrong, but make sure the metric matches what you value.
Finally, document your model clearly and make it accessible to everyone who needs to understand it: your team, your customers and anyone who reviews SLA reports. A well-designed SLA calculation that nobody can explain is almost as problematic as a poorly designed one.
Aim for a shared understanding of what you’ve committed to, how you’re measuring it and what the numbers actually mean. That will serve your team and your customers far better than chasing perfect metrics.
When It’s Time to Review Your SLAs
If you’re not sure your current SLA model reflects how your service desk actually works, it’s worth taking a step back to review it. Our ITSM Assessment looks at how your processes and SLAs are performing against your business priorities. You’ll come away with a clear picture of where the gaps are and a prioritised roadmap for fixing them. That could mean tightening hold statuses, separating customer-facing SLAs from internal OLAs, or reconfiguring your tooling so the numbers match reality.
