Every setting on a resource

A resource is anything scarce that a booking consumes besides a person: a treatment room, a chair, a station, a machine, a studio, a court. Bookodile treats it as a real constraint — if the thing is busy, the time is not offered, however many staff are free.

Resources live at Settings → Resources. There are seven settings on one, and the resource's page also carries the list of services that need it — the same links the service's own page writes, editable from either side.

What a resource is for

Most booking software counts people. That is wrong for most of the businesses that use it, because the bottleneck is usually not the headcount:

• A barbershop with four barbers and three chairs can run three appointments.
• A spa with five therapists and two treatment rooms can run two.
• A nail studio with six technicians and four stations can run four.

Without resources, all three shops would offer times they cannot honour, and the customer finds out on arrival. With them, the calendar tells the truth.

Capacity

Capacity (capacity) is the number of bookings this resource can hold at the same time. The default is 1, which is right for anything private — a room, a chair, a single machine.

Capacity above 1 works properly and is enforced when the booking is made, not just displayed. A studio floor with capacity 8 takes eight bookings in the same slot and refuses the ninth.

That is also how a class that fills up works. A recurring class is a service attached to a capacity resource: the eighth person books, the slot disappears, and if someone cancels, the waiting list offers the freed place automatically. Events are the other shape, and are better for genuinely one-off things.

Two honest notes on how the count works:

• A booking is counted against capacity for its whole window, including the service's buffer. Two bookings that merely touch the window you asked for each use a unit, even if they do not overlap each other. The effect is conservative: it never over-books, and it can occasionally offer less than a perfect packing would.
• Your own team can override a resource conflict when booking from the calendar. That is deliberate — staff know when the extra chair is coming out of the back room — but it means the limit binds customers, not you.

Working hours

A resource can carry its own working hours (working_hours), up to four ranges a day. Left empty, it simply follows the business.

Resource hours narrow and never widen. A room available 24 hours inside a shop open 09:00 to 17:00 is bookable 09:00 to 17:00. A room available only 18:00 to 21:00 inside the same shop is bookable never, and the day comes back empty.

This is the mechanism behind "only on certain days". A service cannot itself be restricted to particular times, so if you want to offer something only on Tuesday and Thursday evenings, attach it to a resource whose hours are exactly those windows.

Resource hours are enforced for every part of a booking — the main service, every stage of a combo, and every add-on.

Who can be booked here

By default a resource is open to anyone who performs its services. That is how every resource behaved before this setting existed, and it is right for most of them: four identical chairs, two interchangeable treatment rooms.

Who can be booked here (resource_employees) changes that. Name one or more people and the resource is theirs: nobody else is ever booked into it, including people you add to the team later. Naming nobody means anyone, which is the default.

It is the setting for a shop where the equipment is not interchangeable:

• Three junior barbers share one chair while the master has his own. Name the master on his chair and the three juniors on theirs, and the juniors are never given the master's chair — even at the busiest hour, and even though it is standing empty.
• A physiotherapist owns the plinth in the back room and the two locums use the front one. A nail technician brings her own station and leaves it set up. A trainer keeps the rig nobody else is signed off on.

Three things follow from it, and all three are the point rather than side effects:

• Somebody with a resource of their own is booked there first. When a person could use several, the booking page gives them the one the fewest other people could have used. The master's chair goes to the master, and the shared chair stays free for whoever has nothing else.
• Somebody the resource is not kept for is not offered at all for a service that needs it. If every resource a service needs is kept for other people, that person is simply not among the ones a customer can pick for it — and your own team is told so on their page and on the service's.
• A service handed to someone else goes with them to a resource they may use. Change the team member and a resource kept for somebody else is swapped for one the new person may use, their own first. Move visit and a drag onto their column also pass over one that is taken at that time; the booking form takes their own and shows the clash if it is busy, so you can pick another. A colour appointment handed to a colleague moves to the colleague's station; a session handed to the locum moves to the locum's plinth. Only when nothing the service uses is open to them does the resource stay as it was, and the dialog says why.

