Direct answer

Client Sign Off Template

A client sign off template is the list of fields that turn a vague yes into a record. The fields are: the project and parties, the deliverables with their exact versions, the criteria they were judged against, the evidence and receipt links, the open items excluded from the sign off, the decision with the decider's name and date, and the rule for changes after sign off. This page gives the full template in copyable form, explains why each field earns its place, and shows the live version: a handover link the client opens, checks, and accepts, with the acceptance itself recorded.

See the live form of this template first: the worked example handover at zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 is open and waiting on its client, and the accepted example, handover 45434a17-4afc-486a-9646-e689bcee4297, was an end-to-end audit handover that a client accepted, minting its own receipt for the acceptance. Check any receipt free at the public verifier. Build a live sign off at zambo.dev/handover.

Updated October 20, 2026.

The template, in full

Copy this structure into a document, a form, or a handover packet. Keep the field order: identity first, then the work, then the evidence, then the exclusions, then the decision. The order teaches the reader how to sign responsibly, top to bottom, and it makes a completed sign off readable by a third party, a manager, an accountant, a successor, who was never part of the project and needs the record to explain itself.

1. Project: project name, the agreement or proposal it was delivered under, and the delivery date.

2. Parties: who delivered the work and who is signing, with the signer's role and their authority to accept on the client side.

3. Deliverables: every deliverable as a numbered line, with its exact version, file name, build, draft, cut, or live address that identifies it.

4. Criteria: the brief, specification, or acceptance criteria each deliverable was judged against, quoted or linked.

5. Evidence: the checks, tests, reviews, or receipts behind the delivery, with a link or reference for each.

6. Open items: everything not covered by this sign off: pending items, known issues, and exclusions, listed explicitly.

7. Decision: accepted, or accepted with the named exceptions above, or not accepted with the reason attached to a numbered deliverable.

8. Signer and date: the decider's name, role, and the date of the decision.

9. After sign off: how changes are requested and treated once this record is signed, per the underlying agreement.

Why each field earns its place

The deliverables field, with versions, is the heart of the template, and the field most sign off forms get wrong by writing website, or report, or final designs as if those words identified anything. A version identifier is what separates the approved object from its near twins: the draft before the last correction, the export after it. Without versions, sign off is applause. With versions, it is a decision about specific work that either side can point to when a different version surfaces later and someone asks which one was actually accepted.

The open items field earns its place by protecting the signer. Clients hesitate to sign because signing feels total, as if one signature endorses everything including the parts they have not seen. An explicit exclusions list makes signing safe and therefore fast: sign for these nine items, with these two openly pending, and the decision covers exactly that. The criteria field earns its place symmetrically, protecting the deliverer: acceptance was given against this brief, so a later standard invented after delivery can be recognized as a new requirement and handled as a change, kindly, with the record open on the table.

A filled example, line by line

Project: spring campaign landing page, delivered under the March proposal, delivered April 18. Parties: delivered by the named freelancer; signed by the client's marketing manager, the person who commissioned the work. Deliverables: line one, landing page at its live address, version published April 18; line two, the page copy document, final draft dated April 17; line three, the sign up form configuration, submissions routed to the client's list. Criteria: the March brief, including the offer, the audience, and the three messages the page had to carry.

Evidence: the checks recorded in the delivery handover, each with its receipt link, and the client's own read through. Open items: the testimonial block, awaiting a customer permission the client owns; one statistic, awaiting the client's confirmation of their own figure. Decision: accepted, with the two open items above excluded. Signer and date: the marketing manager, April 19. After sign off: further changes requested by change note against this record. Read that example again and notice what it makes impossible: a later claim that the email sequence was part of this sign off, that the page approved was a different version, or that the testimonial delay was the freelancer's.

Where paper and PDF templates fail

A static template fails in three predictable places. First, circulation: the form is emailed, printed, photographed, and re-emailed, and the copies diverge the moment anyone annotates one. Second, evidence: the form can reference checks and versions but cannot carry them, so the signer is asked to trust summaries of evidence stored elsewhere, which is precisely what sign off was supposed to remove. Third, custody: the signed copy ends up in one party's files, and the other party, the one who may need it most in a disagreement, holds an unsigned draft or nothing.

None of this makes the template useless. The fields are right; the medium is weak. Keep the template for contexts that genuinely live on paper, a site visit, a regulated workflow, an older client's procurement process, and fill it with the same discipline: versions, criteria, open items, decider, date. But where the work itself is digital, which is most freelance, agency, consulting, design, development, copywriting, and video work, the live version of the same template removes the three failures by existing in exactly one place, carrying its evidence, and being readable by both sides on equal terms.

The live version: how a handover sign off works

A Zambo handover is this template as a working page. Build it at zambo.dev/handover: the goal field carries the project and criteria, the steps carry the deliverables in order with their outputs and versions, each recorded step carries its verifiable receipt as the evidence field, and the open items are listed as open in the packet. Work routed through the Zambo MCP at zambo.dev/mcp, one endpoint with no key, 153 tools in total and 35 on the default surface, in ChatGPT, Claude, Gemini, Grok, Cursor, or another connected client, leaves those receipts as the work runs.

The client opens the link with no account, checks any receipt free at zambo.dev/verify, and makes the decision the template's decision field describes: Accept closes the record, or Flag attaches the objection to one numbered deliverable. The decider and the date are written into the record, and the acceptance mints its own receipt. The deliverer cannot accept their own handover: the creating account is refused. That one rule upgrades the whole template, because the decision on the record is provably the client's act, not the deliverer's filing.

