Support SLA

What angers a customer most in support isn't a slow answer — it's an answer with no known arrival time.

Someone who sent a request has to decide what to do in the meantime. If a reply comes within thirty minutes, they wait. If it takes a day, they find another route or warn their team. With no expectation, they can do neither, and what follows is checking the inbox every half hour without starting anything.

The seller has a problem without a standard too. Agents judge urgency differently. One tries to answer everything the same day while another takes two. Support quality then varies by who picked up the request, and the customer experiences that as luck.

In enterprise contracts the problem moves into the contract itself. Evaluating the tool, a buyer asks in writing who they can reach, and within how many hours, if it stops working. A support SLA is the document written to answer that, and it doubles as the internal standard.

Four things go inside. The first two build the commitment; the last two draw its boundary.

1. Severity levels. Not every request can be answered inside the same window, so they get sorted first. Three or four levels is typical: the service is entirely down, some functionality is broken, it works but is inconvenient, a simple question. The criteria for sorting have to be in the document or you'll argue with the customer about it — and left unwritten, every request arrives at the highest level, since no customer has any reason to describe their own problem as minor.
2. Response time per level. One hour for a full outage, four hours for partial, one business day for inconvenience, two for simple questions. What's being promised here is a response, not a resolution. Promising to fix something within an hour can't be kept; promising that a person will engage and report status within an hour can.
3. Coverage hours — business hours, or around the clock. This line determines actual staffing. A 24-hour commitment requires shifts or an on-call rotation, and that cost has to show up in pricing, which is why 24-hour coverage usually attaches only to higher tiers.
4. Exclusions and scope. A sentence saying time spent waiting on the customer for information doesn't count toward the response clock; a sentence saying problems in the customer's network or a third-party tool are out of scope. Without those lines, things you can't control end up inside the promise.

Some versions add a remedy clause for missed commitments, commonly a credit against part of the monthly fee in enterprise contracts. That clause changes what the document is. It stops being guidance and becomes a promise with money behind it, so the numbers written in it have to be numbers you can actually keep, which usually means writing something less impressive than what the sales team would prefer.

Support owns it but can't set it alone, because it's bound to staffing.

Committing to a one-hour response on full outages around the clock requires somebody reachable at night, and the cost of that person has to land in pricing. So this document gets set by support, leadership, and engineering together. Judging severity and responding overnight ultimately falls to engineering, so its numbers can't contradict the service level agreement (SLA) that commits to service levels contractually.

Three groups read it.

1. The customer's practitioner, before sending a request. Knowing when a reply arrives lets them plan the interval.
2. The customer's reviewer, before purchase. In enterprise deals, the absence of this document sometimes stops the evaluation.
3. Your own agents, daily. This document is what decides what gets worked first. With times written per level, choosing among twelve open support tickets — one ticket being one logged request — becomes a rule rather than a judgment.

Adherence gets confirmed numerically. Measure first response time — intake to first reply — split by level, and read the share that landed inside the committed window. Reading the share rather than the average is what matches this document. A forty-minute average looks healthy, but if ten four-hour cases sit inside it, the commitment was broken for those ten customers.

"This is a level one, so it needs an answer inside an hour."

The document's levels setting the day's order.

"Round-the-clock support attaches to the enterprise tier only. There's an on-call cost."

Explaining that the commitment and the cost are tied.

"Level one adherence was 92 percent last month. Let's look at the three we missed."

Confirming by share and then examining the exceptions.

At Pagedeck the levels are three: one hour for a full outage, four hours for partial, one business day for everything else. Round-the-clock coverage attaches to the enterprise tier; the team tier runs on business hours.

What Sofia reads weekly is the adherence share. One week last quarter level-one adherence dropped, and the cause turned out to be that outage alerts were routed to Sofia alone. She was on vacation that week. Alerts now go to two people, and the routing gets checked whenever anyone's coverage changes. That was the week the team learned that keeping a commitment rests on routing design rather than on anyone's diligence.

A common belief is that shorter committed times mean better support. One hour looks better than four, naturally enough. But a number in this document is only worth something when it's kept. Write one hour and keep it half the time and you're worse off than having promised nothing, because the customer planned their work around the hour and then had it broken. The number to write is the one your current staffing keeps more than 90 percent of the time. Raising the commitment later, once staffing supports it, is a much easier conversation than lowering it.

The other misreading is hearing a response commitment as a resolution commitment — taking "we answer within an hour" to mean "we fix it within an hour." The confusion persists if the seller doesn't separate the two clearly in both the document and the first reply. Which is why a first reply shouldn't just acknowledge receipt: it says what is being checked and when the next update will come. What the customer wants isn't instant resolution but information about when it ends, and that information is cheap to give and expensive to withhold.