What a service level agreement should say for a small business
The service level agreement a small business actually needs: short, specific about severity and response, honest about hours, and reported monthly.
The short answer
A service level agreement for a small business should fit on a page and say five things. Which severity levels exist, with examples, and the response and resolution targets for each. The hours each level applies: critical around the clock through monitoring and on-call, the rest in defined business hours. What is monitored and who is alerted, because response targets mean nothing without detection. How actuals are reported, monthly, with times per incident. And the remedy when targets are missed. It should cover the whole service you experience, the site, the hosting, forms and integrations, not only the supplier’s own code. Uptime percentages are less useful than incident handling; a target for how fast a person responds and restores tells you more than a decimal. Twenty pages of enterprise clauses protect the supplier; one page of specifics protects you.
The one-page agreement
| Section | Contents |
|---|---|
| Severity table | Critical: site or checkout down, security incident, data exposed. Important: form not delivering, errors for some visitors, significant slowdown, certificate warning. Standard: content changes, small features, integration tweaks. Planned: larger improvements in the quarterly plan. Response and resolution targets and hours per level, with examples |
| Coverage | What the agreement applies to: the site, its hosting and configuration, forms, integrations the supplier built, DNS and certificates; what it excludes and why, such as third-party platform outages, with how those are handled anyway |
| Detection | What is monitored: uptime, errors, forms, certificates, domain, security signals; who is alerted, by what channel, at what severity |
| Reporting | Monthly: incidents with detected, acknowledged and resolved times against targets; updates applied; changes delivered; speed and security posture |
| Remedy | Service credits for missed critical and important targets; termination without penalty after repeated misses |
| Review | The table revisited yearly or when the business changes |
Writing it with your partner
- Agree what counts as critical for your business: a shop and a brochure site differ.
- Set targets the partner can meet with their monitoring and on-call, not aspirations.
- Define the hours honestly, and pick them from your exposure rather than from the template: if an outage costs money the moment it happens, a transaction system or a shop in its peak weeks, critical belongs at any hour and a named person belongs behind it. If your site is static and a rollback fixes most failures, monitoring at any hour with response in business hours is the honest arrangement. Say which one you are buying.
- List what is monitored and confirm alerts reach a named person.
- Agree the monthly report format with times per incident.
- Set modest, specific remedies.
- Keep it to a page and attach it to the maintenance contract.
Checking it works
The monthly report is the test: every incident with its times against the targets, every miss with its remedy applied, and the monitoring that caught it named. After a quarter, the pattern is visible: are incidents caught by monitoring or by customers, are targets met, is the classification consistent. An agreement that is reported against becomes real; one that is filed becomes decoration.
What this means for you
Insist on a one-page service level agreement with a severity table, hours, detection, monthly reporting of actuals and modest remedies, covering the whole service you experience. Skip the uptime decimals and the enterprise clauses. Then read the monthly report against it. That page, reported against, is what turns support from a promise into a service.
Frequently asked questions
Do we need an uptime percentage in the agreement?
It is common and less useful than it looks. On a modern static platform, uptime is high by construction, and what matters is what happens when something fails: how it is detected, how fast a person responds, how fast service is restored, and what you are told. A severity table with response and resolution targets, reported monthly with actuals, tells you more than a percentage.
What severity levels should we define?
Four is enough: critical, the site or checkout down, a security incident, data exposed; important, a form not delivering, an error for some visitors, a significant slowdown; standard, content changes and small features; planned, larger improvements in the quarterly plan. Each with a response target, a resolution target and the hours it applies, and with examples so nobody argues about classification during an incident.
What is a fair remedy?
Service credits against the monthly fee for missed critical and important targets, scaled to the miss, and a right to terminate without penalty after repeated misses. Modest and specific. The point of a remedy is to make the target real and give both sides a reason to keep it, not to compensate for a lost afternoon of sales, which no small contract can.