How to Share Project Files With a Client and Keep Proof of Delivery

The internal handoff is finally solid. A crew submits the files, the office accepts them, the work gets filed, and every step has a name and a timestamp on it. Then the deliverable goes out to the client, and all of that discipline evaporates. It leaves as an email attachment or a link to a shared folder, and the moment it lands in someone else's inbox the record stops. Did they open it? Did they get all of it? Is the link they were sent still live in a forwarded thread three months later? Nobody can say.

Client delivery is the last mile of the handoff, and it is usually the least tracked part of the whole process. That is a strange place to lose the thread, because it is often the step that matters most: the client receiving the final files is the event a payment, a sign-off, or a dispute hinges on. The goal of delivering files to an outside party with a record is to make the last mile as tracked as the rest of the road.

Why the usual methods lose the record

Every common way of getting files to a client trades away something you will want later. Email attachments hit size limits and, more importantly, produce no reliable confirmation of receipt; a read receipt, where it works at all, tells you an email was opened, not that the files were downloaded. A public folder link is convenient but blunt: it usually cannot be revoked once sent, it may expose more than the one deliverable, and anyone the link is forwarded to can walk in. A send-a-big-file service moves the bytes but forgets the whole exchange the moment its own link expires.

None of these were built to be part of a record. They are transport, not documentation. What a firm actually needs at the client handoff is narrow: give one outside party access to one set of files, on terms you control, and log what they do with it.

What a share link does differently

A share link points at a single packet the office already holds. The recipient opens a page with that packet's files and notes and nothing else — not your queue, not your other jobs, not a hint of the rest of your firm. They do not need an account. And the important part happens quietly in the background: each time they open the page or download a file, that action is written to the packet's audit trail, next to the recipient the link was made for. The proof of delivery is generated by the delivery itself.

Because the link is scoped to one packet and tied to your firm's record, it extends the same accountability you already have internally out to the client, instead of dropping it at the door.

The controls that make it safe to send

A link is only useful if you can decide how far it reaches. Three settings cover the real cases:

• Expiry. A link can lapse after 7, 30, or 90 days, or never expire when the files are not sensitive and you want the client to keep reaching them. You choose per link, by how much the contents matter.
• Passcode. For anything traveling by email, add a passcode and give it to the recipient another way, so the link alone is not enough to open the files. Leave it off when a plain link is fine.
• Revocation.Sent the wrong link, or finished with it? Revoke it and it stops working at once, whether or not it had an expiry date. There is no orphaned link left live in someone's inbox.

The token behind a link is long and random, and only its hash is stored, so the link works but nobody, including us, can read a working link out of the database. It is a narrow, controlled window, not a shared drive.

Not every file is sensitive — and that is fine

A reasonable objection to expiring links is that plenty of deliverables are not confidential and should simply stay reachable. A final plat, a closeout photo set, a report the client will want to pull up next year — making those expire is an annoyance, not a safeguard. That is exactly why a link can be set never to expire. Sensitivity is a spectrum, and the firm that produced the files is in the best position to place each delivery on it. The tool's job is to offer both ends and stay out of the way.

Keeping the proof after the files leave

The reason to track delivery is the same reason to track anything else in the handoff: the question comes later, and memory is a poor witness. When a client says they never received the final files, an entry in the audit trail showing the link was opened and the files downloaded, on a specific day, ends the conversation. This is the client-facing companion to producing proof of file delivery inside the firm and to documenting exactly what was submitted, received, and filed: the same record, now extended to the last party in the chain.

The finished deliverable should not fall out of the system at the most important moment. Send it on a link you control, let the link log its own use, and the last mile of the handoff becomes as provable as every step before it.