Direct answer

Video Editor Client Handover

A video editor client handover is one link that ends cut confusion. The link carries the cuts in order, the timecoded notes each cut resolves, the final export named with its format and destination, captions and thumbnail where they are part of the job, and a verifiable receipt for each recorded step. The client opens it with no account, checks the final cut against their notes, and accepts that version or flags one moment. It replaces the expiring download link, the notes thread about a cut two versions old, and approval given to a proxy render that was never the final file.

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 video editor actually hands over

A finished edit is several deliverables wearing one name. There is the final cut itself, exported at the specification the destination needs: resolution, frame rate, codec, loudness, and aspect ratio, and often several aspect ratios of the same edit for different platforms. There are captions, as burned in text or as a sidecar file, and they are a deliverable in their own right with their own accuracy questions. There may be a thumbnail, a clean version without captions or graphics, a version with a different ending for a different channel, and the project files if those were part of the deal.

The handover names each deliverable and ties it to the cut it came from. Above the deliverables sit the cuts in order: the rough cut, the revised cut, the final cut, each with the notes it was answering. That chain is the editor's real work product, because a client who only ever sees the final file undervalues the three rounds of judgment inside it, and a client who can see the chain understands both the work and why the final version says what it says, frame by frame.

Cuts: each cut in order, labeled, with the set of notes it resolves quoted or summarized next to it.

Final exports: the accepted version exported per destination, format details stated, one named as the master final.

Supporting deliverables: captions, thumbnail, clean version, and alternate endings where the job includes them, each listed as delivered or open.

Open items: music or footage clearances the client owns, exports still owed, and project file delivery terms, stated plainly.

What clients check before they accept an edit

Clients watch the final cut against their notes, usually their own timecoded list from the previous cut, checking that each note landed: the pause trimmed, the name pronounced and spelled correctly in the lower third, the section reordered, the music level under the voice fixed. They check the unglamorous specifications that decide whether the file is usable at all: does it upload cleanly, are the captions present and accurate, is the loudness right for the platform, is the export the right ratio for the channel it was bought for.

They also check identity questions that editors forget clients worry about: is this the cut we approved in the review meeting, rendered at full quality, or a newer export with last minute changes nobody reviewed. A client who was burned once by an unreviewed final change watches the handover the way an accountant reads a statement, looking for the line that confirms the reviewed version and the delivered file are the same thing. A packet that names the final export, and records acceptance on it specifically, answers that worry in one place.

Where video editor acceptance stalls

It stalls on timecodes that moved. The client's notes were written against cut one; in cut two, an early trim shifted everything after it by seconds, so half the notes now point at the wrong moments, and the review meeting burns its time realigning references instead of judging the edit. It stalls on link rot: the review link expired, the download needs a password nobody saved, the client forwards the packet to their manager and the manager cannot open anything, so approval waits on file logistics instead of on the work.

It stalls hardest on proxy approval. The client approved a low resolution review render for speed, the editor exported the master with a color pass and an audio fix applied after that approval, and the published video differs from the approved one in ways each side describes differently. None of this is bad faith; it is a medium where the deliverable is heavy, versions multiply, and every viewing copy is a derivative. The handover disciplines it by making one export the named final, attaching the notes chain to it, and recording the acceptance against that named version.

The manual way, and why review links fail editors

The manual handover is a review platform link for comments, a different link for the download, and a message asking the client to confirm the final. Three systems, three chances to diverge. The comments live against one upload, the download is a second encode, and the confirmation arrives by email naming neither. When the client later says the published video is not what they approved, the editor reassembles the truth from upload histories and chat logs, during the exact week they should be editing the next project.

Editors also pay for informal handovers in revision accounting. Without a record of which notes were delivered against which cut, a client can honestly believe a note was never addressed, because they looked for its result in the wrong version, and the editor does unpaid work re-proving old fixes. A packet that lists cuts in order with the notes each resolves turns that conversation into a lookup: cut three, note four, resolved here, accepted on this date. The record is not bureaucracy for its own sake; it is the editor's revision ledger, written once, at delivery, when the facts are fresh.

The handover way, step by step

Run the recorded parts of the job, transcription, caption drafting, research, asset checks, and export verification, through tools connected to 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. Assistance in ChatGPT, Claude, Gemini, Grok, or another connected client leaves a verifiable receipt per recorded step. At delivery, assemble the handover at zambo.dev/handover: the brief, the cuts in order with notes resolved, the final exports named with their formats, supporting deliverables, and open items.

