Ask an agency how it handles client file delivery and the answer involves a service with nothing to do with their email: a Dropbox account, a WeTransfer tab, a Google Drive folder shared with a personal address somebody set up years ago. It works, in the sense that files arrive. It also means every client relationship spans two systems that know nothing about each other, and the handover when staff change is whatever that person remembered to write down.
This page is about doing client file delivery from the same account that holds the mail, why that removes a category of small failures, and where a dedicated file service is still the better answer.
How the Usual Setup Fails
The failures are rarely dramatic. They're the slow kind that cost an hour each and never get counted.
Links expire without warning, so a client returning to a file three months later finds nothing and emails to ask. Personal accounts hold company material, and when that person leaves, so does access. Nobody can say who has a given file, because sharing was done ad hoc by whoever had it open. And the file service bills per user while the email bills per user, so client file delivery is being paid for twice on two separate invoices.
None of that is a crisis. All of it is friction, and friction accumulates precisely where you can least afford it — in the part of the relationship the client actually sees.
Client File Delivery From the Mail Account Itself
The alternative is that storage sits in the same account as the mailboxes, so the files and the correspondence about the files live in one place with one set of permissions.
Two mechanisms cover most of it. Share links handle one-off delivery: a link to a file or folder, revocable at any time, with a cap on downloads. Folder sharing with another account handles the ongoing case: a client or contractor with their own account gets access to a folder that stays put, rather than a link that has to be reissued.
The practical difference from a separate file service is that revocation is real and immediate. Client file delivery through a link you control means the day a relationship ends, access ends, without anyone having to remember which of five services holds what.
Structuring It So It Survives Staff Changes
The pattern that lasts is boring and worth writing down before you start rather than after.
One folder per client, not per project. Projects end; clients come back. A folder per client with projects inside it means returning work has somewhere obvious to go, and a new account manager can see the whole history at once.
Name folders the way you name everything else. If your job numbers or client codes appear in mailbox names, use the same codes here. Client file delivery breaks down when finding the folder requires asking someone.
Share the folder, not the file, for anything ongoing. Individual file links are right for one-off delivery and wrong for a relationship, because you end up with dozens of links nobody tracks.
Decide what happens at the end. Archive, revoke, or hand over — but decide once, as policy, rather than case by case at the point when someone is annoyed.
Pairing this with a mailbox per client makes the whole thing coherent: correspondence and files both belong to the client rather than to whoever handled them, which is the pattern described in a mailbox per project.
The Cost Side
Storage runs on a slider from 250 GB at $3.20 a month up to 100 TB, priced by capacity rather than by seat. For client file delivery that distinction matters more than the headline rate, because agencies are exactly the customer per-seat pricing treats worst — a handful of staff holding material for dozens of clients. Dropbox's team plans bill per user with a shared storage allowance attached, which is the model that punishes a small team holding a lot.
Ten people needing 5 TB pay for 5 TB here, not for ten seats with a storage allowance attached. And there's no egress charge, so a client asking for everything at the end of an engagement doesn't produce a bill.
Against a dedicated file service the arithmetic usually favors consolidation, though not always, and the honest comparison depends on how much you're storing rather than how many people touch it.
Where a Dedicated File Service Still Wins
Being straight about this is more useful than pretending the consolidated option is always right.
Real-time collaborative editing. If your clients expect to open a document and type in it alongside you, that's Google Workspace or Microsoft 365 and nothing here replaces it. Client file delivery is not the same problem as co-authoring.
Client-facing portals with heavy branding. If the file-sharing surface is part of your product, a purpose-built portal will do it better.
Enormous shared working sets with constant churn. A video team scrubbing terabytes daily wants tooling built for that, not a general drive.
Clients already standardized elsewhere. If every client is on SharePoint and expects you to be too, fighting it costs more than it saves.
The consolidated approach suits delivery — finished work going out, source material coming in, held for the length of a relationship and then cleanly cut off. That's the majority of agency file movement, but it isn't all of it.
Handing Over at the End of an Engagement
The end of a client relationship is where file arrangements are tested, and where the ad-hoc version fails most visibly.
Clients are entitled to their material, and the request usually arrives at the least convenient moment, often after the working relationship has cooled. If the files are spread across a personal Dropbox, three WeTransfer links that expired, and somebody's desktop, the handover becomes an archaeology project billed to nobody.
With everything in one folder per client, the handover is a single share, or a download, or a transfer of the folder to their own account. It takes minutes, it's complete, and it's demonstrably complete — which matters if there's any dispute about what was delivered.
Decide in advance whether you keep a copy afterwards. There are good arguments both ways: retention protects you if questions arise later, and deletion reduces what you're responsible for holding. What causes trouble is not deciding, and discovering two years on that you still hold a former client's material without knowing why.
Receiving Files From Clients
Client file delivery is usually discussed in one direction, but the inbound side causes at least as much friction and is worth setting up deliberately.
Clients send source material, and left alone they'll send it as email attachments that bounce, or through whichever service they happen to use, arriving in three different places. Giving them a way to put files into the right folder directly removes the sorting work and the "can you resend that?" exchange.
An upload destination per client, shared with them, means their material lands where it belongs without anyone moving it. Where the client won't adopt anything new — which is common, and not worth fighting — the fallback is that oversized attachments they send you still arrive as links rather than bounces, and can be filed once on receipt.
Getting the Files to the Client
Delivery itself ends up being unremarkable, which is the point. A file too large to attach becomes a link automatically as you compose, so client file delivery for a single deliverable is just sending an email. Larger handovers get a shared folder. Everything is revocable and everything is visible in one place.
The mechanics of the links, including download caps and revocation, are in how share links work. If a client or contractor needs the material to appear as a mounted drive rather than a browser tab, that's WebDAV access.
The gain isn't any single feature. It's that client file delivery stops being a second system with its own logins, its own bill and its own institutional memory, and becomes part of the account you were already paying for and already administering.
