What a Good Help Desk SLA Actually Looks Like at Under 100 Employees

Most help desk contracts include a service level agreement, but few buyers could say what a good one actually promises. Somewhere between the sales conversation and the signed contract, "SLA" tends to shrink from a specific, measurable commitment into something closer to "we'll get to it eventually." For a company under 100 employees, that gap only becomes visible when it matters: payroll software goes down on a Friday afternoon, or a phishing alert needs an answer inside the hour, and nobody can say with certainty how fast a response is actually guaranteed.

What an SLA Is Actually Supposed to Promise

A service level agreement exists to answer one question in advance: what happens after you submit a ticket, and by when. That sounds simple, but most SLAs blur two commitments that are not the same thing.

Response time is how long it takes for a human to acknowledge the ticket and confirm someone is working on it. Resolution time is how long it takes to actually fix the problem. A provider that promises a "one-hour response" has told you almost nothing about when your problem will be solved. Confirming which one an SLA actually guarantees, and getting that distinction in writing, is the single highest-value question a buyer can ask before signing.

A complete SLA also needs to specify:

Coverage hours. Is the commitment measured against a standard business day, or genuine 24/7 coverage? A "one-hour response" that only applies from 9 to 5 on weekdays is a different product than one that applies around the clock.
What counts as the clock starting. Ticket submission, ticket triage, or the moment a technician picks it up are three different start points, and providers do not define this consistently.
An escalation path. What happens if the assigned technician cannot resolve the issue within the target window. Without a named escalation step, "someone is working on it" can mean the ticket sits with the wrong person for hours.
Uptime commitments, if the provider is also hosting or managing infrastructure, separate from support response commitments.

Priority Tiers That Actually Hold Up Below 100 Employees

Nearly every credible help desk SLA structures its commitments around a small number of priority tiers, because a printer jam and a full outage should never compete for the same response window. The specific labels vary, but the underlying structure is consistent enough to treat as a baseline for evaluating any proposal.

Priority	Example Issue	Response Target	Resolution Target
Critical	Full outage, security breach, payroll down	15–30 minutes	2–4 hours
High	Single system down, major function blocked	1 hour	4–8 hours
Standard	Individual user issue, non-blocking bug	4 hours	1–2 business days
Low	Cosmetic issue, feature request	Next business day	Best effort

A company under 100 employees does not need more tiers than this. What it needs is a provider that actually applies them consistently, rather than treating every ticket as "standard" until someone escalates loudly enough to get attention.

What "Good" Actually Looks Like, By the Numbers

Vague reassurance ("we're usually pretty fast") is not a standard. A few external benchmarks are useful for judging whether a proposed SLA, or your current one, is actually competitive.

Staffing ratio. Gartner has long cited roughly one IT support staffer per 70 end users as a workable general benchmark, though many organizations run leaner than that in practice, particularly once proactive monitoring and automation absorb some of the routine ticket volume. A provider's SLA is only as credible as the staffing behind it: a promised 15-minute response with one technician covering 300 users is a commitment that will not survive a bad week.

First contact resolution. SQM Group's benchmarking research puts the industry-average first contact resolution rate at roughly 71%, with 70–79% considered a good result and 80% or higher considered world-class. This matters because a ticket that gets "resolved" by being reassigned three times is not actually a fast resolution, even if the initial response was quick.

The cost of getting it wrong. ITIC's 2024 Hourly Cost of Downtime Report, based on a survey of more than 1,000 firms conducted from late 2023 through early 2024, found that hourly downtime costs continue to climb for organizations of every size, with the great majority of mid-size and large enterprises now reporting costs well into six figures per hour. Those enterprise figures do not translate directly to a 40-person company, but the direction is the same: an SLA that is slow on paper is not a minor inconvenience, it is a specific, compounding, dollar cost the moment something actually breaks.

Where Vague SLAs Hide the Real Gaps

Most disappointing help desk relationships do not fail because the provider is incompetent. They fail because the SLA never specified the thing that eventually went wrong. A few patterns worth checking for specifically:

