Radio Automation and Music Scheduling: Running Forty Stations Without Forty Spreadsheets

Why a station group's problems start at station number six

One radio station is a solved problem. RCS Zetta with GSelector, WideOrbit Automation for Radio, ENCO and, at the open source end, Rivendell will all run a station competently. The music scheduling logic in particular, rotation categories, artist and title separation, tempo and mood flow, daypart restrictions, hour clocks, represents decades of refinement and nobody should attempt to rewrite it.

The trouble is that a group is not a collection of stations. It is a shared operation pretending to be a collection of stations. One music director now oversees fifteen formats. One jock voice tracks six markets in an afternoon. Ad breaks come from a group traffic operation but network feeds arrive on a syndicated schedule that ignores your local clock. The streaming simulcast cannot carry the same commercials as the broadcast, so a separate inventory has to be filled and reconciled. And at the end of the period, somebody has to produce accurate performance returns for the licensing bodies, from as run data spread across every station and every system.

All of that coordination sits in the gap between products, which means it sits in spreadsheets, shared drives and the head of one very capable operations person. Ask a group programme director how many stations aired the syndicated show correctly last Sunday and the honest answer is that they would have to check.

Problem 1: licensing returns are assembled by hand from as run data

This is the least glamorous item on the list and usually the most expensive. Performance reporting obligations differ by territory and by licence type, and streaming in particular demands detail that broadcast never did. A webcasting return typically requires per performance records with track identifiers, artist, title, album and listener counts, which is a fundamentally different shape of data from a broadcast return.

What that means practically is that somebody exports as run logs from each station, matches them against a music library that has incomplete track identifiers because a jock imported a file without them in 2019, joins them to listener data from the streaming provider, and assembles a return. It takes days. It is checked less thoroughly than anyone would like. And errors in it are errors in what you pay rights holders, which is a category of mistake nobody wants to make repeatedly.

A custom group layer consolidates as run data from every station and system into one normalised record, enriches it against a properly maintained master music library, joins it to streaming analytics, and generates the return in the format each body wants. Just as importantly it flags the gaps continuously rather than at reporting time: this track has no identifier, this station's log has a two hour hole on Tuesday, this import has duplicate entries. Fixing those as they occur is trivial. Fixing them retrospectively across forty stations is the reason returns take days.

Problem 2: voice tracking across markets is a logistics problem in a scheduling tool

A jock records afternoon breaks for six stations. To do it well they need, for each station, the correct log for that daypart, the intro ramp and outro times of the songs either side, the local information that makes the break sound local, and any traffic or sponsorship read that has to appear. If any of that is wrong, the break is wrong on air and there is no live operator to catch it.

Automation systems provide voice tracking and do it well within a station. What they generally do not provide is the cross station workflow: which of your jocks owes which tracks by when, which stations are covered for tomorrow, what happens when someone is ill, and whether the localisation content each market needs actually reached the person recording. Groups manage that with a whiteboard, a shared calendar, or a message thread.

A build makes voice tracking an assignment queue with completion state per station and daypart, warns before a station is left uncovered rather than after, and puts the local content in front of the jock at the point of recording. It also gives programme directors something they currently lack entirely, which is the ability to review what actually aired across markets without listening to six hours of logger audio.

Problem 3: the stream is a different station and is treated as an afterthought

The simulcast cannot carry the broadcast commercial load, because the rights to those advertisements and often to the music itself differ online. So the stream needs its own inventory filled by ad replacement, triggered on the same break markers. That inventory is sold by a different part of the sales team, delivered by a different system, and reconciled, if at all, at month end.

Meanwhile the metadata story is separate again. Now playing information has to reach the stream, the station app and the RDS data on FM, and each of those has its own path and its own failure mode. A track that shows correctly on the stream and incorrectly on the app looks like carelessness to a listener and is invisible to the operations team.

A group layer treats the stream as a first class output with its own inventory, its own fill reporting and its own reconciliation against what the ad server actually delivered. It also owns metadata distribution to every downstream destination from one source, so the now playing information is right everywhere or wrong everywhere, which sounds like a small thing until you have spent a morning working out why one app shows the wrong artist.

