Timed Entry Ticketing for Small Museums

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "admission" and "visit" because that is what a museum says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

Who this is not for. Excludes major institutions, which are enterprise and already contracted. If that is closer to your operation, the vertical you want is probably a different one — all twenty are listed here.

Everyone arrives at eleven, and the gallery has a number on the wall

A museum without arrival times is a museum whose Saturday happens between eleven and one. The rooms that matter are full, the volunteer on the desk is apologising to a queue, and the fire officer's capacity — the one number nobody is allowed to be relaxed about — is being estimated by eye. The afternoon then runs at a third of capacity with the same staff on the same shift.

What bindro does: An opening day is generated as a grid of arrival slots, each carrying its own inventory pool per admission type, so the shape of the day is decided in advance rather than discovered at half past eleven. A slot that fills says there are no slots left and stops selling, and the pool is locked inside the same transaction that takes the money — the last admission in the 11:00 slot cannot be sold to two families in the same second. Capacity moves up and down while a slot is on sale; the one thing it cannot do is drop below what has already sold. While you are open, the day-of screen shows what is left in each slot as it moves.

The membership scheme lives in a spreadsheet, and the desk is the only thing checking it

Members are the floor under a small museum's income, and the entire enforcement of the scheme is usually a volunteer recognising a face or squinting at a card from 2019. Online it is worse: either members cannot book at all and turn up expecting to walk in, or the member rate is an honesty box anybody can tick. Nobody finds out until the reconciliation, by which point the discount is given and the visit has happened.

What bindro does: A membership number typed at checkout is checked against your own roster at the moment the money moves, and the member price is derived on the server rather than read off the page the buyer is looking at. A number that has expired, been revoked or was never on the roster fails the booking with a message on that box instead of quietly charging list price and leaving you the argument. Read the limit as carefully as the capability: bindro verifies memberships and never sells them. The roster is typed into the console one member at a time — a name, a number, an expiry — with no import, and only a hash of the number is stored, so the page can never read a working number back out to anyone who reaches it.

The donation box is on the way out, and the ticketing has never heard of it

For a museum that is a registered charity the gift is frequently worth more than the admission, and it is collected by a perspex box near the exit that most visitors walk past with no cash on them. The people who would give already decided to come — they are on the website with a card in their hand — and nothing asks them. Folding the gift into a higher admission price, which is what most sites reach for instead, quietly destroys the only deductible part of it.

What bindro does: A donation box rides on the order beside the admission rather than inside its price. It is neither fee base nor tax base, so the platform earns nothing on the gift and no sales tax is computed on it, and the whole amount is credited to you with the rest of the proceeds. A receipt goes out beside the confirmation for every paid order, naming only the donated part as deductible and stating the zero case in words when there was no gift — which is what a tax authority expects a charity to have told the giver. One setting gates all of it: until a registered charity number is saved in the console nothing is issued, and the reports page says so rather than failing silently.

The board meets in a fortnight and somebody is about to lose a weekend

A small museum reports upwards more often than it is credited for: a board pack every quarter, a return to the funder whose grant paid for the education officer, a line in an accreditation submission. The numbers exist in three places — the ticketing export, the bank statement and somebody's memory of which days were free — and reconciling them is a weekend spent by the person who can least afford it. The version that goes out is then unreproducible: a year later nobody can say why the figure was that figure.

What bindro does: The grant and board report is a quarter-by-quarter table you print for the pack or download as a CSV: sessions delivered, admissions registered, visitors actually checked in, free places given, gross, refunded and net. The money lines are read from the ledger rather than re-summed from order rows, so they agree with the money page to the cent and agree with it again next year. Answers to "How did you hear about us?" are broken down underneath, because audience development is the question funders ask most and the one museums are least able to evidence. Two limits, stated before you promise anybody anything: it is your report to submit, since bindro transmits nothing to a funder on your behalf, and it counts only money that went through bindro — a grant, a shop float or the cash box is not in it.

The wifi reaches the office and stops at the doorway

Museums are frequently in the worst buildings in the world for a network: stone, thick walls, a listed frontage nobody may drill through, and a router two rooms away from the entrance. A door that needs a connection is a door that stops on the busiest afternoon of the year, and the fallback — a printed list and a biro — means that day's attendance never reaches anything you can report from.

What bindro does: The door is designed offline-first rather than patched for it. A device downloads a signed manifest for the session before you open, validates every code locally against it with no network call, and uploads its scans when it next reaches signal; a log re-uploaded twice applies once, so a bad connection cannot inflate your attendance. A visitor admitted at two entrances lands in a conflict queue you read afterwards rather than being refused at the second door in front of a queue. When a code will not read at all — cracked screen, dead phone, email in a spam folder — the console has a searchable visitor list with a tap-to-admit button, which keeps the visit inside the numbers instead of outside them.

