Outside Broadcast and Remote Production Scheduling: When One Truck Has Been Promised to Two Live Events

Why one bad scheduling decision costs more than the software

It is Wednesday. Saturday has three fixtures: a top flight match at three, a rugby kickoff at half past five two hundred miles away, and a Sunday morning motorsport meeting that needs a derig and a transit overnight. Truck B came back from Thursday with a vision mixer fault and the engineer thinks it is fine but will not put that in writing. Your senior EVS operator has just accepted a job from another facility because nobody confirmed him. The wall planner in the office is accurate as of Monday, the real schedule is in a spreadsheet, and the actual crew list is in three WhatsApp threads.

Everything in this business is unforgiving in the same way: the event happens whether you are ready or not. A double booked truck on a live sports weekend cannot be recovered by working late. You subcontract a unit at short notice at whatever the market will charge, or you fail to deliver a broadcast that a rights holder has sold advertising against. Both outcomes cost more than any scheduling system.

The specialist products here are Xytech MediaPulse, which is the enterprise incumbent across media operations and genuinely strong on facility scheduling and billing, and Farmerswife, which is well liked in production and post and much lighter to run. Neither was designed around the specific shape of a mobile outside broadcast business, where the unit is a truck plus a kit set plus a crew plus connectivity plus a journey, all of which must be true at once for a job to exist. Generic resource schedulers and project tools are worse, because they book one thing at a time.

Problem 1: you do not book a truck, you book a set

A job needs a unit with enough camera channels, a specific number of EVS channels, a particular audio desk if the client's A1 insists, RF links if there are roving cameras, comms panels, and a connectivity path back to the gallery or the broadcaster. Some of that kit lives permanently in the truck. Some is flightcased and moves between units. Some is hired in when three jobs collide.

Off-the-shelf schedulers model resources as independent bookable items, so a scheduler can happily assign truck A to Saturday and separately assign the same RF rack to a different job on the same day, and nothing objects until the kit list is printed on Friday. Xytech handles resource conflicts properly, which is a real strength, but expressing that a job needs a unit meeting a capability profile rather than a specific named truck is where most systems stop.

What a custom build does: model capability, not just identity. A job specifies twelve camera channels, six EVS channels, a certain audio configuration and two RF paths. The system offers the units that satisfy it, shows what would need to be hired in to make a smaller unit work, and holds the kit as a set so nothing in it can be committed elsewhere while the job stands. Then a change to the job requirement, which happens constantly, immediately shows what breaks.

Problem 2: fixtures move, and the schedule has to move with them

The broadcaster picks the match for a different day. The rugby is postponed for weather. A tournament runs long and the schedule shifts by a day. In this business the calendar is not yours, and a change to one event cascades: the truck that was going to Cardiff on Saturday now goes on Sunday, which breaks the derig time, which breaks the transit, which breaks the driver's hours, which breaks Monday.

Most tools let you drag a booking to a new date. What they do not do is compute the consequences. So the scheduler works out the cascade in their head, and the quality of your operation depends on that person being available and awake.

What a custom build does: treat a job as a chain of dependent tasks with real durations, meaning load, transit, rig, rehearsal, transmission, derig, transit back, service. Move the transmission time and the whole chain moves with it, with the system flagging every downstream conflict: a driver who now exceeds permitted hours, a rig that starts before the previous derig ends, a freelancer whose turnaround falls below the contractual minimum. The scheduler still decides. They just decide with the consequences visible instead of remembered.

Problem 3: crew rules are contractual, and breaking them is a real cost

Freelance crew work to agreements. Minimum turnaround between finishing one job and starting the next, travel days, overnight rates, meal breaks, and a distinction between a working day and a travel day that materially changes what you owe. Where trucks move on public roads, drivers are governed by hours of service rules with recording obligations, and those are legal limits rather than negotiable preferences.

Generic scheduling software has no concept of any of this. It will let you book a camera operator to derig at one in the morning in Manchester and rig at seven in Southampton, and the first person to notice will be the operator, who will decline and tell three colleagues that your facility does not know what it is doing. In a market where crew choose between facilities, that reputation is expensive.

What a custom build does: hold rest and turnaround rules per agreement type and enforce them at the moment of booking, with an override that records who authorized it. Skills and certifications live on the crew record, including rigging and working at height where relevant, so an unqualified booking is caught. Driver hours are modeled against the actual journey rather than a guess, because a transit that looks fine at motorway speed is not fine on a Sunday with roadworks.

