Public Broadcasting Station Software Problems: The 7 That Quietly Cost Revenue, and How to Avoid Them

Why does the project get scoped as a database replacement?

The meeting always starts in the same place. Somebody says the membership database is the problem, and everybody agrees, because it is the screen they stare at. So the scope becomes replace Allegiance, and sometimes replace the traffic system too while we are in there.

That is the biggest scope failure in this category, and it is specific to stations because you are running two businesses on two ledgers. Allegiance knows members and pledges and knows nothing about what aired, by design. WideOrbit Traffic knows spots, avails and logs, and has no concept of a supporter, also by design. Myers ProTrack is genuinely strong on programme rights and scheduling for television and was never built to bill a monthly donor. None of them is broken. The station is reconciling between them by hand, and the pain of that reconciliation gets blamed on whichever system the complainer looks at most.

Replacing traffic is the most expensive version of this mistake. Spot scheduling, avails and log reconciliation are a large, mature problem with a competent incumbent and almost no upside in rebuilding. The fix is a scoping rule you set before you talk to anyone: the supporter side is where the leak lives, so that is where custom work goes, and the broadcast side gets integrated rather than replaced. Write that into the brief, and treat any proposal that opens with rebuilding your log as evidence the developer has not understood the problem.

What goes wrong when you migrate twenty years of donor history?

Coded gift types nobody can explain. Long-lived membership databases accumulate campaign codes, appeal codes, adjustment types and premium codes that meant something precise to a development assistant who left in 2011. The list is usually several hundred entries long, a third of them used once, and a handful carrying real meaning that the current staff assume rather than know.

Teams treat this as a technical import and it is not. It is a decision exercise. Map a code wrong and you either lose the ability to compare year over year giving, or you inherit a distinction that will confuse everyone for another decade. Worse, soft credits, matched gifts, vehicle donations and in-kind support are frequently recorded as ordinary gifts with a code, so a naive import inflates your contributed revenue and your Corporation for Public Broadcasting figures with it.

The fix is to budget a structured pass with your development director as scheduled work: for each code, decide whether it carries forward as a real category, becomes an archived note on the record, or is dropped. Do it before anyone writes an import script. Everything else in the migration is comparatively routine, which is why teams underestimate this one and then lose a month to it. And keep the source records readable somewhere for reference, because a question about a 2009 gift will arrive eventually.

Why do the payment, traffic and fulfilment integrations break after launch?

Because four different integrations here fail in four different ways, and quotes usually price them as one line.

The payment gateway breaks quietly. Recurring charges return issuer decline codes that mean different things, and a system treating a soft decline for insufficient funds the same as a hard decline for a closed account will retry the wrong one and give up on the right one. Enrolment in the card networks' account updater services also has to be maintained, and when it lapses reissued cards stop updating and your recovery rate falls without an error appearing anywhere.

The as-run feed breaks structurally. Some automation and playout vendors expose an interface and others expect a scheduled file drop, and a file that does not arrive looks exactly like a day with no discrepancies. That is the worst possible failure, because it means make-goods stop generating and you find out from a sponsor.

The fulfilment vendor breaks on format. A spreadsheet layout changes, a column shifts, and eight weeks of premiums ship to the wrong addresses or not at all.

Ask three questions before signing. What runs when an expected file does not arrive. What happens when the same record is processed twice. And who receives the exception when a charge, a log line or a fulfilment confirmation cannot be matched. If the answer to the last one is nobody in particular, the queue will fill and be ignored.

What happens when underwriting copy rules and premium deductibility are not covered?

Two compliance gaps sit in this category, and both are the sort that get discovered publicly.

The first is underwriting copy. Announcements on noncommercial educational stations cannot contain calls to action, price or savings claims, or qualitative and comparative language. A seller closes a schedule, the sponsor sends copy with a call to action in it, and if copy is a free text field on a schedule with no approval state, it goes to air. In software terms the requirement is simple and frequently missed: copy is a versioned object with an approval status and a recorded approver, and every version that aired must be traceable to an approval. Confirm the specifics with your own counsel, but build on that assumption.

