Configuring a location
Resources
A resource is whatever actually does the work — a stylist, a chair, a treatment room, a service bay, a machine. Resources are what stop two customers being promised the same thing at the same time, and what turn a position in a queue into a number of minutes.
Where they live
Location settingsResources, or across every branch from account settings. Like services, they belong to the organisation and can be pinned to particular branches.
Needs the permission resources.create (create resources) and resources.update_all_settings (update all resource settings). Owners and Admins have every permission by default.
What a resource holds
- Name, and a separate display name if what customers should see differs from what your team calls it.
- How many visits at once — one for a stylist, more for something several people can share.
- Speed — a multiplier against the standard service duration, for somebody consistently quicker or slower than the book time.
- Hours— the branch's, or its own.
- Services — everything, or only the ones it can actually perform.
- Daily booking limit — a cap on how much you will put through it in a day.
- Visibility — whether customers can see and choose it, or whether it exists only for your own scheduling.
- Category, colour and image — for grouping and for making the calendar readable at a glance.
- A linked team member, where the resource is a person who also uses the dashboard.
What they actually do
They prevent double-booking
An assigned resource is unavailable for the length of the appointment, so neither your booking page nor a member of staff can promise it to somebody else. This is the main reason to define them.
They decide which slots exist
A bookable slot only appears if something that can perform the chosen service is working then and not already claimed. No resources means no constraint, and a booking page that offers every slot in the day.
They set the throughput behind wait estimates
How many visits your branch can have in progress at once — and how fast they move — is the sum of what your resources can handle. That is what the more precise wait estimate model uses to turn a position into minutes.
Do you need them?
Probably not, if
Anybody on your team can serve anybody, there is no fixed number of places, and you only run a waitlist. A shop counter with three staff who all do the same thing gains little.
Yes, if
You take bookings at all, or you have a fixed number of chairs, rooms or bays, or customers ask for a particular person. Any of those and the answer is yes.
Without resources, nothing limits concurrent bookings
Ten people can book eleven o'clock. For a shop that is fine; for a salon with two chairs it is a bad morning. If two at once is a problem, define the resources.
Modelling them well
- Model the actual constraint. If you have four staff and two chairs, the chairs are the limit — model the chairs.
- Only restrict services where it is true. Saying every stylist does everything is fine if they do; narrowing it when it is not true just makes slots vanish.
- Give people their real hours. Somebody who works three days offered on all seven produces bookings nobody can keep.
- Use the speed multiplier sparingly. It is for a consistent, real difference, not for one busy week.
Categories and visibility
Categories group resources for your own sanity — “Stylists”, “Rooms”. Visibility decides whether a customer can pick one when booking: a salon usually wants customers choosing their stylist, while a garage rarely wants them choosing a bay.
When somebody leaves
Deactivate rather than delete. A deactivated resource stops taking new bookings and stays attached to the ones it already had, so your history stays intact. Check for future bookings against them before you do it — those need moving to somebody else.
Their working hours
A resource can follow the branch's hours or keep its own, set under schedules. Own hours narrow availability and never widen it — nobody becomes bookable at a time the branch is shut.