Use four maintenance lanes, an origin-and-impact matrix, a worked example, and a downloadable worksheet to make client edits compatible with a clear care plan.

A website maintenance scope of work gets harder to write once the client can edit. The agency may maintain the platform, the client may publish a new team member, and an AI agent may change several files from one request. When something breaks, ‘maintenance included’ does not say who investigates, what gets restored, or whether the repair consumes the monthly allowance.

I would not solve this by banning client edits or making the client responsible for every problem after they touch the site. I would define the operating state the agency agrees to preserve, then route work through four lanes: baseline care, agency changes, client changes, and recovery.

This guide includes a worked example and a downloadable website maintenance scope worksheet. It is an operational starting point, not legal advice. Have appropriate counsel adapt contractual terms for your business and jurisdiction.

Start the website maintenance scope of work with a maintained state

‘Keep the website working’ is not an acceptance criterion. A useful scope names the pages, systems, journeys, and outputs that should remain in an agreed condition.

For a small service-business site, that state might include:

• the production hostname serves the approved pages over HTTPS;
• the primary navigation and contact path work at representative phone and desktop widths;
• the contact form reaches the approved destination;
• the site remains on supported platform and dependency versions under the plan’s update policy;
• approved titles, canonicals, indexing controls, and sitemap remain in place;
• the client’s intended editing and publishing access remains configured;
• the documented backup and recovery process remains available.

This baseline is not a promise of uninterrupted availability, permanent search rankings, or perfect accessibility. It is the reference state used to classify requests and defects. Attach an identifier such as a release, snapshot, commit, or dated acceptance record so both parties know which version the service began with.

Inventory connected systems too. The visible site may depend on DNS, hosting, a content store, form delivery, analytics, email, a CRM, booking, payments, or an AI provider. A website snapshot does not automatically preserve them all.

Use four lanes instead of one bucket called maintenance

The word ‘maintenance’ often carries recurring care, support requests, content production, incident response, and feature work at once. I would separate those jobs even if the client buys one monthly plan.

Lane A is the care plan’s standing responsibility. Lane B is requested production work. Lane C acknowledges that the client can change the maintained site. Lane D answers the uncomfortable question before an incident: what happens when the cause is unclear or several people changed the system?

This structure also keeps improvement work visible. A new template, integration, conversion experiment, or content strategy is not routine care merely because the site already exists. The broader AI website agency services framework separates care from improvement for the same reason.

Write baseline care as targets, triggers, and evidence

A list of tools is not yet a service. ‘Backups, monitoring, updates, and SEO’ leaves the client guessing what the agency actually does.

For each recurring activity, specify five fields:

1. Target: the page, system, dependency group, form, or report being checked.
2. Cadence or trigger: weekly, monthly, before an update, after a release, or after an alert.
3. Action: review, test, update, investigate, or report.
4. Evidence: a timestamp, version, test record, status, or non-sensitive note.
5. Limit: what the activity does not establish or include.

For example, Google says Search Console can report how it crawls, indexes, and serves a site. Its documentation suggests checking around monthly or when content changes, while noting that the service can email about newly detected issues (Google Search Console documentation). A practical scope might include a monthly review of indexing and security reports plus a review after a material URL change. That is not constant monitoring or a ranking guarantee.

Accessibility needs the same precision. The W3C WAI Easy Checks cover items such as titles, image alternatives, headings, contrast, resizing, keyboard access, focus, and forms. W3C also says these checks are preliminary, not a definitive evaluation. Your scope can promise selected checks after relevant edits without promising complete conformance from a quick pass.

Classify client edits by impact, not by size

‘The client can make small edits’ sounds clear until a three-word change alters a price, a deadline, or a legal claim. Character count is a poor risk measure.

I would classify a client request with five questions:

1. Does it stay inside an approved content field or existing component?
2. Does it change a business fact such as price, availability, qualification, result, or deadline?
3. Does it affect navigation, layout, metadata, a form, or an integration?
4. Does it require new design, code, data, access, or a vendor?
5. Can the existing acceptance checks prove the result works?

