How to collect files back from a client without email attachments

Why attachments are a poor way to collect files

When a client needs to send you something, email is the default. It works for a single document. It works much less well for a logo pack, a folder of photographs or the third round of corrections to a brochure.

The problems are familiar. Mail servers reject large messages, so the sender splits the files across several emails or falls back on a transfer service. Attachments are copied into every recipient's inbox, so a correction cannot reach the copies already sent. Nothing connects the file you receive to the request that prompted it, and nobody can say later which version was the one approved.

A share link avoids most of this. Instead of the file travelling, the file stays in one place and people go to it. That applies in both directions: you can send files out through a link, and you can let a client send files back through one.

What to settle before you send the request

Most collection problems start with an unclear request. A few minutes spent on the following saves several rounds of follow-up.

• The exact list. Name each item you need, rather than asking for brand materials in general.
• The formats. Say whether you need vector logos, print-resolution images or editable source files, and say which formats you cannot use.
• A naming pattern. If you want files to arrive as client-logo-primary-colour.svg, give an example. People follow an example more reliably than a description.
• A deadline. Link expiry dates are easier to defend when the request itself has one.
• One owner on your side. Decide who accepts the files, so the client is not answered by three people.

Setting up the link

A collection link needs fewer settings than a distribution link, but each one matters.

Identify the sender

An anonymous upload page invites spam and makes it impossible to know who sent a file. Asking the person to confirm their email address with a one-time code is enough to tie each upload to a named sender without asking them to create a password or install anything.

Limit the lifetime

Give the link an expiry date that matches the request. A link left open for years is a standing route into your library, and the recipient will forget it exists. If a password is warranted, send it by a different channel from the link.

Keep uploads apart from your library

Uploaded files should not land directly among your approved assets. Hold them somewhere separate first, so that a wrong file, a duplicate or a file nobody asked for does not sit next to the current logo where someone might use it.

Reviewing what comes back

Review is the step that makes a collection link trustworthy. For each incoming file, someone should check four things:

• It is the item that was requested, in a usable format.
• It opens, and it is complete.
• It has the rights and permissions that the sender claims, where that is relevant.
• It is not a duplicate of something already held.

Accepted files then get a proper name, a folder, and the metadata the rest of your team relies on, such as brand, asset type and licence. Rejected files should be removed, and the sender told why so that the replacement is correct.

Keeping a record

A link also gives you something an attachment does not: a history. For each link you can see when it was opened and what was uploaded. That helps when a client says they sent the files last week, and it helps when you need to show which file was approved before a campaign went out.

Comments on the same link keep questions next to the files they concern. This is more useful than a thread buried in a mailbox, because anyone who picks the project up later can read it in context.

How this works in ContentCamel

ContentCamel handles collection this way. A share link can allow uploads as well as downloads, and the recipient confirms their email address with a one-time code. Files that come back go to a review queue with a thumbnail and their origin, and they only become assets when a team member accepts them. Accepted files are filed in a Received via share folder, and rejected files are deleted after 30 days.

The same approach works for freelancers returning revisions, and for organisations that want to stop relying on email attachments altogether. Links can carry a password and an expiry date, and every open, download and upload is logged against the link.

A short checklist

• List the exact items, formats and file names you expect.
• Send one link per request, with an expiry date.
• Identify each sender rather than accepting anonymous uploads.
• Hold incoming files in a review area, not in the main library.
• Check, name and file each accepted file, and tell the sender about any that are rejected.
• Keep the link's activity and comments with the project.