In this piece
The WordPress support contract template
Copy the block below into your own document and fill each bracket. It is organised the same way a reviewer or a dispute would read it: scope first, then the clocks, then the money and the exit.
Template, nine clauses
Core, plugin and theme updates: · Backups: · Security scanning:
Uptime monitoring: · Performance work:
hours or business days from the client raising an issue to the provider starting investigation.
hours or business days from the start of investigation to the issue being fixed, or a stated exception process where a fix cannot be completed in that window.
Cadence: · Retention:
Storage location:
Client access:
Updates tested on before being applied to the live site. Where a live update causes a fault, the reversal process is .
Where an update or change made by the provider breaks the site, the fix is .
Either party may terminate with days written notice.
The client owns all files, the database, content and custom code at all times, regardless of who hosts or maintains the site. On termination, the provider will hand over in within days.
Flat monthly fee: , covering
Billed separately:
Date _____________
For comparison, here is how NoDrama’s own response time and backup commitments read, tier by tier.
| Clause | What it needs to name |
|---|---|
| Scope of services | Each service by function, not a plan label |
| Response time | A number, and what “response” means (acknowledgment, not fix) |
| Resolution time | A separate number for when the issue is actually fixed |
| Backup specification | Cadence, retention, storage location, client access |
| Update testing and liability | Where updates are tested, who pays if a live update breaks the site |
| Termination notice | A stated number of days, in writing |
| Data and credential ownership | Client ownership at all times, handover format on exit |
| Pricing structure | What is flat fee, what is billed as overage |
How to fill each section
Scope of services
Name each service by function, not by the name of a plan. “Plugin and theme updates, weekly” tells a reviewer something. “Everything in the Pro plan” does not, because a plan description can change without the contract changing with it.
List core, plugin and theme updates, backup cadence, security scanning cadence, uptime monitoring and whether performance work is included, each as its own line rather than folded into a single sentence.
Read the finished clause back and confirm it names every service you are actually paying for. If a service you use is missing from the list, it is not covered, whatever the sales conversation implied.
Response time and resolution time
These are two different clocks, and treating them as one is the most common gap in a WordPress support contract. Response time is the period before the provider starts investigating an issue. Resolution time is the period before the issue is actually fixed. A contract that states only a response time has made no commitment about when the problem stops.
| Response time | Resolution time | |
|---|---|---|
| What it measures | Time to acknowledgment and start of investigation | Time to the issue actually being fixed |
| What a missing figure means | No promise anyone starts looking within a set window | No promise the fix happens by any point, even if someone looked at it fast |
| What to require | A number, in hours or business days | A separate number, or a named exception process for cases that cannot be closed in that window |
Generic enterprise SLA templates sometimes list severity-tiered figures, such as a thirty-minute response and a one-hour resolution for the most severe tier. Those numbers are illustrative examples from generic service level agreement boilerplate, not a WordPress-specific standard, and no verified industry standard figure for WordPress support response or resolution time exists. Treat any number you see quoted as someone’s convention, never as a benchmark you are failing to meet.
Confirm the contract states both a response figure and a separate resolution figure, not one number doing both jobs.
Backup specification
A backup clause that just says “we back up your site” is missing three of the four things that make a backup usable when you need it: cadence, retention, storage location and client access.
Cadence is how often the backup runs. Retention is how long a given backup is kept before it is overwritten. Storage location should be offsite, separate from the live server, so a server-level failure does not take out the backup with it. Client access is how you can actually get a copy: whether you can request one and how long that takes, or whether you have direct access at any time.
Confirm none of the four is silently missing. A clause naming three out of four is a partial promise, and the missing one is usually the one you needed.
Update testing and liability
State where updates are tested before they go live, typically a staging copy of the site rather than the live install. Then state what happens if a live update still breaks something: whether the fix is included in the flat fee or billed as extra work, and how the rollback happens.
Staging environments and rollback processes are common practice across managed WordPress providers, not something unique to any one of them, so the clause should describe your provider’s actual process rather than assume the practice itself is a differentiator.
Confirm the clause names where updates are tested before going live, and states plainly who is responsible for a live update that still breaks the site.
Termination and data ownership
Thirty days’ written notice recurs as a commercial convention in support contract practice. It is not a legal minimum, and nothing requires either party to use it, so word the clause as a convention you are choosing rather than a rule you are following.
The client owns the files, the database, the content and any custom code throughout the relationship, not only at the point of exit. On termination, the exit clause should specify that files, the database and credentials get handed over in a format you can actually use elsewhere, within a stated number of days.
Confirm the exit clause specifies file, database and credential handover in a usable format, not just a promise to “assist with migration.”
What a reviewer actually checks
Before signing, run the finished contract past this list:
- Are all eight elements named: scope, response time, resolution time, backups, update liability, termination, data ownership, pricing structure.
- Is a number attached to every time-bound clause, not a general assurance.
- Does the pricing section separate what is flat fee from what is billed as overage.
Run the finished contract past this checklist before signing, section by section, rather than reading it once end to end.
See how NoDrama writes these commitments into its own plan table.
No separate contract page, the plan table states it directly.
What this template does not cover
This is a template, not a legal document, and using it creates no attorney-client relationship with anyone. If your site handles e-commerce checkout or client data, have counsel review the finished contract before you sign it.
It also does not set a WordPress-specific industry standard figure for response or resolution time, because no research supports one existing. Every number in this piece is a named convention or an illustrative example from generic service level agreement practice, never a claimed industry standard for WordPress support.
Where teams get this wrong
Signing a plan description or a sales page as if it were the contract. A page describing what a service generally includes is marketing copy, not a document naming your response time, your backup retention or your termination notice.
Reusing a one-off web build contract for what is actually an ongoing recurring service. A build contract covers a project with an end date. It usually has no backup cadence language and no response time language at all, because neither existed as a concept during a one-time build.
Relying on a verbal or email understanding with nothing written down. A promised backup cadence mentioned on a call is not a clause, and it is not checkable later by either party.
NoDrama writes its own commitments into the plan table rather than a separate contract page. See the three plans and what each covers.
Conclusion
A WordPress support contract is only as strong as the eight things it names separately: scope, response time, resolution time, backup cadence and retention and storage and access, update testing and liability, termination notice, data ownership, and the pricing split between flat fee and overage. A document that describes maintenance in general terms without a number attached to each of those clauses is not a contract you can point to later, and the template above exists to close that gap one field at a time.