Availability
Setting opening hours, closures, concurrent bookings, and spacing.
Availability rules decide when an organization takes bookings. One organization can hold several rules, and all of them apply together.
The five kinds
| Kind | What it does | Main values |
|---|---|---|
hours | Opening hours. Bookings are only taken inside these windows, and the booking grid takes its interval from here. | weekdays, start_time, end_time, slot_minutes |
block | Closes a period. Use it for a holiday or equipment maintenance. | starts_at, ends_at, scope_value |
capacity | How many bookings one time slot accepts. | max_concurrent, slot_minutes |
gap | The minimum time left free between bookings. | gap_minutes |
custom | A condition the four kinds above cannot express. The platform team adds it. | function_slug |
The first four are yours to create and edit in the dashboard. They take effect the moment you save, with nothing to deploy.
Filling in scope_key splits a rule by the values of that field instead of applying it across
the whole organization. A capacity rule with scope_key set to equipment counts each
device separately.
With no opening hours
An organization with no hours rule proposes no times at all, so that no one invents
opening hours it never set. It still accepts bookings, because having no rule to break is
not the same as being closed.
How capacity and gap differ
Both limit bookings, but they measure differently. capacity divides the day into fixed
slots, 30 minutes for example, and counts within each one. gap measures out from a booking
in both directions.
Put a 45 minute gap on a 2pm booking and 1:30pm and 2:30pm both close, while 1pm and 3pm
stay open. With capacity alone, only 2pm would have closed.
A request to leave a few minutes between bookings is a gap. One rule row covers it, and no
development is needed.
Custom rules
custom cannot be created from the dashboard or by the AI. It does not appear in the kind
picker, and a write that carries it is rejected. The rule only works once the platform team
writes code for it.
Staff skills and shift patterns, or two treatments competing for one device, are the kind of condition that belongs here. Tell us what the condition is and we will look at it.
The order matters
The platform team follows an order too. Adding the rule row before the code ships refuses every customer booking for that organization, because a check that cannot reach its condition counts as a refusal rather than a pass. We would rather stop bookings than let an out-of-policy one through.
Where a rule shows up
One rule reaches all four of these. There is nothing to configure per screen.
- The open times the chat AI offers
- The time picker on the landing booking form
- The dashboard booking form and the calendar shading
- The check that runs when a booking is saved
One difference is worth knowing. A booking made by a customer is refused when it breaks a rule, while a booking a staff member makes in the dashboard only warns and still saves. Some bookings arrive by phone and have to go outside opening hours.
Checking your work
Look at the real screens after you add a rule.
- Open the landing booking form and pick a date.
- Check that the times you meant to close are greyed out.
- Ask the chat for open times on that date and check that the same times are missing.
Tell us if the two disagree. They read the same rules, so there is no reason for them to differ.
Checking a custom rule takes one more step: choose what is being booked. A rule that judges
the booking itself, a treatment for instance, closes nothing until you have chosen one.
Common problems
No times are offered at all. Check that an hours rule exists and that its weekdays
include the date you are looking at.
You asked without picking a branch. Head office has no opening hours of its own, because they differ per branch. Pick a branch first.
Several rows of the same custom rule. Keep one row unless you meant to split the configuration across them.