Bookable resources
Rooms, tables, vehicles, courts, chairs, parking, spaces. How to model the physical thing a booking occupies — the three consumption modes, assignment timing, and when a capacity number is a trap.
A bookable resource is the physical thing a service occupies while it happens: a hotel room, a restaurant table, a barber's chair, a tennis court, a parking spot, a rental van. This is the chapter people most need and most often get wrong, because "how many do I have?" feels like enough — right up until two bookings collide or you sell out the wrong thing. Read it carefully.
Two levels: the type and the unit
Keep these straight and most confusion disappears:
- A resource type is a class of interchangeable units: "Deluxe Room", "2-seat Table", "Barber Chair", "Compact Car". It holds the rules — how it's used up, when a specific unit gets assigned.
- A unit (a bookable resource) is one individual item of that type: "Room 101", "Table 5", "Chair 3", a specific van. It has a name, an optional capacity, a location/floor/zone, and a status.
A service requires a type (or, rarely, one specific unit). The pool of units under that type is what availability draws from.
The two-room-types trap
A hotel with Deluxe and Standard rooms is two resource types, each with its own rooms — not one product with a single "15 rooms" count. If you model it as one number, selling a Deluxe wrongly shows a Standard as unavailable, because they share the pool. Model one resource type per class, with that class's real rooms underneath. Then selling a Deluxe only draws down Deluxe, and the Standards are untouched.
This is the canonical example of the guide's core rule: model the fact, not a convenient number. Whenever a merchant says "I have a few different kinds of X", that's a few resource types, not one count. Different tables sizes, room classes, car categories, court types — each is its own type with its own units.
The three ways a booking uses a resource
The consumption mode on the resource type is the core decision. It answers: when a booking happens, how does it draw from the pool?
| Mode | How a booking consumes | Use it for |
|---|---|---|
Whole unit | One booking takes an entire unit. A party too big for one unit packs across several whole units. | Rooms, tables, vehicles, courts, parking — anything a booking owns exclusively. |
Shared capacity | The type is one pool of seats; a booking draws its headcount from the shared total. | Event halls, shared spaces, a co-working floor — capacity is fungible, not unit-by-unit. |
Fixed quantity | A booking holds a set quantity of interchangeable stock, regardless of party size. | Equipment and gear: rent 2 kayaks, reserve 3 projectors. |
How each feels in practice:
- Whole unit — a table for 2 and a table for 4 are different units. Booking Table 5 makes only Table 5 unavailable. A party of 6 might take a 4-top plus a 2-top — Cimplify packs the party across whole units automatically, so you don't pre-define "joined tables".
- Shared capacity — a 50-seat hall is one pool of 50. A booking for 30 leaves 20. You're not assigning a particular seat, just drawing down the count.
- Fixed quantity — a kayak rental holds 2 kayaks out of the fleet for the window. Which two doesn't matter; the count does.
Decide by asking: does a booking own a specific unit (whole unit), share a seat pool (shared capacity), or hold a quantity of gear (fixed)?
For agents: this is consumption on the resource type — WholeUnit, PerCapacity, or Fixed. The resource category (Table, Room, Vehicle, Court, Spot, ServiceSpace, Venue, Custom) sets a sensible default consumption mode (Table, Room, Vehicle, Spot, and Court default to whole-unit; ServiceSpace and Venue to shared capacity; Custom to fixed) and drives the UX pattern. Override the consumption mode if the default doesn't fit.
How a service asks for a resource
On the service, a resource requirement says what a booking needs:
- By type — "any available Deluxe Room", "any free barber chair". The common case; it lets the pool absorb demand.
- By specific unit — "this exact unit". Rare, for when only one physical thing will do.
- Quantity — how many units/seats/items the booking needs (3 parking spots for a group; 2 projectors).
A service can require several types at once — an appointment needing both a room and a piece of equipment. Each requirement is checked before the slot is offered, so a booking only succeeds when everything it needs is free.
When the specific unit is chosen: now or later
The assignment timing on the resource type decides when a booking gets pinned to a particular unit:
- Assign now (immediate) — the unit is chosen at booking time. The customer books Table 5 specifically. Right for tables and most appointments.
- Assign later (deferred) — the booking reserves the type's capacity now and the specific unit is picked later, usually at check-in. Right for hotels: you sell "a Deluxe Room" today and assign Room 204 when the guest arrives, leaving you free to manage housekeeping and upgrades.
With assign-later, availability still counts the reservation against the type's capacity, so you can't oversell — you simply haven't named the unit yet. Staff assign (or reassign) the unit from the booking later.
Taking units offline and unit status
Each unit has a status. To pull a unit from the pool — a room being renovated — set it to maintenance or out of service, and it's removed from availability entirely. Occupied and reserved are handled automatically by bookings; you don't set those by hand. To retire a unit permanently, deactivate it.
Capacity number vs. real resources — how to choose
This is the decision that trips people up. Use the table.
| Use a plain capacity number | Use bookable resources |
|---|---|
| Nothing physical to assign | Specific units exist and matter (Room 101 vs 102) |
| A headcount is all that matters (20 class spots) | You need to assign / reassign a unit, or take one offline |
| One uniform pool, one service | Different classes that must not share a pool |
| Walking tour, webinar, open class | Hotel, restaurant floor, rental fleet, courts |
The trap is reaching for a capacity number because it's quick, then discovering you can't tell two room types apart, can't assign a table, and can't take a unit offline. If real units exist, model resources from the start.
Checkout holds (automatic)
While a customer is checking out, the unit or capacity they're taking is held provisionally for a short window, then released automatically if payment never completes. So an abandoned basket can't lock a room forever, and you don't oversell during the few minutes someone is paying. There's nothing to configure — it just happens.
Worked examples
Hotel. Two resource types — "Deluxe" and "Standard" — each whole-unit, assign-later, with their real rooms underneath. The stay is a multi-day service requiring the room type. Selling a Deluxe never touches the Standards.
Restaurant floor. One resource type "Table" (or several by size), whole-unit, assign-now. Units are the actual tables with their seat counts. A party of 6 packs across a 4-top and a 2-top automatically.
Barbershop. "Barber Chair" type, whole-unit, assign-now, with chairs 1–4 as units. A haircut requires a chair by type — and a barber too, if barbers are individually bookable.
Car rental. "Compact" and "SUV" types, whole-unit, often assign-later (pick the actual vehicle at pickup). The rental is a multi-day service with pickup/return wording.
Event hall. One type, shared-capacity, capacity = seats. A booking draws its headcount from the pool; no seat assignment.
Kayak hire. "Kayak" type, fixed-quantity. A booking holds N kayaks from the fleet for the window.
Mistakes to avoid
- One capacity number for several real classes. The two-room-types trap. One type per class.
- Whole-unit when it should be shared capacity (or vice versa). Re-read the three modes.
- A resource-backed service with an empty pool. It reads as zero availability (fail-safe), not "one" — configure the units before going live.
- Assign-now for hotels. Use assign-later so the front desk keeps unit flexibility.
Common questions
A party is bigger than any one unit. Do I make a "big table"? No. With whole-unit, Cimplify packs the party across several free units automatically. Only make a literal big unit if it physically exists.
Can one booking use a room and equipment? Yes — two requirements on one service. Both are guaranteed before the booking is confirmed.
How is a rental different from a sale? A rental returns. It's a multi-day service over a whole-unit (vehicle) or fixed-quantity (gear) resource, with pickup/return wording — not a retail sale where ownership transfers.
What happens if I take a room offline mid-future-bookings? New availability excludes it. Existing bookings on it stay; reassign them to another unit (assign-later makes this easy) before the date.
I'm an agent. What's the minimum to model a resource-backed service? Create the resource type(s) with the right consumption mode, add their units, then add a resource requirement (by type) to the service. Choose assign-now vs assign-later per how the business hands out units.
Next: Pricing & extras, or see a hotel and a restaurant modelled end to end.
Services
Time you sell over a calendar: appointments vs multi-day stays, duration, capacity, availability, staff, deposits, cancellation and reschedule policy, and multi-day check-in/out.
Pricing & extras
How a price is built up, add-ons and custom fields that change it, tax-inclusive vs exclusive, deposits, discounts, and subscriptions and instalments.