Software Support Contracts and SLAs: What to Look For
Software keeps living after launch: bugs appear, operating systems and libraries update, vulnerabilities are announced and business needs change. Running critical software without a support contract is like driving without insurance. So what should a good support contract include? At its centre is the SLA.
What is an SLA?
A Service Level Agreement defines the measurable commitments of a support service: how quickly an issue is responded to, how quickly it is resolved, during which hours service is provided and how available the system will be.
"We'll look at it as soon as possible" is not an SLA. An SLA contains numbers.
Response time is not resolution time
The two most commonly confused terms:
- Response time: until an engineer starts working on your ticket
- Resolution (or workaround) time: until the issue is fixed or a workaround lets work continue
If a contract only states response time, an automated "we received your ticket" email may technically meet it. Both must be defined.
Priority levels
| Level | Example | Expectation |
|---|---|---|
| Critical | System down, risk of data loss | Fastest response, including out of hours |
| High | Key function broken, no workaround | Same business day |
| Medium | Function faulty, workaround exists | A few business days |
| Low | Cosmetic issue, enhancement request | Planned release |
The contract should define each level with examples; otherwise everything gets reported as critical, or nothing is accepted as such.
What a support contract should include
- Scope: which applications, environments and integrations
- Service hours: business hours or 24/7, public holidays
- Priority definitions and times: response and resolution separately
- Reporting channel: email, portal, phone — and who to reach in a critical incident
- Preventive maintenance: security patches, library upgrades, backup checks
- Monitoring: catching problems before users notice
- Development hours: a monthly pool for small improvements
- Reporting: monthly tickets, times and system health
- Exclusions: what is billed separately
- Exit plan: handover of documentation and access when the contract ends
Software built by another team
If someone else built the software, a technical review before signing is healthy for both sides: code quality, test coverage, dependency freshness and documentation are assessed so the SLA rests on realistic ground.
Conclusion
A good support contract doesn't just tell you who to call when something breaks — it prevents most things from breaking. See our approach to software support and plan options on the pricing page. For applications that talk to external systems, integration monitoring can be included through system integration.