"Response" is undefined. If the contract does not say whether response means a human reply or an automated ticket confirmation, assume the weaker interpretation and ask directly.
After-hours coverage is assumed, not stated. A team that works 9 to 5 with no documented after-hours tier will treat a Saturday outage as a Monday problem, whether or not that was the intent.
Priority is self-reported with no verification. If every customer can mark their own ticket "critical," the tier system provides no real prioritization at all.
There is no consequence for missing the target. An SLA without a remedy, a credit, an escalation to a named manager, a defined review, is a statement of intent, not a commitment.
Resolution time has no ceiling. A provider that will not commit to any outer bound on resolution time, even for standard-priority tickets, has effectively declined to make a resolution commitment at all.

A Simple Framework for Evaluating Your Current SLA

Before renewing or signing a help desk contract, walk the agreement through four questions:

Does it separate response time from resolution time, in writing, for every priority tier?
Does it define coverage hours explicitly, including whether after-hours and weekend support exists and what it costs?
Does it name an escalation path, with a specific point of contact if a ticket exceeds its target window?
Is there an actual consequence, not just an apology, when the SLA is missed?

If the answer to any of these is "we've never actually asked," that is the conversation to have before the next renewal, not after the next outage.

Where This Fits at Elevaire

Elevaire built Foundation IT around exactly this gap: growing organizations that need reliable device management, proactive monitoring, and a help desk with a clear owner, not a vague promise that someone will get to it. Every request gets triaged against a defined priority structure with a named resolution path, whether it is a Microsoft 365 issue, a device problem, or a question nobody on the team knows who else to ask. Foundation IT also includes a quarterly Technology Health Review directly with Elevaire, so the conversation about whether your support model is actually keeping pace with your growth happens on a fixed schedule instead of only after something breaks. Organizations that outgrow Foundation IT's day-to-day scope move into Fractional IT Leadership as an expansion of the same relationship, not a vendor change.

Frequently Asked Questions

How much does a properly structured help desk SLA cost compared to a vague one?

Pricing is driven more by scope, coverage hours, and headcount than by SLA specificity itself. A well-defined SLA with response and resolution targets, escalation paths, and after-hours coverage is not inherently more expensive than a vague one; it is simply harder for a provider to write if they are not confident they can actually hit the numbers. Treat SLA precision as a signal of provider maturity, not a pricing upsell.

We already have an internal IT person. Does a formal help desk SLA overlap with what they do?

It should not, if scoped correctly. A help desk SLA covers recurring, time-bound ticket resolution, the volume work that consumes an internal person's day without using their most valuable skills. A properly scoped arrangement frees that person to focus on projects and decisions specific to your business instead of routine troubleshooting, rather than duplicating their role.

What's the most common mistake companies make when reviewing an SLA?

Reading the headline response time and stopping there. The response time tells you almost nothing about resolution time, coverage hours, or what happens if the target is missed. A one-hour response commitment attached to a three-day resolution window and no after-hours coverage is a very different product than the same one-hour number attached to a defined four-hour resolution target.

Is a formal SLA necessary for a company this small, or is that overkill?

It is not overkill. Smaller organizations have less redundancy to absorb a slow response, a single unresolved outage can affect a much larger share of the business than it would at a larger company. A clear, appropriately scoped SLA is more important below 100 employees, not less, precisely because there is no large IT department to compensate for gaps in the support model.

How do we get started evaluating whether our current SLA is adequate?

Pull the current contract and run it through the four-question framework above: separated response and resolution targets, explicit coverage hours, a named escalation path, and an actual consequence for missed targets. Any gap identified there is worth a direct conversation with the current provider, or a documented requirement in the next proposal you request.

What happens if a provider consistently misses its own SLA?

That depends entirely on what the contract specifies, which is exactly why the consequence clause matters as much as the target itself. Some agreements include service credits for missed targets; many say nothing at all, which in practice means nothing happens. If a provider is unwilling to put a remedy in writing, that reluctance is worth treating as information about how seriously the target itself is meant to be taken.