ZAMBO.

Direct answer

Prove you delivered the work: hand over a record the client can check, not a claim they have to trust

When a client says the work never arrived, or arrives in a different form than the one being billed, the argument is not really about the work. It is about who holds a record both sides can open. A screenshot can be edited, an email proves a send and not the contents, and your memory of the project is worth nothing across the table. The fix is to prove delivery with a record that was fixed while the work ran: the deliverables, the steps that produced them, and the client's acceptance, each step carrying a verifiable receipt.

See the instrument first: the live demo runs one real call and hands you its verifiable receipt, no signup.

Updated October 29, 2026. First published October 29, 2026.

Step 1. Know what counts as proof, and what only looks like it

Proof of delivery has three parts, and most disputes happen because only one of them exists. First, the deliverable itself, in the exact form the client received. Second, a timestamped record of the work that produced it, made at the time, not reconstructed later. Third, the client's acceptance: a dated decision that the work was received and taken. A file in your sent folder covers a weak version of the first part only. A delivery record that carries all three ends the argument before it starts, because each side is looking at the same fixed record instead of two recollections.

Step 2. Assemble the delivery record from what the work already left behind

Start with what exists. Gather the final deliverables, the messages where the client reacted to them, and any acceptance, approval, or sign-off, however informal. Then close the gap between 'I sent files' and 'here is the delivery': when work runs through Zambo, every call is saved as it runs and carries a verifiable receipt under AER-1, published as an IETF Internet-Draft (draft-zambo-aer1-26), and the job can be closed as a handover, one record that carries the goal, the finished steps with their receipts, the outputs, and the client's decision with its date. A real public example: an accepted handover, 4 of 4 steps checked, decided by the client on 2026-10-16, release marked ok to release. That is the shape of proof that survives a dispute: not a folder of attachments, a single record with a decision on it.

Step 3. Send one link, and let the client run the check

Send the handover link with one short message: here is the delivery record for the project, each step has a verifiable receipt, and your acceptance is on it with its date. The client opens it free, no account, and can check any receipt at zambo.dev/verify: the check recomputes the fingerprint over the saved result and compares it with the fingerprint filed when the call ran. A match shows the saved result was not changed since it was saved. You are not asking the client to trust your screenshot of the work. You are handing them the means to check the work, which is a stronger position in a payment conversation and a calmer one.

Step 4. If the dispute is already live, answer from the record only

When the claim is 'this was never delivered' or 'this is not what we agreed', do not debate from memory and do not send new versions of the work, which muddy which delivery is being argued about. Reply with the record: the delivery date, the acceptance date, and the link. If the work was delivered before you kept records this way, say what your evidence does show, in order: the deliverables, the thread, the acceptance. The companion page covers the harder version of this fight: a client claims you did not do the work you billed for.

Step 5. Set it up before the next job, where it costs nothing

Delivery proof is cheap at the start of a job and expensive at the end of one. Agree the shape up front: work delivered as a handover, acceptance recorded on the record, invoice tied to the acceptance date. Then run the work so the record builds itself. On Zambo the free tier is 20 calls + 1 wrap-up free every day, and picking up in another AI is always free; a Day Pass at $0.99 is unlimited for 24 hours. The 153 tools sit behind one MCP endpoint, and every call, including the wrap-up that closes the job, carries its receipt.

What a record does not settle

A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the work was good, the answer was right, or the client can pay. Quality is the client's acceptance, money is the agreement you both signed, and the record's job is narrower and stronger: it fixes what was delivered, when, and in what form, so the conversation can be about the work instead of about whose memory is better.

Frequently asked questions

How do I prove I delivered work to a client?

Prove it with a record that was made while the work ran, not with evidence assembled after the dispute started. The strong form is a delivery record: the deliverables themselves, the time each step ran, and a verifiable receipt for each step, closed by the client's acceptance on a dated handover. Send the client one link to that record. Anyone can open it and check that the saved results were not changed since they were saved, which turns 'trust me, I sent it' into 'here is the delivery, check it yourself'.

What if I only have emails and chat messages as proof?

Use them, but know their weight. An email proves a file was sent, not what the file contained when it arrived, and a chat screenshot proves what a screen showed, not what was delivered. Attach the actual deliverables, the thread where the client responded to them, and any acceptance message, in that order. Then fix the gap for the next job: run the delivery through a recorded handover so the proof is built while the work happens, not rebuilt under pressure.

Can a client check the proof without an account or special software?

Yes, when the proof is a verifiable receipt under an open format. AER-1 receipts can be checked free at zambo.dev/verify with no signup: the check recomputes the fingerprint over the saved result and compares it with the fingerprint filed when the call ran. A match shows the saved result was not changed since it was saved. The client needs nothing installed and no account, which is what makes the proof usable in a real dispute.

Does proof of delivery prove the work was good?

No, and saying so plainly makes the proof stronger. A verifiable receipt proves the saved result was not changed since it was saved; it does not prove the answer was right or the work was good. Quality is settled by the client's acceptance, which is why the delivery record pairs the receipts with a dated sign-off: the receipts fix what was delivered, the acceptance fixes that the client took it.

Related