Most support agreements are written to be signed rather than to be used. They contain impressive-looking response times, several tiers with names, and an escalation matrix — and when something genuinely breaks at an inconvenient hour, none of it helps.

The failures are consistent and avoidable. Here is what goes wrong and how to write an agreement worth having.

The core problem: response time is not resolution

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

Acknowledgement is close to worthless. 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 genuinely 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 actually 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.

How we structure support

We contract on time-to-engaged and time-to-mitigation rather than acknowledgement, let the customer set severity, name individuals with direct numbers at each escalation level, and write post-incident reviews for serious incidents as standard. Handover terms are agreed at the start of every engagement.

Support arrangements cover systems built by our software development and web development teams, and our customer service management practice helps organisations design support operations of their own.

Talk to us about what your systems actually need covering.