IT Support SLAs: Setting and Measuring Helpdesk Response Times

Every managed IT proposal you receive will quote response times. Almost none of them define the terms the same way, and very few publish whether they actually hit the numbers. That gap is where most IT support frustration begins.

This is a practical guide to reading, negotiating, and measuring IT support SLAs, whether you are hiring a provider or setting expectations for an internal helpdesk.

Response time is not resolution time

The single most important distinction. Response time is how long until a qualified human acknowledges your ticket and begins work. Resolution time is how long until the problem is fixed.

A provider promising a 15 minute response may still take three days to fix a printer, and that can be perfectly acceptable. A provider promising "same day resolution" without defining severity is promising something they cannot deliver on a failed server.

Insist that both are defined, and that response means work started, not an automated email saying "we received your ticket."

Severity levels that reflect business impact

Good SLAs tie targets to impact, not to how loudly someone complains. A workable four tier model:

Severity 1, critical. Business stopped. Server down, site wide outage, ransomware suspected, no email for the whole company. Target: response within 15 minutes, work continuously until resolved, 24/7.

Severity 2, high. A department or key function is blocked. A shared application is down, a location has lost connectivity, an executive cannot work. Target: response within 1 hour during business hours, resolution target of 4 to 8 hours.

Severity 3, normal. A single user is impaired but can work around it. Application errors, slow performance, printer failures. Target: response within 4 business hours, resolution within 1 to 2 business days.

Severity 4, low. Requests rather than failures. New user setup, software installs, questions, scheduled changes. Target: response within 8 business hours, resolution by an agreed date.

Write down who classifies severity. The best arrangement is that the requester proposes it, the provider confirms it, and disputes escalate immediately rather than sitting in a queue.

Coverage windows matter more than the numbers

A 15 minute response target means nothing if it only applies from 9 a.m. to 5 p.m. Monday through Friday. Ransomware does not respect business hours, and neither do failed backups or Friday night deployments.

Clarify:

• Which severity levels are covered 24/7 versus business hours only
• What counts as a holiday, and whose calendar applies
• Whether after hours support is included or billed separately
• How to reach a human outside business hours, and how long that path takes

For most businesses the right answer is 24/7 coverage for severity 1 and 2, and business hours for everything else.

Metrics worth reporting monthly

If nobody measures the SLA, the SLA is decoration. Ask for these numbers every month:

• First response time, reported as a median and a 90th percentile, not an average. Averages hide the tickets that sat for two days.
• Time to resolution by severity level.
• SLA attainment percentage by severity, with an explanation for every miss.
• First contact resolution rate. How often an issue is solved without escalation or a second touch.
• Ticket volume by category. Rising volume in one category is a signal to fix a root cause, not to hire more technicians.
• Reopened ticket rate. A high rate means tickets are being closed, not solved.
• User satisfaction, collected per ticket rather than in an annual survey.

Reasonable benchmarks for a well run helpdesk serving small and mid-sized businesses: 90 percent or better SLA attainment, first contact resolution above 65 percent, reopen rate under 5 percent, and satisfaction above 4.5 out of 5.

Contract terms people forget to negotiate

• Remedies for misses. Service credits are common. They should be meaningful enough to matter and automatic rather than requiring you to claim them.
• Exclusions. Third party vendor delays, user unavailability, and force majeure are usually excluded. Make sure the exclusion list is specific rather than open ended.
• The clock start. Does the timer begin when the ticket is submitted, or when it is triaged? It should be submission.
• Escalation path. Named roles and contact methods for when a severity 1 is not moving.
• Onboarding grace period. Expect 30 to 60 days before full SLA applies while documentation and monitoring are established. Get the length in writing.
• Review cadence. SLAs should be revisited annually against actual performance and changing business needs.

Setting expectations with your own staff

Half of IT support dissatisfaction comes from mismatched expectations rather than slow work. Publish internally:

• How to submit a ticket, and why the portal or email address is faster than tapping someone on the shoulder
• What information to include so the first response is useful
• What the targets are for each severity
• How to escalate if something is genuinely urgent

Organizations that communicate this see measurable drops in escalations and duplicate tickets within a quarter.

What good looks like in practice

You should be able to open a dashboard and see, without asking anyone, how many tickets are open, how long the oldest has been waiting, whether targets were met last month, and what categories are trending. Support becomes a managed service rather than a series of favors.

SecureMe247 runs a 24/7 helpdesk and security operations center for businesses across Northern Virginia, with published response targets and monthly reporting against them. If your current provider cannot tell you their SLA attainment for last month, that is the first question worth asking.