The second is premium deductibility. When a donor takes the tote and the mug, the acknowledgment letter must state the deductible portion net of the premium value, and a donor who declined a premium should get a letter stating the full amount. If premiums are a code on the pledge rather than an inventoried item with a value, the letter is computed wrong, and that is exactly the paperwork your auditor asks about. The same model fixes the other premium failure, which is a phone volunteer promising a mug that ran out an hour earlier because the pledge screen has no view of stock.

Should you build custom or configure what you already own?

If your station raises under roughly $1.5M from individuals, runs two drives a year and sells underwriting through one or two people, keep Allegiance or your existing donor tool, keep your traffic system, and fix the fulfilment spreadsheet instead. The reconciliation between them is a few hours a month at that size, and a few hours a month does not justify a build. Put the money into content and into a fulfilment vendor who answers email.

Even when you do build, keep the traffic system. If WideOrbit works for your spot scheduling, integrate with it. Spending your budget rebuilding avails while the supporter side stays broken is the most common way stations end up disappointed by a custom project.

The signals that justify building arrive in pairs. Sustainers are more than half your individual giving and you cannot state your monthly involuntary churn. You run radio and television, or multiple licences, and no system spans them. Underwriting is large enough that make-goods and proof of performance are handled by a person rather than by a process. Your annual federal reporting takes more than a week of somebody's life because the numbers live in four exports. Or your membership database is old enough that the vendor's roadmap and your needs stopped overlapping years ago.

How do hidden costs get into the quote?

Five ways, and most are avoidable by naming them in the brief.

Two media. Running both radio and television with different traffic systems is not a slightly larger project, it is a second set of scheduling, avails and as-run integrations against a shared supporter record.

Multiple licences and repeaters. Separate programme schedules per signal multiply the reconciliation logic.

The as-run integration itself. Every automation vendor exposes logs differently, so this is specific work per vendor rather than a generic connector, and a quote that does not name your vendor has not priced it.

Membership card and local business benefit programmes, which look like a small feature and are actually a partner directory, redemption tracking and a support burden.

And the migration decision pass described above, which is compliance and development work rather than engineering, and should be resourced and timetabled explicitly instead of assumed to be free. For anchoring, our bands: a focused first release covering the supporter record, sustainer billing with card recovery, pledge intake and premium fulfilment runs $60,000 to $120,000 in twelve to sixteen weeks. A full platform adding underwriting agreements, copy approval, as-run reconciliation, events and federal reporting exports runs $150,000 to $350,000 phased over six to twelve months.

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

Timing against the drive calendar, first and most importantly. Never cut over during a pledge drive. A first release ships in twelve to sixteen weeks, which means starting roughly five months before the drive you want to run on it. The pattern that works is going live on sustainer billing and the supporter record between drives, running one drive on the new pledge intake with the old system still available for reference, then retiring the old path afterwards.

Separation of the pledge path from the administrative system. For two weeks a year your systems take more traffic in an hour than in a normal month, entered by volunteers trained twenty minutes earlier. If a slow report can affect the form a volunteer is typing into, you will lose pledges in the 8am hour, which is the hour with the strongest ask of the day. Duplicate detection runs after the drive, not during it.

A recovery number that somebody owns. Before the build, write down what you know about lapsed sustainers this year, even if the answer is that you do not know. After launch, the development director should open one view each Monday showing sustainers at risk this month and dollars recovered last month. That number is the return on the whole project, and if nobody watches it, the feature quietly stops being used.

And ownership settled in writing before kickoff. You should hold the repository, the cloud accounts and the right to hire anyone else to continue the work. A station's donor file is the institution's most valuable asset, and it should never sit somewhere the station cannot reach on its own terms.