A National Radio Broadcaster Automates Radio Ingest From Pastors and Remote Reporters With Files.com
A national US radio broadcaster runs dozens of stations across the country's major markets alongside a syndication network serving thousands of affiliates. In two of those markets, the broadcaster runs news/talk stations whose air is filled around the clock by broadcast automation: a playout system pulls a named audio file on a fixed schedule and puts it on the air.
But much of what those systems play does not come from studios the broadcaster controls. It comes from outside: clients who came to the broadcaster wanting to do a radio show, and news, weather and traffic reporters filing from other states. A church pastor producing next week's teaching program is a content supplier to a broadcast operation, and he is not a broadcast operator. That gap, between people who make radio content and machines that demand exact files at exact times, is where the broadcaster's ingest problem lived.
Every Contributor Was a Hands-On Exception
Broadcast automation is literal. It looks for the file it was told to expect, where it was told to expect it, and a file named wrong is a file it cannot find. Before Files.com, closing that gap was manual work: station staff told each contributor, individually, how to label their audio, then shepherded what arrived into the systems that would play it. Every contributor was a standing exception that a person had to manage, and contributors could not work ahead or cover their own absences without someone at the station in the middle.
The constraint that kept the problem alive is that the contributors cannot be made technical. They are pastors and reporters, not operators, and teaching them transfer protocols and metadata standards was never going to happen. At the same time, radio runs on smaller station staffs than it once did, and hand-carrying every contributor's files is exactly the work a lean operation cannot afford to keep doing.
So the fix had to make correct behavior the easy behavior at the point of upload. Each contributor needed a place of their own. The filename had to carry enough information for a machine to act on. The harvest had to run with nobody involved. And the same platform had to be reachable by a web browser for the pastor and by FTP and SFTP for the automation systems downstream. The broadcaster built that intake layer on Files.com.
A Folder of Their Own, a Naming Rule, and a Nightly Harvest
Each contributor got a Files.com folder of their own. Per-user landing folders and folder-level permissions mean a contributor who logs in sees their space and nothing else, so the instruction to a new contributor shrinks to one teachable thing: name the file this way, and drop it here.
Using Files.com Automations, a scheduled job runs each night and sweeps correctly named files out of the contributor folders into the broadcaster's internal routing folders. Radio Spider then pulls the audio from Files.com over SFTP into the broadcaster's WideOrbit playout system. Contributors touch a web page. The machines speak FTP and SFTP. Both work against the same folders on the same platform.
Contributors Load Weeks of Content Ahead, and Nobody Touches It
With the intake workflow in production, the broadcaster replaced per-contributor hand-holding with a standing pattern: a folder, a permission, and a naming rule.
- Contributors self-serve. Taught once, a client drops their own show in, and can pre-load weeks or even years of content ahead of a vacation. The nightly harvest picks up each file when its turn comes.
- Ingest runs unattended. The work of moving contributor audio into distribution, once done by hand for every contributor, is now done by the automation.
- The pattern absorbed a whole second market. When a second station's operation came under the same operations owner as the first, its workflows were added to the existing Files.com site as another folder set with its own automations, and both markets now run from one folder set.
- The site's user base has grown substantially, and the ingest work did not grow with it.
The Intelligence Moved Into the Convention
Today, a pastor rushing to finish five MP3s for next week does not call anyone at the station. He names the files the way he was taught, drops them into his folder, and overnight Files.com carries them into the same routing chain as the station's own news and traffic. What used to require a staff member standing between every contributor and the air chain now requires a naming convention and a schedule. The broadcaster never made its contributors technical. It moved the intelligence into the convention and the automation, so the contributor's only job is the one thing they can always do: deliver the file.
Related Customer Stories
A Global News Organization Replaced Its Photo Desk’s FTP Server With Files.com Without Pausing Production or Changing Its Publishing Pipeline
The global photo desk moved photographers individually onto a managed inbound perimeter while its cameras, internal servers and downstream publishing systems kept working as before.
Read The Story
A Book Distributor Moved Book Order Intake From Its Own FTP and SFTP Servers to Files.com
The UK operation replaced internally hosted transfer servers while preserving the FTP and SFTP access its clients used for orders and product updates.
Read The Story
One DNS Change Let a Radio Broadcaster Retire Four FTP Servers Without Reconfiguring Dozens of Affiliates
By rebuilding the file layer in parallel on Files.com, the broadcaster kept affiliate connections unchanged while ending the infrastructure work its broadcast engineers had handled themselves.
Read The Story
Get The File Orchestration Platform Today
4,000+ organizations trust Files.com for mission-critical file operations. Start your free trial now and build your first flow in 60 seconds.
No credit card required • 7-day free trial • Live in minutes