Direct answer
Proof the work is done: what to send, and what to stop sending.
The instinct, when a client needs convincing, is to send more: more screenshots, more documents, a certificate with your own name on it twice. Volume is not what convinces. What convinces is a record the client can check without believing you. This page ranks the things freelancers send today, shows the packet that replaces all of them, and gives the one short message that carries it.
Updated October 17, 2026. The two delivery records quoted below are real and public, with their states read back from the live service on publication day.
What people send now, and why it underperforms
Screenshots. A picture of a result, chosen by the person being checked. Croppable, stageable, and silent about every step around the moment captured.
The self-written certificate or completion form. A document in which the worker attests that the worker worked. It has the shape of proof and the authorship problem of a claim, and clients price it accordingly.
The completion email. A summary written after the fact, by the same person, in prose. It reads exactly as polished for a job that went sideways as for a job that went perfectly, and there is no way to tell the difference from inside the email.
The file dump. Every draft, export, and asset in one folder. It proves files exist. It does not show what ran, in what order, or which version the client is actually accepting, so the checking work lands back on the client, who bills you for it in delay.
The proof packet: four parts, one link
The deliverable, in context. Not a loose file, the result sitting at the end of the steps that produced it.
The step-by-step record. Each step of the work, what it produced, and the time it was saved. This is the part no screenshot folder can imitate, because it was written during the work, not arranged after it.
The acceptance state. Whether the client has accepted, flagged, or not yet decided, visible to both sides. Proof of done-ness is incomplete without the state of the client's decision, because done is ultimately their call to record.
The short message. The job name, the link, the decision needed, a date. Four lines. The packet does the persuading; the message just delivers it.
When work runs through Zambo this packet is not assembled, it is the delivery: a handover link carrying the steps as verifiable receipts, the times, and the accept or flag controls. Two live examples:
The packet, accepted
Scope: Retrieval, extraction, verification, and reporting pipeline producing an AI-adoption research packet for a law firm.
- Status: accepted by the client on 2026-10-16, decision ok_to_release.
- The record covers 4 steps, each saved as it ran, each openable from the one link.
- Open the handover or read its acceptance.json.
The packet, waiting for its decision
Scope: AI visibility audit of zambo.dev: homepage copy inventory, on-page citation audit, and evidence-based recommendations.
- Status: still pending, decision hold. The client has not accepted or flagged it yet.
- The record covers 5 of 5 steps, all saved on 2026-10-16. Nothing about this packet needs the freelancer to vouch for it.
- Open the handover or read its acceptance.json.
The deeper page on the seller's side of this question, how to prove you delivered the work, ranks the four levels of proof from say-so up to the delivery record. This page is the sending side: given the record exists, the packet above is what leaves your outbox.
What proof cannot carry
A verifiable receipt proves the saved result was not changed since it was saved. It does not prove the work was good, and no packet settles taste. The client's judgment still happens; the packet simply gives that judgment a complete, ordered, checkable object to land on, instead of a claim to wonder about. It also does not prove who produced the work. Send proof for what proof does, and let the work itself carry the rest.
Frequently asked questions
What should I send a client as proof the work is done?
Send one link, not a pile of attachments. Behind the link: the deliverable, the record of the work step by step with the time each step was saved, and the acceptance control where the client accepts or flags the work. Add one short message that names the job, the link, and the decision you need. That bundle is the proof packet. It beats screenshots, self-written completion certificates, and summary emails for one reason: none of it asks the client to take your word. The record was made while the work ran, the client checks the same page you see, and their decision lands in the record. When the work runs through Zambo, the packet already exists at delivery, because the handover is the delivery.
Are screenshots proof the work is done?
Screenshots are evidence of a screen, not of work. They can be cropped, staged, or taken from a different job entirely, and every client who has been burned once knows it. Worse, a folder of screenshots tells the client you expect to be doubted, while showing them the least checkable form of the work. If a step matters, the client should open the step, not a picture of it. Screenshots belong as supporting color inside a record, never as the proof itself.
How is a delivery record different from a certificate I write myself?
Authorship and timing. A completion certificate is written by you, after the work, asserting the work happened. A delivery record is written by the system the work ran through, at the moment each step executed, before anyone needed proof of anything. The certificate asks to be believed. The record asks to be checked: each step can be opened, its saved result compared, its time read. That is also why the record carries an acceptance state and the certificate does not. A client cannot accept a certificate in a way that changes anything; they accept a delivery, and the state of that decision is part of the record.
When should I send proof, with the work or after?
With the work, always. Proof sent after a question arrives reads as a defense, assembled under pressure, and invites the client to wonder what was left out. Proof that arrives as the delivery itself reads as confidence and makes the question unnecessary. Send the packet with the deliverable and the invoice together: the client checks, accepts, and pays against the same page. If a dispute ever comes later, nothing new needs to be produced, because the packet they received on delivery day is the packet, unchanged.
How do I send proof instead of files on my next delivery?
Run the work somewhere the record makes itself. When the work runs through Zambo, every step is saved as it executes and delivery is one handover link carrying the steps, the times, and the accept or flag decision, so the proof packet is not a document you prepare, it is the form the delivery takes. For $0.99, send proof instead of files on your next delivery: get the Day Pass. A Day Pass covers 24 hours, no subscription. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders, which adds private handover links, your branding, and the approval record as PDF and JSON files.
The client-facing version of this page lives on the main site: a client-ready proof report without giving the client my raw chat history, built on the redacted handover.