# Every setting on a resource

> Rooms, chairs, stations and equipment as bookable things — capacity, their own working hours, who can be booked into each one, resource-only services, and why declaring a scarce resource usually lowers your bill rather than raising it.

_Last verified: 2026-09-10. Source: https://bookodile.com/docs/reference-resources_

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](/docs/sharing-rooms-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](/docs/reference-services).

## 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](/docs/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.
