SLAs, Escalation Paths and Support Tiers That Actually Hold Up

Published by ANAWAZ

A useful support agreement explains what happens after an incident is reported: how severity is assessed, when an engineer starts work, who leads the response and how the customer receives updates. A fast acknowledgement alone does not restore a service or provide a workable escalation path.

A practical decision guide

The core problem: response time is not resolution

The common SLA commits to a response time. Within some number of hours, the supplier will acknowledge your ticket.

Acknowledgement confirms receipt, but does not show that an engineer has assessed the problem. An automated reply saying a ticket has been assigned meets a one-hour response SLA perfectly while your production system remains down. The metric is fully satisfied and your problem is untouched.

What you care about is when it works again. Suppliers resist committing to resolution times, and for one legitimate reason: they cannot know in advance how hard a fault will be to fix, and a bug in a third-party dependency may be outside their control.

The workable middle ground has three parts:

• Time to a human engaged — not an acknowledgement, but a named engineer actively working the problem. This is committable and it is what starts the clock on a fix.
• Time to mitigation — restoring service, even via a workaround, rollback or failover. Distinct from a permanent fix and far more predictable.
• Continuous effort until mitigated — for the highest severity, a commitment that work does not stop overnight or over a weekend once it has started.

That last clause is the one that matters most in practice and the one most often absent. Without it, a Friday evening outage can legitimately sit until Monday while every stated SLA is met.

Define severity by business impact, and settle who decides

Severity levels are usually defined in technical terms — system down, degraded, minor issue — which produces immediate disputes, because “degraded” is subjective and the two parties have opposite incentives.

Define severity by business impact instead, in terms specific to your operation:

• Severity 1: Revenue-generating or safety-critical function is unavailable, or data is at risk. Customers cannot buy, staff cannot serve them, or information is being lost or exposed.
• Severity 2: Significant function impaired with no acceptable workaround, or a workaround exists but imposes substantial manual effort.
• Severity 3: Function impaired with a reasonable workaround; normal operation continues with inconvenience.
• Severity 4: Cosmetic issues, minor defects, and requests for change.

Then settle the question that causes most real disputes: who assigns severity?

Our position is that the customer sets initial severity, because only the customer knows the business impact. The supplier may request a downgrade with reasons, but cannot unilaterally reclassify. Without this, every Severity 1 becomes a negotiation at the exact moment nobody has time to negotiate.

Balance it with a good-faith clause about not inflating severity, and review classifications together in the monthly service review rather than in the middle of an incident.

Escalation must name people

An escalation path that says issues will be escalated to senior management as appropriate is not a path. It is a sentence.

A usable escalation path specifies, for each level: a named individual, their direct contact details including a phone number, the time after which you escalate to them, and their named deputy.

Typically three levels are enough — the support lead, the engineering or delivery manager, and a director or account owner with commercial authority.

Three details make the difference between a path that works and one that does not:

1. Phone numbers, not just email. When something is badly wrong, email is too slow and too easy to miss.
2. You may escalate on elapsed time alone, without needing the supplier’s agreement that escalation is warranted.
3. The contact list is reviewed quarterly. People change roles. A path pointing at someone who left the company eight months ago is the normal state of an unmaintained escalation matrix, and you discover it during an incident.

State the coverage hours honestly

“24/7 support” is used loosely and means several different things. Establish which one you are buying:

• Is someone awake and working at 3am, or on call and asleep with a pager?
• If on call, what is the committed time from page to engaged?
• Does after-hours cover all severities, or only Severity 1?
• Which public holidays are excluded — and in which country?
• Is there a single on-call engineer, or genuine rotation and backup? A single person is a single point of failure, and they will eventually be unreachable.

The holiday question matters particularly in cross-border arrangements, where each side may assume the other’s calendar. Attach the actual calendar to the agreement.

What service credits are and are not

Most agreements attach service credits — a percentage of fees refunded when an SLA is missed. These are worth understanding correctly.

Service credits are almost never meaningful compensation. A refund of a fraction of a monthly fee does not offset a day of lost revenue, and it was never designed to.

Their real function is as a signal. They give the supplier a financial reason to care, and they create a recorded, unambiguous fact that an SLA was missed. That record matters at renewal, and it converts a vague sense that support has been poor into an evidenced pattern.

So do include them, keep the claiming process simple — automatic on breach, ideally, rather than requiring you to notice and apply — but do not mistake them for insurance. If downtime carries serious financial consequences, that is a question for your insurer and for your architecture, not for the SLA.

The clauses people forget

Four provisions that rarely appear and are consistently valuable:

• Post-incident reviews. For every Severity 1, a written review within an agreed number of working days covering what happened, why, and what will change to prevent recurrence. This is how support improves rather than repeating.
• A monthly service report. Tickets raised by severity, SLA performance, recurring themes, outstanding issues. Without this, you have no basis for assessing the service beyond impressions.
• Exit and handover terms. What happens at termination: what is handed over, in what format, over what period, and at what cost. Negotiate it at signing, when you have leverage. Negotiating handover during a breakdown in the relationship goes badly.
• Named-person continuity. A commitment that people with knowledge of your system will not all be rotated off simultaneously, and that a defined handover happens when someone does move on.

Before you sign

1. Does the SLA commit to anything beyond acknowledgement?
2. Is there a commitment to continuous effort on Severity 1 outside business hours?
3. Are severity levels defined by business impact, and is it clear who assigns them?
4. Does escalation name individuals with phone numbers and deputies?
5. Can we escalate on elapsed time without the supplier’s agreement?
6. Exactly which hours and holidays are covered, and is on-call a rotation?
7. Are post-incident reviews required for serious incidents?
8. Are exit and handover terms defined now?

If the answer to most of these is no, the agreement protects the supplier rather than you — and that is worth raising before signature rather than during an outage.

Worked example

If orders cannot be submitted, an incident may need urgent restoration even when the website itself is available. If a reporting page is slow but a workaround exists, the response can be different. Severity should reflect these business effects, with an agreed decision-maker when the parties disagree.

This is an illustrative planning scenario, not a client case study.

Turn the decision into a plan

Write down the outcome you need, the evidence that would show success, the unresolved risks and the person responsible for the next decision. Use a bounded first step to test the difficult assumptions before committing to a larger programme.

ANAWAZ can help you scope the engineering work through our Managed support and service operations. Tell us about your current systems and the result you want to achieve.