Performing Arts Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does replacing the ticketing system keep swallowing the project?

The conversation usually starts in the right place. The development database holds people who have given, the ticketing system holds people who have bought, and the patron who has attended eleven performances across three seasons without ever giving a dollar is invisible to the people whose job is to find them. Everyone agrees that has to change.

Then the scope drifts, because the ticketing platform is where the annoyance lives day to day and replacing it feels like solving everything at once. Seat maps, price zones, holds and kills, subscription packages with exchange privileges, comps, accessibility seating, box office cash handling, scanning at the door and card processing are all months of work, and none of them are the reason you started. A company that funds a build to see its patrons more clearly ends up funding a ticketing engine and paying for the patron work in a phase two that never gets approved.

This is specific to arts organisations because the pain is felt in the box office and the value is created in development. The loudest complaints come from the people using the seating chart. The money comes from knowing who to call.

The fix is a boundary written down before anyone quotes. Ticketing keeps seat inventory, checkout and payments. The build owns the constituent record, the giving pipeline, the conversion triggers, benefits and reporting, with a live integration between them. For a company between roughly three and twenty million dollars this keeps a first release inside 14 to 18 weeks and $75,000 to $150,000, and it leaves you free to change ticketing vendors later without losing donor history.

What goes wrong when you migrate a thirty year donor database?

Migration is where arts projects lose their schedule, and it is almost never a technical problem. It is a decision problem with technical consequences.

Old donor files carry pledge structures nobody documented, tribute and memorial gifts recorded four different ways depending on who was in the office that decade, soft credits pointing at family foundations, and coding conventions invented by a development director who retired before the current staff arrived. Somebody has to decide what each means before it can be mapped, and that somebody is your development director, who also has a gala.

The failure mode is a project plan with migration as a two week step inside a larger phase. Week two arrives, thirty questions surface, and each one needs an answer that affects reported lifetime giving. Now your auditor has an opinion and the build stops.

The fix is to treat migration as its own workstream with its own owner, running in parallel from week one rather than starting when the software is ready. Extract early, profile the data, and produce a written list of ambiguous cases in the first fortnight. Get your finance director and, where reported totals are affected, your auditor to sign the mapping rules before anything is loaded. Then load a sample and reconcile lifetime giving for your top hundred donors against the old system, which catches almost every systematic error while it is still cheap to fix.

Why do ticketing and accounting integrations break after launch?

If the build reads from a ticketing platform, that integration is now a permanent dependency, and dependencies drift.

The specific failures here are seasonal, which makes them worse. A new season gets loaded with a different naming convention for performances, so the rule that groups performances into productions stops working and your per production report silently splits a run in two. Someone in the box office creates a price type outside the agreed list for a one off promotion, and it lands in reporting as an unrecognised category. Subscription packages get restructured between seasons and last season's allocation rule no longer applies.

The accounting side breaks differently. A chart of accounts change or a new project code for a production means the expense side of your season report goes blank, and nobody notices until the board packet is being assembled.

What to require: nightly reconciliation checks that alert when ticketing revenue by performance does not match what the build ingested. Reference data such as price types, performance to production mapping and fund codes held as staff editable configuration rather than code. A named owner on your side, usually whoever runs the box office, so a new price type is a decision rather than a surprise. And a written test to run at every season rollover, because rollover is when this breaks.

What happens when benefits and front of house are not covered?

Benefits fulfilment is the piece that gets deferred to phase two and then quietly damages the relationships the whole project was meant to strengthen.

A patron at a giving level is promised priority seating, waived exchange fees, an opening night reception invitation, a programme listing with their name spelled the way they want it, and access to the donor lounge. Development promises this in a letter. The box office and front of house deliver it, often to someone they have never met, sometimes at 7:25pm with a queue behind them.

When benefits live in the donor system and delivery happens in ticketing, the gap gets filled with printed lists. Lists go stale. The patron who upgraded in October is not on the November list, and they notice, and they mention it to the board member who solicited them.

