Understanding IT Support SLAs
Businesses considering changing IT service providers are doing more homework than ever.
Many are using AI tools to prepare questions, build comparison checklists and understand what they should look for in a managed IT services provider.
That is a good thing.
Better-prepared buyers should have better conversations and make better decisions.
However, there is one question we are being asked more often than ever:
"What are your response time SLAs?”
It sounds like a simple question.
It rarely has a simple answer.
The problem is not that response times are unimportant. They are important. When a team member cannot work, they want help quickly.
The problem is that a response time can be measured in several different ways—and the number itself may tell you very little about the support experience your people will actually receive.
That is why the conversation should not stop at SLAs.
It should also include XLAs.
What is an SLA?
SLA stands for Service Level Agreement.
In plain English, an SLA is a measurable commitment from a service provider.
For IT support, an SLA might specify how quickly the provider will respond to a support request, based on its priority.
For example, a critical issue affecting the whole business may have a very short response target. A problem affecting one employee may have a longer target. A routine request may be scheduled within an agreed timeframe.
This provides accountability and helps set expectations.
But the important question is:
What does “response” actually mean?
For one provider, it may mean an automated email confirming that the ticket was received.
For another, it may mean someone has reviewed and categorised the request.
For another, it may mean a technician has started investigating the problem.
Those are three very different events, even though each could be described as a response.
A fast response is not the same as a fast resolution
Imagine one of your employees reports that they cannot access an important business application.
Within two minutes, they receive an automated acknowledgement.
The SLA clock has been met.
But nobody starts investigating for another hour.
When a technician eventually calls, the employee explains the problem. It is then escalated to someone else, and the employee has to explain everything again.
Several hours later, the issue is resolved.
Technically, the provider delivered an impressive response time.
From the employee’s perspective, however, they lost several productive hours and had a frustrating support experience.
This is why response times should never be considered in isolation.
A provider can improve its headline response figure by acknowledging tickets quickly, passing requests through a triage team or repeatedly prioritising new tickets ahead of work already in progress.
That may make the response-time report look good.
It does not necessarily help people get back to work sooner.
Response time, resolution time and disruption time
There are three different measurements worth understanding.
Response time
How long did it take the provider to acknowledge the request or begin working on it?
Resolution time
How long did it take to solve the problem?
Disruption time
How much productive time did the business and its employees lose because of the issue?
Disruption time is often the most useful measure because it considers the real business impact.
That includes:
- How long the issue prevented someone from working effectively
- How much time the employee spent communicating with support
- Whether the employee had to repeat the problem to several people
- How many employees were affected
- Whether the issue was resolved properly the first time
- How frequently similar problems occur
A five-minute response followed by four hours of disruption is not necessarily better than a 20-minute response that resolves the issue in one interaction.
The first provider may have the better-looking SLA.
The second may have delivered the better outcome.
What is an XLA?
XLA stands for Experience Level Agreement.
While an SLA measures whether a service provider completed a defined activity within a target time, an XLA looks more closely at the experience and outcome.
In simple terms:
An SLA asks, “Did the provider meet the number?”
An XLA asks, “Did the service work well for the client and its people?”
An XLA may consider questions such as:
- Was the employee kept informed?
- Was the communication clear?
- Did the employee feel that someone took ownership of the issue?
- Was the problem resolved with minimal effort from the employee?
- Was it fixed properly the first time?
- Could the employee continue working while the issue was being investigated?
- Is the overall number of IT problems decreasing?
- Are employees satisfied with the support they receive?
These measures are not as simple as a response-time percentage, but they provide a much fuller picture of service quality.
SLAs and XLAs are not competitors
The answer is not to abandon SLAs.
SLAs remain useful. Businesses need defined priorities, escalation processes and measurable service commitments.
The better approach is to use SLAs and XLAs together.
The SLA creates the operational baseline.
The XLA helps determine whether that operating model is producing the right experience and business outcome.
For example, a service provider may report that it responded to 98 per cent of tickets within the agreed SLA.
That sounds positive.
But what if employees regularly need to follow up? What if tickets are passed between several technicians? What if people have to explain the same issue repeatedly? What if recurring problems are never properly addressed?
The SLA report may still be green while the client’s experience is red.
An XLA helps uncover that difference.
Looking Beyond Response Times
Every IT service provider says it is proactive
Almost every managed IT service provider describes itself as proactive.
The word appears in proposals, websites and sales presentations across the industry.
But “proactive” is not a process.
It does not explain what is reviewed, what standard is being applied, how gaps are identified, who is accountable for addressing them or how progress is measured.
A provider may describe monitoring, patching or periodic reviews as proactive. Those activities can be useful, but on their own they do not provide a structured way to improve the client’s technology environment.
The more useful question is:
“What specific process do you use to reduce risk, improve consistency and prevent avoidable support issues?”
That is where technical alignment becomes important.
Beyond proactive: technical alignment to a standards library
Since 2018, Netcare has used a technical alignment process to assess client environments against our documented standards library.
Rather than relying on a broad promise to be proactive, technical alignment provides a repeatable and measurable process.
The standards library defines how we believe a well-managed client environment should be configured, documented, secured and maintained.
The technical alignment process then compares the client’s actual environment with those standards.
This helps identify:
- Technology that is not configured consistently
- Security controls that are missing or incomplete
- Systems that are approaching end of life
- Documentation gaps
- Recurring technical weaknesses
- Areas where unnecessary complexity is increasing support demand
- Conditions that could contribute to future disruption
Those findings can then be prioritised, discussed and addressed through an agreed improvement plan.
This is very different from simply responding quickly when something goes wrong.
It is also more meaningful than saying, “We are proactive.”
Technical alignment creates a clear connection between the standards expected across the environment and the work required to move the client closer to those standards.
The best support issue is the one that never happens
Response times matter when an incident occurs.
But the quality of an IT service provider should not be judged only by how quickly it reacts after something has already gone wrong.
A well-managed environment should also produce fewer avoidable interruptions.
That requires more than monitoring tools and good intentions.
It requires a documented understanding of what good looks like, regular comparison of the client environment against that standard, and a disciplined process for addressing the gaps.
Technical alignment helps shift the conversation from:
“How fast will you respond when something breaks?”
to:
“What are you doing to reduce the likelihood and impact of issues in the first place?”
This matters because the best support experience is not always a very fast ticket.
Often, it is an issue that never needed to become a ticket at all.
How technical alignment supports the XLA
Technical alignment also strengthens the experience measured by an XLA.
A more consistent, well-documented and standards-aligned environment should be easier to support.
Technicians have better information.
Systems are configured more consistently.
Known risks are visible.
Recurring issues are more likely to be identified and addressed at their source.
That can contribute to:
- Fewer interruptions
- More consistent resolutions
- Less time spent diagnosing avoidable configuration problems
- Fewer repeat tickets
- Clearer communication
- Greater confidence in the technology environment
The result is not simply a better-looking service report.
It is a better day-to-day experience for the client’s employees.
Questions to Ask Before Comparing IT Service Providers
Better questions to ask an IT service provider
When assessing a prospective IT provider, asking about response times is still appropriate.
But do not stop at:
“What is your SLA?”
Ask:
How do you define a response?
Does the timer stop when an automated acknowledgement is sent, when someone reviews the request, or when a technician begins meaningful work?
How do you prioritise tickets?
Is priority based only on the type of technical fault, or does it also consider how many people are affected and how seriously the business is disrupted?
What do you measure beyond initial response time?
Look for measures such as resolution time, ticket age, first-contact resolution, reopened tickets and employee satisfaction.
How will our employees be kept informed?
Communication matters, particularly when an issue cannot be fixed immediately.
How do you identify recurring or avoidable issues?
A provider should not simply close the same type of ticket repeatedly. It should have a process for identifying the underlying technical condition.
What standards do you assess our environment against?
Ask whether the provider has a documented standards library or is relying on individual technician judgement.
How is technical alignment measured and reported?
The provider should be able to explain how gaps are identified, prioritised, assigned and reviewed.
How do you measure the employee experience?
Ask how the provider collects feedback and what it does when the service experience falls short.
How do you reduce overall business disruption?
This moves the conversation beyond helpdesk statistics and towards productivity, continuity and business outcomes.
Be cautious with headline promises
Very short response-time promises can be appealing, particularly when your current provider is slow or difficult to deal with.
But it is worth examining exactly what is being promised.
A headline such as “responses within five minutes” may refer to an acknowledgement, a call from a coordinator or an initial triage step—not necessarily a technician resolving the issue.
It is also important to understand the trade-offs.
If a service desk constantly interrupts existing work to touch every new ticket immediately, initial response figures may improve while older tickets take longer to resolve.
Similarly, moving a ticket rapidly between several people may produce plenty of activity without producing a good experience.
The objective should not be to find the provider with the smallest number on a proposal.
It should be to understand which provider has the people, processes and service model to minimise disruption, support employees effectively and systematically improve the technology environment.
So, what is a reasonable IT support response time?
The honest answer is:
It depends on the impact and urgency of the issue.
A complete business outage should receive a very different response from a routine request to install an application.
That is why a credible IT provider should be able to explain:
- How priorities are determined
- What each response target actually means
- How urgent issues are escalated
- How progress is communicated
- How quickly issues are typically resolved
- How service quality and employee experience are measured
- What standards the technology environment is assessed against
- How technical gaps are identified and addressed
- How recurring incidents are reduced over time
A table of SLA targets may form part of that explanation.
It should not be the entire explanation.
Move the conversation from speed to experience
When employees contact IT support, they do not really want a ticket number.
They want confidence that someone understands the issue, takes ownership of it and will help them return to productive work with as little frustration as possible.
That is the difference between measuring activity and measuring experience.
SLAs tell you whether a provider responded according to an agreed process.
XLAs help you understand whether that process delivered a good result for your people and your business.
Technical alignment goes one step further by helping reduce the technical conditions that create disruption in the first place.
So, when comparing IT service providers, by all means ask about response times.
Then ask the more revealing questions:
“How will you measure the experience our employees receive?”
“What standards will you assess our environment against?”
“What process will you use to identify and address the gaps?”
The answers will tell you much more than a headline SLA—or a generic promise to be proactive—ever could.
Considering a change of IT service provider?
Choosing an IT partner should not be reduced to comparing response-time promises on a spreadsheet.
Netcare helps businesses examine the complete service model: responsiveness, resolution, communication, employee experience, technical alignment and the systematic reduction of business disruption.
Since 2018, our technical alignment process has assessed client environments against Netcare’s standards library, providing a structured basis for identifying gaps and prioritising improvement.
Because saying you are proactive is easy.
Having a documented process that shows what good looks like—and measures how closely each client environment aligns with it—is something quite different.
Not sure what your IT provider’s SLA really promises?
Netcare can help you assess the complete service model—including response, resolution, communication, employee experience and technical alignment to a documented standards library.
To discuss this in further depth, call us now on (02) 9114 9920 or .