The agreement should say whether the client may draft, approve, and publish each class. Those are different actions. If the platform cannot enforce a boundary, describe it as a process rule and keep release authority with the appropriate reviewer.

Fork’s current roles and permissions documentation separates roles and project permissions such as edit, approve, deploy, invite, and delete. It also says project access does not automatically grant sandbox administration. That is a useful workflow boundary, but it does not turn every agency rule into a content-level lock. Test the client’s actual role and editing surface. The client AI editing guide covers that setup in more detail.

Give client changes a short operating protocol

A self-service lane should be easier than opening a support ticket, but it still needs a repeatable path. I would use five steps:

1. Brief: name the page or record, exact outcome, approved source, elements to preserve, and verification target.
2. Preview: inspect the result before release when the platform supports that separation.
3. Verify: run the checks matched to the edit’s impact.
4. Release: use the agreed approval and publishing permission.
5. Record: retain a change summary and new baseline identifier.

Fork’s agent documentation recommends giving an agent an outcome and a verification target. That makes a client request more testable, but the prompt remains an instruction rather than an enforced permission.

On the Team page, add Jordan Lee using the existing team-member format and the approved bio and portrait attached to this request. Keep the card order, typography, links, and all other profiles unchanged. Check the full card at phone and desktop widths, confirm the image crop and alternative text, and stop if a new layout or field is required.

Define the escalation trigger in advance. If the request needs a new field, component, template, integration, or approval route, it leaves the client-edit lane. The client should not have to discover that boundary after an accidental redesign.

Scope remediation without turning it into a blame contest

Some agreements exclude every problem after a client edit. That protects the agency from unlimited repair, but it can make the service feel useless precisely when the client needs help.

I prefer an included triage step. The agency identifies the affected version, impact, likely system, and safest next action. After triage, the repair follows one of three commercial paths:

• Included remediation: an agency change failed its agreed acceptance check, or a covered baseline-care task was not performed as specified.
• Allowance work: a bounded client edit needs ordinary correction and fits the monthly change allowance.
• Separate estimate: the repair requires reconstruction, new design or code, specialist work, an external vendor, large content cleanup, or recovery outside the protected systems.

This rule is about responsibility, not punishment. Preserve evidence before changing more things: the request, actor, time, affected release, observed behavior, and relevant non-sensitive logs. Do not put secret values or private customer data in an incident record.

Also state what happens if the cause is still unknown. The client can approve a capped investigation, the agency can provide a written estimate, or both can pause at the safest known state. ‘Unlimited fixes’ should not silently become unlimited forensic work.

Separate response targets from resolution promises

A maintenance plan can control when someone acknowledges a request. It often cannot control when a platform vendor, DNS provider, payment service, or unknown defect will be resolved.

Define priority with observable impact, then give each priority a request channel, coverage window, acknowledgement target, update cadence, and resolution method.

Name conditions that pause the clock, such as waiting for client facts, access, approval, a reproducible example, or a third-party response. A resolution guarantee should appear only when you can truly staff and control it.

Make backup and recovery a separate mini-scope

‘Daily backups’ says nothing about what is captured or whether anyone can restore it.

For each protected system, name the data, frequency or trigger, retention, location, access owner, review process, restore-test cadence, and authorization required for a destructive restore. If you promise a restore point or recovery time, define the unit and assumptions.

WordPress is a useful example of why this detail matters. Its official backup documentation says a typical complete restore needs both the database and files. It also recommends checking automated backups and retaining recent copies in different locations. A file archive alone may not contain current posts, form records, or settings.

Fork automatically checkpoints file-changing agent work, and its history documentation describes read-only previews and deliberate restore. It also warns that restore replaces current workspace state. I would use that history for website changes while documenting connected services separately. Restoring the site does not unsend an email, reverse a payment, restore a vendor account, or guarantee recovery of every external record.

Worked example: a client-edited professional-services site

