Name the assets and service boundaries
List the website, hosting account, domain, content platform, integrations and third-party services that may be included. Identify which organisation owns each account and who can authorise a change. A plan that says ‘website support’ without naming these boundaries leaves both sides guessing when an incident spans several providers.
Separate routine maintenance from feature development, content editing, design changes, copywriting, campaign work and emergency recovery. State what is included, what is excluded and how out-of-scope work is estimated and confirmed.
One linked public discussion shows the scope question in practice: an owner of an 11-person HVAC business said they could not tell what a proposed ‘maintenance and hosting’ fee would deliver after hearing it covered hosting, security updates and two content changes. This is one self-reported example, not detail of a typical fee, UK demand or a working rule plan.
Describe the recurring work in operational terms
For each recurring task, state the system, frequency or trigger, responsible party and detail that it was completed. Depending on the stack, this could include dependency review, security updates, backup checks, form checks, uptime monitoring, broken-link triage or a monthly release review.
WordPress.org's maintenance guide covers scheduled updates, backups, link checks and validating a site after changes. Those are WordPress-specific examples, not a universal maintenance calendar; use the current guidance for the actual platform and agree a cadence that fits the site and its risk.
Avoid promising that a checklist prevents every outage or security incident. The plan should say what is monitored and what is not, how alert ownership works and which supplier remains responsible for a hosted platform or payment service.
- Covered sites, accounts and integrations
- Routine updates and review cadence
- Backup, restore and escalation responsibilities
- Monitoring scope and alert recipients
- Out-of-scope work and review route
Set response expectations without confusing them with resolution
Define support hours, contact route, severity examples, acknowledgement target and the information needed to triage an issue. An acknowledgement target is not a promise that a complex supplier or data problem will be fixed within the same period.
Specify how urgent incidents are escalated outside normal work and whether that route is part of the agreement. If there is no out-of-hours coverage, state that plainly so the business can plan a separate contingency.
Check restore and release procedures
Ask where backups are stored, who can initiate a restore, how often restore readiness is checked and what data may not be included. Record the recovery decision-maker and the steps required to return to a known-good version.
For a Next.js App Router site, official guidance covers production error handling, caching, accessibility, security configuration and checks such as a production build and simulated Lighthouse review. These are platform-specific examples, not a recurring maintenance schedule or support contract; use the relevant documentation for the site's actual stack and risk.
Use a one-page scope review before signing
Ask the provider to show one ordinary request and one incident moving through the plan. Check who receives the report, who can approve work, how time or fees are recorded and how the business receives a monthly status summary.
A support plan is useful when it makes ownership and response predictable. If the provider cannot identify the covered systems or the recovery decision-maker, resolve those gaps before treating a monthly fee as a complete risk-control measure.
The fictional entries below show how to make a plan testable. Replace the example cadence and response target with terms agreed for the actual site; an acknowledgement target does not promise that a fault will be fixed within that time.
| Work item | Trigger or cadence | Owner and response | detail and exclusions |
|---|---|---|---|
| Review core, theme and plugin updates | Monthly review; assess a relevant security notice sooner | Provider checks compatibility and proposes changes; the site owner approves material updates | Keep a dated update log and post-change checks. New features and content work are separate unless listed. |
| Check the main enquiry form | Monthly and after a form or deployment change | Provider submits a test; the site owner confirms receipt in the agreed inbox | Keep the test date and result. External CRM faults are excluded unless named. |
| Triage a support request | When an issue is reported | Example target: acknowledge by the next working day; agree a resolution estimate after diagnosis | Keep the ticket, severity, next update and result. Acknowledgement is not a fix promise; out-of-hours support is excluded unless listed. |