Plan a remote video shoot
On a normal set, a hundred small questions get answered by a glance. Remotely, each one becomes a message.
What this is about
Two different things travel under the same name. In one, a local crew shoots while director and client watch from another city. In the other, the subject records themselves at home while somebody directs down a video call. Both fail at the same point: bandwidth for decisions. Every question that would have taken two seconds on set turns into a delay and a chance for two people to assume different things. The planning work therefore moves forward — into a more explicit brief, a defined comms channel, and a written list of the decisions the local crew is allowed to make alone.
The order matters more than the tools. Skip a step and you usually notice two steps later — by which point the fix costs several times as much.
What runs differently here
In planning terms, that means:
- Remote supervision needs one channel and one voice — a director speaking through three people produces three contradictory instructions.
- A live monitoring feed carries latency and compression: judge framing on it, never focus, exposure detail or colour.
- Decision rights are delegated in advance: what the crew changes alone, what needs a call, and who picks up.
- Self-recording contributors need a kit and a rehearsal, because a second attempt costs an entire additional day.
Step by step
This order gets you there fastest:
- Decide who is physically on set and who is not, then give the on-set side a clear lead — the person the crew turns to when the link drops.
- Brief harder than usual: shot list with reference frames, a floor plan or location photos, and one written line per shot on what it has to achieve.
- Set up one comms channel for the shoot day plus a backup, and agree that instructions given anywhere else simply do not count.
- Test the monitoring path before the shoot day with the same network, hardware and people, at the actual location whenever that is possible.
- Write down which calls the local crew makes alone — framing tweaks, lens swaps, wardrobe. Anything off that list gets a phone call rather than a guess.
- Put check-in points into the schedule instead of supervising continuously: after the first setup, after each location, before wrap. The day keeps moving between them.
- Have the crew upload dailies or selected takes the same evening, so a problem surfaces while the location and the cast are still available.
- Give the client their own on-set contact. A client watching a laggy stream needs someone to interpret it, or every soft frame becomes an emergency.
Common pitfalls
What most often goes wrong in practice:
- Judging focus on a compressed stream and calling a sharp take soft, or a soft take good.
- Running the shoot through a group chat where three people give the camera three different instructions.
- Booking a location with no usable connection when remote supervision was the entire plan.
With TillyGen
TillyGen hands a remote crew the unambiguous version of the plan: shot list, storyboard frames and schedule in one place, so nobody reconstructs intent over a phone line.
Change one constraint and the consequences travel through the whole plan: affected shots are flagged, the call sheet is regenerated, and nobody keeps working from yesterday's version.
Frequently asked
What connection does a remote shoot need?
Enough upstream for a stable monitoring feed, tested at the location itself with the real gear. A phone hotspot behaves differently once the crew arrives.
Can the client watch the shoot live?
Yes, with expectations set first. Streams lag and compress, so agree that framing is judged live and image quality is judged on dailies.
How do we direct someone recording themselves?
Send a kit, rehearse on a call and record a test the day before. Home recordings usually fail on sound and light, and both are fixable in advance.
How long does it take to get started with TillyGen?
A first project takes under an hour to set up. There is no configuration phase in which templates and fields have to be defined before the tool produces anything.
Can the results be exported?
Yes — as PDF for the crew, CSV for downstream systems and through the API for anything automated. The plan stays the source; the exports are views of it.