Client Handoff Checklist for a Small Service Project

← All SoloHatch guides

SOLOHATCH FIELD GUIDE · SOLO WORKFLOWS

A useful client handoff gives the recipient the agreed deliverables, a clear way to access and use them, and an explicit list of anything still open.

Before closing a small service project, check the actual files and access route, identify the current version, and tell the client what response is needed. Sending an attachment is one event. Completing the agreed handoff requires checking the items and process you promised.

Use this handoff checklist

Mark each item ready, needs review, or not applicable. Add an owner and next action where a point remains open. A checklist is useful when it reveals unfinished work, not when every box is ticked automatically.

1. Match the package to the scope

• Each agreed deliverable is present, with the correct quantity and format.
• The package identifies the scope or project version it relates to.
• Completion checks have been reviewed against the agreed inputs.
• Included source files, instructions, or other supporting items are present.
• Outstanding corrections, decisions, and excluded items are named separately.

Do not add source files or ongoing support merely because they seem like a helpful extra. Check what was agreed, what you are authorized to share, and what the recipient needs to use the deliverable.

2. Check files and access

• Open the files from the actual handoff location, rather than only from your working folder.
• Check names, version labels, links, and any supplied contact details.
• Confirm that the intended recipient can use the agreed delivery route.
• Identify which file is the current one and how older drafts are labelled.
• Keep unrelated client files and internal notes out of the package.

If a shared folder or account is involved, use the authorized access route. An invitation sent is not the same as access confirmed. Ask for confirmation where you cannot verify the recipient’s view. Never put a password into the handoff email as a shortcut.

3. Make the next action explicit

• Name the person who should review or receive the work.
• Say whether you need a receipt check, a review response, or a specific approval decision.
• Include any review date that was actually agreed.
• Explain how to report a missing file or a problem against the completion checks.
• State any agreed support boundary and what will need a separate discussion.

A handoff message should not invent a new approval deadline or turn silence into acceptance. Use the project’s agreed process. If no review route was settled, ask the client to confirm one.

Create a small delivery manifest

A manifest is an index of what you sent. It helps the recipient find the right version and helps you answer a later question without reconstructing the whole project.

PROJECT / SCOPE VERSION:
HANDOFF DATE:
RECIPIENT / REVIEW OWNER:

DELIVERED ITEM:
File name or location:
Version:
Purpose / how to use:
Completion check:

SUPPORTING ITEMS:
Instructions or source files included:

OPEN ITEMS:
Issue / owner / next action:

RESPONSE NEEDED:
Receipt check / review / approval decision:
Agreed response date, if any:

AFTER HANDOFF:
Agreed support and limits:
Route for a new request:

Filled example: a customer enquiry response pack

Illustrative example: a solo writer has prepared six reusable email responses from a client’s approved service information. This is a hypothetical delivery example, not a customer result or a claim that the messages improve reply rates.

PROJECT: Enquiry response pack, scope v2
DELIVERED: enquiry-response-pack-v1.docx
CONTENTS: Six responses, with editable placeholders
SUPPORTING ITEM: response-use-notes-v1.pdf
CHECKS: Six agreed situations covered; supplied service
names and contact details checked against approved inputs
OPEN ITEM: Client must choose who maintains future updates
REVIEW OWNER: Named client contact
RESPONSE NEEDED: Confirm receipt and identify any mismatch
against the agreed six situations
AFTER HANDOFF: Future new responses need a separate scope

The writer also explains that placeholders need to be replaced before a message is sent. That is a usage instruction, not a hidden unfinished deliverable. An unapproved service price, by comparison, would be an open input requiring a decision rather than something to conceal inside a placeholder.

A handoff email you can adapt

Subject: [Project] handoff — files and next step

Hi [Name],

The agreed [deliverables] are available here: [location].
Please use [file/version] as the current version.

Included:
- [Item and purpose]
- [Supporting file or instructions]

I checked [specific completion checks].
Please note [known limitation or open item, with owner].

Could you [specific receipt/review/approval action]?
[Agreed review date, if there is one.]
If something is missing or does not match the scope,
please identify the item and the expected result.

The agreed next step after handoff is [step].
For [additional work], we can discuss a separate scope.

Best,
[Name]

In the enquiry-pack example, the requested response could be: “Please confirm you can open both files and tell me if one of the six agreed situations is missing.” That is more useful than asking whether everything “looks good.”

Record the result before closing your work item

Keep the manifest, the delivered version, the location, the sent message, and the client’s actual response together. Mark receipt, review, and approval separately when they are different events. Record unanswered questions as unanswered.

Follow the retention and access arrangements agreed for the project. Do not delete working material, revoke access, or transfer ownership just to make a checklist look complete. Those actions may require a separate decision.

Use your next weekly business review to note one handoff issue worth improving. If missing inputs caused the delay, revise the client intake and onboarding checklist. For the wider process, explore the Solo Workflows guides and all free guides.

This guide was developed with AI assistance for SoloHatch, operated by My Target Limited. Examples are illustrative, and templates should be adapted to your situation. About SoloHatch.