Send one link. The client opens it with no account, watches and reads the packet, checks any receipt free at zambo.dev/verify, and accepts the named final version or flags one moment, so a correction request arrives pointed at its exact place in the final cut. You cannot accept your own handover: the creating account is refused, making the acceptance a real client decision on a specific export, which is the record you want when the video is reposted, re-edited by someone else, or questioned months after publication.

Two real records, and what each one shows

The open worked example, bd7e5325-33fd-4c5e-b029-76b781fa2f51, shows a packet in the waiting state every editor knows: the work is done, the link is sent, the client's decision is still outstanding, and the record says so honestly. The accepted example, 45434a17-4afc-486a-9646-e689bcee4297, was an end-to-end audit handover that a client checked and accepted, minting a receipt for the acceptance. Process heavy work, audit or edit, closes the same way: not when the maker says done, but when the client's decision lands on the record.

Use the pair when onboarding a client. Most video clients have been trained by other editors to expect a folder and a chase. Showing them, before the first cut, that delivery in your studio ends with one packet, their notes visibly resolved cut by cut, and their acceptance recorded on the named final, reframes you as the organized option in a trade where clients mostly complain about communication, not cutting.

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. For an edit, the acceptance receipt is the centerpiece: it proves who accepted this packet, naming this final export, and when. If a different export is published later, the packet remains the record of what was actually delivered and approved, and the difference is a fact to discuss, not a memory to contest.

The record does not prove the edit is good, the captions perfect, or the music cleared: craft, accuracy checks, and rights remain the professional work around the packet, and clearances owned by the client should sit in the open items until the client confirms them. It is not a contract, a license, or a payment. AER-1, the open receipt format underneath, is an IETF Internet-Draft, draft-zambo-aer1-24, not a finalized standard. Claim exactly what the record shows and it will be believed precisely where it counts, in the disagreement you hope never happens.

Variants: social cuts, long form, and event films

A social video handover weights versions: the same edit in vertical, square, and landscape, each named with its destination, captions treated as a first class deliverable because most viewing is muted, and the hook frames identified so a client reordering request is understood as the structural change it is. A long form handover, a course, a documentary, a podcast edit, weights the notes chain across many review rounds and the chapter or segment list, because acceptance usually happens segment by segment before the whole is closed.

An event film handover weights speed and completeness: the highlight cut, the full length record, the stills pulled from footage, delivered against a date the client has already announced publicly. In each variant the packet shape holds, and in each the same failure is prevented: approval landing on a derivative, a draft, or a memory, instead of on the named final the client actually received.

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, fitting an export day: final checks run, packet assembled, link sent inside 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 re-export argument avoided, or one set of old notes proven resolved without unpaid rework, covers a season of passes.

Honest limits

The packet covers steps recorded through connected tools. Editing decisions made inside the editing application, viewing checks on a client's own screen, and clearance conversations have no receipt unless their outputs were recorded through Zambo, and an honest packet lists them as unchecked. Large video files themselves live in your usual delivery storage: the handover names and records them, it does not host them. The acceptance is a decision record, not a copyright transfer, a music license, or a payment, and a receipt proves the saved result was not changed, never that the edit was good. The client still judges the cut. The record settles which cut they judged.

Frequently asked questions

What is a video editor client handover?

A video editor client handover is how an editor delivers finished work as one link: the brief, the cuts in order with the notes each cut resolves, the final exports named with their formats, captions and other supporting deliverables, any open items, and a verifiable receipt for each recorded step. The client opens the link with no account, checks the final cut against their notes, and accepts that named version or flags one moment. It replaces expiring links and approval given to a proxy render.

How does a handover handle timecoded client notes?

Each cut in the packet lists the notes it resolves, stated next to that cut, so a note is tracked against the version that answered it rather than floating in a thread while timecodes shift between cuts. When the client reviews the final cut, they can check their original notes against the resolution list cut by cut. If a note is missing or wrong, they flag that step in the packet, and the correction conversation starts at the exact moment in the final version.

Why does it matter which export the client accepts?

Because review copies are derivatives: a proxy render approved for speed may differ from the master export in color, audio, or last minute fixes. The packet names one export as the master final, with its format and destination stated, and the client's acceptance is recorded against that named version with its own receipt. If a different file is published later, the accepted packet shows what was actually delivered and approved, and the difference is a fact, not a memory dispute.

Do captions and other versions belong in the handover?

Yes, as deliverables in their own right, listed as delivered or open. Captions, thumbnails, clean versions without graphics, and alternate ratios or endings are exactly the items that go missing in folder based delivery and get discovered at upload time. Listing them in the packet the client accepts means acceptance covers the complete set the job promised, and anything still owed, like a clearance the client owns, sits in the open items where both sides can see it.

How much does a video editor 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.

Related