You set this on the resource, never on the person: a team member's page shows where they work and says so, but it is read-only, because one row with two places to edit it is how two screens start disagreeing.

Worked through end to end, with the shapes a real shop has: sharing rooms, chairs and equipment.

Name, description and colour

Name (name) is what your team sees on the calendar and in the resource filter. Customers never choose one: they see times appearing or not appearing, and the name of the one their booking takes only in the summary on the booking page's last step and in their reminder email.

Translations (translations) are the name in the business's other languages (Settings → Business profile → Also in), written by Bookodile within a few minutes of any change, so a customer reading the booking page in English sees "Chair 1" where the team wrote "Kreslo 1". See translations under the name shows them and lets you correct one; a changed name is translated afresh.

Description (description) is a note for your own team.

Colour (color) tints the resource on calendar views that group by resource.

Turning one off

Active (is_active) takes a resource out of service without deleting it — the room being redecorated, the machine away for repair. An inactive resource takes no new bookings from the booking page and is no longer offered in the calendar's resource picker. Bookings already on it are kept.

A service is offered only while at least one of the resources it can use is active. If a service can use any of three rooms and you switch one off, it keeps running on the other two. Switch off the last one and the service offers no times at all, on every day, until a room is active again. A service linked to no resource is unaffected.

A combo is stricter. Each stage of a combo that uses a resource is set to one resource, not a choice between several, so there is nothing to fall back on: switch off the resource that any one stage uses and the whole combo offers no times until it is active again.

A service that cannot be offered leaves the booking page by itself. While every resource it needs is off, customers do not see it at all — not a service with an empty week — and it comes back on its own when a resource is switched on again. On the Services list it is marked Not offered, with the switched-off resource named and a Switch on button beside it. There is no separate switch on the service to keep in step; archiving is still how a service stops for good.

Switching one off tells you first what it takes with it. When switching a resource off changes something, you are shown the services that stop being offered, the ones that keep going with fewer resources to choose from, and how many upcoming bookings already hold it (they stay). A resource that no service needs switches off without asking. While it is off, its row in Settings → Resources names the services it is keeping off your booking page.

Deleting one

A resource that a service needs, and nothing else, cannot be deleted. Deleting removes its links to services, so a service that needed only that room would stop needing any room — and be bookable with no limit, at any hour you are open. You are shown which services still need it and offered to switch it off instead, or you can give those services another resource first. A resource that no service depends on alone deletes as before.

Your own team is not bound by the switch. From the calendar a booking can still be created for that service with no resource attached — the same override that lets staff book past a full resource.

Linking a resource to a service

Two ways, and a service uses the union of both — never one instead of the other, and never a conflict to resolve:

• Directly, on the service's own Resources card, or on the resource's own page under Which services need it.
• Through its category, set once and inherited by every service in it — including services you add to that category later. Set it on the category, or on the resource's page with Whole category; they write the same thing.

Saying it in both places is the same answer twice, not twice the answer: a booking still takes one resource. The screens say which is which. On the service, a category's resources are read-only chips; on the resource, a service that inherits it is shown ticked and marked from the category, because unticking it there would change a row that is not what makes it true.

Turn Whole category off and each service in it goes back to its own link — the ones somebody ticked one at a time are still there, untouched.

Linking several resources to a service means any one of them, not all of them together. A booking holds exactly one resource: for each time, the booking page tries the service's resources — its own before its category's — and gives the booking the first one that is free then: not full, inside its own hours, and not blocked out in the calendar. A haircut linked to three chairs is offered while any chair is free; a massage linked to two treatment rooms goes into whichever room is empty.

So one booking cannot hold two resources at the same time. A treatment that needs both a room and a particular machine cannot be set up to wait for both. A combo can use a different resource at each stage, but its stages run one after another, not together.

