Topics: Custom software & SaaS
Want this done for your business? Get a fixed quote or book a free 30-minute call.
Quick answer: A useful support SLA names three or four severity levels with real examples, sets a response time and a fix-or-workaround time for each, states the covered hours in your own time zone, and separates maintenance from new work. It also covers monitoring, reporting, escalation and handover if you leave. For most small-business systems, about 99.5% monthly uptime plus planned maintenance windows is a sensible target.
Most support contracts get read properly exactly once: on the evening something breaks. That is the wrong moment to learn that "priority support" meant an email reply the next working day. If you are still deciding how much to spend each year, start with budgeting for maintenance and support; this checklist covers what the contract itself should say.
What is a software support SLA, and does a small business need one?
A service level agreement turns "we'll look after it" into promises you can measure: how fast someone responds, how fast a problem is fixed or worked around, which hours are covered and what happens when targets slip.
You need one if the software takes money, takes bookings or holds customer records your team relies on daily. A simple internal tool used by three people can live on pay-as-you-go support; a customer portal or ordering app cannot, because downtime there costs revenue within hours. Two or three plain-English pages answering the questions below are enough.
How should severity levels be defined?
Use three or four levels and attach examples from your own system. Labels such as "critical" and "high" invite arguments at the worst moment; "customers cannot pay" does not.
| Severity | Meaning | Examples for a booking or ordering system |
|---|---|---|
| 1 – Critical | System down, data exposed, or a core revenue function failing for everyone | Checkout fails for every user, nobody can log in |
| 2 – High | A major function fails with no reasonable workaround | Payment confirmations not sending |
| 3 – Medium | Broken, but a workaround exists | One report filter misbehaves |
| 4 – Low | Cosmetic issues and how-to questions | A typo or misaligned button |
Write down who can declare a Severity 1 and how: a phone call or dedicated channel, not an email sitting overnight in a shared inbox. The supplier should only downgrade a ticket with your agreement or a written reason.
What is the difference between response time and resolution time?
Response time is when a qualified person starts working on the problem. Resolution or workaround time is when your business can operate again. Plenty of contracts promise only the first, which is the less useful of the two.
An automated acknowledgement is not a response; a person investigating and sending you a first update is.
A permanent fix cannot always be promised, since some bugs take days to trace or depend on a third party such as a payment gateway. Good SLAs therefore set a workaround target for urgent issues: switching off a broken feature, rolling back the last release, or processing affected orders by hand. Rollback only works if deployments are reversible, so ask how releases are done.
Illustrative targets a small team can realistically meet (negotiate your own):
| Severity | Response | Workaround or fix | Updates to you |
|---|---|---|---|
| 1 – Critical | Within 1 hour in covered hours | Workaround within 4 hours | Hourly until stable |
| 2 – High | Within 4 working hours | Within 1–2 working days | Daily |
| 3 – Medium | Within 1 working day | Next scheduled release | Weekly |
| 4 – Low | Within 3 working days | Planned into the backlog | On request |
Treat these as a starting point, not a standard. Tighter numbers cost more because someone must be on call for you.
What coverage hours work across India and Australia time zones?
Match coverage to your trading hours and write those hours in your own time zone. "Business hours" means nothing in a contract between a team in Bengaluru and a clinic in Sydney.
Do the arithmetic. India runs on IST (UTC+5:30). Sydney is 4.5 hours ahead on standard time and 5.5 hours ahead during daylight saving, so 9am in Sydney is 4:30am or 3:30am in India. Perth is 2.5 hours ahead all year; London is 4.5 to 5.5 hours behind.
An offshore team can cover Australian hours well if the SLA says so and the supplier rosters for it. Arrangements that work:
- An early shift in India covering the Australian morning, plus on-call cover for Severity 1
- Round-the-clock cover for Severity 1 only, with everything else in office hours
- Weekend Severity 1 cover for businesses that trade on weekends
Say whose public holidays apply, too; Diwali and Australia Day sit on different calendars.
What is included, and what counts as new work?
Keep "keeping it healthy" separate from "making it do new things". Without that line, small feature requests quietly eat the retainer and nothing is left for the security patch that matters.
Normally included in a maintenance SLA:
- Fixing defects in features that were delivered and accepted
- Security patches for the framework, libraries and server
- Dependency and operating-system updates that keep the system running and in the app stores
- Monitoring, backups and restore tests
- Small configuration changes such as wording and user roles
Normally quoted as new work:
- New screens, reports or integrations
- Changes to agreed behaviour ("could it also…")
- Clean-ups after user error
- Rework caused by a third party changing its API, unless the contract assigns that cost
Tie-breaker for grey areas: if the software no longer does what the accepted specification says, it is a fix; anything the specification never covered is an enhancement.
Is an uptime guarantee worth paying for?
Each extra "nine" is harder to guarantee and costlier to run, so buy the availability your business actually needs. Here is what common targets allow in a 30-day month:
| Uptime target | Downtime allowed per month (approx.) |
|---|---|
| 99% | 7 hours 12 minutes |
| 99.5% | 3 hours 36 minutes |
| 99.9% | 43 minutes |
| 99.99% | 4 minutes |
Most small-business systems are well served by about 99.5% a month, excluding maintenance announced in advance and scheduled outside trading hours. Beyond 99.9% you are paying for redundant servers, automatic failover and round-the-clock engineers.
Two details matter more than the headline: how uptime is measured (an external monitor checking a real page every minute or so, not the host's dashboard) and what happens when it is missed. Service credits off the next invoice are common; they will not cover lost sales, but they keep attention on the problem.
What reporting, escalation and exit terms belong in it?
This part protects you over years, not just during incidents. Check that the agreement covers:
- Monitoring. Uptime, error rates and failed background jobs, with alerts going to the supplier and to a named person on your side.
- Backups you have seen restored. Daily backups, with a restore test at least quarterly. See security basics to ask for for more.
- A monthly report. Tickets by severity, targets met or missed, uptime, updates applied, hours used and upcoming risks.
- Named contacts. A day-to-day contact and an escalation contact with authority, such as a director.
- Remedies. Service credits, and a right to end the agreement if Severity 1 targets are repeatedly missed.
- Term and notice. Month-to-month or a short minimum term; long lock-ins favour the supplier.
- Handover on exit. Code, access, credentials, documentation and a cooperation period (30 days is reasonable). Our software handover checklist lists what to collect.
All of this is easiest to agree straight after go-live. During the first 90 days after launch, the system's weak spots are fresh, so severity examples practically write themselves.
Frequently asked questions
What is a reasonable response time for a critical software issue?
For a small business, one hour within covered hours is a common, achievable target for a system-down issue, with a workaround within a few hours. Round-the-clock response is possible but needs paid on-call cover.
Does a support SLA cover new features?
Usually not. An SLA covers fixes, security updates and keeping the system running; new features are quoted separately. If your retainer includes hours for small enhancements, list them apart from support so urgent fixes are never squeezed out.
What uptime should a small business ask for?
Around 99.5% a month, excluding announced maintenance, suits most booking, ordering and portal systems. A busy checkout where every minute offline costs money may justify 99.9%. Ask how uptime is measured before comparing suppliers.
What happens if the developer misses the SLA?
Only what the contract says, which is why remedies must be written in. Typical ones are service credits, escalation to a senior contact and, after repeated Severity 1 misses, a right to terminate early with a full handover.
Can an offshore team support Australian business hours?
Yes, if the hours are written into the SLA in Australian time and the supplier rosters for them. A team in India can start early to cover the Australian morning, with an engineer on call for critical issues. Remember that daylight saving shifts the overlap.
Get support terms you can rely on
We build and look after custom software for businesses in India, Australia, the UK and the USA, and our agreements spell out severity levels, hours and handover in plain English. See how we approach software support and maintenance, or send us your current contract and we will point out the gaps. Prefer a conversation? Book a free call.