The programme listing is the other reliable failure. A name spelled wrong, an anonymous donor named, or a memorial credit line dropped produces the kind of apology that costs a gift.

The fix is to express benefits as rules attached to giving levels and memberships, evaluated live rather than exported. Front of house sees the entitlement on a tablet at the door, including yesterday's upgrade. Programme listings generate from the same source using the preferred credit line with anonymity flags respected, which removes an annual proofreading exercise that reliably produces one painful error a season. This belongs in the first release wherever contributed revenue is comparable to earned revenue.

Should you build custom or configure what you already own?

A real share of arts organisations should configure rather than build, and the honest test is the size of contributed revenue.

If contributed income is under about a quarter of your budget, your season is straightforward and your development director can hold the donor file in their head, buy. Spektrix is a genuinely good mid market platform with real relationship thinking behind it. PatronManager builds on Salesforce, which means much of the reporting and automation you want is configuration rather than development. AudienceView covers a broad range of venue types. Any of those costs far less than a build and reaches value faster.

If you are already running Tessitura at a large house with staff to support it, keep it. A working installation is not a problem worth solving with a rewrite, and the depth you would be rebuilding is real.

Build when two or more of these are true. Earned and contributed revenue are of comparable size and your two systems disagree about who your patrons are. Your development team maintains parallel spreadsheets for anything above the annual fund, so major gift history walks out of the building when a person leaves. You cannot produce a per production result you trust without a week of work. Benefits are delivered by printed lists at the door. Or you have concluded that an enterprise platform would consume a staff position you do not have while a mid market product cannot express your season.

How do hidden costs get into the quote?

Arts projects get quoted optimistically because the buyer is usually describing a reporting problem and the seller is hearing a small one. The items below are the ones that move the number.

• Replace versus integrate. This is the single largest fork in the road and it is often left unstated in a proposal. Ask which one is assumed.
• Donor migration. Decades of pledges, tributes and soft credits is a discovery exercise, not an export. It deserves its own line.
• The subscription allocation rule. Someone has to decide how package revenue lands across productions, and that decision involves your finance director and possibly your auditor. Two weeks of facilitation is normal.
• Multiple venues or a resident company arrangement where another organisation sells some of your seats, which changes the data ownership question entirely.
• Education and community programmes with their own registrations, waivers and grant reporting, which are a separate domain wearing the same brand.
• Go live timing. Arts calendars do not move for software, so the release window is a specific few weeks after subscription on sale closes and before the year end campaign starts.

In Digital Heroes delivery experience the first release band is $75,000 to $150,000 over 14 to 18 weeks, and a full platform adding campaigns, memberships and benefits, galas with table seating, board views and accounting integration runs $180,000 to $420,000 phased over 8 to 14 months. A quote well under the lower band has usually assumed your ticketing platform will hand over clean data without work on either side.

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

The projects that succeed in this sector are recognisable early.

They start with the constituent record and the giving pipeline, not the dashboards. The patron model is the asset. Reporting built on a sound model is a week of work later; reporting built on a weak one is rebuilt every time a question changes.

They define the conversion rungs explicitly and put a human on each trigger. A third attendance in a season, a first upgrade to a premium price zone, a first booking of more than four seats, a lapse after two subscribed seasons. Each becomes an alert with an owner and an action, whether that is a note from the artistic director or a place on a portfolio. Without owners, triggers become another report nobody opens.

They agree the subscription allocation rule once, in writing, with finance. That single number is the reason board packets get argued over, and settling it converts season planning from an opinion into an analysis.

And they pick a go live window that respects the season. The right moment for most companies is early autumn, after subscription on sale closes and before the year end campaign begins. Working backwards from that window produces a realistic plan. Working forwards from a contract date produces a launch during your busiest fortnight, which is how good systems get abandoned by the staff who were meant to adopt them.