The special exhibition is the year's income, priced like an ordinary Tuesday

The touring exhibition that took two years to book, cost a five-figure loan fee and fills the museum for eleven weeks is very often sold at the same price, on the same ticket, through the same box as a wet Tuesday in February. The consequence is obvious afterwards and invisible at the time: the exhibition subsidises the quiet months rather than paying for itself, and nobody can say what it earned because its income was never separable from general admission.

What bindro does: Every admission type carries its own stock in every slot, its own price and its own member rate, so a special exhibition can be a second type on the same arrival slots — capped separately, because the exhibition room is smaller than the museum — or its own event when it runs on different days. Priced tiers let a concession, a family rate and an exhibition rate sit side by side with separate pools, and promo codes cover the partner offer without training everybody to wait for a discount: the code carries the value, and a client is never trusted to name an amount. Catalogues, guidebooks and anything else you can count sell as add-ons beside the admission with their own finite stock.

A month of opening days, generated from a pattern rather than typed

You give bindro a date range, the arrival times you want to run, how long a slot lasts and a capacity, and it creates a session for every time on every day with its own inventory pool per admission type. Twenty-four entry times a day is the ceiling and two hundred sessions is the bound on a single generation, so a month of half-hour slots is one pass and a season is a handful. Days you are not opening are simply not generated — there is no closure control to lean on afterwards.

• Arrival slots per opening day, each holding its own stock per admission type.
• Per-slot capacity, so the quiet first hour and the busy middle are different numbers.
• Up to twenty-four entry times a day; two hundred sessions per generation.
• Capacity is editable while a slot is on sale, but never below what has sold — the database refuses it outright.

Member prices derived on the server, against a roster you control

Member pricing is a verify-at-checkout rule and it is honest about being exactly that. Any admission type can publish a member rate; a visitor gives their number; the server looks it up in your roster and derives the price there, inside the transaction that charges the card. A current member booking a type with no member rate simply pays list price — a valid membership is never a reason to refuse a booking — and a lapsed one is told on the box rather than charged the difference in silence.

• The roster is name, number and expiry, typed into the console one member at a time.
• Numbers are stored hashed, so the roster page cannot hand a working number back.
• No import, no renewal reminder, no billing and no card: bindro verifies memberships and does not sell them.
• Nothing adds a buyer to the roster automatically — not a season pass, not a gift card.

A pass that admits at every slot of the event it belongs to

A season pass is a tier with its own stock whose holder is admitted at every session of the event it was sold under, including on an offline door manifest, without booking a slot each time — the right shape for a members' pass or an annual admission on a single published season. It carries one limitation, stated in the migration that created it rather than left to be discovered: a pass consumes no slot inventory. It takes a seat at none of the sessions it opens, so a gallery with a real capacity limit has to size its slots for pass holders as well as admissions, and nothing warns the desk that a busy slot is fuller than the screen says.

• Admits at every session of its own event; opens nothing on a separately published one.
• The pass tier's own pool bounds how many passes exist, not how many visits they make.
• Works on the offline manifest, so a pass holder is admitted with the network down.
• If members should get into a special exhibition free, it has to be a type on the same event, or a second pass.

Donations that reach you whole, and receipts that say only what is true

The donation box adds a gift to the order rather than to the admission price, and that distinction is the whole point. Because it is neither fee base nor tax base, the platform earns nothing on it, no sales tax is computed on it, and the entire gift is credited to the museum. The receipt quotes only the donated amount as deductible — a gift folded into a higher admission price is not deductible at all, because the visitor received goods and services worth what they paid, and a receipt that pretends otherwise is worse than no receipt.

• The gift carries no platform fee and no sales tax, and is credited to you in full.
• Receipts go out beside the confirmation — but only once a registered charity number is saved in the console; until then nothing is issued and the reports page says so.
• The receipt states the zero case out loud when there was no gift.
• A refund reverses the gift with the rest of the order.

A front door that does not need the network, and a second entrance that agrees with it

Offline is designed in rather than bolted on. The device pulls a signed manifest while it still has signal, admits from it with no connection, and replays afterwards; the upload is idempotent, so a log sent twice by a flaky line counts once. Two entrances scanning at once produce a conflict queue you read afterwards rather than a refusal at the door. Be clear about what this is before planning around it: the offline path is an API and there is no bindro scanner app to install, so a properly offline second entrance needs somebody technical before opening day. What works out of the box is the console's searchable visitor list with a tap-to-admit button.