Problem 4: connectivity has lead times and lives in somebody's inbox

Fiber circuits are ordered from providers with lead times measured in weeks, not hours. Satellite space segment is booked for windows. Remote production over IP, where the gallery stays at base and only cameras and a small crew travel, changes the equipment picture entirely but makes the connectivity path the single point of failure for the entire show.

In most facilities this ordering process is email plus a spreadsheet, held by one person. When they are on leave, the risk is that a circuit for a job three weeks out was never actually confirmed, and nobody finds out until the rig.

What a custom build does: make connectivity a bookable resource on the job with its own state, meaning requested, ordered, confirmed, tested and live, with the provider reference and the ordering deadline attached. The job cannot show as ready while the path is unconfirmed. For remote production the system tracks both ends, since a job now consumes gallery capacity at base as well as kit on site, and gallery capacity is the constraint that quietly limits how much remote work you can take.

Problem 5: you find out whether a job made money when the invoices arrive

A job carries a quoted price, and against it sits truck time, kit hire, freelance day rates, subcontracted units, fuel, tolls, ferries, hotels, per diems and overtime. Freelancer invoices arrive weeks later, sometimes with rates nobody agreed in writing. By the time finance closes the month, the crew that produced the loss have moved on to four more jobs.

What a custom build does: accrue cost against the job as it is committed rather than as it is invoiced. A booked freelancer at an agreed rate is a cost the moment the booking is confirmed, so the job margin is live and visible while there is still time to act. Rate cards hold client-specific pricing, and a quote is generated from the same resource model that will deliver the job, which means the estimate and the actual are directly comparable. The report worth having is margin by client and by event type, which regularly shows that the prestige contract everyone fights to keep is carried by the routine midweek work nobody talks about.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the honest shape is this. A focused first release covering resources modeled as capability sets, the event and job chain with dependent tasks, crew booking with rest and turnaround enforcement, and a schedule view your planners actually run the week from, runs $70,000 to $140,000 and ships in 12 to 18 weeks. A full platform adding connectivity ordering, travel and accommodation logistics, rate cards and quoting, live job costing, crew self-service with availability and timesheets, and finance integration runs $170,000 to $380,000 phased over 6 to 12 months.

What drives cost up in outside broadcast specifically: operating across borders, since carnets, different driver hours regimes and cross-border crew arrangements are real complexity; a large remote production operation, because modeling gallery capacity at base alongside kit on site effectively doubles the resource model; integration with an existing finance system for purchase orders and freelancer payments; and any requirement to sync with a rights holder's fixture feed, which is the difference between hearing about a schedule change on Wednesday and hearing about it on Monday.

What keeps cost down: starting with resources, jobs and crew booking, and leaving quoting and costing to a second phase. The double booking is the thing that burns money this month.

Build versus buy, and when buying is right

Buy, or simply stay on a spreadsheet, if you run two or three units with a staff crew and a small number of long-running contracts. A competent scheduler with a shared calendar will beat a partially adopted system.

Consider Xytech if you are a larger media operation where outside broadcast sits alongside post, playout and facility work, since the breadth is the point and the billing side is mature.

Build when two or more of these are true. You own multiple units and your kit moves between them, so capability rather than truck identity determines what can take a job. Your crew are mostly freelance and their agreements have rules your scheduler currently enforces from memory. You do enough remote production that gallery capacity at base has become a scheduling constraint. Your fixtures move often enough that cascading reschedules happen weekly. Or you cannot state the margin on last month's jobs without waiting for invoices.

The honest tipping point in this sector is a person, not a number. When one scheduler holds the operation together and the business cannot function during their annual leave, the knowledge needs to move into a system while they are still there to explain it.

How to choose a developer for broadcast resource scheduling

Ask them to model a job on a whiteboard. If they draw a booking with a start and end time, they have understood none of it. You want load, transit, rig, rehearsal, transmission, derig and return as dependent tasks, with resources attached to the phases they are actually needed for, because a rigging crew and a transmission crew are not the same people.

Ask how they would enforce a minimum turnaround between two bookings and what happens when a scheduler needs to break it anyway. The right answer is a hard warning with a recorded override, not a silent block and not a silent allow.

Ask what they know about connectivity ordering lead times. A developer who treats fiber as an attribute on the job rather than as an ordered resource with a deadline and a confirmation state will build you something that looks complete and lets a show go unbooked.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. The scheduling logic you encode is the accumulated operational knowledge of your business, and it should not sit inside a vendor's product. At Digital Heroes the code is yours from the first commit.