Art gallery software for the sale, not just the wall.

Art gallery management software runs the commercial operation behind the wall: artwork records, consignments, artist payouts, exhibition checklists, collector records, offers and holds, sales, and fair lists in one system. A website on its own shows the work. Gallery management software makes sure a work can be found, priced, sold, shipped, and settled without retyping the same facts into several tools.

A museum collection system is built for an institution that holds work long term: cataloguing, provenance research, and public visiting. This page is about a commercial gallery that sells work it usually does not own. The hard parts here are consignment terms, the split on each sale, artist statements, exhibition checklists that feed a price list, and fair lists that have to work on a busy stand. If your buyer is a visitor buying a ticket, that is a different page. If your buyer is a collector buying a work, this is the page.

A generic CRM tracks people and conversations. It does not understand that one artwork can be consigned by one person, shown in an exhibition, held for a collector, sold on agreed terms, and still owed a payout. Gallery software keeps the artwork record, the consignment terms, the offer history, and the collector history together, so a sale, a statement, and a follow-up all read from the same facts. A CRM alone leaves your team to join those facts up by hand every time a work moves or sells.

Each consignment names the consignor, the work, the agreed price, the split, the period it runs for, what discount the artist has approved, and who carries insurance while the work is in your care. The record also tracks where the work is now: in the gallery, in storage, at a fair, out on approval, or on loan. When a consignment period nears its end, the system should flag it before the work is held past the agreed term, and when the work sells, the sale should read the terms from the consignment itself, not from a note someone has to remember to check.

A sale creates the payout from the agreed terms: the sale price, the split, any approved discount, and any costs the agreement says come off first. The artist statement should show the same figures as the sale and the invoice, work by work, so the artist can check it without asking your team to explain it. Payouts should be traceable: what was sold, when, for how much, what the artist is owed, and what has already been paid. If the statement needs a spreadsheet to make sense, the system has not done its job.

Every work needs one record that answers three questions at a glance: where is it, who owns it, and is it available. Ownership matters because gallery stock, artist consignment, and a secondary-market work consigned by a collector are handled differently when they sell. Availability matters because a work can be available, on hold, reserved, sold, or not for sale, and for whom and until when. The record should also keep the movement history, so a work that went to a fair, came back, and went out on approval leaves a trail your team can follow without asking around.

An offer, a hold, and a sale should all sit on the same artwork record and the same collector record, so the team can see who asked about a work, who saw it at a fair, and who has bought that artist before. A hold needs an end date and a named collector, or works quietly disappear from sale. A discount needs the approval the artist gave, checked at the point of sale, not discovered when the statement is written. Test this in any demo with a work that has a hold, an offer below asking price, and a discount limit, because that is where a weak system quietly lets the wrong price through.

An exhibition checklist is the working list for one show: the works in it, their prices, their availability, their wall or catalogue details, and the documents behind them, such as condition notes and consignment terms. It should be drawn from the live artwork records, not retyped for the show, so a price change or a sale updates the checklist and the price list together. When the show closes, the checklist becomes the record of what sold, what returned, and what still needs a payout, instead of a document that is filed and forgotten.

A fair list is the subset of works travelling to one fair, with prices, availability, and collector interest attached, plus the shipping and return trail for each work. The booth team needs that list on a phone or tablet, with images and current status, so a collector question can be answered on the stand. After the fair, unsold works need a return record that puts them back into gallery stock or storage with their location updated, and sold works need to flow into invoicing and artist payouts without being typed up again from a paper list.

This has to be agreed in scope, not assumed. Fair Wi-Fi is unreliable at busy times, so the booth view should at least hold the current fair list, prices, and status for the day, so a short signal gap does not leave the team blind. What the team records while offline, what syncs when signal returns, and what happens if two people change the same record must be named before release and tested in real fair conditions, not only an office connection.

Usually because the new system does not match how the team actually works, or because the move was planned around features instead of the daily workflow. Staff keep the spreadsheet when the system misses a step, needs the same fact typed twice, or produces statements nobody trusts. The fix is to trace one real artwork from intake to payout, name who owns each step, and test the system against that artwork with real users before it goes live. A system your team works around is a second job, not a replacement.

Buy a ready-made product when it covers your consignments, your exhibitions, your fair lists, and your collector rules with reasonable setup, and its pricing makes sense. Have software made for your gallery when the way you sell is itself the advantage, when repeated manual work has a measurable cost, or when a connection to your other systems cannot be done cleanly any other way. If your consignment rules are still changing every week, settle them first. Software will not settle a selling policy for you.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how many artwork types and sales routes you run, how many kinds of users it serves, what it needs to connect to, whether data needs moving over, whether the fair team needs a phone view, any compliance requirements, and the condition of existing code. The agreed phase is priced in writing before it starts.

Ask for the quote to name everyone who will use the system, including your own team. Every platform has two sides: what collectors see, and what your people use all day: consignments, exceptions, refunds, managing users, and a record of who did what. When that second side is quoted as an admin line on a single line, it becomes the overrun. Our quotes treat your team's screens as their own scope, with their own users. Then the phase names the workflow, what 'done' looks like, the price, and the exclusions, all before paid work starts. You review working software at agreed checkpoints, and when new information changes the scope, you hear the effect on price and timing before anything is approved.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the gallery workflow agreed at the start. Progress is reported in plain language: what changed, what is next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your business.

We need one person who owns the gallery operation, access to the relevant users and systems, timely answers on business rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

A small gallery is often where this pays first, because one person is holding consignments, payouts, and fair lists together in their head. Start with the core record: artworks, consignments, collectors, and sales, then add exhibitions, fair lists, and website publishing as the gallery grows. The test is not gallery size. It is whether the work you sell, the terms behind it, and the payouts after it are already too tangled to hold in spreadsheets and memory.