Direct answer

Designer Client Handover

A designer client handover is one link that ends version chaos. The link carries the final files, the rounds that produced them, the decision made on each round, source files and exports side by side, and a verifiable receipt for each recorded step. The client opens it with no account, checks they have the exact approved version, and accepts the design or flags one file. It replaces the shared folder full of files named final, final two, and final approved, where nobody can prove which one the client actually said yes to.

Open a real one first: the worked example handover at zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 is open and waiting on its client. The accepted example, handover 45434a17-4afc-486a-9646-e689bcee4297, was an end-to-end audit handover that a client accepted, and that acceptance minted its own receipt on the record. Check any receipt free at the public verifier. Start your own at zambo.dev/handover.

Updated October 20, 2026.

What a designer actually hands over

Design delivery is a set of related artifacts, not a single picture. A brand job hands over the logo in its lockups and colorways, source files, exported files for print and screen, the color and type specifications, and usually a short usage guide. A web or product design job hands over the screen designs, the component states, the responsive variants, exported assets at the sizes development needs, and notes on behavior that a static screen cannot show. A print job hands over press ready files with bleed and color setup stated, plus the proof the client approved.

The handover has to name the final version of each artifact and separate it from the rounds behind it. Rounds matter because they carry decisions: round one explored three directions, the client chose the second, round two refined it, round three fixed the spacing complaint from the marketing lead. If the packet contains only the final files, a later change request turns into an argument about what was already tried and rejected. If it contains the rounds with their decisions, the next conversation starts from the record: this direction was explored, this one was chosen, this version was approved.

Final files: the approved design in every promised format, source and export, named as final in the packet.

Rounds: each round's output with the client's decision on it, kept behind the final version, not mixed into it.

Specifications: colors, type, spacing, and file setup as delivered, so a printer, developer, or future designer can reproduce the work.

Open items: formats still owed, assets the client still has to supply, and anything explicitly out of scope for this delivery.

What clients check before they accept design work

Clients check that what they are opening is what they approved in the review meeting, and this check fails more often than designers expect, because the approved mockup and the exported file are different objects produced at different moments. They check the practical set: do we have the logo in the formats our website, printer, and social profiles each need, do the screens cover the states development asked about, are the files named and organized so our team can find things without asking the designer.

They also check the commercial points. Is this the complete set the quote covered, including source files if those were promised, and is anything extra, like the additional lockup the director requested mid project, listed as delivered or as an open item rather than assumed. A client who finds the full set in one packet, each file in its final version, accepts quickly. A client who has to email asking where the vertical logo version is does not experience that as a small delay: they experience the handover itself as unfinished, and acceptance waits.

Where designer acceptance stalls

It stalls on the word final. The client approved a design verbally on a call, the designer exported a slightly corrected version afterward, and when the printed result looks different from the screen approval, each side holds a different final. It stalls on stakeholder spread: the founder approved the direction, the marketing lead never saw round three, and the person who will use the files daily asks for changes after the project was considered closed. It stalls on source files: the client believed source files were included, the designer believed they were licensed as exports only, and acceptance becomes the moment that misunderstanding surfaces.

Every one of these stalls is a record problem. The approval was never attached to a specific version. The rounds and their decisions were never kept in one place the client could revisit. The deliverables list, which would have settled the source file question before work began, existed only as a line in a proposal nobody rereads. A handover packet attacks all three: versions are named, decisions sit next to the rounds they decided, and the deliverables list is the thing the client accepts.

The manual way, and how folders fail designers

The manual handover is a folder link and a message saying the finals are in there. Folders are living places: the designer tidies them, replaces a file with a corrected export, adds the extra format a week later. Each kindness quietly rewrites history, until the folder no longer shows what was delivered on delivery day. When a dispute comes, about a color, a version, a missing file, the folder testifies to the present, not to the handover, and the designer's memory is the only witness left.

Email approvals fail differently. The client replied looks great to a thread containing a preview image, not the files. The preview was compressed, cropped by the mail client, and two revisions behind the export. Treating that reply as approval of the delivered files is a stretch everyone makes in good faith and regrets in bad moments. The handover replaces both habits with a single object that does not drift: the packet as sent, the files as listed, the acceptance as recorded, readable the same way on the day of a reprint two years later as on delivery day.

The handover way, step by step

Do the design work with your usual tools, and route the recorded steps, research, asset generation, checks, and exports, through Zambo, the verifiable work layer for AI, at zambo.dev/mcp, one endpoint with no key, 153 tools in total and 35 on the default surface. Design assistance in ChatGPT, Claude, Gemini, Grok, or another connected client leaves a verifiable receipt per recorded step. At delivery, build the handover at zambo.dev/handover: the brief as agreed, the rounds in order with decisions, the final files named as final, the specifications, and the open items.

Redact anything that is not the client's to see, then send one link. The client opens it with no account, checks the final files against the rounds, and accepts the design or flags one file, so a correction request names its target. You cannot accept your own handover: the creating account is refused. That refusal turns the client's click into a real approval of a specific version, the kind you can point to when a change request arrives dressed as a correction, or when a new stakeholder asks to reopen a direction the record shows was already explored and set aside.