• Signed manifest downloaded before opening; local validation with no network call.
• Re-uploaded scan logs apply once, so attendance cannot be inflated by a bad line.
• Second entrances raise conflicts to read, never a refusal in front of a queue.
• Codes scan off a phone screen or a printed sheet; each person on a booking has their own.
• Admit by hand from the console when a code will not read — an unscanned visitor is a hole in the quarterly report.

The front desk and the shop till, in the same day's numbers

A museum that cannot sell to the family who walked in off the street is turning down its easiest income. A walk-up admission takes a card on the operator's own device and runs through exactly the same checkout as the website — same server-derived price, same inventory lock, same credential in the same pool. The shop till is a catalogue of items whose sales are recorded against the day. One thing is deliberately not implemented: a cash admission cannot be recorded, because crediting your balance for money bindro never held would pay you for the same sale twice.

• Card walk-ups at the desk, drawing on the same slot inventory as an online booking.
• Shop sales recorded against the day as an auditable record for your own numbers.
• Till takings never enter the platform ledger — that money is already yours.
• Back-office orders for the phone booking, the group of nine and the hand correction.

Your own website, our page, or both selling the same slots

Most museums already have a website that a designer or a volunteer built, and asking visitors to leave it is where bookings are lost. Bindro gives you a hosted page per event that works on a phone held in one hand at a bus stop, and an embeddable checkout for the site you already have — and they sell the same inventory, so there is no second set of numbers to reconcile and no way for the two to oversell each other.

• A hosted page per event with the day picker, the slot picker, tiers and add-ons.
• Embedded checkout on your own domain, selling the same pools as everything else.
• One inventory behind the website, the embed and the front desk.

Gift cards, comps and the codes that fill a quiet Wednesday

An admission is fixed to a day and a slot and cannot be handed on or moved, because this vertical resolves neither transfer nor deferral — so the giftable instrument is a gift card, not a ticket. It is emailed as a code to the person receiving it rather than to the buyer, valid for two years, and spent as real tender against any booking, with a larger booking taking what is left on the card and charging the difference. Comps are the other instrument small museums actually need: the trustee, the lender, the local paper and the volunteer's family.

• Gift cards are carried as a liability until redeemed, which is also why unredeemed value cannot be paid out to you.
• Comp admissions consume real inventory and scan exactly like a sale, while writing no revenue lines.
• Promo codes carry their value on the code; the client never names an amount.
• What you cannot give somebody is a membership — nothing adds a person to the roster except you typing them in.

Sales tax, self-service refunds and the disputes nobody plans for

US sales tax, where you set a rate, is applied price-exclusively on top of the admission and computed on the discounted amount by the server, itemised on the pay page so the visitor sees it. Leave the rate at zero if your admissions are exempt and nothing is added. Inclusive VAT is a different capability this vertical does not have, and onboarding offers the United States only.

• Visitors refund themselves in full from their own confirmation link right up until their arrival slot starts; after that the decision is yours, from the console.
• A refund you choose to give is one order at a time; the one bulk refund there is rides on closing a day, and settles every booking on it at once.
• Chargebacks debit the museum in full and are handled idempotently by provider reference, so the same dispute cannot land twice.
• Financial reports per event come off the ledger the payout reconciles against, not off a re-sum of orders.

The visitor record, and the two years after a visit

A museum thinks in decades and its systems should not hold it hostage for one. The visitor record persists across seasons, so the family who came for the summer exhibition is somebody you can recognise next year, and a post-event follow-up goes to those who opted in once the whole event has finished. What matters more is what the retention sweep does and does not reach, because that decides what it is wise to ask for at checkout in the first place.

• Names and email addresses are anonymised two years after a visitor's last visit.
• Answers typed on the order — access needs, membership number, party size, how they heard — are never cleared by that sweep. Treat the order record as permanent when you decide what to ask.
• Access requirements are classed as health information: out of exports, out of the funder breakdown and out of AI context, with no override in any vertical.
• The quarterly grant and board table exports as CSV alongside orders and visitors.

Who pays the booking fee?

The visitor, unless you say otherwise. Every visit carries its own setting — the visitor pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-admission $25.00 visit that is $16.20 either added to what visitors pay or taken out of what you keep.

Because the default is the visitor, a museum can go from signing up to a sold-out visit without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by visit, admits one only once its LAST session has ended, and pays it once. A visit sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on visits that have not happened is exactly how a cancellation becomes visitors with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per visit, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

How finely you can read that number is decided by how you publish the calendar: money groups by EVENT and attendance by SESSION, so a quarter published as one long event gives one gross figure, and the same quarter published monthly gives three you can compare.

