Museum Management Software: Why Collections and Ticketing Never Reconcile

Why museum software makes or breaks a multi-site operator

Walk into the back office of almost any mid-size museum system and you find the same architecture. PastPerfect or a TMS (The Museum System) install holds the collection. Altru or Tessitura or ACME handles tickets and memberships. Blackbaud Raiser's Edge NXT holds donors. A shared drive full of Excel files does everything those three refuse to do. The registrar's loan tracker is a spreadsheet. The membership renewal list is a spreadsheet. The exhibition budget is a spreadsheet. None of them talk, and the person who knows how they connect is one director of operations who has been there eleven years.

The cost is not abstract. On a recent engagement, a three-site museum organization was paying roughly $28,000 a year in ticketing platform fees and per-ticket charges, another $12,000 for collections software with maintenance, and had two full-time staff whose actual job, once you watched them for a week, was moving data between those systems by hand. Reconciling a single busy Saturday across three sites took a finance coordinator most of Monday, because the ticketing platform reported gross, the payment processor reported net, the gift shop POS (Point of Sale) reported separately, and the membership discounts applied at the door never matched what the CRM (Customer Relationship Management) thought the member was entitled to.

The moment that decided the build was smaller than any of that. A traveling exhibition opened. Timed entry sold out. A member arrived with a valid membership, was told at the desk that her tier did not include the special exhibition, argued, and was let in by a sympathetic front-of-house lead. That override was never recorded anywhere. We counted roughly 40 of those a week across three sites, which made the membership program's real economics unknowable. The development director was building a renewal campaign on numbers that were wrong by an amount nobody could measure.

Problem: collections data and revenue data live in separate universes

The registrar records an object in TMS or PastPerfect with an accession number, provenance, condition reports, and location history. The ticketing system sells admission to an exhibition. Nothing connects the object to the exhibition to the ticket. So when the board asks which objects drove attendance, or which loans justified their insurance and crating cost, the answer is a guess assembled from memory.

Off-the-shelf cannot fix this because the vendors sit on opposite sides of a market split that has existed for thirty years. Collections management vendors sell to registrars and curators and treat revenue as somebody else's problem. Ticketing vendors sell to marketing and finance and treat objects as marketing copy. Even inside one vendor family the products were acquired rather than designed together, and the integration is a nightly file drop at best.

A custom build gives you one object registry with proper accession records, and an exhibition entity that references objects by ID, carries date ranges, and is the same entity the ticket type points at. Attendance, revenue, and object list join at the database instead of in a spreadsheet. The exhibition record carries its loan agreements, insurance values, crate and courier costs, and its ticket revenue, so exhibition P&L becomes a query rather than a quarterly project. We usually keep the existing collections system as the system of record for cataloguing during phase one, sync objects into the new platform read-only, and migrate cataloguing itself only in a later phase if the curators want it.

Problem: membership entitlements are enforced by human memory at the front desk

You have Individual, Dual, Family, Contributor, Patron, Director's Circle, plus reciprocal programs like NARM and ROAM, plus corporate memberships where the entitlement belongs to an employer, plus complimentary staff and board passes. Each carries different guest counts, different special-exhibition rules, different store discounts, different early-access windows. Altru and ACME model tiers well enough. But the moment you have a rule like "Family covers two named adults plus any four children under 18 living at the same address, and Contributor and above get two guest passes per visit but only one during a ticketed special exhibition," you are outside the config screens and into staff training.

So the rule lives in the front-of-house lead's head. Staff turn over. Rules drift by site. A member gets a different answer at your downtown location than at your campus location, complains, and the development director issues a goodwill upgrade that never makes it into the renewal model.

The custom build makes entitlement a rules engine rather than a policy document. A membership record holds tier, named members, household address, join and expiry dates, and reciprocal program IDs. Entitlement is evaluated at scan time against the specific event: this member, this date, this exhibition, this site, returning admitted party size, guest passes remaining, discount rate, and any conditions. The desk sees the answer instead of the policy. Overrides stay allowed, because museums are hospitality businesses and the answer at the desk is sometimes yes regardless, but every override captures who, why, and value, so the membership program's real economics show up in a report instead of vanishing.

