Service level agreements are read closely once, at signature, by people who will not be the ones invoking them. The gap between what the document says and what the business believes it says only becomes visible during a major incident, which is the worst possible moment to discover it.

This is a clause-by-clause walk through what these agreements actually commit a provider to, where the language is doing less work than it appears to, and which terms are worth negotiating hardest.

Key Takeaways

  • Severity is defined by business impact, and who assigns it is more consequential than the definitions themselves.
  • A response target commits the provider to starting; only a resolution target commits them to finishing.
  • "24/7" describes when someone answers, not what capability is awake — ask what the overnight team can actually do.
  • Exclusions and clock-stop clauses decide more disputes than any headline number.
  • Service credits are usually too small to change provider behaviour and should not be treated as the remedy.

Severity: The Definition That Decides Everything

Every support agreement classifies incidents by severity, and every subsequent commitment hangs off that classification.

The definitions themselves are broadly standard and follow common service-management practice: the highest tier for a critical business function unavailable with no workaround; the next for significant degradation or a critical function with a workaround; then moderate impact; then minor issues and requests.

Two things matter far more than the wording.

Who assigns severity. If the provider classifies, expect classification to drift downward — the incentive is structural rather than dishonest. The workable arrangement is that the customer assigns initial severity, with a defined process for the provider to challenge it, and a rule that it stays at the customer's level while the challenge is resolved.

Whether the definitions are written in your language. "Critical business function" is meaningless until it names the functions. A support agreement that lists your actual critical services — the payment run, the claims intake, the ordering channel — removes the argument entirely. This is straightforward to negotiate and rarely requested.

Response Time Is Not Resolution Time

The single most consequential misunderstanding in these agreements.

Response time is the interval between an incident being raised and the provider acknowledging or beginning work. It is controllable, easy to measure, easy to commit to, and it is what most agreements quote.

Resolution time is the interval until the service is restored. It depends on the fault, which is why providers resist committing to it — and it is what the business actually experiences.

An agreement with a fifteen-minute response target and no resolution target has committed a provider to answering the phone quickly. That is not nothing, and it is not a restoration commitment.

Where a provider will not commit to resolution targets, two fallbacks are worth pursuing. Update cadence — a commitment to substantive updates at defined intervals during an incident, which at least makes progress visible. And escalation triggers — automatic escalation to defined seniority at defined elapsed times, so an incident cannot sit with the same engineer indefinitely.

Also negotiate what "resolved" means. A workaround that restores service is a legitimate resolution for the incident clock, but the underlying problem should carry its own commitment. Otherwise a recurring fault is repeatedly resolved and never fixed.

Infographic contrasting response time, update cadence, workaround, resolution and problem closure along an incident timeline, showing which of them most agreements actually commit to

What "24/7" Actually Covers

Continuous coverage is quoted almost universally and delivered in several quite different ways.

Full capability, continuously. The overnight team can diagnose and fix at the same level as the daytime team. Genuinely expensive and comparatively rare.

Triage overnight, capability by day. A staffed overnight function that logs, performs first-line diagnosis, and escalates. Whether anything gets fixed depends on the on-call arrangement behind it.

On-call rather than staffed. Nobody is awake until an incident is raised, and someone is then paged. Response times reflect waking a person, and this is often what a low-priced continuous-coverage offer describes.

None of these is wrong. Buying the third while believing you bought the first is.

Three questions clarify it: how many engineers are working at 3am on a Sunday; what can they resolve without escalating; and how long does escalation to a specialist take out of hours. Answers to those describe the service far better than the coverage clause does.

Follow-the-sun describes something more specific — a service passed between teams in different geographies so each works its own daytime. It is more sustainable than shift work, since nobody works permanently against their body clock, and its distinctive risk is handover. The right question is what is transferred at each handover and whether an incident in progress genuinely continues or effectively restarts. The geography trade-offs are covered in our comparison of offshore delivery locations.

Exclusions and Clock Stops

More disputes arise here than anywhere else in the document.

Common exclusions: third-party product defects; anything requiring vendor engagement; changes as distinct from incidents; issues arising from customer-made changes; problems in unsupported versions; and problem management as distinct from incident management.

Each is defensible. Together they can carve out a great deal, and the boundary between an incident and a change is often where the argument sits — a configuration fix to restore service is arguably both.

Clock-stop clauses pause the resolution timer while the provider waits on the customer. Reasonable in principle and abusable in practice: a request for information at the point of an approaching breach stops the clock, and vague information requests can stop it repeatedly. Negotiate that the clock stops only on a specific, actionable request, and restarts when the information is supplied rather than when the provider next looks at it.

Dependency exclusions matter most in a mixed estate. When an incident spans a supported system and an unsupported one, someone must own the incident end to end. Without that, an outage becomes a supplier discussion while the business waits. Name an owner for cross-boundary incidents in the contract.

Service Credits Are Not the Remedy

Most agreements provide credits against the monthly fee for missed targets. They are usually a small percentage, capped, and claimable only through a defined process.

Two implications. First, credits are rarely large enough to change provider behaviour — a modest percentage of a monthly fee does not compare with the cost of staffing to a level that never misses. Treating credits as the enforcement mechanism is therefore optimistic.

Second, credits are compensation for fee, not for business loss. An outage costing the business substantially is compensated by a fraction of one month's fee. That is normal commercially and worth understanding rather than discovering.

The mechanisms that actually change behaviour are elsewhere: sustained-underperformance termination rights, mandatory service-improvement plans after repeated breaches, governance meetings with named executive attendance, and — most effectively — a contract short enough that renewal is a live question.

The Terms Worth Negotiating Hardest

If negotiating capital is limited, spend it here.

Severity assignment by the customer, with a challenge process that does not downgrade during the challenge.

Resolution or update-cadence commitments, not response alone.

A named owner for incidents spanning the support boundary.

Tight clock-stop wording requiring specific actionable requests.

Exit provisions specifying what is handed over, in what format, and in what period. Agreed at signature, when leverage exists.

Notably absent from that list: the headline response time. It is the most negotiated term and among the least consequential.

Measuring the Service in Practice

Track resolution time by severity rather than response, first-contact resolution rate, repeat-incident rate, and the proportion of incidents where severity was disputed.

That last measure is diagnostic. Frequent severity disputes indicate either definitions that do not match your business or a provider under commercial pressure — both are worth addressing before they become a renewal argument.

Measure independently of the provider's reporting. Not from suspicion, but because a provider's figures are produced against their own definitions and their own clock. Two parties measuring the same service and agreeing is a good sign; only one party measuring is not a measurement. IdeaGCS provides this under its enterprise service-desk services.

Conclusion

A support agreement commits a provider to considerably less than most buyers believe, and the gap sits in four places: who assigns severity, whether resolution is committed at all, what continuous coverage actually staffs, and what the exclusions and clock stops remove.

Negotiate those four and the headline response time barely matters. Track resolution rather than response, watch the repeat-incident and severity-dispute rates, and measure the service yourself rather than reading the provider's report. Talk to IdeaGCS if you want an existing agreement reviewed against what your business actually needs.