Of the three measures this vertical is designed around, donation attach rate is the one bindro serves best: the gift is a line on the order and in the CSV export, so orders carrying a donation against orders placed is a division you can do per event today. No screen shows it as a percentage and no chart trends it, but the rows are complete and they are yours.

Membership conversion is a harder truth. Bindro can tell you how many admissions sold at a member price, because that is a priced tier on an order — but not how many visitors joined, because nothing in the product ever sells a membership. Members reach the roster by somebody typing them in, so the conversion figure a board asks for is assembled from your roster on one side and bindro's member-rate admissions on the other. Pretending otherwise would be exactly the defect this site is built to avoid.

The gift aid rate is the sharpest case of the same principle, and the answer is that bindro cannot produce it. Gift Aid is a United Kingdom relief; onboarding offers the United States, the tax the engine applies is price-exclusive US sales tax, and nothing anywhere claims a relief on a donation — despite the term appearing in this vertical's own glossary. If you are a UK museum, weigh that before anything else on this page.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per visit, read from the ledger the payouts reconcile against.
• Admissions sold against visitors checked in, with a no-show percentage per session.
• Live remaining capacity while the visit is running, per pool, on the day-of screen.
• This museum's own funnel — view → slot selected → checkout → paid → attended → member joined — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and visitors as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a museum's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• bindro does not sell, renew or bill a membership. There is no recurring charge anywhere in the product, no renewal reminder, no membership card and no lapsed-member sweep. The roster that unlocks member prices is typed into the console by hand, one member at a time, with no CSV import — and buying a season pass adds nobody to it. Whatever runs your membership scheme today keeps running it.
• A season pass consumes no slot inventory. A pass admits its holder at every slot of its event and takes a seat at none of them, so a gallery with a real capacity limit has to size its slots for the members it expects as well as for the admissions it sells. Nothing warns the front desk that a busy slot is fuller than the number on the screen.
• No waiting list. When an arrival slot is full the page says there are no slots left and stops: nobody joins a list, nobody is emailed when an admission is refunded, and a refunded admission does not return itself to sale — the count of what has sold is not decremented by a refund. If you want to let one more party in, raise that slot's capacity by one.
• No transfers and no date changes. A visitor who cannot come on the Saturday cannot hand their admission to a friend and cannot move it to the Sunday: this vertical resolves neither ticket transfer nor deferral, and there is no credit note to issue. The only lever is a refund, after which they book again at whatever is on sale. A gift card is the giftable instrument; an admission is not.
• A confirmed headcount only goes DOWN. A school booked for thirty that becomes twenty-four is confirmed down to twenty-four and the six places go straight back into the room. A class that grows to thirty-four cannot be confirmed upwards, because those places were never held and the room may have sold them since — growth is a second booking through the room like any other. A headcount cannot be reduced after the invoice has been paid either: that is a refund, and refunds go one order at a time under the policy the booking was sold under.
• Cash is not a ticket sale. The front-desk walk-up takes a card on the operator's own device, and recording a cash admission is deliberately not implemented, because crediting the museum's balance for money bindro never held would pay it twice at payout. Shop takings recorded at the till are an auditable record for your own numbers and never enter the platform ledger — that money is already yours.
• United States only, so no VAT and no Gift Aid. Onboarding offers one country, and the tax the engine applies is price-exclusive US sales tax added on top of the admission; inclusive VAT is a separate capability this vertical does not resolve, and nothing anywhere claims Gift Aid on a donation, despite the term appearing in this vertical's own glossary. A museum outside the United States cannot be onboarded today.
• bindro will not decide that you are closed. Closing a day is one control on the day — it comes off sale, every booking on it is settled the same way, and the visitors are emailed if you ask — but nothing reads a forecast or a building alarm, so the call is yours. Nor is there a general message tool: that cancellation mail is the only one bindro sends to a day's visitors, so anything else goes out from your own tool.
• The retention sweep does not reach what a visitor typed on the order. Names and email addresses are anonymised two years after that visitor's last visit, but the access requirement, membership number, party size and how-heard answers are stored on the order itself and nothing in the product ever clears them — not a sweep, not a console action. Treat the order record as permanent when you decide what to ask for.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

The mechanism is set out in full in the payout section above; what matters here is what it implies for a museum's calendar. Museums sit on the low-risk tier, which is the shortest delay the platform has and holds no reserve back — but the delay is measured from the end of the event, not from the sale, and that is the part people plan around wrongly. Monthly or termly events cost a little more setup, since each is its own generation of arrival slots and its own page, and buy you money arriving through the year rather than after it.

