Public Broadcasting Membership and Underwriting Software: Where Sustainer Revenue Quietly Leaks

Why membership and underwriting are one system pretending to be two

It is the third morning of the fall drive. The development director is watching a whiteboard tally while a volunteer phone bank types pledges into a form. In the next office, the traffic manager is reconciling yesterday's as-run log against the underwriting schedule because a sponsor's spot did not air in morning drive and the credit has to be made good this week. Both of these people are chasing revenue from the same audience. Their systems have never spoken.

The typical stack is Allegiance or a similar membership database, WideOrbit Traffic or Myers ProTrack on the broadcast side, a playout system with its own as-run log, a premium fulfillment vendor with a spreadsheet, a payment gateway, and email in a marketing tool. Each product is competent inside its own boundary. Allegiance knows members and pledges and knows nothing about what aired. WideOrbit Traffic knows spots, avails and logs, and has no concept of a supporter. Myers ProTrack is genuinely strong on program rights and scheduling for television and was never intended to bill a monthly donor. Nobody is wrong. The station is just running two businesses on two ledgers and reconciling them by hand.

The leak shows up in three places every year. Sustainers fail on expired cards and nobody notices until the annual comparison. Premiums promised on air arrive late or never, and the complaint lands on the general manager. And the CPB Annual Financial Report plus non-federal financial support figures get assembled from exports that require somebody to remember which spreadsheet was the good one. Across membership and media projects we have delivered, the recurring pattern is 8 to 15 hours a week of manual reconciliation and a quiet monthly loss of recurring gifts that nobody has ever quantified because nothing measures it.

Problem 1: sustainers fail on expired cards and the failure is silent

A sustaining member at $15 a month is worth more over five years than most one-time gifts, which is exactly why every station pushed hard to convert. The consequence is that your individual giving now depends on a stored payment credential surviving contact with reality. Cards expire. Cards get reissued after a breach at a retailer. Banks change BINs. The donor did not cancel and does not know they stopped giving.

Most membership systems will retry a declined charge and send an email. What they generally do not do is treat recovery as a campaign with its own logic: retry timing that respects issuer behavior, participation in Visa Account Updater and the Mastercard equivalent so a reissued card updates automatically, a fallback to ACH for donors who keep failing, a phone list for the top band of lapsing sustainers, and an on-air ask that never goes to someone whose gift is already active. Stations that do not run this end up re-acquiring donors they never lost.

What a custom build does: model the recurring gift as a schedule with its own health state, not as a row in a batch job. Every attempt is logged with the issuer response code, because a soft decline for insufficient funds needs a different retry than a hard decline for a closed account. Account updater results flow in automatically. Donors who fail twice enter a recovery track with an email, a text and a call task assigned to staff by gift size. The dashboard the development director opens each Monday shows sustainers at risk this month and dollars recovered last month, which is the number nobody currently has.

Problem 2: a premium promised on air is a contract, and the fulfillment file is a spreadsheet

During a drive the host says that a gift of $120 gets the tote and the mug, and that the coffee partner's beans are available at the $180 level while supplies last. That is inventory, and it is being sold by a person reading copy in real time, with no view of stock.

Membership systems handle premiums as a code on the pledge. They rarely handle premium inventory, vendor drop-ship, back orders, substitutions when the mug runs out mid-drive, or the fact that a donor who chose no premium should be flagged so the acknowledgment letter can state the full deductible amount rather than the reduced one. The fulfillment vendor gets a spreadsheet, the spreadsheet has errors, and the complaints arrive six weeks later when the drive team has moved on.

What a custom build does: premiums are inventoried items with counts, thresholds and vendor routing. The pledge screen shows the phone volunteer what is genuinely still available so nobody promises a mug that ran out an hour ago. Fulfillment files generate per vendor on a schedule with confirmations coming back, so a donor record shows shipped or not shipped rather than sent to vendor. Acknowledgment letters compute the tax-deductible portion from the actual premium value, which is the paperwork your auditor will ask about.

Problem 3: underwriting sold, scheduled, aired and proved are four different facts

An underwriting seller closes a schedule with a local credit union: eight spots a week for a quarter, in specific dayparts, with copy that has to satisfy the FCC restrictions on announcements for noncommercial educational stations, which means no calls to action, no price or savings claims, and no qualitative comparisons. That copy needs approval. The spots need to be placed in avails without stacking two financial institutions in the same break. Then they need to actually air, and the as-run log needs to prove it, and if morning drive ran long and a spot dropped, somebody owes a make-good.

