Use this checklist before every delivery handoff, even for “small” updates. Most client frustration comes from small misses, not major failures.

This page is the execution checklist for a delivery stage, not the full delivery method. If milestone ownership, approval rules, or handoff timing are still fuzzy, start with Milestone Delivery Workflow for Solo Service Businesses first. This page should stay downstream from that workflow guide.

It is most useful when the delivery method is already decided and the risk now is avoidable misses at the handoff moment.

What this checklist assumes you already know

  • what the milestone or delivery is supposed to include,
  • who can approve it,
  • what next action the client is expected to take,
  • whether handoff should trigger billing, revision, or closeout.

If any of those are still open questions, go back to the workflow first.

When this checklist matters most

Use it before:

  • a milestone submission,
  • a revision round closeout,
  • a final delivery,
  • any handoff where the client needs to approve, implement, or pay next.

The more routine the handoff feels, the easier it is to skip one important detail.

What this checklist is not for

Do not use this page to decide:

  • whether the milestone itself is ready to close,
  • whether a change request should be accepted,
  • who the approval owner is,
  • whether the next invoice should exist at all.

Those decisions belong in the workflow pages upstream from this asset.

Pre-handoff QA checklist

A) Scope alignment

  • Confirm deliverable matches agreed scope.
  • Confirm requested revisions are incorporated.
  • Confirm out-of-scope items are documented separately.

B) Technical or content quality

  • Validate file integrity and formatting.
  • Verify links, references, and assets.
  • Confirm naming and versioning conventions are correct.

C) Client readiness

  • Add short summary of what is included.
  • Add clear usage or implementation notes where needed.
  • Add explicit request for approval or next action.

D) Operational controls

  • Log delivery date in the system of record.
  • Update milestone status.
  • Trigger next invoice or next-stage action if applicable.

Minimum evidence to attach before handoff

Where relevant, attach:

  • the final file or approved access link,
  • a short list of what changed,
  • any implementation note the client needs to avoid misuse,
  • the exact next response or approval you need back.

This turns the checklist from internal QA into a client-ready handoff asset.

Final handoff message structure

  • What is being delivered now.
  • What changed from the prior draft or milestone.
  • What the client should review first.
  • What response is needed and by when.

Good use cases for this page

  • recurring milestone deliveries,
  • final project handoffs,
  • any client-facing delivery where approval unlocks billing, closeout, or the next stage.

The QA misses that usually cost the most

  • Sending the right file with the wrong version label.
  • Forgetting to mention what the client is supposed to do next.
  • Delivering in email but failing to update the live project record.
  • Finishing a milestone without triggering the invoice or closeout step it should unlock.

Edge cases worth deciding in advance

  • If the client asked for a small extra item, note whether it is included or deferred instead of burying it in the handoff note.
  • If implementation depends on the client’s team, name the dependency directly in the handoff.
  • If approval is needed by a certain date, state the deadline and the consequence of delay clearly.

Ready-to-send standard

This checklist is complete only when:

  • the delivered item matches the agreed scope,
  • the client knows the next expected action,
  • the project record is updated,
  • the next operational trigger is queued.

What to do next