A practical guide to gathering VTs, graphics and media from remote contributors for a broadcast or live event — why email and WeTransfer fall apart, and the workflow that actually scales.
Every producer knows the week-of-show scramble: a dozen contributors, each sending a VT, a lower-third spelling, a sponsor logo and a headshot — by email, WhatsApp, a shared drive, a file-transfer link that expired, and one memory stick that never turned up. The files arrive named Final_v3_ACTUAL.mov, half of them are missing the metadata you needed, and you find out at 4pm that the 900 MB opener never finished uploading.
Collecting assets is one of the least glamorous parts of running a show, and one of the most common places for a broadcast to go wrong. This guide covers why the usual tools struggle, what a reliable collection workflow actually looks like, and how to set one up.
Why email and file-transfer tools break down
The tools most teams reach for weren't built for broadcast asset collection, and it shows once you're past a couple of contributors.
- Email silently caps attachments at 20–25 MB. A single ProRes VT blows straight past that, so contributors compress, split or give up — and you lose control of quality.
- Consumer file-transfer links handle size, but links expire, downloads are all-or-nothing on a flaky venue connection, and you get a pile of files with no structure and no idea who sent what.
- Shared cloud drives turn into a free-for-all: contributors can see (and overwrite, or delete) each other's files, folder conventions drift, and there's no record of who uploaded which version when.
- None of them collect metadata. The clip title, duration, the exact lower-third spelling, clearance notes — that all ends up in the email body, a separate spreadsheet, or nowhere.
The common thread: these tools move files. A show needs to collect assets — files plus the information around them, from known people, in a structured, auditable way.
What a good collection workflow looks like
A workflow that survives contact with a real show has six properties. Whether you build it yourself or use a purpose-made tool, aim for all six.
1. One point of collection per show
Every contributor goes to the same place for a given show, rather than replying to whichever thread they can find. That single funnel is what lets you see, at a glance, what's in and what's still outstanding.
2. Per-slot rules
Not every asset is the same. Your VT slot might allow 1 GB video files; your graphics slot only PNGs up to 25 MB. Define the allowed file types, the size limit and the required fields per slot, so contributors can't send you a .key file where you needed a .mov.
3. Verify who's uploading
An asset you can't trace is a liability — for clearance, for corrections, and for spotting the wrong-file-attached mistake before air. Verifying each contributor's identity (a simple email one-time code is enough) creates an auditable record of who submitted what.
4. Large files that survive a bad connection
Broadcast files are big and venue Wi-Fi is bad. A 900 MB upload that restarts from zero every time the connection hiccups will never finish. You need resumable transfer — the upload picks up where it left off rather than starting again. This one property is the difference between "it uploaded overnight" and "it never uploaded". (More on this in how to send large video files to a production team.)
Resumable uploads use a protocol (the open TUS standard) that checkpoints progress as the file transfers, so a dropped connection resumes instead of restarting. It's the same idea behind reliable large-file uploads in tools like Vimeo and Cloudflare Stream.
5. Blind uploads
Contributors should submit into the show, not browse it. They shouldn't see each other's files, and ideally can't revisit or edit their own once submitted. This keeps assets confidential between contributors and gives you a clean, tamper-resistant record.
6. Notifications and a lifecycle
You want to know the moment a file lands — not to go hunting. And once the show has aired, those assets shouldn't live on your disk forever: a retention policy that auto-expires media after the broadcast date keeps storage (and data-protection risk) under control.
Metadata: the part everyone forgets
The file is only half the asset. For every VT you almost always need the on-screen title, the duration, the correct spelling of names for the lower third, and often a clearance or source note. Collect that at the point of upload, attached to the file, and you eliminate the parallel spreadsheet entirely. Skip it, and you'll be chasing 12 people for details on the day.
A good rule of thumb: if a piece of information has to be typed into the graphics system or the running order later, capture it when the file comes in. For the full field-by-field breakdown, see what metadata to collect with every VT.
A quick pre-show checklist
- A single upload point per show, split into slots with their own rules
- Per-slot file-type and size limits set
- Required metadata fields defined for each slot
- Contributor identity verified on upload
- Resumable transport for large files
- Real-time notification when a file arrives
- A retention/expiry policy for after the show
How Show Runner handles this
Show Runner was built specifically for this problem. You create a show, add upload slots (VTs, GFX, running orders — each with its own allowed types, size limits and metadata fields), and hand each slot a 16-digit contributor key. Contributors enter the key, verify their email with a one-time code, and upload — with every file carrying the metadata you asked for. Uploads are blind, resumable up to 1 GB on the TUS protocol, and you're notified by email and in-app the instant a file lands. Assets auto-expire after the broadcast date unless you keep them.
It's the six properties above, out of the box, without the spreadsheet.
FAQ
How do contributors send large video files without an account?
They don't need one. You share a contributor key for the relevant upload slot; the contributor enters it, verifies their email with a one-time code, and uploads directly. No sign-up, no software to install — just a browser.
What file size can contributors upload?
Show Runner supports resumable uploads up to 1 GB per file over the TUS protocol, so large broadcast files upload reliably and resume automatically if the connection drops. You can set a lower per-slot limit where you want to cap it.
Can contributors see each other's uploads?
No. Uploads are blind: a contributor submits into the slot and sees only a success confirmation. They can't view other contributors' files or browse the show, which keeps assets confidential and the record clean.
How long are assets kept?
By default, assets are retained until the show's lifecycle expires — typically 30 days after the broadcast date — after which they're automatically deleted. Permanent retention is available on higher plans.
Ready to stop chasing files by email? Start collecting assets the reliable way — it's free to begin.