How to hand off a project to a client

Most project handoffs fail not because the work is wrong, but because of ambiguity about what the client now owns and what they're supposed to do with it.

The client receives a finished automation, a completed website, or a document package — and doesn't know how to use it without the builder. This creates two problems: the client feels dependent, and the builder gets support requests they weren't paid for.

A clean handoff transfers not just the deliverable but the knowledge required to own it. This guide gives you a repeatable process for doing that in one structured session, with documentation that lasts past the call.

Send a handoff document to the client 24 hours before the handoff call. This document should cover:

What was built A plain-language description of the system, workflow, or deliverable. One paragraph. No jargon.

How it works A step-by-step description of the process: what triggers it, what it does, what the output is. For automations, include a workflow map. For software, include a user flow diagram or annotated screenshots.

Credentials and access Where login credentials are stored, who has access, and how to add or remove users. Never include actual credentials in a document — point to the vault or password manager where they live.

How to make common changes The three to five things the client will most likely want to change after delivery. For a Zapier workflow: how to add a new field, how to pause the automation, how to view run history. For a website: how to update a page, how to add a blog post.

What to do if something breaks The failure mode and the recovery path. "If the automation stops running, go to Zap History and check the error message. Common causes are: expired account connection (reconnect the app), changed column name in the spreadsheet (update the Zap field mapping)."

The handoff call is a walkthrough, not a demo. The difference: in a demo, you operate the system. In a walkthrough, the client operates it while you guide.

Agenda for a 45-minute handoff call:

1. Overview (5 min) — Walk through the handoff document at a high level. Confirm they received it and had a chance to review.
2. Walkthrough (20 min) — Share your screen and navigate to the system. Then ask the client to share theirs and guide them through each part. Have them click, navigate, and find things themselves. This reveals what's unclear.
3. Scenario testing (10 min) — Run through the two or three most common real scenarios. If it's an automation: submit a test form together and watch the data flow. If it's a website: have them make a test edit and publish it.
4. Questions (10 min) — Open questions. Write down anything you need to follow up on.

Record the call if the client agrees. The recording is the best backup documentation.

The handoff call is the boundary between "you build it" and "they own it." Make that explicit before you end the call.

What to cover:

Warranty period: "I'll fix any bugs or errors related to the work I delivered within [X days] at no charge. Changes or new features are out of scope."

Support channel: "For questions about the system, reach out by [email/Slack] and I'll respond within [X] business days."

Out-of-scope requests: "Anything beyond what's covered in the SOW — new features, integrations, or design changes — will be scoped and quoted as a new project."

Documentation location: Confirm where the handoff document, credentials, and any supporting materials live. Google Drive, Notion, a shared folder — wherever it is, make sure the client knows how to find it without you.

The goal is that the client can solve 90% of their post-delivery questions by reading the handoff document, watching the recording, or following the "what to do if something breaks" section. The 10% that requires you should be clearly in-scope for your support terms.

A project isn't closed until two things happen: the deliverable is accepted and the final invoice is paid.

After the handoff call:

1. Send a follow-up email summarizing what was delivered, what was handed off, links to all documentation, and any open items discussed on the call.
2. Send the final invoice if not already sent. Reference the SOW payment terms.
3. Get written acceptance — a reply confirming receipt and acceptance of the deliverable. This email is your documentation if a dispute arises later.
4. Request feedback — one to three sentences. Not a form, not a long survey. A direct ask: "Would you be willing to share a sentence or two about working together? I use this to understand what I did well and what to improve." Most clients who had a good experience will say yes.

Once payment is received and acceptance is confirmed, the project is closed. Archive all relevant documents, mark it complete in your project tracker, and move on.