Client file sharing: what actually works with the people paying you
You finish the work. You attach it to an email, write "let me know if you have any questions", and hit send. Then you spend three days wondering whether they opened it, whether they opened the right version, or whether it bounced off their mail server and is sitting in a quarantine folder nobody checks.
Client file sharing is one of those parts of running a business that nobody teaches you and almost everybody gets slightly wrong. It looks solved. It isn't, because the actual job was never moving bytes from your machine to theirs. The job is making sure the right person sees the current version and understands what they are looking at.
I have been on both sides of this: years of sending decks, reports and one-pagers in growth roles, and now sending proposals and walkthroughs most weeks while building LiveDocument. The file almost always arrives fine. The understanding is the bit that goes missing.
What clients actually complain about
Not your tool. Nobody has ever emailed me to say they were disappointed by my choice of file host.
What they complain about, usually to someone other than you, is version confusion. Three PDFs all called proposal_final sitting in one thread, and no way of telling which one you meant. Or a 40MB attachment that jams their inbox. Or a link that asks them to create an account before they can look at something they are paying you for.
The account one does the most damage. Every login wall between a client and your work is a chance for them to close the tab and come back to it later, and later usually means never. So the rule I work to now is that if a client has to do anything other than click and read, I have made my own job harder.
Three ways to get a file to a client, and when each one is fine
The email attachment
Fine for something small and final. A signed invoice, a one-page summary, anything that will never be revised.
It stops being fine the moment the document has a version two. Most mail providers cap attachments somewhere around 25MB, and Gmail switches to a Drive link above that anyway, which means you are using a cloud link and pretending you aren't. You also get no idea whether anyone read it, and the file lives forever in a thread that will be forwarded to people you did not choose.
A cloud drive link
Google Drive, Dropbox and SharePoint all do this in about four clicks. In Drive it is right-click, Share, then Copy link, and you have to change General access from Restricted to "Anyone with the link" or the client gets a permission request instead of a document. Dropbox does the same job from the Share button with its own copy-link flow, and Google documents the access settings in its own help pages.
This is the sensible default for client work and what I would tell most people to use. Two things to watch. The default permission on Drive is restricted, so a genuinely large share of "can you check this link" emails are just permission requests in disguise. And a drive link puts the client inside your storage tool, which means they see a file browser rather than a document, and sometimes a bit more of your folder structure than you meant.
One thing to be deliberate about: "Anyone with the link" is anonymous access, and it travels with the link when the client forwards it. For a deliverable you would not mind a stranger reading, that is a fair trade for the friction it removes. For pricing, contracts or anything with personal data in it, share with named people or use a link that expires, and put up with the extra step.
A link built for sending work out, not storing it
There is a category of tool designed around the outbound moment rather than the storage: DocSend, Papermark, and the thing I build, LiveDocument. You upload a PDF or an image, you get one link, and you can see page-level engagement afterwards, so you know whether page six was read or skipped. LiveDocument also lets you record a video walkthrough that sits with the document, so the client gets your explanation next to the thing you are explaining. What it will not do is act as your storage or your file manager, and it has no watermarking or NDA gate, so if you need a proper data room with granular permissions, DocSend or a real VDR is the honest answer.
The trade-off across this whole category is the same. You get visibility, and you give up the "everything lives in one drive" tidiness. For work that has to persuade somebody, I take that trade every time. For the raw asset folder with 400 photos in it, I don't.
Set the sharing rules in week one, not week nine
Most client file sharing problems are really naming and ownership problems in a technology costume.
Pick one place things live and say it out loud on the kick-off call. Agree a naming convention that has a date in it rather than the word final. Name one person on each side who owns the folder. Then hold the line, because the first time you email an attachment "just quickly", you have taught the client that the shared folder is optional.
Agree early what happens to access when the work ends, too. Link expiry is the polite version of that conversation, and it stops a two-year-old pricing document turning up in a negotiation you had forgotten about. For the longer version of this with people outside your organisation, I wrote about sharing files with external users separately, and the options are broken down further on the file sharing software page.
A sent file is not a read file
This is the bit that took me longest to accept.
When I was running growth at a data company I would send a deck on a Friday and spend the weekend guessing whether it had been opened, whether the pricing page had landed, and whether the silence on Monday meant no or meant busy. I made a lot of follow-up decisions on absolutely nothing.
Knowing someone opened your document is a start, and tracking a PDF will tell you that much. Knowing they understood it is a different problem, and it is the one that decides whether the project happens. A PDF in an inbox is a static object with nobody standing next to it. If the document needs explaining, send the explanation with it rather than hoping the client books a call to ask.
That is also why I would rather share a PDF as a link than an attachment even for simple stuff. Same effort, and you find out what happened next.
FAQ
Should I use a client portal or just send links?
Portals earn their keep when the relationship is long, the file count is high, and the same people log in every week. For a handful of documents over a few months, a portal is usually more admin than it saves, and clients quietly stop logging in. Start with links, move to a portal when you notice yourself hunting for things.
How do I stop clients opening the wrong version?
Stop sending files that can go stale. A link you can update in place means there is only ever one live version, and the one you replaced stops existing rather than sitting in an inbox forever. If you must send attachments, put the date in the filename and never use the word final.
Do clients mind being tracked?
In my experience, no, as long as you are not weird about it. Nobody is offended that you know your proposal was opened. They get offended when you ring them ninety seconds later to mention it. Use the data to decide what to write in the follow-up, not to prove you were watching.
I built LiveDocument because I got tired of sending work into the void and calling the silence feedback. If that feeling is familiar, it is at livedocument.com.
About the Author
Cameron JamesCameron is the founder of LiveDocument. He writes about sharing documents, PDFs, decks and contracts, and why pairing a video walkthrough with a document beats sending it cold.