A Service Level Agreement (SLA) turns "we will support your application" into something both sides can measure. Without one, expectations drift and every incident becomes a negotiation.

1. Scope of support

Start by listing exactly what is covered: which applications, environments (production, staging), integrations and third-party services. Be equally clear about what is out of scope.

2. Priority levels

Define priorities in business terms, for example:

  • Critical: the application is down or a core function is unavailable for all users.
  • High: a major feature is broken, with no reasonable workaround.
  • Medium: a feature is impaired but a workaround exists.
  • Low: cosmetic issues, questions and minor enhancements.

3. Response and resolution targets

For each priority, agree on a response target (when someone starts working on it) and a resolution or workaround target. Keep targets realistic and aligned with the support hours you are paying for.

4. Support hours and channels

State the support window, time zone and how issues are reported: ticketing system, email or phone for critical incidents.

5. Escalation path

Name who is contacted, and when, if a critical issue is not progressing. A clear escalation path prevents delays during an outage.

6. Maintenance and change windows

Include how planned updates, patches and deployments are scheduled and communicated.

7. Reporting

Monthly reports should cover tickets raised and resolved, response performance, recurring issues and recommended improvements.

8. Responsibilities on both sides

The client usually provides access, timely approvals and a point of contact. The support provider handles diagnosis, fixes, communication and documentation.

A good SLA is short, specific and reviewed regularly. Its real value is not the penalties but the shared understanding it creates.