Name the final version of every file, and keep rounds behind it, clearly labeled as rounds.
Record the decision on each round, including directions explored and set aside, with the reason in a line.
List specifications as delivered: colors, type, sizes, and print setup where print is part of the job.
State source file inclusion plainly in the deliverables list, so acceptance settles that question too.
List open items and out of scope requests separately, so the final set is complete by definition.

Two real records, and what each one shows

Open the worked example, bd7e5325-33fd-4c5e-b029-76b781fa2f51, and you see a packet mid decision: steps and outputs in place, acceptance still owed. That is the exact moment design clients live in when they circulate finals internally. The accepted example, 45434a17-4afc-486a-9646-e689bcee4297, was an end-to-end audit handover that a client reviewed and accepted, minting a receipt for the acceptance itself. In design terms, that accepted state is the difference between a client who seemed happy on a call and a client whose approval is attached to a named record.

Keep both states in mind when you pitch. A prospect does not need your process explained in the abstract: show the open packet, show the accepted one, and let them see the moment their own approval would become a record instead of a reply. Designers are usually hired for taste and retained for reliability, and a clean acceptance record is reliability made visible.

What the record proves, and what it does not

A receipt proves the saved result of a step was not changed after the fact, checkable free at zambo.dev/verify with no signup. The acceptance receipt proves who accepted this packet, with these files listed, and when. If the client later receives a different export from a shared folder, the packet still shows what was actually handed over and approved. That settles the version question, which is the question underneath most design delivery disputes.

The record does not prove the design is good, original, or legally clear to use: taste, research, and rights checks remain the designer's professional work, done before the packet is assembled. It does not transfer any rights by itself either: licensing and ownership still live in your contract, and the handover should reference that contract rather than replace it. AER-1, the open receipt format underneath, is an IETF Internet-Draft, draft-zambo-aer1-24, not a finalized standard. Stating these limits plainly is part of why clients trust the parts the record does prove.

Variants: brand, UI, and print handovers

A brand handover should weight specifications heavily: the guide, the color values in each color space, the clear space and minimum size rules, because the client will hand your files to people who never met you. A UI handover should weight states and variants: empty states, error states, mobile and desktop, the assets at production sizes, and notes for the developer who builds from it, ideally accepted by the client before development starts so design changes stop arriving mid build. A print handover should weight the proof: the exact file sent to press, its setup, and the client's acceptance of that file, because print errors are the ones that cannot be patched after the fact.

For ongoing design support, hand over per drop rather than per project: each batch of social assets, each landing page, each illustration set as its own small packet with its own acceptance. The habit compounds into a design history the client can browse, which quietly answers the most common retention question, what have we actually made together this year, with records instead of a portfolio reconstruction.

What it costs

Public handovers 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, a natural fit for delivery day: final exports, final checks, packet assembled and sent in one window. 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. One avoided reprint or one change request correctly treated as new work pays for a long run of passes.

Honest limits

The packet covers steps recorded through connected tools; design work done entirely in a desktop application and never routed through Zambo has no receipt, and an honest handover lists such files as delivered but unchecked rather than implying a record exists for them. The acceptance is a decision record, not a rights transfer, a license, or a payment: contracts and invoices keep their own jobs. And a receipt proves the saved result was not changed; it never proves a design was correct, appropriate, or clear of third party rights. The client still judges the design. The record settles which design they judged.

Frequently asked questions

What is a designer client handover?

A designer client handover is how a designer delivers finished work as one link: the brief, the rounds in order with the decision on each, the final files named as final, the specifications, any open items, and a verifiable receipt for each recorded step. The client opens the link with no account, checks the final files against the rounds, and accepts the design or flags one file. It replaces the folder of files all named final, where nobody can prove which version was approved.

How does a handover stop arguments about which version was approved?

The packet names the final version of every file, and the client's acceptance is written into that same record with its own receipt, including who accepted and when. If a different export circulates later from a shared folder, the accepted packet still shows the version that was handed over and approved. Change requests then start from the approved version: corrections to it are fixes, and new directions are new work, and the record shows which is which.

Should rounds and rejected directions be included in a design handover?

Yes, behind the final files and clearly labeled as rounds. The rounds carry the decisions: which directions were explored, which the client chose, and which were set aside and why. That history stops a later stakeholder from reopening a rejected direction as if it were new, and it shows the client the work their fee covered. Keep the final set separate and unmistakable, so inclusion of rounds never muddies which files are the delivery.

Do clients need an account to accept a design handover?

No. The client opens the link in a browser with no account and no signup, reviews the packet, and clicks Accept or Flag on a specific file. Each receipt in the packet can be checked free at https://zambo.dev/verify/ with no signup. The designer cannot accept their own handover: the creating account is refused, which is what makes the client's acceptance on the record a real approval rather than the designer's own bookkeeping.

How much does a designer client handover cost?

Public handovers are free to send and free for the client to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, which runs 153 tools in total with 35 on the default surface. 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.