What you will learn
- How museum software differs from generic booking or catalogue tools
- What each of the twelve project types actually includes
- Where visitor-facing tools and back-of-house systems meet
- The data and content each project needs before build starts
- Common failure points in museum launches, and how to avoid them
- How to judge whether a project fits a small museum or a large one
What these guides cover
Museums hold objects, stories, and people in the same building, and their software has to respect all three. A collections system records where an object came from, what it is made of, and where it sits right now. A ticketing system controls how many people enter a gallery in a given hour. A tour product decides how a visitor experiences a room they may never walk into. Each guide below treats one of those jobs as its own project, with its own users, data, and risks.
The twelve guides are grouped loosely by audience. Staff-facing projects include collections management, loan tracking, and conservation records. Visitor-facing projects include ticketing, audio guides, virtual tours, and the visitor app. Projects such as membership, archives, and donations sit between the two: the public sees a simple page, while staff manage the records behind it. Reading the guides in that order gives a full picture of a museum's digital estate.
- Collections, loans, and conservation for staff
- Ticketing, tours, and guides for visitors
- Membership, archives, and donations bridging both sides
How to choose a starting project
Start with the pain that costs the most staff time or the most visitor goodwill. A museum still tracking loans in spreadsheets usually gains more from a loan tracker than from a new public feature. A museum turning visitors away at the door on busy days gains more from timed ticketing than from another content project. The guides name the users and the daily tasks for each project so the comparison is concrete rather than a guess.
Budget and schedule depend on scope, integrations, and content volume. A ticketing page with no existing payment setup is a different project from one that plugs into a system already in use. A virtual tour of three galleries is a different project from a tour of an entire building. Confirm scope, budget, and schedule with a quote before committing to any of the twelve builds.
- Fix the staff bottleneck first if records work eats the week
- Fix the visitor bottleneck first if queues or sold-out days dominate
- Pick one project, ship it, then add the next rather than launching all at once
What most museum projects share
Almost every museum project needs clean, consistent data before any code earns its keep. Object records need agreed fields for maker, date, material, and location. Ticket products need agreed rules for capacity, pricing bands, and refunds. Tour content needs agreed scripts, images, and rights. Projects that start with a data clean-up week finish faster than projects that discover messy data halfway through the build.
Accessibility and plain language also cut across all twelve guides. Museum visitors include school children, older adults, and people using screen readers or translation. Captions on tour video, clear contrast on ticketing pages, and audio guides that work without a steady connection are not extras. They decide whether a large share of visitors can use the product at all.
- Agreed data fields before build, not during it
- Content rights checked for every image and recording used
- Accessibility tested with real visitors, not only with checklists
Frequently asked questions
Which museum project should a small museum build first?
Timed ticketing or a membership portal usually pays back fastest for a small museum, because both touch revenue directly. A collections system matters more once object records, loans, or conservation work outgrow spreadsheets.
Do these projects replace a museum's existing systems?
Not always. Some replace a spreadsheet or a paper process outright, while others sit beside an existing ticketing or collections tool and exchange data with it. Each guide names the integration points to check before deciding.
How much content does a museum need before building?
It depends on the project. Ticketing needs product and pricing rules. Tours and audio guides need scripts, images, and recordings. Collections and archive projects need agreed record fields and a sample of cleaned records to test against.
Can one build cover several of these projects?
Sometimes, where the audience and data overlap — a visitor app can carry audio guides and wayfinding, for example. The guides keep the projects separate so the scope of each stays honest; combining them is a scoping decision, not a shortcut.
Who should be involved from the museum side?
Curatorial staff for collections content, front-of-house staff for ticketing and visitor flow, and education staff for school and family products. A build without front-of-house input usually misses the details visitors trip over first.