File request best practices: 9 things to specify upfront
The difference between a clean file handoff and a confused one is usually nine specifics the requester forgot to mention. Here is the checklist.
June 30, 2026 · 9 min read · Dropspot
The first request goes out. Two days later, the wrong files come
back — in the wrong format, at the wrong resolution, from the
wrong person, with the wrong naming convention. You ask for the
right version. They send the right version. The whole exchange
took four days and three back-and-forths.
Almost every one of those back-and-forths could have been avoided
by being explicit upfront. Not just about what you need — most
people remember that part — but about the nine specifics around
the deliverable that most file requests skip.
This is the checklist. Run it before you send the next request.
The single most common mistake. You ask for "the logo" and you
get a JPG when you needed an SVG. You ask for "the videos" and
you get H.264 MP4s when you needed ProRes 422. You ask for "the
photos" and you get JPGs when you needed RAW.
The fix is two lines in the request: the format you need, plus
why. The "why" matters because senders sometimes have choices
you don't know about. "Send me the RAW files — I need to grade
them" is more useful than "send me the RAW files." If the
sender doesn't shoot RAW, they can offer JPEG + an explanation
of why.
Bare minimum to specify:
Format/codec — JPG/PNG/HEIC/RAW for photos, H.264/ProRes/
RAW for video, WAV/MP3/AIFF for audio, SVG/PNG/PDF for design.
Why — one short clause so the sender can adapt if they
can't deliver the exact format.
The second most common mistake. You ask for "high-resolution
photos" and get 1920×1080 JPGs because that's what their phone
exported. You wanted 4000×3000.
State the minimum:
Photos: minimum long edge in pixels. "Long edge ≥ 4000px"
is a number; "high-res" isn't.
Video: minimum resolution + minimum duration. "1080p, at
least 30 seconds" vs "good quality."
Audio: minimum sample rate + minimum duration. "48 kHz,
at least 60 seconds" vs "decent audio."
The number does the work that adjectives can't. If the sender
can't meet it, they tell you and you decide together — instead
of finding out three days later.
Option A: Strict convention. "Files should be named
YYYYMMDD_lastname_description.ext." Useful when you're
ingesting into a system that expects a specific shape. Annoying
for the sender; takes a sentence to explain.
Try the shape
One link to receive anything from anyone.
Pick a handle. Live in 60 seconds. Free until you're getting real volume.
Option B: Loose convention. "Just include your last name in
the filename somewhere." The 80/20 of file naming — enough
context to find anything later, no friction on the sender side.
Option C: Don't bother — let the inbox tag. If your intake
system tags files by sender on arrival (the Dropspot
inbox shape does this), the sender's filename
doesn't matter much. You can find the files by sender + date
later without any convention.
Pick the option that fits how you'll process the files. The
common failure mode is picking nothing — files come in as
IMG_4823.HEIC and you spend an hour renaming.
Three configurations, each appropriate to a different context:
Anonymous. Sometimes correct. Tipsters to journalists. Honest
feedback to a manager. Demo submissions where you'll judge on
the work, not the name.
Name only. Casual context. Wedding guests, podcast voice
notes, community submissions.
Name + email. Professional context. Client briefs, recruiting,
vendor handoffs. Email lets you reply without a separate channel.
Specify which one in the request. A common mistake is asking for
"your contact info" — that's vague enough that some senders give
you a phone number, some give an email, some give Instagram
handles. The reply step gets messy.
If you want both: make both required, and label clearly.
"Required so I can confirm receipt" is better than just a red
asterisk.
The deadline is when you need the file in your hand. State
it in absolute terms — "by end of day Friday May 31st," not "by
next week." Senders read "next week" differently than you do.
The auto-delete window is when files age out of the inbox.
Different from the deadline. Useful because senders see the
countdown and treat the upload accordingly — they upload
before expiry rather than at the last minute.
Default windows that work:
7 days for casual intake.
30 days for professional client work.
60 days for events (weddings, conferences) where slow
uploaders are common.
Custom for compliance-heavy contexts (legal/medical).
State the window in the request. "Files auto-delete after 30
days unless I star them" sets the expectation cleanly.
A surprisingly common confusion. The sender has eight photos. Do
they upload them as eight separate submissions or one
multi-file drop?
The answer is "one multi-file drop" almost always — fewer
notifications for you, less context-switching for them. But it
helps to say so explicitly. "Drop all your photos at once;
multi-select is supported."
If you specifically want one file per submission (for instance,
each file needs its own metadata or comment), say that too.
"Upload one at a time so you can add a caption per photo."
If you're collecting briefs, the "talk it through instead of
typing" option needs an explicit invitation. Otherwise, senders
default to text — because forms have trained them that text is
what forms are for.
A specific line that works: "If you'd rather just talk it
through, hit the voice note field — 60 seconds is plenty."
This is doing two jobs: it normalizes voice as a real submission
modality, and it caps expected length so senders don't feel they
have to deliver a podcast episode.
Same shape for screen recordings: "Or record your screen if
you'd rather show me — under three minutes is best."
8. The next step they'll get (auto-reply or human follow-up)#
A request without a stated next-step leaves the sender wondering
if their upload went through. Two common configurations:
Auto-reply. A confirmation email immediately on upload.
"Thanks — got your files. I'll reply within X days." Works for
high-volume intake where you can't personally reply to every
submission.
Human reply within a window. "I'll get back to you within
two business days." Higher trust signal, higher work cost.
Appropriate for client-facing intake.
State which one in the request. The sender adjusts their
expectations accordingly. The worst experience is uploading,
hearing nothing for a week, and starting to wonder if anything
arrived — which leads to a follow-up email asking "did you get
my files?" that you now have to reply to.
9. The single permanent link they'll come back to#
The biggest leverage point. If your file request goes out via
WeTransfer (one-shot link), the sender treats this submission
as a one-time event. If your file request goes out via a
permanent inbound link they can return to, the sender treats
it as an ongoing channel.
The permanent-link shape changes behavior on the sender side:
They save the URL (or your business card with the QR) instead
of bookmarking an email.
They send additional things they remembered after the fact —
without you asking.
They reference the same URL when colleagues ask "where do I
send my files?"
State the link's permanence in the request itself. "This is my
permanent link — save it; you can drop anything else relevant
here over the coming weeks too."
The sentence sounds small. It changes the workflow.
The "send me a few photos" request. Underspecified by
design — the requester wants flexibility and trusts the
sender's judgment. Fine for friends-of-friends contexts;
problematic for professional work because "a few" turns into
"two" or "twenty" depending on the sender's mood.
The "use the contact form" request. No file upload field;
sender has to follow up via email. The intake fails before it
starts. Either give them a real upload surface or don't ask.
The "WhatsApp me" request. Casual; works for one-off
handoffs; breaks at three or more senders because WhatsApp has
no inbox structure. Switch to a real inbound link the moment
the volume justifies it.
Do I really need to specify all nine every time?
For high-volume intake, yes — automate it into the form's intro
text. For one-off requests to people you know well, half of
them are implicit. The cost of specifying is one minute; the
cost of missing one is usually a day.
What if my senders are non-technical?
The checklist works better for non-technical senders, not
worse. Technical senders fill in the gaps from context;
non-technical senders need the specifics.
Won't a long request page feel intimidating?
Not if it's bulleted and skimmable. The list above takes ten
seconds to read; a 200-word paragraph of the same content
would take a minute. Structure matters.
Can I just template this and reuse it?
Yes — that's the point. Build the intake page once, set the
defaults once, and the next 200 requests inherit the structure.
What if the deliverable changes per project?
Most of the nine specifics don't change per project (sender
identity, deadline structure, auto-reply, link permanence).
Three or four do (file type, dimensions, naming). Make those
configurable per intake page; lock the rest.
The handoff isn't the file. The handoff is the agreement around
the file. Specify the nine things upfront and the file arrives
right the first time. Build your file-request page —
the version that doesn't generate follow-up emails.