Broadcast Traffic Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does someone always propose replacing the traffic system?

Because the complaints all point at it. Sellers complain that avails do not reflect digital inventory. Finance complains that invoices need three exports stitched together. Traffic complains about retyping agency instructions. Every one of those is real, and none of them is a defect in the traffic system, which is doing precisely what it was designed to do: manage linear inventory and produce a log.

A developer hearing that list will reasonably conclude the system is the problem. They then price a replacement, and the price looks credible because nobody in the room has scoped what the traffic system actually does at the edges: preemption handling, daypart rules, separation requirements, copy rotation, invoicing formats per agency, and thirty years of accumulated conventions that live in configuration nobody has documented.

The fix is a scoping decision made before any proposal is written. State plainly that the traffic system stays and that the build is a layer, then judge suppliers on how comfortably they accept that constraint. The value sits in one order object that can hold a cross platform package and a reconciliation engine that classifies as run exceptions, and both are specific to how your group sells. Neither requires touching the log build. A supplier who argues for replacement is either inexperienced in broadcast or optimistic about your budget, and both should end the conversation.

What goes wrong when you pull orders, logs and as run data out of the traffic system?

The export exists and it is not what you assumed. Order data comes out shaped by the traffic system's model, which means a line is a flight against a daypart on a station, and the package the seller actually sold does not appear anywhere because it was never represented. Reconstructing the package from its parts requires rules that live with the account executive, not in the data.

As run data has a different problem. It records what aired, and the interesting cases are what did not: spots dropped for a live event overrun, breaks moved, a spot that ran outside its purchased daypart. Matching an ordered spot to an as run line sounds like a join and is not, because identifiers differ between systems, times shift, and a substituted spot may carry the same code as the one it replaced.

The fix is to insist on a matching design with explicit exception classification before any code is written. Every ordered spot has an expected airing, every as run line matches or does not, and every non match is classified by cause rather than dumped into a discrepancy list for a human to interpret. Then run the matcher against a full historical month during development, not a sample week, and have your traffic managers review the exceptions. The rules that make matching work are in their heads, and this is the only reliable way to get them out.

Why do the playout, digital ad server and agency ordering integrations break after launch?

Because each one is a separate problem with a separate failure mode and quotes routinely treat them as one line called integrations. Reading a traffic system export is not the same as writing back to it. Pulling as run data from playout automation is not the same as either. Taking orders electronically from an agency platform such as Mediaocean carries its own certification effort and its own trading conventions per partner.

After launch, breakage is usually silent. A playout system starts emitting a new event type after an upgrade and the reconciler quietly stops matching a category of spot, so the exception rate rises and nobody notices because exceptions were always present. A digital ad server changes a reporting field and delivery numbers drift. The first symptom is a finance question about an invoice, weeks later.

The fix is monitoring on the data rather than on the connection. Track match rates, exception counts by cause and delivery totals per platform against expected ranges, and alert on movement rather than on failure, because these interfaces rarely fail loudly. Sequence the work so the group proves value on one integration before adding the next, and start read only. A layer that reads orders, logs and as run data and produces reconciliation reporting earns its credibility in weeks with zero risk to the daily log build, and that credibility is what buys permission to write back later.

What happens when political advertising obligations are not covered?

The workload lands on one experienced person and a manual checking routine, which works until the cycle where it does not. Federal candidates are entitled to lowest unit charge during the windows preceding a primary and a general election, and that entitlement is a function of every other rate you charged for comparable inventory in the same period. Stations must keep the political file in the online public inspection file current. Neither obligation is satisfied by recording what happened after the fact.

The failure mode is specific. Rates are set commercially all cycle, then a lowest unit charge position is reconstructed at the end of a period from reports, and if the reconstruction shows a political order was charged above the correct rate, the remedy is a rebate and a conversation you did not want. Disclosure records assembled by someone remembering to assemble them will eventually be assembled late.

The fix is to compute rather than record. Track comparable inventory and rates continuously so the lowest unit charge position for a class of time is a live figure available at the moment an order is accepted, and generate disclosure records as orders are accepted so the public file obligation is met by the process rather than by a person. Have the rules verified by your own counsel, since the windows and the definitions are specific and enforcement is real. The practical benefit is that election season stops depending on one individual being available.

Should you build custom or configure what you already own?

If you are a single station or a small group selling linear inventory with a conventional sales model and little digital fulfilment, configure what you have and build nothing. WideOrbit and Marketron do that job properly, your traffic department already knows them, and a custom layer would be solving a coordination problem you do not have. Myers ProTrack is the sensible answer in public broadcasting, where the underwriting and programming model differs from commercial.

Before commissioning anything, ask your traffic managers what the current system can do that nobody uses. In several groups we have looked at, some of the cross platform frustration was a configuration and training gap rather than a capability gap, and closing it costs a fraction of a build.

Build a layer, never a replacement, when two or more of these hold: you sell cross platform packages and reconcile them in a spreadsheet, you run streaming channels whose inventory is invisible next to linear, more than one person spends most of their week retyping agency traffic instructions, your political workload depends on one individual, or you cannot state what preemption cost the group last quarter. That last one is the honest test, because a group that cannot measure the leak cannot judge whether the build is worth it.

How do hidden costs get into the quote?

Through five doors. Integration count is the first and largest, and it is hidden by the word integrations appearing once in a proposal. Price the traffic system read, the traffic system write, the digital ad server, the streaming platform and the playout feed as five separate lines with five separate assumptions.

Agency order intake is the second. Electronic ordering through a platform such as Mediaocean is a project with certification effort, not a feature, and each trading relationship has its own conventions. Invoicing is the third, because affidavit and format requirements differ by advertiser and agency, and a build that produces one invoice format has priced one advertiser.

Station count and shared inventory is the fourth. Groups where stations share inventory or sell as a combination need rules that a single station design never encounters. The fifth is the rules elicitation work itself: makegood policy, separation requirements and preemption priorities are usually undocumented, and turning them into configuration takes weeks of structured sessions with your traffic managers. That time is the real deliverable and it should be a priced line rather than absorbed.

What separates a build that works from one that fails here?

Ask them to model a cross platform order on a whiteboard. A team that has worked in broadcast will separate the order, the line, the fulfilment target and the delivery record, and will ask what you want to happen when linear over delivers and digital under delivers on the same package. A team that draws orders and line items with a quantity has built a commerce system and will learn avails arithmetic at your expense.

Ask how they would handle a live event overrun in reconciliation. The answer should involve classifying dropped spots by cause and applying a makegood placement policy that respects the value of the inventory being given away. Flagging a mismatch for a human is a report, not a system, and reports are what you already have.

Ask what they have actually integrated, naming the vendor and the interface rather than claiming general familiarity with programming interfaces. Ask what monitoring they put on match rates and exception counts, because silent drift is the characteristic failure here.

Then settle ownership in writing before kickoff. The group should hold the repository, the cloud accounts and the unrestricted right to hire another firm. At Digital Heroes the client owns the code from the first commit. Revenue reporting will depend on this layer within a quarter of go live, and a supplier with independent control of it holds a position over your billing that no commercial arrangement should create.