Sooner or later a client asks for “an SLA”. Sometimes it comes from their procurement team, sometimes from a new marketing director who has worked with larger suppliers, sometimes from a client who has just lived through an outage and wants something in writing. The request often arrives without a clear idea of what should be in it, and agencies tend to respond in one of two unhelpful ways: they paste in impressive-sounding response times they cannot keep, or they avoid the conversation.
There is a better middle path. An SLA is just a written description of the service, measured in ways both sides can check. Done well, it protects the agency as much as the client. This post explains what an SLA actually is, what goes into one for WordPress support and maintenance, and how to set targets you can honour. It is general information, not legal advice.
What an SLA is, in plain terms
SLA stands for service level agreement. It describes the level of service a provider commits to: what is covered, when it is covered, how quickly the provider will respond, how problems are prioritised, and what happens if the commitments are missed.
It is not the same as the main contract. A contract or terms of service covers the commercial relationship: payment, liability, intellectual property, termination. The SLA usually sits alongside it, often as a schedule or appendix, and deals only with how the service performs. Some agencies fold both into one document. What matters is that the service commitments are specific and written down.
It is also not a statement of work. A statement of work describes a project with an end. An SLA describes an ongoing service, such as maintenance, support or hosting management, that continues month after month.
Why an agency benefits from one
Without an SLA, every client carries their own private expectation. One assumes you will answer at midnight. Another assumes a typo fix should happen the same morning. When those unspoken expectations are missed, it feels to the client like a broken promise, even though nothing was ever promised.
A clear SLA turns those expectations into something shared:
- It tells the client what to expect before they need it.
- It gives your team a rule for prioritising when several clients need help at once.
- It gives you a fair basis for charging when a request falls outside the agreed service.
- It makes care plans easier to compare and sell, because the difference between tiers becomes concrete.
The parts of a workable SLA
Scope of service
Start with what the SLA covers. Name the sites, the environments (live, staging) and the kinds of work: updates, monitoring, backups, bug fixes, content edits, hosting liaison. Then list what it does not cover, for example new features, design changes, third-party services you do not control, or problems caused by changes made by someone outside your team. Exclusions prevent more arguments than any other clause.
Hours of cover
State when the service runs. Business hours, in which time zone, and what counts as a business day, including public holidays. If you offer anything outside those hours, describe it separately and be specific about which kinds of problem qualify. Do not describe cover you do not have staffed.
Priority levels
Group requests by how badly they affect the client’s business. Three or four levels are usually enough. Define each by its effect, not by how annoyed the client is. A ticket triage policy and an SLA should use the same definitions; our guide to sorting client requests by urgency has a fuller framework.
| Priority | Typical definition | Example |
|---|---|---|
| Critical | Site unavailable, or a core business function stopped | Site offline; checkout failing; site hacked |
| High | Important feature broken, with a workaround or partial impact | One payment method failing; forms not emailing |
| Normal | Problem with limited business impact | Layout glitch on one page; a broken link |
| Request | Change or small task, not a fault | Update text; add a team member page |
Response and resolution targets
This is the part people focus on, and where most mistakes happen. Two different measures are often confused:
- Response means a person has acknowledged the request and started on it. It is within your control.
- Resolution means the problem is fixed. It often depends on things outside your control: the host, a plugin developer, the client supplying information.
Many service providers commit firmly to response targets and describe resolution as a target or an aim, with a promise of regular updates until it is done. That is an honest split. Set the actual targets for each priority level based on what your team, and any partner you use, can deliver consistently on an ordinary bad week, not on your best one. If in doubt, leave placeholders such as [response target] in your template and fill them only after you have tracked real performance for a while.
How requests are made
Specify the channel that starts the clock: a support email, a ticket form, a shared channel. Say that a request sent to a personal phone or buried in an unrelated thread may not be picked up as quickly. This one sentence saves a lot of disputes.
Client responsibilities
The SLA should also say what the client must do: keep access working, tell you before changing hosting or adding plugins, give someone authority to approve fixes, and supply information when asked. The clock should pause while you are waiting on the client.
Measurement and reporting
Describe how performance will be tracked and reported, for example a monthly summary of requests and how each was handled. If you cannot measure a commitment, it does not belong in the SLA.
Remedies
Some SLAs include service credits: a reduction on a future invoice if a target is missed. They are common in hosting and larger IT contracts. For a small agency they are optional, and if you include them, define them narrowly, cap them, and make them the only remedy for missed service levels. This is the clause where a lawyer’s review is most worthwhile.
Review
Say when the SLA will be reviewed, such as at renewal. Sites change, businesses grow, and a level that suited a brochure site may not suit a store.
Uptime commitments: be careful
Clients sometimes ask for an uptime figure. Unless you run the hosting yourself, you do not control uptime; the host does. Rather than promising one, consider committing to what you can do: monitoring the site, alerting the client, raising a ticket with the host, and restoring service from backup if the host cannot. If you resell hosting, check the host’s own SLA and make sure yours is no stronger than theirs. Our piece on what a maintenance agreement should say covers related wording around hosting and third parties.
If you outsource the work, your SLA depends on someone else’s
When an outside team handles some of the support, your promise to the client is only as good as the partner’s promise to you. Line them up deliberately:
- Your agreement with the partner should define the same priority levels.
- Their targets to you should leave room for your own step of reviewing and replying to the client.
- Hours of cover need careful thought when there is a large time difference. A partner working while your team is offline can extend useful cover, but only if you agree who receives and approves overnight work.
- Agree what the partner sends you for reporting, so your monthly summary to the client is accurate.
The written terms with the partner, including confidentiality, belong in the same conversation; our article on what an outsourcing NDA and agreement should cover walks through those. The wider question of choosing and working with a partner is covered in our guide for agencies outsourcing WordPress work.
Sample SLA structure you can adapt
Here is an outline to start from. Replace bracketed items with your own terms.
- Service covered. Maintenance and support for [site list], as described in [plan name].
- Not covered. New development, design changes, third-party services, issues caused by changes outside our work. These are quoted separately.
- Hours. [Days and hours], [time zone], excluding [holidays].
- How to request support. [Support email or ticket form]. Requests elsewhere may be delayed.
- Priority levels. Critical, High, Normal, Request, as defined in the table.
- Targets. First response within [target] for each level during service hours. We aim to resolve each request as quickly as practical and will update you at [interval] on critical issues until resolved.
- Your part. Keep our access working, tell us before changing hosting or plugins, name a person who can approve fixes.
- Reporting. A [monthly] summary of requests and how they were handled.
- If we miss a target. [Your remedy, or a statement that there is none beyond review.]
- Review. This SLA is reviewed at each renewal.
Questions to ask before you sign one a client wrote
Larger clients may send their own SLA template. Before agreeing, check:
- Are the hours of cover ones you actually staff?
- Does “resolution” have a hard deadline for problems outside your control?
- Are there penalties, and are they capped?
- Does it cover systems you do not manage, such as their email or CRM?
- Does the clock pause while you wait for them?
- Can your partner, if you use one, meet the parts you would pass on?
If the answer to any of these worries you, propose changes. A client who wants an SLA generally wants clarity more than a particular set of targets, and most will accept honest terms over ambitious ones.
If you are building a care plan and want the delivery behind it handled to a written standard while you set the client-facing terms, our white-label care plan delivery is designed for that split.
Next in this series: How to Explain Technical Issues to Clients Clearly
