A practical handoff for agencies: set the scope, test the permissions, and help your client make their first useful update.

A website handoff checklist needs one extra layer when the site comes with AI editing: the client needs to understand what they can ask for, what their account can actually change, and how to get help when a change needs the agency.

I would judge the handoff by a simple test. Can the client make one useful update, check the result, and explain what they would do if it went wrong?

Sharing a login does not answer that question. Neither does a recording of me making the change on their behalf.

This is the process I would use for an agency-built website with AI access. It includes a permissions worksheet, a first-edit exercise, a support boundary, and a checklist you can download without giving me your email.

What changes when your client has an AI editor?

A conventional handoff teaches someone where to click. An AI website handoff also teaches someone how to describe an outcome.

“Replace the hero headline with these exact words” is a fairly bounded task. “Make our site more premium” leaves decisions about typography, spacing, imagery, and copy to the system.

Both are reasonable requests from a client. They should not automatically have the same path to the live site.

I would separate three things before training anyone:

• Capability: what the editing system can do.
• Permission: what this person's account is allowed to do.
• Process: what we have agreed they should do themselves.

A note saying “please leave the navigation alone” describes a process. It does not prove that the account is technically prevented from changing navigation. If I promise a protected boundary, I need to verify the product actually enforces it.

That is why I would finish the permissions check before the client training call. A confident demonstration from my administrator account tells me very little about their experience.

1. Decide who owns what after launch

The first document I would write is one page long: who owns the domain, who pays for the platform, who can invite collaborators, and who responds when something stops working.

These questions belong in an ordinary handoff too. Webflow's agency collaboration guidance calls out ongoing access, maintenance, and responsibility for changes as part of the working agreement.

AI adds another practical question: who pays for editing usage, and what happens if the agreed allowance is exhausted? I would put the answer next to hosting and support, using the actual terms of the client's plan.

For a small agency project, my worksheet would look like this:

“The agency” is not a useful emergency contact. I would name a person or monitored support channel, plus a backup if the first contact is away.

I would also write down the exit arrangement. If the client leaves, who retains the domain, how is their content delivered, and which services need replacement? Agreeing on this before launch makes the ongoing service easier to understand.

2. Build a permissions worksheet, then test it

Start with the client's actual jobs. A restaurant manager might need to update opening hours and a seasonal menu. An architecture studio might need to add a project description and replace an image.

Neither job automatically requires organization administration, billing access, or control of application secrets.

In Fork, roles and permissions distinguish administrators, editors, commenters, and viewers. Custom roles can use project permissions such as editing, approval, deployment, and invitations, subject to a role ceiling.

That gives me a starting point for access design. It does not establish that every content-level rule I write down is a built-in, enforceable restriction.

I would use a separate test account with the intended client role. Try an allowed task and a restricted task. Confirm what happens when that account attempts to invite another person, publish, or reach an administrator-only setting.

If a boundary cannot be enforced at the level the project needs, I would change the workflow. Keep that work behind agency review, choose a narrower editing surface, or revise the promise before selling it.

There is a second boundary to check on sites with customer accounts. Fork's user documentation separates people who administer a space from people who use its application. Project permissions do not replace authorization inside the app.

A client portal that lets two customers see each other's records has a problem that a better handoff video cannot solve. Test those application permissions separately.

3. Capture the baseline and agree on recovery

Before the first client edit, I would record the approved version, the key pages, and the flows that must keep working.

My baseline would include desktop and phone screenshots, the contact form destination, primary calls to action, page titles, and any booking or checkout flow. The list should match what the site actually does.

In Fork, file-changing agent and MCP work is checkpointed automatically. The history documentation also describes read-only checkpoint previews and restoring a selected snapshot.

I would show the client where history lives, then explain who is responsible for recovery. An agency can make history useful without asking every client to become the recovery operator.

A restore can replace later work, so I would identify the exact version and preserve anything newer that matters before doing it. I would also check application data and connected services separately rather than assuming a website snapshot reverses every external action.

The handoff note should answer: “If an update goes wrong, stop editing, send this information, and contact this person.” That is more useful under pressure than a generic promise that everything is backed up.

4. Let the client make the first real edit

