Use the Locate, Change, Preserve, Prove framework, a worked example, and a downloadable brief to turn a casual website edit into bounded, reviewable work.

A website change request template should do more than protect an agency from out-of-scope work. It should help a client describe the need, help the agency assess the tradeoffs, and give the person or AI doing the work a boundary they can actually follow.

Most forms cover the commercial decision: what is changing, why, how much it costs, when it will be ready, and who approves it. Those fields matter. But an approved request can still be a weak implementation brief. “Update the homepage CTA” does not identify which CTA, its approved destination, what should stay untouched, or what evidence makes the change complete.

I use a second layer built around four verbs: Locate, Change, Preserve, Prove. It turns the approved idea into an observable website change without pretending that a detailed prompt is the same as permission.

Why a normal change form is not enough for AI work

A conventional change request is a decision record. That is useful because a request, an estimate, an approval, and completed work are not the same thing.

Asana’s change request guidance includes the project, requester, description, reason, priority, implementation date, expected impact, and supporting details. Atlassian’s Jira Service Management documentation goes further by separating priority, impact, urgency, risk, timing, affected components, assignees, and approvers.

That separation is important. “Urgent” tells me when the client feels pain. It does not tell me how many pages the change touches. “Low effort” does not mean low risk. A three-word price change may be easy to type and commercially consequential.

AI adds another distinction. A human account lead may infer that “the blue button” means the primary hero link on the approved homepage. An agent needs enough evidence to identify it. If the request leaves room for interpretation, broad capability can turn a small request into a redesign.

The answer is not a fifty-field form for every typo. The answer is a short client intake followed by an agency-owned execution brief proportional to the impact.

Use Locate, Change, Preserve, Prove

The four-part framework keeps the brief focused on the finished website rather than on a vague instruction.

This is not only prompt structure. Locate and Change usually begin with the client. Preserve and Prove often need agency judgment because the client may not know that a button also carries an analytics event, opens a form state, or appears again on mobile.

Fork’s agent documentation recommends giving an agent an outcome and a verification target. I would make both explicit, then add the protected boundary. “Improve the CTA” is a direction. “Change this exact label and destination, keep these adjacent elements unchanged, and verify these results” is a work brief.

Start with one coherent request

One request should produce one decision. If a client asks to change the hero copy, add a pricing page, connect a booking tool, and update the navigation, split the work. The copy could be approved while the booking integration needs discovery.

I do not split every comma correction into a separate record. I split work when the pieces can have different answers to any of these questions:

• Can one part be approved while another is deferred?
• Does one part require a different fact owner, budget owner, or release owner?
• Can one part be implemented or rolled back independently?
• Does one part add a page, component, integration, data flow, purchase, or legal review?
• Would one part need different acceptance checks?

That rule keeps the request small enough to reason about without burying the client in paperwork.

Locate the current state precisely

“Homepage” is not always a complete location. A modern site can have desktop and mobile navigation, signed-in and signed-out states, modal panels, validation errors, language variants, and content assembled from reusable components.

A useful location block includes:

• the public URL or application route;
• the visible page, section, component, or content record;
• the relevant state, such as menu open, form submitted, or error shown;
• the current words, image, link, or behavior;
• a screenshot or other evidence when the target could be confused with a similar element.

Do not use a screenshot as the only source. It can show appearance while hiding the destination, semantics, repeated instances, or responsive behavior. Pair it with the route and a plain description.

Also identify the baseline. In Fork, file-changing agent work is checkpointed automatically, and the history documentation describes read-only checkpoint previews. That can help a reviewer inspect a known state. A restore is deliberate and replaces current workspace state, so history is not permission to roll back casually. It also does not prove that external messages, payments, vendor records, or every application record can be recovered.

Write the change as before and after

I prefer a short “Now” and “After” pair over a paragraph full of adjectives.

Now: The primary hero link says “Learn more” and opens the Services page.

After: The primary hero link says “Start a project” and opens the project inquiry heading on the existing Contact page.

The After statement is testable. “Make the CTA stronger” is not. If the client wants a stylistic exploration, say that the requested output is a proposal with two bounded options, not an unapproved live redesign.

Attach approved source material. For copy, include the exact words and the person responsible for the fact. For an image, include the approved file, usage rights status, intended crop, and meaningful alternative text where relevant. For a link, include the exact destination. Never place passwords, secret values, tokens, or private customer data in the request.

If the source conflicts with another live page, stop. The implementer should not decide which price, deadline, qualification, or legal claim is true.

Name what must stay unchanged

“Change only this” sounds precise, but it does not tell a reviewer what “this” includes. A label change may alter line wrapping. A new image may change the card height. A destination change may affect tracking or focus behavior.

Name the preservation boundary in ordinary language:

• keep the hero heading, paragraph, image, secondary link, and spacing unchanged;
• keep the desktop and mobile navigation items in the same order;
• do not change the contact form fields, recipient, validation, or confirmation;
• do not change unrelated metadata, analytics, integrations, or routes;
• preserve the signed-in and signed-out behavior.

A preservation note is still an instruction, not a technical lock. If the boundary matters enough to enforce, use an editing surface, role, branch rule, or release process that can enforce it. Fork’s roles documentation distinguishes editing, approval, deployment, invitation, and administrative authority. Project access does not automatically grant runtime administration. Your platform’s actual controls, not the wording in the brief, decide what an account can do.

For a wider setup covering client editing surfaces and prompts, use the AI website editing for clients guide. The change request is the record for one specific piece of work inside that operating system.

Separate impact from priority

The client should explain the business effect and the real date. The agency should assess delivery impact. Do not ask the client to estimate technical effort they cannot see.

This assessment can return four useful answers: approve as requested, approve a smaller option, defer to a later phase, or keep the current baseline. A change process should make “not now” as clear as “yes.”

If the site is already in ongoing care, connect the request to the website maintenance scope of work. A bounded content edit, a structural change, and remediation after a failed release may use different commercial lanes.

Turn approval into an execution brief

After the commercial decision, the agency owner should convert the request into a brief the implementer can use. I include five items:

1. Observable outcome: one sentence describing what a visitor can see or do afterward.
2. Allowed boundary: the exact pages, components, records, files, or services that may change.
3. Preserved boundary: the nearby and connected things that must stay unchanged.
4. Acceptance checks: facts, viewports, interactions, accessibility, metadata, and external destinations that need evidence.
5. Stop conditions: discoveries that require clarification rather than improvisation.

Useful stop conditions include a missing source, conflicting copy, a nonexistent target, an unapproved integration, a required purchase, an access change, a real payment, private customer data, or unrelated modifications. “Stop if the work expands beyond this component” is safer than silently solving a different problem.

The brief should also state whether the implementer may edit only, prepare a preview, or release. Approval of the idea does not automatically authorize production deployment.

Prove the result with checks matched to the change

Verification should follow the risk. A typo correction needs a factual and visual check. A new form needs labels, keyboard use, validation, destination, confirmation, and a marked test submission when authorized.

I choose from these checks:

• Fact: compare the finished words, dates, prices, claims, and links with the approved source.
• Scope: inspect the change summary for unrelated work.
• Layout: view the affected state at representative phone and desktop widths.
• Interaction: use the link, menu, form, booking, or checkout path that changed.
• Accessibility: inspect the affected headings, labels, image alternatives, contrast, keyboard path, focus, and resize behavior.
• Search and sharing: inspect titles, metadata, canonicals, URLs, redirects, and social assets when touched.
• Destination: confirm where a submission, event, notification, or record actually goes.

The W3C WAI Easy Checks cover titles, image alternatives, headings, contrast, text resizing, keyboard access and focus, forms, labels, and errors. W3C describes them as preliminary checks, not a definitive accessibility evaluation. Put that limitation into the brief rather than turning a quick pass into a conformance claim.

Ask for evidence, not “done.” A useful completion note says which route, state, viewport, interaction, and destination were checked, what passed, and what could not be verified.

Worked example: a homepage CTA change

This example is illustrative. Assume a fictional five-page consulting website with an existing contact form, no checkout, and no customer login. The client marketing lead owns the approved copy. The agency owns release.

Notice what the brief does not assume. It does not ask the implementer to create the missing anchor, change analytics, or test a live submission without authorization. Those discoveries return to the owner as decisions.

Use a definition of ready before work begins

A request is ready when the implementer can start without guessing about the goal, location, source, boundary, or authority. My gate is short:

• one coherent outcome is described;
• the exact current location and state are identifiable;
• approved facts and assets are attached or linked;
• preserved areas are named;
• scope, cost, and schedule have a decision;
• acceptance checks match the change;
• stop conditions are clear;
• the implementer and release owner have the required access;
• the brief contains no secrets or private customer data.

Download the website change request template for the client intake, agency assessment, execution brief, verification record, definition of ready, and worked example.

After release, record the new baseline and run the checks that only production can prove. If this change is part of a larger transfer of ownership, connect the record to the website handoff checklist so the client knows who requests, approves, implements, releases, and recovers future changes.

Make the brief small enough to use

The best template is not the longest one. It is the shortest record that lets everyone make the next decision without relying on memory.

Keep client intake plain. Let the agency add technical impact, preservation, and verification. Use one record for one decision. Scale the checks with consequence. Most importantly, keep approval and authority separate: a person can want a change without owning the budget, approve the copy without approving the release, or operate an editor without administering the runtime.

That is the advantage of a better change brief. It does not merely document that somebody asked. It tells the client what they are deciding, tells the implementer what is bounded, and tells the reviewer what evidence should exist.

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

Written by Chris Peterson. Sources checked 2026-11-01.