WideOrbit Traffic does this part of the job properly and is the reason it exists. The gap is not spot scheduling, it is everything around it. The seller's pipeline lives in a spreadsheet or a generic CRM (Customer Relationship Management). Copy approval is an email chain. The proof of performance a sponsor gets is a PDF someone assembles. And the underwriter who is also a $2,500 individual donor appears as two unrelated organizations in two systems, which means your general manager walks into a renewal meeting without knowing that.

What a custom build does: one account record that holds the underwriting agreement, the copy versions with approval status and who approved them, the scheduled spots, the as-run confirmations pulled from the automation system, and the relationship history including any personal giving by the contacts. Make-goods generate automatically from the log comparison instead of from a complaint. Proof of performance goes out on a schedule as a real report, not a favor.

Problem 4: drive volume breaks whatever you built for a normal Tuesday

Two weeks a year your systems take more traffic in an hour than in a normal month, and the people using them are volunteers who were trained twenty minutes ago. Every extra field on the pledge form costs you completed pledges. Every timeout during the 8am hour costs you the exact donors who respond to the strongest ask of the day.

What a custom build does: a pledge intake path that is deliberately separate from the administrative system, so a slow report cannot affect the form a volunteer is typing into. Web and phone pledges land in the same queue. Matching challenges and board challenges are configured objects with live remaining balances a host can read on air without asking anyone. Duplicate detection runs after the drive, not during it, because slowing a volunteer to prevent a duplicate is a bad trade.

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 the supporter record, sustainer billing with card recovery, pledge intake and premium fulfillment runs $60,000 to $120,000 and ships in 12 to 16 weeks. A full platform adding underwriting sales and agreements, copy approval, spot scheduling or integration with your existing traffic system, as-run reconciliation, events, and CPB reporting exports runs $150,000 to $350,000 phased over 6 to 12 months.

What drives cost up at stations specifically: running both radio and television with different traffic systems; multiple licenses or a network of repeaters with separate program schedules; integration with a playout system for as-run data, since each vendor exposes logs differently and some expect a file drop rather than an interface; membership card and benefit programs tied to local businesses; and migration off a long-lived donor database whose history includes twenty years of coded gift types nobody can explain.

What keeps cost down: leaving traffic where it is. If WideOrbit works for your spot scheduling, integrate with it rather than rebuilding it, and spend your budget on the supporter side where the leak is.

Build versus buy, and when buying is the right answer

Buy if your station raises under roughly $1.5M from individuals, runs two drives a year, and sells underwriting through one or two people. Allegiance and its peers will hold your members, your traffic system will hold your spots, and the reconciliation is a few hours a month. Spend the money on content and a fulfillment vendor who answers email.

Build when two or more of these are true. Sustainers are more than half your individual giving and you cannot state your monthly involuntary churn from memory. You run radio and television, or multiple licenses, and no system spans them. Your underwriting revenue is large enough that make-goods and proof of performance are handled by a person rather than by a process. Your CPB reporting takes more than a week of somebody's life each year 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.

Our position is that most stations should build the supporter side and integrate the broadcast side. Rebuilding traffic and log reconciliation from scratch is a large project with a mature incumbent and little upside. Rebuilding the supporter relationship, which is where your revenue and your leak both live, is where custom work pays.

How to choose a developer for public broadcasting systems

Ask how they would model a recurring gift. If the answer is a subscription in a payment provider, they have missed the point: the payment provider holds the charge schedule, but the station needs gift-level history, premium linkage, deductibility, soft credits and recovery state that survives changing gateways. A good developer separates the two.

Ask what they know about the FCC constraints on underwriting copy. They do not have to be a broadcast lawyer, but a developer who has never heard that noncommercial announcements cannot contain a call to action will build a copy field with no approval workflow and you will find out on air.

Ask which specific systems they have integrated. An as-run log from an automation vendor, a payment gateway with account updater enrollment, a fulfillment vendor's file format and an email platform are four separate integration problems with four different failure modes. Vague answers here predict vague delivery.

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 anyone else to continue the work. At Digital Heroes the code is yours from the first commit, and a developer who hedges on that is building a dependency, not a system.