I would structure the training around one small change the client already needs. Updating a service description is better than making up a task just to demonstrate the AI.

The client should use their own account and share their screen. I would talk them through the process while they do the work.

1. 01DescribeOne bounded change
2. 02InspectRead what changed
3. 03CheckPhone, links, forms
4. 04ConfirmFollow the agreed release path

Here is a prompt I would give them as a starting point:

On the homepage, replace the introductory paragraph under “Our services” with the text below. Keep the heading, typography, spacing, images, and links as they are. Show me what changed and check the result at phone and desktop widths. If the change requires anything outside this paragraph, explain that before continuing.

This narrows the request and gives the agent something concrete to verify. It is still an instruction, not a permission system. The account's actual access controls need to support the process.

Fork's agent guide recommends giving the agent both an outcome and a verification target. I would make that a habit from the first client session: describe the change, then describe how to check it.

After the update, ask the client to read the result aloud. That catches surprisingly ordinary mistakes: an incorrect date, an offer that has expired, a phone number copied from an old page.

Then inspect the page at phone width, follow the primary link, and check the relevant flow. If a form is involved, use a clearly marked test submission and confirm it reaches the intended destination.

The exercise is complete when the client can repeat the process in their own words. If they are still guessing where the change went or whether it is live, I would simplify the instructions before adding more features.

5. Use this website handoff checklist

This is the checklist I would keep beside the handoff call. The boxes are for this visit; download the text version if you want a project record.

I would keep a completed copy with the project notes and share the relevant parts with the client. The reusable version includes the ownership worksheet and a short handoff email.

Domain readiness deserves its own check. If the project uses a custom hostname, Fork's domain setup includes ownership verification, routing, and certificate provisioning. I would confirm the intended live address works before describing the handoff as complete.

6. Define what the ongoing service includes

Giving clients AI access changes what they can do themselves. It does not remove the need to say what the agency is selling after launch.

I would describe the ongoing service in concrete terms: hosting administration, access management, usage allowance, monitoring, support, and any agreed improvement work. Only include services the agency will actually provide.

Then I would give examples of requests that need a separate estimate: a new booking system, a redesigned page template, a new integration, or a change to the site's commercial workflow.

“Small updates included” leaves room for two completely different interpretations. “One monthly content review, named support hours, and the editing allowance listed in your plan” is easier to operate.

I would avoid promising that AI access eliminates all support. The useful goal is to let clients handle suitable routine work while making it easy to identify the changes that need the agency.

A week after handoff, I would ask three questions: What did you try to update? Where did you hesitate? What did you still send to us?

Those answers tell me whether the next improvement belongs in training, the product setup, or the service agreement. I would record them before deciding that another tutorial is the answer.

Questions I would settle before handoff

Should a client get administrator access?

Only when their responsibilities require it. I would start with the work they need to do, choose the appropriate role, and test that role. Billing, invitations, editing, and deployment should each have an explicit owner.

Can instructions guarantee that an AI will leave the design alone?

I would not make that guarantee from instructions alone. Clear prompts reduce ambiguity; verified permissions and a suitable review process establish the boundary. If the product cannot enforce a required restriction, change the workflow.

Is saving a change the same as publishing it?

It depends on the platform and setup. For example, Wix Studio documents saving, previewing, and publishing as separate steps. I would demonstrate the actual behavior of the client's site instead of borrowing assumptions from another editor.

How long should the training call be?

I would scope it around completing one useful edit, reviewing the result, and explaining recovery and support. If that does not fit comfortably into the planned session, reduce the number of tasks. A long feature tour is a poor substitute for a successful first update.

What should I send after the call?

The live URL, sign-in instructions, the approved scope of client edits, a short recording or written guide, the recovery contact, and the support arrangement. Webflow's handoff guide is a useful reference for the broader documentation and training work.

Make the first update part of delivery

My acceptance test would be a client making a real update with their own access, then checking that the site still does its job.

If they can do that, know the limits, and know how to get help, the handoff has something concrete behind it.

Fork is built around client websites with AI access. If you are exploring that workflow for your agency, start with one client, one ordinary edit, and the checklist above. Join the Fork waitlist to follow the product and try the approach as access becomes available.