Client Handoff Documentation That Gets Read After Launch

Six months after launching a client’s site, they call because they can’t log in to edit a page. You’ve moved on to other projects. The team member who handled that project has moved on. Someone spends an hour recovering a password to a system that was documented — in a 40-page PDF that the client printed once and lost.

This is the standard outcome of most agency handoff documentation. Not because the documentation was wrong, but because it was in the wrong format, in the wrong location, and covered the wrong things.

Good handoff documentation is designed for the person who will need it under stress six months from now, not for the person writing it at the end of a well-understood project.

What Clients Actually Read

Clients read things that answer the question they have right now. They don’t read documentation for learning — they scan it to find a specific answer.

In practice, this means:

They read access documents. Where do I log in? What’s the password? Who do I call if this is broken?

They read how-to steps for the things they do most often. Publish a new blog post. Update the team member list. Change the home page headline.

They read the escalation path. Who handles hosting issues? Who do I call if the site is down?

They don’t read architecture diagrams, rationale for technology choices, full API documentation, or changelogs — at least not on their own. That information belongs somewhere accessible if a future developer needs it, but it’s not what the client will actually look for.

The Three Documents

Every project should produce three separate documents, not one comprehensive one.

Document 1: The Access Sheet

A single page listing every account that exists for this project, with login instructions for each.

## Hosting
Platform: Vercel
URL: vercel.com/dashboard
Login: client@company.com (Google login)
Project name: client-website-prod

## CMS
Platform: Contentful
URL: app.contentful.com
Login: client@company.com
Password: [stored in 1Password > Client > Contentful]

## Domain Registrar
Platform: Namecheap
URL: namecheap.com
Login: client_username
Password: [stored in 1Password > Client > Namecheap]
Auto-renew: Enabled (card ending 4242)
Expiry: 2028-03-15

## DNS
Provider: Cloudflare (managed by agency)
Note: We manage DNS on your behalf. Contact us before making DNS changes.

## Analytics
Platform: Google Analytics 4
Property ID: G-XXXXXXXXXX
Access: client@company.com is Owner

## Email Service
Platform: Resend
URL: resend.com
Login: client@company.com
Daily send limit: 3,000 emails/day

## Support contact
For hosting issues: ops@agency.com
For feature requests: hello@agency.com
Emergency (site down): +91-98765-43210

Store this in the client’s own Google Drive or Notion, not in your agency’s tools. When they need it, they can’t access your tools anyway.

Document 2: The Runbook

A numbered steps list for the five to ten things the client will actually do. Keep it to one page per task. Screenshots for anything that has more than four steps.

Example for a blog-based site:

## How to publish a blog post

1. Go to app.contentful.com and log in
2. Click "Content" in the left sidebar
3. Click "+ Add entry" → choose "Blog Post"
4. Fill in:
   - Title (required)
   - Slug (auto-fills from title, edit if needed)
   - Body (rich text editor)
   - Featured Image (upload from computer)
   - Published Date (defaults to today)
5. Click "Publish" in the top right
6. Wait 60–90 seconds for the site to rebuild
7. Verify at yourdomain.com/blog/your-slug

Notes:
- Slugs are permanent — don't change them after publishing, 
  it will break any links shared to that post
- Images should be at least 1200px wide for the featured image

Repeat this format for:

• Editing an existing page
• Adding a team member
• Updating contact information
• Any form configuration
• Analytics access

Write these during the final sprint when the flows are fresh in your mind, not the day before handoff when you’re rushing.

Document 3: The Technical Reference

This one is for the next developer, not the client. It covers:

• Repository location and access
• Local development setup (step by step)
• Deployment process
• Environment variables and where they’re set
• Architecture overview (one diagram, not five)
• Third-party service relationships
• Known limitations or technical debt

## Tech Stack
- Framework: Next.js 15 (App Router)
- Database: Supabase Postgres
- CMS: Contentful
- Hosting: Vercel
- Email: Resend
- Analytics: Google Analytics 4

## Repository
GitHub: github.com/agency/client-website
Branch strategy: main → production, develop → staging

## Environment Variables
Set in Vercel dashboard. Required locally:
- NEXT_PUBLIC_SUPABASE_URL
- NEXT_PUBLIC_SUPABASE_ANON_KEY
- CONTENTFUL_SPACE_ID
- CONTENTFUL_ACCESS_TOKEN
- RESEND_API_KEY

## Deployment
Push to main → auto-deploys to production via Vercel
Preview deployments on every PR

## Known Issues
- Image optimization on Vercel is on the free tier; 
  upgrade if image serve cost becomes a factor
- Contact form has no spam protection; 
  add Turnstile if needed in future

This document lives in the repository’s /docs folder, not in a shared Google Drive.

How to Deliver

A PDF is the wrong format for all three documents. Clients print it once and it becomes outdated immediately.

The access sheet goes in the client’s password manager or their shared Google Drive, as a Google Doc they own. Not in your 1Password vault — you’re handing off credentials, not archiving them.

The runbook goes in Notion or Google Docs, in a workspace the client owns. Set up the document for them during the handoff call. Walk them through it.

The technical reference goes in the repository.

The Handoff Call

Documentation without a handoff call is rarely enough. Schedule 60 minutes with the client’s main operational contact (not the project sponsor — whoever will actually manage the site day-to-day).

Walk through the access sheet together. Make sure they can log in to each service. Have them publish a test blog post or make a test edit while you’re on the call, so any confusion about the steps surfaces now rather than six months from now.

Record the call. It becomes part of the handoff artifacts.

What Most Agencies Skip

Credentials stored in agency tools, not client tools. When the client relationship ends or the agency goes offline, the client can’t recover their own passwords. Credentials belong in the client’s tools before handoff.

Auto-renewal details. Domain and hosting renewals fail because the client doesn’t know which card is on file or when the renewal date is. Include this in the access sheet.

Who is on the hook for what. Clients often assume the agency is monitoring and responsible for things the agency has handed off. The handoff document should explicitly state what you are and aren’t monitoring after launch.

The escalation path for the right kind of failure. “Email us” is fine for feature requests. “Call this number” needs to be there for site-down incidents. Clients don’t distinguish between the two in the moment.

After Launch

If you’re offering a maintenance retainer, the handoff documentation changes slightly. You keep more access, the client keeps less — they don’t need the deployment workflow if you’re handling deployments. Document what they control and what you control, and make it explicit in the retainer agreement.

If the engagement ends at launch with no ongoing relationship, the documentation should be complete enough that someone else could take over with no calls to you. That’s the real test: can a developer you’ve never spoken to set up a local environment and deploy a fix from the docs alone?

Most can’t, from most handoffs. It’s worth fixing before you’re on the other end of that support call.