Putting a month of timed entry slots on sale without overselling the gallery

How long should an arrival slot be, and how many should I run?

A slot is an arrival window, not a visit length: it controls how many people walk through the door in that period, and nothing anywhere times them out afterwards. So the slot length is a question about your entrance and your cloakroom, not about how long a visitor stays in the building.

Most small sites land on thirty-minute windows with a capacity that the front desk can actually process — the number people can be greeted, taken payment from if they walk up, and pointed at the first room without a queue forming outside. You can run up to twenty-four entry times a day, which is one every half hour across a twelve-hour opening.

• Slot length: how often you want a fresh group arriving, not how long they stay.
• Capacity: what the desk can process, or what the fire officer allows in the first room, whichever is smaller.
• Entry times: between one and twenty-four per day, and they repeat across every day in the range.

How do I generate a month of slots?

Give bindro a first date, a last date, the entry times, a slot length and a capacity, and it creates a session for every time on every day, each with its own inventory pool for every admission type you have published. A generation is bounded at two hundred sessions, which is roughly a month of six daily slots, so a season goes up in a few passes rather than one.

Availability is live on the booking page and refreshes while a visitor is choosing, and the last admission in a slot cannot be sold twice: the pool is locked inside the same transaction that takes the money, so two people pressing pay at the same moment cannot both get the last place.

Why does the capacity number lie when members walk in?

Because a season pass — which is how a membership admits on bindro — consumes no inventory in the slots it covers. The pass tier has its own pool, which bounds how many passes you sell, and after that a pass holder admits at every session of the event without taking a seat at any of them. That is what a season ticket is, and the migration that added it says so as a stated limitation rather than leaving it to be discovered.

The practical consequence for a room with a real capacity limit: size the slot for the admissions you sell PLUS the members you expect through it. If a Sunday afternoon normally sees a dozen members, a slot capped at forty is a room of fifty-two. Nothing at the door warns you, because from the pool's point of view nothing is wrong.

What happens when a slot sells out, and what if I want one more in?

The slot shows no availability and the visitor picks another one. There is no waiting list, nobody is notified when somebody refunds, and a refunded admission does not return itself to sale — the sold count is not decremented by a refund, so the slot stays full even though a place has been given back.

If you want to let one more party in, raise that slot's capacity by one and it is immediately buyable. Capacity moves in both directions while a slot is on sale, and the one thing it cannot do is drop below what has already been sold, which the database refuses outright rather than trusting the console to be careful.

How should I structure events so the money arrives on time?

Payouts are scheduled per event, once every session of that event has ended, and released two days later. A whole season published as one event therefore pays out once, after the last day of the season — which for a site that publishes its summer in April means the first payout lands in September.

Publish a month, or a term, as its own event and the money moves at that rhythm instead. It costs nothing else: slots, prices, member rates and passes all work the same way inside a smaller event, and a pass sold against one event admits across exactly that event's slots, which is usually what a monthly membership window should do anyway.