Preventing a double-booked Space — Help

Double-booking a room is one of the few mistakes in events that is genuinely hard to recover from. 1pm guards against it: if you try to hold the same Space for two events whose times overlap, it stops the save and tells you which booking is in the way, before the clash ever reaches a client. You still get full control for the rooms that genuinely can take two events at once.

The rule, in one line

Assign a Space to an event, and if its time overlaps another booking already holding that Space, 1pm blocks it. The only exception is a Space you have marked as divisible, where two events may overlap as long as they are in different Zones.

Which bookings count as holding a Space

Only committed bookings hold a Space: tentative, confirmed, and completed events. An enquiry does not hold anything, because it is not a commitment yet, so an enquiry never blocks another booking and is never blocked itself. This is deliberate: you can pencil in speculative enquiries freely, and the block only bites once a booking is real.

How 1pm works out the overlap

To decide whether two bookings clash, 1pm looks at the window each one holds the room for:

If you have set an access-from and vacate-by window, that load-in to clear-out span is used, because that is the truest picture of when the room is unavailable.
Otherwise it uses the event's own start and end times.
If no times are set at all, it treats the event as holding the whole day, which is the safe assumption.

Back-to-back bookings are fine by default. If one event vacates at 17:00 and the next loads in at 17:00, they touch at the boundary but do not overlap, so both are allowed. Multi-day bookings are handled the same way, across every day they span.

If you have set a changeover buffer on the Space, that is no longer true, and deliberately so. A buffer holds extra minutes on either side of every booking, for turnaround on a room or travel time for a person or a vehicle, and the clash check counts them as part of the window. With a 60-minute buffer, a 17:00 vacate and a 17:00 load-in do clash, because the room is not actually free. Buffers are set per Space and can be overridden on an individual event. See What a Space is for where they live.

Rooms that can take two events at once

Some Spaces really do host two events side by side: a ballroom that divides into halves, a shared foyer, an open lawn. For those, open the Space and turn on Allow concurrent bookings.

With that on, two overlapping events in the same Space are allowed only when they sit in different Zones (the free-text sub-area label you set per event, like "east wing" or "stage left"). Two events in the same Zone, or both with no Zone set, still clash. The toggle is the gate here: Zone on its own cannot let two events share a room unless the Space has been declared divisible. Leave the toggle off and the Space can never be double-booked, whatever the Zones say.

When an overlap is allowed this way, 1pm shows a quiet notice that the event shares the Space with another, rather than a block. Nothing to fix; it is just letting you know they overlap.

Where you see it, and how to clear a block

The check runs live as you work, in four places:

On the event form, as you set the Space, date, and times. A blocking clash shows a red warning naming the other booking, and the save is rejected while it stands. An allowed, different-Zone overlap shows a blue notice instead.
On the calendar, when you drag an event to a new day or a different Space. A move that would double-book is refused the same way.
When a quote is accepted, covered in its own section below.
In the Move events preview, when you shift bookings from one Space to another in bulk. Each one is tested against the destination before anything is written, and against the rest of the batch. See Moving events between Spaces.

When a save is blocked, you have three ways out, and the message spells them out:

Change the time so the two no longer overlap.
Pick another Space for one of them.
If the room genuinely can hold both, allow concurrent bookings on the Space and give the two events different Zones.

When a client accepts a quote

Accepting a quote places a hold, so it runs the same check before it does. The window it tests is the one the event is about to be created with: the lead's own Space, its start and end times, and its date, including the roll to the next day when an end time falls before its start time. A lead with no times at all still holds the whole day.

What happens next depends on who is accepting.

A client accepting on their own quote link is hard-blocked. They are told the slot is not available and that you will be in touch. A client must never be able to book over a room you are already holding for somebody else, and they have no way of knowing what the clash is.
You accepting from the quote page get the choice. The clash is named, with the booking it collides with and when that booking runs, and an Accept anyway button behind a confirmation. Use it when you know the two can genuinely run together. It is logged, and flashed back to you afterwards, so a deliberate double-booking is never silent.

Give your leads a Space

The check can only measure a room if it knows which room. A lead with no Space set has nothing to test against, so it falls back to checking your whole account for that date: your Space's concurrent-bookings setting is ignored, Zones count for nothing, and any booking at all on that day reads as a clash.

That is worth avoiding in both directions. It refuses slots that are genuinely free, and it is not really guarding a room. Set a default Space for new leads, or pick one on the lead before you quote.

What a Space is covers Zones, capacity, changeover buffers, and the concurrent-bookings toggle.
A default Space for new leads covers where a booking's Space comes from.
Moving events between Spaces covers running this check over a batch of bookings at once.
Access from and vacate by covers the load-in and clear-out window the check prefers.
Quotes and invoices covers the accept step the check now runs on.