When an organisation signs a support contract, the service-level agreement is the part most people skim and later regret. A weak SLA reads well in a sales meeting and falls apart during the first serious outage, when it turns out that “four-hour response” meant an automated acknowledgement rather than someone actually fixing the problem. A strong SLA, by contrast, sets shared expectations that protect both sides: the business knows what it can rely on, and the support team knows what it is accountable for. This guide explains how to structure a support SLA that reflects real operational risk rather than optimistic marketing.

Start with severity, not speed

The most common mistake is to promise a single response time for everything. A login outage affecting every customer and a cosmetic typo on an internal page are not the same problem, and treating them identically either over-services the trivial or under-services the critical. A sound SLA begins by defining severity levels, each tied to genuine business impact rather than the requester’s mood.

• Severity 1 (critical): a core service is down or unusable, with no workaround, affecting many users or revenue.
• Severity 2 (high): major functionality is degraded or a workaround exists but is painful, affecting a meaningful group.
• Severity 3 (medium): a non-critical feature is impaired, with a reasonable workaround available.
• Severity 4 (low): minor issues, cosmetic defects, and routine requests with no operational impact.

Agreeing these definitions in plain language, with examples drawn from the actual application, prevents the recurring argument over whether a given ticket is “really” critical.

Separate response time from resolution time

Two distinct clocks matter, and conflating them is how SLAs mislead. Response time is how quickly a human acknowledges the issue and begins work; resolution time is how quickly the issue is actually fixed or a reliable workaround is in place. A contract that only commits to response time is committing to attention, not to outcomes.

Because not every problem can be fixed on a fixed schedule, mature agreements handle resolution carefully:

• Set firm response targets per severity, since acknowledging and triaging is fully within the supplier’s control.
• Express resolution as a target with a defined escalation path, recognising that some root causes are genuinely complex.
• Require regular, time-boxed status updates on unresolved critical incidents so the business is never left guessing.
• Distinguish a permanent fix from a temporary workaround, and state which one stops the SLA clock.

Define coverage windows that match real risk

Coverage is where cost and protection meet. Round-the-clock support sounds reassuring, but it is expensive and often unnecessary for systems that nobody uses overnight. The right window is the one that maps to when the application genuinely matters to the business.

• Business hours coverage suits internal tools and back-office systems with no out-of-hours dependency.
• Extended hours coverage fits customer-facing services that peak in evenings or across nearby time zones.
• 24×7 coverage is justified for revenue-critical or safety-relevant systems where any downtime is unacceptable.

It is also worth defining how public holidays and planned maintenance windows are treated, since these are a frequent source of disputes when they are left unstated.

Make the SLA measurable and reviewable

An SLA that cannot be measured is merely a statement of intent. The agreement should name the specific metrics that will be reported, the source of truth for those numbers, and the cadence at which performance is reviewed together. This is what turns a contract from a defensive document into a working relationship.

• Time to first meaningful response per severity, measured from when the ticket was raised, not when it was noticed.
• Resolution within target as a percentage, broken down by severity so a flood of trivial tickets cannot mask slow critical fixes.
• Reopened-ticket rate, which exposes fixes that did not actually hold.
• Backlog trend, showing whether issues are being cleared faster than they arrive.

Beware vanity metrics

Some numbers look impressive while hiding poor service. A high “tickets closed” count means little if tickets are closed prematurely and reopened days later. An excellent average response time can disguise a handful of critical incidents that took far too long. Always pair an average with its outliers, and weight the metrics that reflect business pain rather than ticket-queue housekeeping.

Build in escalation and shared accountability

Even a well-written SLA will occasionally be missed, and how that is handled matters more than pretending it will never happen. A clear escalation ladder, naming who is contacted and when as an incident ages, prevents a stuck ticket from quietly languishing. Equally, the agreement should acknowledge the customer’s own obligations, such as providing timely access, accurate information, and a single point of contact, because support cannot meet its targets when it is starved of what it needs to work.

Where engineering depth strengthens an SLA

The hardest support commitments to honour are resolution targets for complex defects, because those depend on genuinely understanding the system, not just triaging tickets. Support that is backed by hands-on software engineering can diagnose root causes rather than repeatedly applying surface-level patches, and AI-assisted analysis of logs and incident history increasingly helps spot recurring patterns before they escalate. Combined with disciplined service management, this is what allows a realistic SLA to be set and then consistently met, rather than negotiated optimistically and quietly missed.

Key takeaways

• Define severity levels by genuine business impact before committing to any time targets.
• Separate response time from resolution time, and never let acknowledgement masquerade as a fix.
• Match coverage windows to when the system actually matters, rather than defaulting to expensive 24×7.
• Make the SLA measurable with metrics that reflect business pain, and review performance on a regular cadence.
• Include an escalation ladder and the customer’s own obligations, so accountability runs both ways.

If you are negotiating a new support contract or suspect your current SLA is protecting the supplier more than your business, an experienced review can sharpen it considerably. Glaricx Technologies pairs hands-on software engineering with disciplined service management in our Support & Maintenance service, helping organisations agree realistic, measurable support commitments and then meet them. Whenever you would like a candid view on whether your support arrangements truly fit your operational risk, we are glad to talk.