---
title: "Bookable resources"
description: "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](/docs/services) 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

<Callout type="warn">
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.
</Callout>

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?

<PropsTable
  headers={["Mode", "How a booking consumes", "Use it for"]}
  rows={[
    ["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)?

<Callout type="info">
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.
</Callout>

## 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](/docs/services#multi-day-stays-in-detail) 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](#the-three-ways-a-booking-uses-a-resource).
- **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](/docs/services) over a whole-unit (vehicle) or fixed-quantity (gear) resource, with pickup/return wording — not a [retail](/docs/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](/docs/pricing), or see a [hotel and a restaurant modelled end to end](/docs/scenarios).