Handle booking requests & your calendar

Requests come in through your venue page and land in one queue.

The queue

Each request shows the event and the organizer behind it, with the date it would hold on your calendar. Two actions: Approve or Decline — declining asks you to confirm, and for a reason that goes back to the organizer. If you need to ask something before deciding, reach out to the organizer from their profile; the queue itself is deliberately a yes/no.

Dates are exclusive by default

When you approve a booking, that slot is held exclusively. A second organizer can't book over it, and the calendar shows it as taken. This is the default because double-booking a venue is the single most expensive mistake either side can make.

Turnover time

You can set a buffer around bookings — the time you need to reset the room. A request that overlaps another booking plus its turnover window is flagged as a conflict before you approve it, not after.

When two organizers want the same night

The second request isn't silently rejected. It goes on a waitlist for that slot, in order — so if the first booking falls through, you know exactly who wanted the date and can go back to them rather than starting from nothing.

Sharing your space

Some spaces genuinely run two things at once — separate floors, a courtyard and a room. Venues on the free-for-community arrangement can opt into shared occupancy, which lets more than one booking coexist. It's opt-in, and limited to that arrangement, precisely because it's wrong for most venues most of the time.

Overriding a conflict

You can approve over a conflict when you know something the calendar doesn't. It asks you to confirm first, so an override is always a decision rather than an accident.

Declining well

Declining asks for a reason, and the reason goes to the organizer. It costs you ten seconds and it's the difference between an organizer who tries you again with a better-fitting date and one who doesn't come back.