A museum runs two operations at once: the collection behind the scenes and the visitors at the front door. When object records, loans, and conservation notes live apart from ticketing, memberships, and the gift shop, staff reconcile the same information twice and nobody sees the whole museum. We build the system that holds both sides together.
Collections care, loans, and exhibition records in the same system as ticketing, memberships, and shop sales
Accession, provenance, and conservation history kept with the object, not in a separate file
Loan deadlines, condition checks, and exhibition schedules visible to the whole team
Payment, accounting, and ticketing integrations scoped first, because they drive most of the risk
3+ years Retention·Week 1 First milestone·Fixed price Pricing
The problem
Sound familiar?
Collections, loans, and conservation records kept apart from ticketing, memberships, and gift-shop sales, so staff work from two versions of the museum?
Loan deadlines, conservation checks, and exhibition schedules tracked by hand, so each new exhibition starts with a scramble?
Short answer
RaftLabs builds custom museum management software for museums, galleries, and collections: cataloguing, loans, provenance, and conservation records joined to ticketing, memberships, and gift-shop sales in one system. Collections staff and visitor teams stop working from separate records, and every object, loan, and ticket lives in one place.
Who this is for
Museum teams we work with
Museum directors
Collections and visitors in one daily view, not two reports that disagree.
Collections managers and registrars
Accession, provenance, loans, and conservation history kept with the object.
Visitor services and membership teams
Ticketing, memberships, and donations without re-keying from another tool.
Museum groups and networks
One system across sites, with each museum keeping its own collection and records.
Key takeaways
The object record is the center. Accession, provenance, conservation, location, and loan history belong with the object, so every team reads the same record before acting.
Collections and visitors are one operation in software, even though they feel like two jobs. When ticketing, memberships, and shop sales share records with the catalogue, reconciliation stops being a manual job.
A loan is a deadline with an object attached. It is not a date on a calendar; it is an object out of the building with a condition report, a return date, and a borrower. The system must hold all three together.
Exhibitions run on a cycle, not a launch date. Planning, loans, conservation checks, the run, and returns each need their own records, and the next exhibition starts from the last one's close.
The public collection is a publishing decision, not a second database. Records marked for publication feed the online search; the rest stay internal, from the same catalogue.
Off-the-shelf tools usually fit one side. Collections tools rarely cover ticketing well, and ticketing tools know nothing about provenance. The custom case is the join, not either side alone.
01 Diagnosis
Problems we solve in museum software
01
Problem
Your collection records live apart from your visitor operation
Solution
The catalogue holds the objects. Ticketing holds the visitors. Memberships live in a third tool, and the gift shop runs a till that talks to none of them. A simple question, which members visited the new exhibition and what did they buy, needs three exports and a spreadsheet to answer. Staff reconcile the same people and the same money twice, and the museum looks smaller in each system than it really is. The cost is not only hours. It is the membership renewal that never goes out because the visitor list and the member list were never the same list.
02
Problem
Loan deadlines tracked by hand
Solution
A loan is an object out of the building, and its return date matters as much as its location. When loans live in a calendar, a spreadsheet, and a registrar's inbox, the return deadline is only as reliable as the last person who updated each one. Condition reports at send and return sit in separate files, so a dispute about damage becomes a search through email. The risk is quiet until it is not: a loan runs past its term, or an object returns in a different condition than it left and nobody can prove what changed.
03
Problem
Ticketing, memberships, and shop sales reconcile by hand
Solution
Admission, memberships, donations, and shop sales each close the day in a different place. The front desk counts the till, memberships reconcile in another tool, and donations arrive through a third. Finance waits for all three before the day is closed, and a discrepancy means tracing the same visitor across systems that never shared a record. None of this is carelessness. It is what happens when every income line has its own tool and nobody designed the join between them.
04
Problem
Off-the-shelf tools fit one side of the museum
Solution
Collections software is built for registrars: strong on accession and provenance, weak on ticketing, memberships, and shop sales. Visitor tools are built for the front door: strong on tickets and members, silent on loans, conservation, and provenance. A museum that buys both gets two systems and a reconciliation job in the middle. A museum that buys one accepts that half the operation runs outside it. The gap is not a missing feature. It is the join itself, and no configuration of either tool creates it.
02 What the system covers
What the system covers
01
Collections and cataloguing
The catalogue is the record every team reads. Accession numbers, provenance chains, condition and conservation history, locations, images, and loan history sit with the object. Cataloguing gaps are flagged rather than hidden, so the collections team closes them in priority order instead of discovering them during exhibition planning.
02
Loans and exhibitions
Outgoing and incoming loans tracked as objects out of the building or into it: borrower, period, condition reports at send and return, and reminders before the return date. Exhibitions draw on the same records, with objects assigned, conservation holds respected, and a checklist of what must be ready before opening day.
03
Digital archives and public search
Digitized objects, documents, and images held with the catalogue records they belong to, not in a separate drive. Records marked for publication feed an online search by maker, period, medium, or keyword. Rights are tracked per image, so only material the museum may show reaches the public.
04
Ticketing and admissions
Timed tickets and general admission through one online flow, with capacity per slot and member booking from the same place. The front desk sees the same visitor record as the online sale, so a ticket bought at home and a ticket bought at the door reconcile together at close.
05
Memberships and fundraising
Memberships bought, renewed, and lapsed on a schedule, with benefits and discounts applied from the membership record itself. Donations sit in the same flow, so a gift after a visit joins the visitor's record instead of starting a new file. Renewal reminders go out on schedule, not when someone remembers.
06
Gift shop and point of sale
Shop sales through the same till as ticket and membership income, with stock tracked per item and reorder visible before a popular line runs out. Member discounts apply from the membership record. The day reconciles once: tickets, memberships, donations, and shop sales in one close.
How an exhibition year runs on one system
A museum does not have a steady year. It has a cycle of planning, mounting, running, and returning exhibitions, and the system should follow that rhythm instead of fighting it.
Before the exhibition
Planning starts with loans. Requests go out, borrowers confirm, and each incoming object gets a condition check on arrival and a location in storage or the gallery. Conservation holds are set on any object not fit to travel, so it cannot be promised to a borrower by mistake. The catalogue is checked for gaps on the objects the exhibition needs, and digitization catches up where the public record will need images. The question planning answers is simple: when opening day comes, is every object accounted for, fit to show, and in the right place?
During the run
The run belongs to the front door. Timed tickets sell online and at the desk from the same capacity, members book without a phone call, and the shop sells the exhibition catalogue and related lines through the same till. When a visitor asks about an object on the wall, staff answer from the catalogue record, not from a printed sheet that went out of date. Memberships bought during a popular run renew on schedule, and donations made after a visit land on the visitor's record. The exhibition's numbers, attendance, memberships, and shop sales, all come from one close at day end.
Between exhibitions
The close is returns and repair. Outgoing loans go back with condition reports checked against the ones taken at send, so any change is caught while the evidence is fresh. Incoming loans return to their owners on schedule, with reminders before the deadline rather than after it. Conservation work found during the run is scheduled, and the next exhibition's loan requests go out while the team still remembers what the last one needed. The catalogue keeps the whole cycle: every object that travelled, every condition noted, every exhibition it appeared in, ready for the next plan.
A note on scope. This page is about museums, galleries, and collections: the objects, the loans, and the visitors. The build itself is custom software work, covered on our custom software development page. If you are still weighing a custom build against an off-the-shelf tool, our build-vs-buy calculator gives a first estimate.
Integrations
Connected across the museum
Payments, accounting, and ticketing connect into one workflow, because the connections drive most of the scope.
Money
Payment processing · Accounting
Visitors and collections
Ticketing · Digital archives and image storage
A discovery phase scopes the integrations first; they drive most of the cost variance.
03 Buy, build, or wait
Stay on off-the-shelf software while collections-only tools fit, and move to a custom system when visitor operations need the same records.
The museum software question is really about whether collections and visitor work can stay in separate tools or need one record.
Buy or rent
An off-the-shelf collections tool, while visitor work stays small
Faster to start and fine when the catalogue is the whole job and ticketing stays simple.
Wait, while separate tools cost little staff time
Keep renting while reconciling two systems is an occasional job, not a daily one.
Build custom
When collections and visitor records must join
One object, loan, ticket, and member record instead of re-keying between tools.
When loans and exhibitions outgrow the catalogue tool
Loan deadlines, condition reports, and exhibition checklists the vendor never designed for.
When reconciliation eats staff time every week
Ticketing, memberships, donations, and shop sales reconciled by hand across separate tills.
Bottom line
Stay on off-the-shelf software while collections-only tools fit and reconciliation stays occasional. Move to a custom system when the join between collections and visitor work costs more staff time than owning it.
04 How we work
How we work with museum teams
01
Map the operation
We start by mapping how your museum actually runs: the collection and its catalogue, the loan and exhibition cycle, the visitor operation, and every system the software has to talk to: payment processing, accounting, and ticketing. This step surfaces the integration requirements that cause rework when they are discovered mid-build.
02
Design around objects, loans, and visitors
We design the data model around the objects your museum actually works in: collection records, loans, exhibitions, tickets, and memberships. The highest-risk integration, usually payments or ticketing, is prototyped in the first sprint because it is the most common cause of a timeline slip.
03
Working software in slices
You review working software every two weeks, not wireframes. Each slice is usable on its own: the catalogue, then loans and exhibitions, then ticketing and memberships, then shop sales. Scope is fixed and priced before the build, so the number does not move unless you change what you are building.
04
Launch before the next exhibition
We test every integration against real payment and ticketing data, not just a sandbox, because payment and ticketing feeds fail in ways a sandbox never shows. Launch is planned backward from the next exhibition opening. You get a documented, tested system, your data in your control, and a handover so your team or ours can run it.
05 Questions
Common questions
Both. A museum gets collections, loans, exhibitions, ticketing, memberships, and shop sales in one system. A gallery with a smaller collection gets the catalogue, loans, and sales without the full museum modules. The object record is shared either way, so a work that moves from storage to a loan to an exhibition wall carries one history, not three files.
The accession number, title, maker, date, medium, dimensions, and current location, plus the provenance chain, condition and conservation history, images, and every loan the object has been on. The record is the single place any staff member checks before answering a question about the object, whether the question comes from a curator, a registrar, or a borrower.
A loan is tracked as an object out of the building: the borrower, the loan period, the condition report at send and at return, and the return deadline with reminders before it arrives. Exhibitions pull from the same records: objects assigned, conservation holds that block a fragile object from travel, and the checklist of what must be ready before opening day.
Yes. Timed tickets, general admission, and member booking run through the same online flow, and memberships can be bought and renewed there too. Donations sit in the same flow, so a visitor who gives after a visit does not need a second system. Member and ticket records join to the same visitor record the front desk sees.
Yes. Shop sales post through the same till as ticket and membership income, stock levels are tracked per item, and the day reconciles in one place instead of three counts at closing time. A member discount applies from the membership record, so the till does not need a separate list of who qualifies.
Yes, from the same catalogue. Records marked for publication feed an online search by maker, period, medium, or keyword, with images where the museum holds the rights to show them. Records not marked stay internal. Publishing is a flag on the record, not a second database to keep in step.
It is imported and checked, not re-catalogued from scratch. Spreadsheet rows, an older collections database, and paper record cards are mapped to the new object record, and gaps are flagged for the collections team to close rather than silently dropped. The import is tested on a sample first, so problems surface before the full collection moves.
Each object carries a condition history, and conservation tasks are scheduled against it: routine checks, treatment work, and pre-loan inspections. A conservation hold blocks a fragile object from being assigned to a loan or an exhibition until it is cleared. The schedule is visible to registrars and curators alike, so a loan is never promised on an object that is not fit to travel.
You do. Your data lives in systems you control, and we hand over documentation so your team or ours can maintain it. There is no per-seat lock-in on the software itself.
Talk to us about your museum software.
Tell us how large your collection is, how loans and exhibitions run today, which systems you use for ticketing and memberships, and where staff time goes on reconciliation. We will tell you how we would approach it.
Scope and cost agreed before work starts. No surprises. No obligation.
Working prototype within 3 weeks of kickoff.
Pay by milestone. You see progress before each invoice.
60-day post-launch warranty. Bug fixes, UI tweaks, and deployment support. No retainer.
