Software support SLA: define response and restoration

Write a practical software support SLA with severity examples, coverage windows, response obligations, restoration goals, exclusions and escalation.

A software support SLA should help both parties act during a problem. Phrases such as rapid response or full support are difficult to enforce because they do not define the clock, scope or expected action. Separate acknowledgement, investigation, restoration and permanent resolution. A supplier can respond quickly while the service remains unavailable; those are different outcomes and should not be reported as the same promise.

Define severity through business impact

Use concrete examples of affected journeys, users and available workarounds. A failed payment path may have greater impact than a cosmetic issue on a high-traffic page. State who can assign or change severity and how disagreement is resolved. Include security and data-integrity concerns in the classification process without assuming every alert proves an incident. Keep the matrix short enough for support staff to use under pressure.

Make the clock unambiguous

Specify timezone, business hours, holidays and out-of-hours coverage. Define when a valid request starts the clock, which communication channel is monitored and what information is required. If a timer pauses while awaiting customer action, describe the conditions and notification. Distinguish a contractual target from an estimate dependent on a third-party provider. Do not promise a universal resolution time for every unknown defect without defining the support boundary.

Specify responsibilities and exclusions

• Name the supported systems, environments and integrations, plus any unsupported versions or inherited defects.
• Assign access, approval and communication responsibilities to both customer and supplier.
• Define escalation contacts, update frequency and the procedure when a target is at risk.
• State whether emergency changes, root-cause analysis and permanent remediation are included or separately scoped.

Test the agreement with a scenario

Walk through a checkout outage late in the coverage window. Who receives the alert, who can deploy, who tells customers and what happens if the payment provider is unavailable? Revise unclear clauses before a real incident. Review service reports using the defined clock and outcomes, not only ticket counts. An effective SLA supports a workable operating relationship: each party understands what is promised, what evidence demonstrates it and what must happen when the service cannot meet that promise. Both parties should retain the same current agreement.

• Maintenance and support →
• Website Maintenance Checklist for Business-Critical Sites →
• Maintenance Retainer vs Pay-As-You-Go Development →