Direct answer
Your client says the work never arrived. Here is how that gets settled.
It is one of the oldest sentences in freelance work, and it survives because most delivery channels genuinely cannot disprove it. Email proves you sent something. It does not prove arrival, and it says nothing about opening. This page separates the three claims hiding in the sentence, shows what each channel actually proves, and gives the delivery form that makes the sentence impossible to say with a straight face.
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.
Three claims wearing one sentence
It was never sent. Settled by your side of the record: the sent message, the upload, the saved steps, each with times. If your delivery was a handover, the steps were saved as the work ran, so this claim dies on the timestamps alone.
It was sent but never arrived. Settled by the channel. Attachments die in spam filters, size limits, and full inboxes, and email gives you no arrival signal worth the name. A delivery page has no arrival problem: the work does not travel to the client, it sits at one address, and either the client can open it or nothing about inboxes matters.
It arrived but was never opened. The honest one, and the one no channel fully settles. What settles it in practice is making opening the delivery the client's recorded act: they open the page, they see the work, they accept or flag it. Before that act, the record shows the work complete and waiting, which reframes the conversation from your failure to send into their pending decision. The sister page on a client who says you never delivered breaks the same three claims down from the delivery side, with the exact reply to send.
What your channels actually prove
Email proves composition and sending, full stop. File-sharing links prove a file was placed somewhere at a time; the download log, where one exists, belongs to the platform and may or may not be shown to you. Chat attachments prove the message rendered in a thread the client may never scroll back to. Read receipts, as the FAQ covers, prove close to nothing in either direction. None of this makes you careless for using these channels. It makes the received question unanswerable inside them, which is why experienced clients ask it and experienced freelancers change the channel instead of arguing inside it.
The delivery that answers itself
Delivered, waiting, and provably so
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 between 14:33:42 and 14:34:01 UTC.
- The work sits at one link, complete, with its times. If this client said they never received it, the answer is the link and the record, not a resend.
- Open the handover or read its acceptance.json.
Received, checked, closed
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. Receipt here is not inferred from a mail log; the client's own decision is in the record.
- Open the handover or read its acceptance.json.
What a delivery record cannot prove
A delivery record proves the saved result was not changed since it was saved, and it shows the work waiting at one address with its times. It does not prove a particular human opened the page and read every step; the acceptance record's own scope line says receipt bytes only, not human review of every step. It does not prove who produced the work. What it removes is the fog: sent, arrived, and opened stop being three guesses about an inbox and become states anyone can look at.
Frequently asked questions
My client says they never received my work. What do I do?
Do not just resend the same files into the same silence. First work out which claim it is: never sent, sent but never arrived, or arrived but never opened. Then change the channel, not the attachment. Send the work as one delivery link to a page that holds the work itself, step by step, with the time each step was saved, and ask the client to confirm on that page. A delivery made through Zambo already lives at such a link: the record shows the work saved and waiting, and the client accepts or flags it there, which turns receipt into a recorded act instead of a claim in an inbox. Reply once, factually, with the link and the saved times, and keep that reply with the job records.
Should I just resend the files?
Resending fixes exactly one failure: a message that genuinely never left or never landed, where the second attempt lands. If the work arrived and was never opened, or was opened and the claim is tactical, a resend changes nothing except the date on the argument. Worse, every resend restarts the confusion about which version is current. Resend once if delivery truly failed, and resend as a link to one fixed delivery page, so there is a single place that is the work, and every later conversation points at it.
Do read receipts prove a client received my work?
No. Read receipts are optional on most mail systems, switched off by many clients, and triggered by preview panes and mail scanners that no human looked at. A missing read receipt proves nothing about arrival, and a fired one proves little about reading. Email itself proves sending from your side and nothing solid about the other side. That gap is the whole reason delivery belongs on a page with its own record: the work sits there with its saved times, independent of any inbox, and the client's acceptance on that page is the confirmation, not a mail setting.
What if the client still says they never got it?
Put the facts in one short message and stop adding new ones. The work, the delivery link, the times each step was saved, and the state of the record: delivered and waiting for their decision. If a platform sits between you, file the same link and times with the platform. If the job moves to a formal route, that single message is your exhibit. What you should not do is keep producing fresh deliveries to fresh addresses, which scatters the record and lets the claim survive every version of it. One delivery, one link, one state: that is what makes the sentence impossible to repeat.
How do I make the received question impossible next time?
Deliver to a page, not an inbox. When the work runs through Zambo, delivery is a handover link: the steps saved as they ran, the whole job visible in one place, and an accept or flag decision for the client on the same page. Receipt stops being something you argue about and becomes the state of the record, which reads hold until the client decides and ok_to_release when they accept. For $0.99, deliver your next job so receipt is a state, not an argument: 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.