A software support Service Level Agreement is the part of a contract that sets out what happens after a system goes live. It defines how quickly a supplier will respond when something goes wrong, what they will actually do, and what consequences follow if they fail to meet those commitments. For any business relying on a CRM, customer portal, internal tool or SaaS product, the SLA is the practical difference between a brief inconvenience and a prolonged operational failure.
Decision summary: Define measurement, priority, response, restoration, exclusions, escalation, reporting and remedy as one operating commitment.
The first distinction to understand is between support and maintenance. Support covers incidents: unexpected errors, performance degradation, access problems and things that worked before but have stopped. Maintenance covers planned work: security patches, operating-system updates, dependency upgrades and minor adjustments to keep the system running on current infrastructure. Some contracts bundle both under one SLA; others separate them. Either way, the business needs to know exactly which activities are included and which are treated as chargeable change requests.
An SLA is not a guarantee that nothing will break. It is a commitment about what the supplier will do once a problem is reported. That distinction matters because businesses sometimes sign SLAs assuming they have bought reliability, when in fact they have bought a response process. Reliability comes from system design, hosting infrastructure, monitoring and testing. The SLA governs what happens when those measures are not enough.
| Contract area | Risk if unclear | What to record |
|---|---|---|
| What a support SLA should define | Without these elements, the SLA is a statement of intent rather than an enforceable commitment. | Put the agreed position, evidence and remedy in the signed documents. |
| Matching severity levels to business impact | Most SLAs use a tiered severity model, often labelled P1 through P4 or Critical through Low. | Record the requirement and remedy in the contract and relevant schedule. |
| Response time versus resolution time | Response time is how long until someone acknowledges the report and begins investigating. | Record the requirement and remedy in the contract and relevant schedule. |
| Coverage hours and communication | A 24/7 SLA costs more than business-hours cover because the supplier must maintain out-of-hours availability. | Record the requirement and remedy in the contract and relevant schedule. |
An SLA must describe service and remedy, not only target numbers
Response targets, restoration objectives, availability calculations, exclusions, maintenance, escalation, reporting and service credits should be read together. A fast acknowledgement is not a promise of resolution, and a percentage availability target can be misleading if the measurement window, excluded events and business hours are unclear.
What a support SLA should define
- The scope of covered incidents versus excluded work
- How incidents are classified by severity
- Response time targets for each severity level
- Resolution time targets, or a clear explanation of why resolution times cannot be fixed
- Communication channels and expected update frequency
- Escalation paths when the assigned person cannot resolve the issue
- Consequences of missing the agreed targets
- Hours of coverage: business hours, extended hours or round-the-clock
- Who has authority to classify severity and reclassify it
Without these elements, the SLA is a statement of intent rather than an enforceable commitment. The contract should reference the SLA directly and make clear that SLA performance is a contractual obligation, not an aspirational guideline.
The right SLA terms depend on what the software does and what the business loses when it stops working. An internal admin panel used by a small team during office hours has different requirements from a customer-facing portal that processes orders around the clock. A SaaS product serving paying subscribers carries a different level of commercial risk again. The SLA should reflect that variation rather than applying a single standard to every system.
Matching severity levels to business impact
Most SLAs use a tiered severity model, often labelled P1 through P4 or Critical through Low. The practical test is whether each level maps clearly to a real business scenario rather than being defined in abstract technical language. A P1 incident should mean something specific: the system is completely unavailable to users who need it right now, or data integrity is at risk. A P4 might mean a minor visual issue on a screen that few users visit. If the definitions are vague, the supplier has room to downgrade incidents and meet their targets on paper while the business continues to suffer.
Consider who decides the severity. If the supplier classifies every incident as P3 by default, the response time will be slower regardless of actual impact. The contract should give the business a clear mechanism to challenge a classification, ideally with a defined escalation point and a time limit for that challenge.
Response time versus resolution time
Response time is how long until someone acknowledges the report and begins investigating. Resolution time is how long until the problem is fixed. Both should appear in the SLA, and the gap between them matters enormously. A one-hour response with no resolution target means the business gets a quick acknowledgement but may wait days for a fix. A four-hour resolution target with no response commitment means the business has no visibility of progress until the deadline approaches.
For some issues, resolution time genuinely cannot be predicted in advance. A complex integration failure or a deep infrastructure problem may require investigation before any meaningful estimate is possible. In those cases, the SLA should require the supplier to provide an initial assessment and a revised resolution estimate within the response window, with further updates at defined intervals.
Coverage hours and communication
A 24/7 SLA costs more than business-hours cover because the supplier must maintain out-of-hours availability. The business decision is whether that cost is justified by the actual risk. If the system only processes work during UK business hours and users in other time zones do not rely on it, 24/7 cover may be an unnecessary expense. If the system handles automated overnight processes or serves international customers, the calculation changes.
Communication terms should specify the channel (ticketing system, email, phone), the minimum update frequency during an active incident, and who receives those updates. A support team updating a ticket that nobody in the business checks until the next morning does not meet the practical need, even if it technically satisfies the SLA wording.
Consequences for missed targets
Some SLAs include service credits: a percentage reduction in the support fee if targets are missed. Others include termination rights if performance falls below a threshold over a defined period. Some include nothing at all, relying on the commercial relationship to motivate the supplier. A business should decide which mechanism provides real leverage and ensure it is written into the contract rather than left as an informal understanding.
Assuming the SLA prevents problems
The most common mistake is treating the SLA as a substitute for system resilience. A strong SLA with weak infrastructure means frequent incidents and fast responses, which is expensive and disruptive. The SLA should be the last line of defence, not the primary risk strategy. Monitoring, backups, error handling and sensible architecture do more to prevent incidents than any response commitment can.
Accepting vague or one-sided language
Phrases such as "best endeavours", "reasonable efforts" or "as soon as practicable" have no measurable meaning. If the SLA uses this language for response or resolution commitments, it provides no enforceable standard. Every time target should include a specific number of hours or minutes, tied to a specific severity level, with a defined start point (usually the moment the incident is reported through the agreed channel).
Not covering data recovery
Restoring data from backups is often treated as a separate operational matter rather than an SLA item. For systems where data loss would be serious, the SLA should include recovery time objectives: how long it should take to restore the system to a working state from a backup, and what point in time the backup represents. This connects the SLA to the broader backup and recovery planning that the business should already have in place.
Ignoring the end of the support period
Support contracts have a finite term. When that term ends, the business needs to know what happens next. Can the contract be renewed on the same terms? Will the price increase? Is there a notice period? If the relationship ends, what support is available during a transition to another supplier? These questions belong in the contract alongside the SLA, because a good SLA for the current term provides no protection if the business cannot secure equivalent cover afterwards.
Not specifying excluded work clearly
Support SLAs typically exclude new features, changes to business logic, third-party system failures and problems caused by the business modifying the system without the supplier's involvement. These exclusions are reasonable, but they need to be stated explicitly. If the boundary between a bug and a change request is unclear, the supplier may classify legitimate defects as out-of-scope work and charge accordingly. The contract should include a defined process for resolving disputes about whether something is a covered incident or a change request.
Key questions to put to a supplier
- Who classifies incident severity, and what is the process for challenging a classification?
- What is the difference between a covered incident and a chargeable change request, and who makes that decision?
- Are response and resolution times measured in business hours or calendar hours?
- What happens if a P1 incident occurs outside the stated coverage hours?
- How are service credits calculated, and is there a cap on total credits in a billing period?
- What is the escalation path if the assigned engineer cannot resolve the issue within the target?
- Does the SLA cover problems caused by third-party integrations, and if not, how are those handled?
- What is the minimum notice period for changes to the SLA terms, and can the business reject those changes?
- What support is provided during a handover if the contract is not renewed?
Reviewing the SLA before signing is considerably cheaper than discovering its gaps during an outage. The business should read the SLA section of any support contract as carefully as the pricing and scope sections, and should be prepared to negotiate terms that reflect actual operational risk rather than accepting a standard template designed to protect the supplier.
Contract points to settle before signature
- Identify which signed document controls if schedules, proposals or emails conflict.
- Make the contract, schedules, statement of work and change-control process consistent with one another.
- Distinguish ownership, licence rights, practical access and third-party restrictions.
- Define acceptance evidence, remedies, liability allocation, exit assistance and governing law explicitly.
Primary guidance checked for this edition
Sources for “Software Support SLA: What a Business Should Ask For” were checked on 22 July 2026. Recheck the applicable rules, product documentation and contractual terms before implementation because these can change after the review date.