No employee needed. A service can be set to skip the person entirely, so availability comes from the resource alone. That is how a room, a court or a studio is rented with nobody attending. See every setting on a service.

Resources and what you pay

This is the part worth understanding before you decide how to model your shop, because it usually works in your favour.

Bookodile bills per booking spot — the number of appointments you can run at the same time — not per person. A pool of people constrained by a resource counts as the smaller of the two.

So five barbers sharing one chair is one spot, not five. Four therapists with two treatment rooms is two. Declaring the scarce thing is what tells the meter your real capacity, and it lowers the bill.

Keeping a resource for named people does not change what you pay today. The meter counts people against resource units; it does not yet read who is kept for whom. It is on the list to change, and the direction is downward — a chair only one person can sit in constrains your shop more than the count alone suggests, not less.

The mistake that costs money is the opposite one: leaving a scarce resource undeclared. A shop with five staff and no resources is a shop claiming five simultaneous bookings, and it is billed for five. Declaring an abundant resource costs nothing.

Full model: What Bookodile costs.

Worked examples

A barbershop, four barbers, three chairs. Three resources of capacity 1, linked to every haircut service. Four barbers can be rostered; three appointments can run. The bill is three spots.

A spa, five therapists, two treatment rooms and one sauna. Two capacity-1 rooms linked to the massage and facial services, and a capacity-4 sauna linked to the sauna session. Massages cap at two concurrent, the sauna takes four, and the sauna is a resource-only service with no therapist attached.

A gym running classes. The studio floor is one resource with capacity 12, and the class is a service linked to it. Twelve people book the 18:00 slot and it closes; a cancellation is offered to whoever is on the waiting list. The gym's personal-training services are linked to nothing, because the trainer is the constraint.

A barbershop where one chair belongs to somebody. Three juniors share Chair 1 and the master has Chair 2, which is named for him. Book all four at 10:00 and two of them get a time: the master in his own chair, one junior in theirs. The other two juniors are offered the next slot rather than the master's empty chair. The same shape covers a clinic where one practitioner owns the back room, and a studio where a technician keeps her own station.

A nail studio, six technicians, four stations. Four capacity-1 stations. The fifth simultaneous booking is refused even with two technicians idle, which is correct — there is nowhere to sit. The bill is four spots rather than six.

Limits

• Customers never choose a resource. There is no "choose a room" step: they pick a time, and the booking is given a free resource behind it. The review screen before they confirm names the one it was given.
• A booking takes one resource, never two at once. A service linked to several resources uses whichever one is free; there is no way to require a room and a machine together.
• Switching off a service's only resource leaves the service on the menu with no times to pick — and for a combo, so does switching off the resource any one stage uses. Archive the service if it should disappear.
• A resource cannot be booked directly. It is always reached through a service, including a service with no employee.
• Nothing in the database enforces capacity. It is checked when the booking is made, and two requests arriving in the same instant can in principle both pass. The check is repeated immediately before writing, which narrows the window without closing it entirely.
• Your team can override a resource conflict from the calendar; customers cannot.
• Resource hours narrow, never widen — a resource cannot make a shop open outside its own hours.
• Who a resource is kept for does not affect your bill yet. It changes who can be booked where, today; the meter still counts people against units.
• A person kept out of everything a service needs disappears from it. They stay perfectly bookable for every service that needs no resource, and their own page says which case they are in.
• There is no "usually mine, but shared when busy". A resource is open to anyone or kept for named people; it cannot be given away only at the busiest hour. If a chair should be available to everyone when free, leave it open — whoever has a chair of their own is sent there first anyway.
• Your team can override a clash, the same way they can book past a full resource: a service handed to someone who may use none of its resources, or whose own are all taken then, warns and can be moved anyway. What they cannot do is give a combo stage somebody its resource is not kept for — a stage is pinned to one resource with nothing to fall back on, so the stage's list of people only offers the ones it is open to. The setting binds customers; the combo stage binds everybody.