The reporting effect matters more than the enforcement. Once entitlements are structured, you can finally answer whether Family memberships are profitable at $150 given actual visit frequency and guest pass usage. Two of our museum clients repriced tiers off that data in the first year.

Problem: timed entry and capacity across multiple sites and one busy weekend

Timed entry became permanent after 2020 and most ticketing platforms bolted it on. It works for one venue with one capacity number. It falls apart when you have three sites, a special exhibition with its own gallery capacity inside a general admission building, school groups blocking slots, a members-only preview hour, and a fire code number that differs from the comfort number the visitor experience director actually wants to hold.

The failure mode is specific. A school group of 60 books through a separate group sales process that lives in email and a spreadsheet. The ticketing system never learns about it. The 10:30 slot sells to the public as if the gallery is empty. Saturday at 10:30 the gallery is at 140% of the comfortable number, dwell time collapses, and the exhibition your curators worked two years on gets experienced as a shuffling queue.

Off-the-shelf cannot fix it because capacity in these systems is an attribute of an event rather than a shared resource. Your gallery is a resource consumed by multiple event types at once. That is a different data model, not a settings change.

The custom build treats space as the constrained resource. Each gallery or building has a capacity calendar. Every booking type, public timed entry, group sales, school programs, member previews, private events, draws from the same pool, with configurable holds and release rules: hold 30% for members until 7 days out, release school group blocks at 48 hours if unconfirmed. Front-of-house sees a live occupancy view per gallery rather than a ticket count. AI has one honest job here: a forecast trained on your own two or three years of scan data, weather, school calendar, and exhibition week number, predicting slot demand well enough to set staffing 10 days out. It tells your visitor experience manager whether Saturday needs six floor staff or nine, which on a 40-person hourly roster is real money.

Problem: loans, condition reports, and the paperwork nobody has time to chase

Your registrar manages incoming and outgoing loans. Each has a loan agreement, an insurance certificate, a facility report from the borrowing institution, condition reports at four points (outgoing, arrival, return arrival, return), courier arrangements, and a return date. TMS handles some of this. PastPerfect handles less. Neither one chases.

The scenario: a loan to a peer institution is due back in 40 days. The registrar knows. The registrar is also installing the next exhibition. The reminder lives in Outlook. It slips. The object comes back three weeks late, the insurance rider lapsed for eleven days, and nobody knew until an auditor asked.

A custom build makes the loan a workflow object with states and owners instead of a folder. Every document type required for each state is a checklist item with a due date and a responsible person. Document extraction genuinely helps here: incoming facility reports and insurance certificates arrive as PDFs, and an extraction pass pulls coverage amounts, effective dates, and environmental specs into structured fields, flagging where the borrower's stated relative humidity range falls outside your conservator's requirement. The registrar reviews and confirms rather than retyping. On one build this cut the registrar's paperwork time by roughly a day and a half per loan cycle, and it made lapses visible before they happened rather than after.

Problem: the after-hours and group sales pipeline runs on an inbox

At the museums we have built for, venue rental, corporate events, school programs, birthday parties, and private tours were a big enough slice of earned revenue that the executive director could name the figure from memory. All of it ran through a shared events@ inbox, a Google Calendar, and a group sales coordinator who answered within two business days. The inquiry that came in Friday at 7pm from a corporate planner got a reply Tuesday morning. The planner booked somewhere else Monday.

No ticketing platform fixes this, because group and venue sales are a quoting problem rather than a ticketing problem: variable pricing by day and space, catering minimums, AV, staffing, and a contract.

The custom build puts real availability behind an inquiry form that reads from the same space calendar as everything else, generates a price range instantly against your rate card, and holds the date for 72 hours. An AI assistant handles the after-hours conversation within tight limits: it answers capacity, catering, and AV questions from your own documented policies, qualifies the inquiry, and books a call. It does not quote outside the rate card and it does not sign anything. It converts the Friday 7pm inquiry into a held date and a Monday morning call instead of a lost lead. Follow-up sequences on unconverted inquiries run automatically, which is the cheapest revenue in this entire category and the thing a coordinator with 40 open threads never gets to.