Template field 1 to 2, project and parties, become the handover title, goal, and the named client decision maker.
Template field 3, deliverables with versions, becomes the packet steps and their named outputs.
Template field 5, evidence, becomes the receipt on each recorded step, checkable free by anyone.
Template field 6, open items, stays visible in the packet instead of being negotiated away at signing time.
Template fields 7 to 9, decision, signer, and the change rule, become the recorded Accept or Flag, its receipt, and the baseline every later change is measured against.

Two real records, and what each one shows

The open worked example, bd7e5325-33fd-4c5e-b029-76b781fa2f51, is a sign off form in its before state: fields filled, evidence attached, decision blank, waiting on the client. Leave a copy of this page open while you read it and the template stops being abstract: every field above has a visible home on that page. The accepted example, 45434a17-4afc-486a-9646-e689bcee4297, was an end-to-end audit handover that a client reviewed and accepted, so its decision field is filled by the only person entitled to fill it, and the acceptance carries its own receipt.

Presenting both states is the honest way to teach sign off, because the failure mode of templates is pretending the decision happens by itself. It does not. A good record makes the decision easy to take and hard to fake: the client can check everything the form claims, and then their name, not yours, goes on the line. If you use the paper version, imitate that asymmetry anyway: the deliverer fills the work fields, the client alone fills the decision, and both sides keep the completed whole.

What a sign off proves, and what it does not

A receipt under a step proves the saved result of that step was not changed after the fact, and the acceptance receipt proves who accepted the packet and when. A completed sign off, paper or live, proves a named person accepted named deliverables against named criteria on a named date, with named items excluded. That is a decision record, and decision records settle the disputes that actually occur: what was delivered, which version, who approved it, and what was knowingly left open.

A sign off does not prove the work was correct, effective, or worth its price, and a receipt does not prove the saved result was right: a faithfully recorded error is still an error. Sign off is not a contract, a warranty, a rights transfer, or a payment, and it should sit alongside the agreement and the invoice, referencing them, never replacing them. AER-1, the open receipt format underneath the live version, is an IETF Internet-Draft, draft-zambo-aer1-24, not a finalized standard. A template that states its own limits this plainly gets more trust, not less, from the clients worth having.

Adapting the template by trade

For design work, the deliverables field should carry file formats and the round each final came from. For development, it should carry the build identifier, the deploy address, and the test evidence, with known issues in the open items. For consulting, criteria become the commissioned question, and recommendations can be numbered as deliverables so the client can accept them individually. For copywriting, the deliverable is the exact final text, and the brief section should note which claims the client supplied. For video, the deliverable is the named master export, with captions and alternates as their own lines.

The fields do not change across trades; only what counts as a version changes. That stability is the point of a template: a client who has signed one of your sign offs can read the next one in seconds, a bookkeeper can file them uniformly, and you can compare records across a year of projects because they were all built on the same skeleton. Customize the examples inside the fields freely. Do not customize away the versions, the criteria, the open items, or the decider: those four are the record.

What the live version costs

The paper template on this page is free to copy and use as written. Public handovers, the live version, are free to send and free for the client to open. For $0.99, a Day Pass covers 24 hours of full recorded work through the Zambo MCP, enough to assemble a delivery packet with its evidence in one sitting. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402. The template asks for an hour of discipline per project; the live version returns most of that hour by carrying the evidence itself.

Honest limits

A sign off records a decision; it does not create the trust that makes a client willing to sign, and it cannot rescue work the client has not actually reviewed. In the live version, only steps recorded through connected tools carry receipts: work done entirely outside the record has no receipt and should be listed as unchecked in the evidence field rather than implied. Keep credentials and personal data out of any sign off, paper or live. And remember the boundary that keeps the record credible: a receipt proves the saved result was not changed, never that the work was right. The client still judges the work. The record settles what they judged, and that they judged it.

Frequently asked questions

What should a client sign off template include?

Include nine fields: the project and the agreement it was delivered under, the parties with the signer's role, every deliverable as a numbered line with its exact version, the criteria each deliverable was judged against, the evidence with links or references, the open items excluded from this sign off, the decision, the signer's name and date, and the rule for changes after sign off. Versions, criteria, open items, and the named decider are the four fields that turn a form into a record.

What is the difference between a sign off form and a live handover sign off?

The fields are the same; the medium differs. A form circulates as copies, references evidence stored elsewhere, and usually ends up filed by one side only. A live handover sign off is one page both sides read at the same address: the deliverables and their receipts are inside it, the client accepts or flags a named item, and the acceptance is written into the record with its own receipt. The deliverer cannot accept their own handover, so the decision on the record is the client's act.

Why must deliverables carry version identifiers on a sign off?

Because approval without a version approves nothing specific. Drafts, builds, cuts, and exports all have near twins: the version before the last correction and the version after it. When a different version surfaces later, a sign off that named the version settles which one was accepted, and change requests can be measured against it. A sign off that just says website or final designs leaves the most common delivery dispute, which version was approved, completely open.

Can a client sign off with exceptions instead of a plain yes or no?

Yes, and the template is built for it. The client accepts the numbered deliverables and lists exceptions in the open items: the testimonial awaiting permission, the statistic they still must confirm, the one recommendation they are deferring. Acceptance with named exceptions closes the project honestly, releases the completed work, and keeps the pending items visible to both sides. In a live handover, the client can also flag one named item, which records the objection at the exact place it applies.

Is a client sign off a contract or a payment guarantee?

No. A sign off is a decision record: it proves a named person accepted named deliverables, in named versions, against named criteria, on a named date, with named items excluded. It is not a contract, a warranty, a rights transfer, or a promise of payment, and it should sit alongside the agreement and the invoice, each doing its own job. In the live handover version, a receipt proves the saved result was not changed after the fact; it never proves the work was correct.