The Client Handoff That Ends the 11pm "Can You Change One Word" Email

Every agency knows this client. The site launched in March. It is now September, and you have changed their opening hours four times, swapped a headshot twice, and fixed a typo they introduced while trying to fix a different typo. None of it was billed, because who invoices for changing "Tuesday" to "Thursday"?

The instinct is to blame the client, or to solve it with a maintenance retainer. But most small clients do not want a retainer for text changes, and chasing $75/month for edits you resent doing is not a business. The real fix is upstream: a handoff that leaves the client genuinely able to make routine edits themselves, and clear about where their editing ends and your paid work begins.

Here is the four-part handoff we recommend, with the exact things to hand over and a way to verify each part actually landed.

Part 1: Give the right amount of access (it is less than you think)

The single most common handoff mistake is handing over the admin login. Full admin access means the client can edit text, and also delete pages, uninstall things, and rearrange the layout you spent two weeks getting right. Then they call you to un-break it, and now you are doing free work that is also stressful.

Every serious platform has an editor-level role for exactly this reason. In WordPress it is the Editor role; Webflow and Framer both have a content-editor tier; site builders vary. Whatever the platform calls it, the test is the same:

1. The client CAN: change text, swap images, add a blog post, update hours and contact details.

2. The client CANNOT: edit layout, delete pages, change navigation, touch domain or billing settings.

3. Keep one admin account for the agency, in the CLIENT'S name if the relationship might end. Agency-owned logins holding a client's site hostage is how you end up in a bad Google review.

How to verify: log in as the client's account yourself and try to break something. If you can drag a section or delete the homepage, the role is too powerful.

Part 2: Build guardrails before you hand over the keys

Access control decides what the client can touch. Guardrails decide what happens when they touch it. Fifteen minutes of setup here prevents most of the classic disasters:

• Drafts by default. New blog posts and pages should start unpublished, so a half-written post never goes live by accident.

• Required fields with help text. If a blog post needs an excerpt and a featured image, make those fields required and write the image size in the field description ("landscape, at least 1600px wide").

• Image size notes where they upload. The 8MB straight-off-the-phone photo is the number one thing clients do to a fast site. A one-line note at the upload point catches most of them.

• A styles-locked template for new pages. If the client will add pages (a new service, a new team member), leave a duplicate-me template so new pages inherit the design instead of improvising it.

How to verify: create a test blog post as the client would. If you can publish it with no image, no excerpt, and a 9MB photo, the guardrails are not done.

Part 3: Train them on their own site, and make them drive

A screen-share where you click around for 45 minutes feels like training but is not. People retain what they do, not what they watch. The version that sticks takes 20 minutes:

1. Client shares THEIR screen, logged in as themselves.

2. They make three real edits while you talk them through it: change a line of text, swap an image, publish a short blog post. Real edits on the live site, not a sandbox. What they fix during training is a change they no longer email you about.

3. Record the call (Loom, Meet, Zoom, anything) and send them the link. The recording is the real training; the call is just where it gets made.

4. Watch for the moment they hesitate. Wherever they got confused is a line for the cheat sheet, not a personal failing.

How to verify: a week later, ask them to make one small edit without you on the phone. If they can, the handoff worked. If they cannot, redo the 20 minutes; it is still cheaper than a year of free edits.

Part 4: The one-page cheat sheet (and the price list)

The final artifact is a single page, PDF or shared doc, that answers the questions the client will have at 9pm on a Sunday when you are not answering the phone:

• Where to log in (the exact URL, because they will lose it).

• The five edits they will actually make, one line each: hours, text, images, new blog post, team member.

• What to call you for, WITH PRICES: new pages, design changes, "something looks broken". A rate on paper turns the 11pm favor into a normal business transaction.

• Who owns what: domain registrar, hosting, email, and where each renews. Clients discovering surprise renewals at month 6 is a trust-killer.

How to verify: send the cheat sheet to someone in the client's office who was NOT on the training call. If they can log in and change the opening hours using only the sheet, it is done.

The uncomfortable variable: the platform

Everything above gets easier or harder depending on what you built the site on. A stack with plugins to update and hosting to babysit means even a perfect handoff leaves maintenance work that someone must own, and "someone" is usually you, unpaid. This is exactly why we built StoryPress the way we did: clients edit by literally asking an AI assistant to make the change, there are no plugins to update, and hosting maintenance does not exist, so an agency can hand over a $5/month site with nothing left to babysit. We wrote up how the AI editing works in the MCP server announcement.

Whatever platform you use, the playbook stands: right-sized access, guardrails, training where the client drives, and one page of documentation with prices on it. Do those four things on your next launch and count the support emails that never arrive.