Assume a fictional five-page consultancy site with a contact form, a team collection, service pages, and an insights section. The client’s marketing lead can edit and publish collection content. The agency controls templates, navigation, forms, integrations, domain settings, and releases that touch code. There is no checkout or customer login. This is an illustrative service design, not a customer result or market-price recommendation.

Suppose the client adds a team profile and the portrait stretches the card on mobile. Triage confirms the image has the wrong aspect ratio but the template is intact. Replacing and checking the image is bounded allowance work. If the client asks for every profile to support a gallery and video, that is a schema and template change, so the agency estimates new scope.

Now suppose the contact form stops delivering after a vendor changes an account setting. The plan includes a form test and triage, so the agency confirms the visible behavior and destination. If restoring delivery only requires correcting an existing configuration the agency manages, the plan can define that as included. If the vendor requires a paid migration or the client changed account ownership, the agency gets approval for the external work. The distinction comes from the written system ownership and repair rule, not from an argument over who touched the site most recently.

Report evidence, not a vague claim that everything is fine

A short monthly record makes the scope easier to renew and easier to improve. I would report:

• baseline-care activities completed and their status;
• agency changes released with the allowance used;
• client changes reviewed, corrected, or escalated;
• incidents, affected versions, and remediation path;
• backup review and restore-test status;
• known issues with owners and due dates;
• work proposed outside scope;
• access or ownership changes that need attention.

Do not inflate this into a dashboard of numbers nobody uses. The report should let the client answer three questions: what was cared for, what changed, and what needs a decision.

Review the scope after the first month of real client editing. If almost every client change needs agency repair, the editing surface, training, or template may be the real problem. If every request becomes a change order, the included lane may be too narrow or poorly explained.

Turn the framework into a service schedule

The website maintenance scope worksheet includes the system inventory, maintained baseline, four lanes, client-change matrix, priority table, backup definition, verification record, monthly report, and exit plan.

Complete the worksheet before choosing package names. Then test the proposed scope against three realistic events:

1. The client publishes an ordinary update that works.
2. The client publishes a bounded update that needs correction.
3. A critical form fails and the cause is initially unknown.

If the document cannot explain the request route, initial response, commercial treatment, and evidence for all three, it is not ready.

Connect this service schedule to the ownership and training established in the website handoff checklist. The handoff explains how the client operates the site. The maintenance scope explains what the agency continues to own after that operation begins.

Common questions about maintenance when clients edit

Should client edits void the maintenance agreement?

I would not use a blanket rule. Define approved client-edit surfaces and include triage. Charge repair according to the maintained baseline, impact, cause, and written allowance. Reserve separate estimates for reconstruction, new capability, external recovery, and other named exclusions.

Are unlimited content edits a good offer?

Only if ‘content edit’ and the operating limits are precise. Define eligible fields, complete inputs, request channel, concurrency, turnaround method, approval, and exclusions. Unlimited eligible requests in a queue is different from unlimited simultaneous production work.

Does version history replace backups?

No. History may preserve website or workspace changes. A complete recovery plan may also need databases, uploads, DNS, vendor configuration, and external records. Define each protected system and test the relevant restore path.

Who owns the accuracy of client-published content?

The scope should assign a fact owner. The agency can check presentation, links, layout, and agreed technical outputs. The client or appropriate specialist should approve prices, dates, qualifications, legal claims, and other business facts they control.

Scope the operating relationship, not just a task list

Client editing does not make maintenance obsolete. It changes maintenance from ‘send every edit to the agency’ into a shared operating system.

Define the maintained state. Separate recurring care from requested changes. Give client edits a real lane. Include triage without promising unlimited repair. Name the recovery boundary. Then report enough evidence for both parties to see what the plan accomplished.

Fork is built for client websites with AI access, with project roles, agent workflows, checkpoints, and previews that agencies can shape into this kind of service. Workspaces are currently opening in batches. Join the Fork waitlist if you want to explore the workflow for your client sites.