There is a real cost to splitting and it is not the setup. Reporting groups by event too, so twelve events mean twelve financial reports rather than one annual figure, and a visitor browsing sees several pages rather than one long calendar. The quarterly grant and board table is unaffected either way — it is computed from the ledger across whatever events fall in the quarter — which is usually the reassurance that makes the decision easy.

A special exhibition is the case where the answer differs. An eleven-week exhibition published as its own event settles on its own and reports as its own line, which is exactly what you want when somebody asks whether the loan fee was worth it. Run it as a second admission type on your ordinary slots and its income sits inside the month's figure, separable only by exporting and filtering.

The reason is not an oversight and it is not on a roadmap. Recurring billing was withdrawn across the whole platform because the payout engine settles per delivered event and has no way to settle a charge that is not attached to one — so a museum billing an annual membership through bindro would be money the platform could take and could not pay out. Rather than build half of it and let a museum discover the other half in month two, the capability is not declared and the checkout refuses it.

What that leaves is genuinely useful and worth setting up properly. Put your current members on the roster and every admission type that publishes a member rate enforces it at the moment of payment rather than at the desk. A members' pass on top of that is the piece most museums want next, and it works with one caveat to size for: the pass consumes no slot inventory, so the number on the day-of screen is admissions sold and not people expected. On a quiet Wednesday that is invisible; in a small gallery on a bank holiday it is the difference between comfortable and over the fire-officer figure, so leave headroom.

The last piece is the reporting one. Because members join through your scheme and not through bindro, the platform reports how many admissions went at a member price but not how many memberships were sold. A board pack asking for conversion needs both halves, and it is better to know that in advance than to promise one number and produce two.

The order is short: close the day, choose what happens to the money — none of the options is preselected — and tick the box if you want every visitor written to. That mail goes out after the money has actually moved and tells each person which of the three happened to theirs. It is the only bulk message bindro sends, so anything else still goes out from your own tool, off the visitor export.

Timing matters more than most museums expect. Until an arrival slot has started, every visitor can refund themselves in full from the link in their own confirmation email, with no notice window to configure and no fee you can withhold. Deciding early and saying so early means a good share of the work does itself; after the slot has started, every refund is yours to issue by hand.

Two things to plan around. Moving the money in bulk is an owner or finance action — a manager can close the day and rearrange it but cannot refund it — so somebody with that authority has to be reachable. And a closed day leaves the payout schedule rather than delaying it; close every date of an event and there is no delivered date left to settle against, so nothing is paid out until you have settled it. A closure policy on your own website is still worth more than one in bindro, because bindro cannot enforce yours — it decides nothing about whether you open.

The band is a floor, a ceiling and a suggested amount. A visitor picks anything between the two ends; below the floor is refused by the server rather than quietly rounded up, because the floor is the point of an access scheme. What they chose is recorded as a chosen price and not as a discount off something else, so your reporting shows what admission actually earned. One caveat for receipts: an amount paid for admission is not a gift however generous it is, so a low fixed admission with the donation box on top still receipts better if deductibility matters to your funders.

The school visit is one order, one invoice and one contact — thirty admissions, not thirty bookings — with a per-place roster the teacher fills in through their own link. The part that matters is the headcount: a class of thirty that becomes twenty-four the week before is confirmed down to twenty-four, and the six unused places go straight back into the room for somebody else to buy. It only works downwards, deliberately — confirming a bigger number would take places nobody ever held, and growth goes through the room the same way any other booking does.

Two smaller refusals belong in the same list because they surprise people at the worst moment. There is no waiting list: a full slot says there are no slots left and stops, nobody is emailed when an admission is refunded, and a refunded admission does not return itself to sale. And there are no transfers and no date changes — an admission cannot be handed to a friend or moved to the Sunday, and there is no credit note. The lever in both cases is a refund and a fresh booking, or raising a slot's capacity by one if you decide the room can take another party.

The country question is first because it is absolute. Onboarding offers the United States, the engine applies price-exclusive US sales tax, and there is no inclusive VAT and no Gift Aid anywhere in the product. A museum outside the United States cannot be onboarded today, and no amount of the rest of this page changes that.

The second is the membership one, and the most common reason a museum should choose something else: if you need a constituent database with fundraising history attached, that is a different kind of product and the comparisons below say so.

Then rehearse the door. Comp yourself four admissions across two arrival slots, walk them through the real entrance on the real device with the network turned off, and let the upload run when you get back to the office. Comps consume real inventory and scan exactly like a sale while writing no revenue lines, which makes them the right instrument — you are testing the door, not polluting the accounts. If your entrance is a room where nothing connects, that half hour is the whole evaluation.