What this actually costs and how long it takes

These are Digital Heroes numbers from our own delivery across 2,000-plus projects. A focused first release, the thing we would actually recommend for a museum system with three sites and 300,000 annual visitors, runs $60,000 to $130,000 and ships in 12 to 16 weeks. That scope is unified ticketing and timed entry with shared space capacity, the membership entitlement engine, a read-only sync from your existing collections system, front-of-house scanning apps, and reconciled daily revenue reporting. You keep Raiser's Edge or your existing donor CRM and we integrate. A full platform, meaning you are retiring Altru or a Tessitura plus PastPerfect combination entirely, including collections cataloguing, loans workflow, group and venue sales, and gift shop POS integration, runs $150,000 to $400,000 phased across 6 to 12 months.

Four things drive price up in this category specifically. Collections data migration: a 40,000-object PastPerfect database with thirty years of inconsistent cataloguing, free-text provenance, and image files linked by filesystem path is not a weekend import, so budget $20,000 to $50,000 and expect your registrar to spend real hours on decisions only they can make. Payment and PCI scope: card-present scanning at the door with your existing terminals, plus online, plus the gift shop, means you want tokenized flows and a P2PE terminal path so your PCI scope stays SAQ A-EP or lower rather than dragging your whole platform into scope. Accessibility: you are very likely receiving public funds and you should be building to WCAG 2.1 AA properly, which in our estimating adds roughly 10% to 15% to front-end work when built in from the start and about three times that when retrofitted. And the number of physical entry points, because every door is a device, a network assumption, and an offline mode. Your scanners must work when the building's wifi drops, which it will, on the busiest day.

Build versus buy: a position

Stay on the off-the-shelf tool if you are a single site under roughly 100,000 annual visitors with a membership base under 5,000 and no venue rental business. ACME or Altru will hold you fine and the money is better spent on a person than on software. Same answer if your collection is under a few thousand objects and PastPerfect is not hurting anyone. For most museums in America, buying is simply the right call.

Build when these signals stack up. You are running two or more sites and cannot get one honest occupancy or revenue number without a human assembling it. Your membership program has rules the vendor's config screens cannot express, so they live in staff heads. Your registrar maintains a shadow spreadsheet because the collections system will not model your loans, and that spreadsheet is load-bearing. Your platform fees plus per-ticket charges are past roughly $40,000 a year, which is where a build starts amortizing inside 36 months on fees alone. And the signal that should decide it: you are making pricing, exhibition, and staffing decisions on numbers you privately do not trust. At that point you are not buying software to save time. You are buying it because your strategy is running on inputs nobody can defend.

We recommend a partial build more often than a full replacement: build the layer that unifies ticketing, membership, and capacity, and leave collections cataloguing where it is. Curators and registrars have workflows in TMS that took years to settle. Replacing that in phase one is how these projects die.

How to choose a developer for museum management software

Ask them to model an accession record and a loan on a whiteboard, unprompted. If they cannot distinguish an accession number from an object ID, or do not immediately ask whether you catalogue at the object or lot level, they have never built this and you will pay for their education. The same test applies to membership: ask how they would model a household with two named adults and a floating guest pass allowance, and listen for whether they reach for a rules engine or a column.

Ask what they have integrated. The specific names matter: TMS, PastPerfect, CollectiveAccess, Blackbaud Raiser's Edge NXT, Altru, Tessitura, Shopify or Lightspeed for the shop, Stripe or a P2PE terminal provider for card-present. Ask what broke. Anyone who has actually done a Tessitura integration has a story about it, and the absence of a story means the absence of the work.

Ask how they handle compliance without being asked. PCI scope reduction, WCAG 2.1 AA for a publicly funded institution, data retention for minors when you sell school programs, and GDPR or CCPA if you have international members or California visitors. A developer who treats these as change orders discovered in month four is telling you what month four will look like.

Finally, get code ownership and infrastructure access in writing before the first invoice. You should own the repository, the cloud account, and the data from day one rather than on completion. Museums hold things for centuries. Your software should at minimum outlive your vendor relationship.