We publish our own service levels and we would rather be evaluated against a standard than against a competitor’s brochure. So here is the standard, including the questions that are uncomfortable to answer, ours included.

1. A response target, defined precisely

The most common failure is language like “we respond promptly” or “priority response.” Neither is a commitment.

A real response target states a maximum elapsed time between a defined starting event and a defined action, differentiated by severity. It also defines what starts the clock, because that is where the ambiguity hides.

Ask:

• Does the clock start when the ticket is submitted, or when someone reads it?
• Does it run during the coverage window only, or continuously?
• What counts as a response? An automated acknowledgment, or a qualified engineer engaging with the problem?

An automated email that stops a response clock is a widely used arrangement and it is worth nothing to you.

2. A restoration target

Response is cheap to promise. Restoration is the commitment that reflects what you actually care about, and many agreements omit it entirely.

A restoration target states when service is expected to be working again, or when an acceptable workaround will be in place, by severity. It should also name honestly the dependencies that can suspend the clock, such as waiting on a carrier, a hardware RMA, or site access.

A provider who will not commit to any restoration target is telling you something. A provider who commits to one with no exclusions at all is telling you something too, because carrier and vendor dependencies are real.

Ask:

• Is there a restoration target at all, or only a response target?
• Which dependencies suspend the clock, and are they listed exhaustively?
• Does the target differ by severity, and who assigns severity?

That last point matters. If the provider unilaterally classifies severity with no defined criteria and no appeal, every commitment above it is discretionary.

3. An escalation path with names

An escalation clause should tell you who to contact, who that person escalates to, and at what elapsed time escalation happens automatically without you having to demand it.

Automatic escalation is the key element. If escalation only happens when a client complains loudly enough, then the quiet clients, which is most of them, never get it.

Ask:

• Are the escalation contacts named, with a role and a direct method of reaching them?
• Does escalation trigger on elapsed time automatically?
• Is there a defined point at which someone with authority to commit resources gets involved?

4. A measurement method

A commitment nobody measures is a slogan. The agreement should say how performance is measured, over what window, from which system of record, and how the results reach you.

Ask:

• What system records the timestamps, and can you see it?
• Over what period is performance calculated, monthly or quarterly?
• Are you given a report without having to request it?
• Can you audit the underlying ticket data?

If the only party who can see the measurement is the party being measured, and it is only produced on request, the practical effect is no measurement at all.

5. A remedy

What happens when the provider misses. Without this, everything above is a statement of intent.

Remedies are usually service credits, and it is worth being realistic: a credit rarely compensates for the actual cost of an outage. Its real function is to make misses visible and to give both parties a reason to treat them as significant rather than routine.

Ask:

• Is there a remedy for a missed target?
• Is it applied automatically, or must you claim it within a window?
• Is there a threshold of repeated misses that lets you terminate for cause?

That final question is the one that matters most. A right to terminate for chronic failure to perform is the only remedy with real weight behind it.

The exclusions section deserves as much attention as the commitments

Every legitimate SLA has exclusions. Carrier outages, utility power, force majeure, client-caused changes, unsupported or end-of-life equipment, and anything outside the defined scope are all reasonable.

What is not reasonable is exclusions that swallow the commitment. Read them and ask: after applying all of these, what is actually left that the provider is on the hook for? Sometimes the honest answer is very little.

Watch specifically for an exclusion covering “issues arising from the client’s existing infrastructure,” which in an environment the provider inherited can cover almost anything.

Two questions that reveal more than the document

“Show me your SLA performance for the last two quarters.” A provider who measures will have this. A provider who does not will explain why it is complicated.

“Tell me about a time you missed and what you did.” Everyone misses. The answer tells you whether misses are treated as events to learn from or as facts to manage away.

A service level agreement is not primarily a legal instrument. It is a written record of what both parties agreed to expect, which is what prevents the argument during the outage.

Our position

Our Management Service Agreement contains all five elements, with severity criteria defined so classification is not discretionary, automatic time-based escalation, and exclusions listed exhaustively rather than gestured at.

We also state plainly that full service levels apply once onboarding remediation is complete. If an environment has unsupported hardware or unverified backups on day one, a restoration commitment on it would not be honest, and we would rather say that in writing than discover it together during an incident.

If you are evaluating providers, run this checklist against all of them, us included. If ours does not hold up, we would like to know.

General information, not legal advice. Have your own counsel review any agreement before signing.

See how our MSA and SLA are structured