Problem 4: network feeds, opt outs and emergency events depend on operator memory

A syndicated show arrives on a feed with cues for local breaks. Stations join and leave at defined points. Some markets carry it, some do not, and one carries it delayed. Emergency alerting has to interrupt everything and be logged. Local opt outs for sport or community programming break the group clock in ways that are documented somewhere, probably in a document from three years ago.

Each station's automation handles its own switching correctly when configured correctly. The risk is in configuration drift across a group: a station whose clock was edited during a format change six months ago now misses a network junction by four seconds, and nobody knows until an affiliate complains.

A build monitors the group's configuration as a set rather than as individual stations. It compares intended clocks and network carriage against what each system is actually configured to do, flags drift, and verifies from as run data that junctions were hit. It also makes emergency event logging consistent across every station, which matters when you are asked to prove an alert aired.

What this costs and how long it takes

Across the 2,000 plus projects Digital Heroes has delivered, here is the honest shape. A focused first release covering group wide as run consolidation, a master music library with identifier hygiene, licensing return generation and a group operations view runs $70,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding voice tracking assignment workflow, stream inventory and reconciliation, metadata distribution, network carriage verification and podcast repurposing runs $200,000 to $500,000 phased over 6 to 12 months.

What drives price up specifically in radio: the number of distinct automation systems and versions across the group, which for a group built by acquisition is usually more than management thinks. Streaming provider integrations, since analytics and ad insertion vary by vendor. The state of your music library metadata, which is frequently the real project, because a return is only as good as the identifiers behind it. Podcast repurposing, if you want show segments extracted from the log with broadcast advertising swapped for dynamic insertion, which requires accurate segment boundaries. And any requirement to write back into automation, which needs far more care than reading from it.

What keeps price down: starting read only with as run consolidation and the licensing return. It touches nothing on air, it removes a genuinely painful recurring task, and it exposes the data quality problems you will need to fix before anything else works.

Build versus buy, and when RCS Zetta is enough

Buy and change nothing if you run a handful of stations on one platform with a conventional format and a modest streaming operation. Zetta with GSelector remains the strongest music scheduling logic available and rewriting a rules engine of that maturity would be an act of vandalism against your own budget. ENCO is dependable on air automation. WideOrbit's radio automation sits close to their traffic product, which is genuinely useful if you already run it. Rivendell is capable at a single station if you have the engineering appetite to own it.

Build a group layer when two or more of these are true. You run more than about 15 stations, or fewer stations across more than one automation vendor. Licensing returns take more than a day per period and you are not confident they are right. Voice tracking coverage is tracked on a whiteboard or in a message thread. Your stream inventory is reconciled at month end, if at all. Or you cannot tell without checking whether a syndicated show aired correctly across every carrying station last weekend.

Our position, stated plainly: never rebuild the music scheduling engine and never rebuild on air playback. Those are mature, hard, and already solved by people who have been at it for decades. Build the layer that knows about all your stations at once, because no vendor sells that and it is precisely where a group's operating leverage comes from. Groups that get this wrong spend three hundred thousand dollars reproducing GSelector badly.

How to choose a developer for radio group software

Ask them what they would build first. The right answer is as run consolidation and the licensing return, because it is read only, it removes real pain and it surfaces the data quality problems everything else depends on. A developer who wants to start with a shiny operations dashboard has not understood where the value is.

Ask how they would handle a track with no identifier in the as run log. The answer should involve matching against a maintained master library, flagging unmatched entries at the moment they occur, and never silently guessing, because a guess in a licensing return is a payment to the wrong rights holder.

Ask what they have actually integrated. Reading as run data from an automation system, writing a log back into one, pulling analytics from a streaming provider and driving metadata to RDS and app endpoints are four different problems. Ask for the specific vendor and version, because in radio the version genuinely matters and acquisitions leave older ones in place.

Ask who owns the code and get it in writing before kickoff. The group should own the repository, the cloud accounts and the right to hire anyone else. At Digital Heroes the client owns the code from the first commit, and for anything that reads from or writes to on air systems we expect your engineering team in the design reviews rather than shown a finished product.