Reservations: calendar, staff blocks and booking management

The Reservations view is where staff see and manage everything booked against your bookable products. Open it from the main navigation to get one screen for every reservation — customer bookings made from the storefront, and the blocks your team creates for maintenance, staff holds and partner allocations.

Use it to scan what is booked over a day, week, month or year; filter down to the reservations you care about; open a reservation to read its facts and the order, cart and customer behind it; block time out of a pool; cancel a booking; and assign a unit to a reservation that does not have one yet. The storefront booking flow that creates these reservations lives with the Booking APIs.

Two views share the same set of reservations, and you switch between them from the toolbar. Calendar lays reservations out as bars across a grid; the list (labelled Nerdy) shows them as a table — one row per reservation, with columns for the product, rate plan (SKU), unit, when it runs, its duration, its state and source, and the customer and order behind it.

Both views move through time at four zoom levels — day, week, month and year — chosen from the toolbar. Day and week show each reservation individually; month stacks them per day, with a “+N more” that opens that day’s full list; year gives a compact overview. Stepping forward and back shifts the window at the current zoom, and Today returns to the current period.

In the calendar, customer (cart) bookings are drawn in their solid state colour, while staff blocks carry a hatched pattern and a dashed edge, so an admin block reads differently from a real booking at a glance; a confirmed booking that is running right now is marked on-going. Click any reservation to open its details; in day or week view, click an empty slot to start a block for that window — past windows are not clickable.

The sidebar on the left narrows what both views show, and reports how many reservations currently match as a running count at the top (for example, 42 reservations; on the paged list this reads as a floor, such as 42+). It offers:

• Activity — an Ongoing only switch that narrows the view to bookings running right now. It is exclusive: turning it on replaces the rest of the selection, and ticking any state or the blocker turns it back off.
• State — tick Pending, Confirmed, Completed, Cancelled or Expired to show only those states; tick several to combine them.
• Blocker — show only staff-created blocks (maintenance, staff holds, partner allocations and other), hiding customer cart bookings.
• Product — search for and pick one or more bookable products to focus on; Clear all removes them.

Within the state and product groups the choices combine as “any of these”; across groups they narrow together — so two states and one product means “either state, for that product”. Activity stands apart: it cannot be combined, and it and the filters below it switch each other off.

Every reservation — in a calendar bar, a list row or the detail panel — carries two colour-coded tags: its state and its source. Together they tell you where a booking is in its life and where it came from. Each value has its own colour, so the same state or source looks the same wherever it appears.

Click a reservation to open its detail panel. The left side identifies the resource: the product, its rate plan (variant SKU), the unit it is Reserved on (or Unit — when none is assigned yet), the pool it draws from, and the Source with any reason typed when it was created.

The right side covers the booking itself: the Window with its state tag, the start and end, and the duration between them. Under Booked under, it shows the frozen booking policy terms the reservation was admitted under — advance window, buffers, cancellation window and hold durations — which govern it even if the product's policy has since changed.

It also ties the reservation back to the rest of Crystallize: the Customer who made it and the Order it belongs to, each a link through to that record. A staff block shows no customer or order; a booking still sitting in a cart shows no order yet.

To take a resource out of the pool — for maintenance, a staff hold or a partner allocation — choose New blocker in the toolbar, or click an empty slot in the day or week calendar. A block is what the screen writes instead of a customer booking: a reservation the pool has to honour, so the time stops being bookable. You set:

• Product and rate plan (SKU) — the pool comes from the product; pick the variant when it has more than one.
• The range — a start and an end. The product's policy buffers are blocked alongside the window.
• A unit (optional) — pin one named unit, or leave it off to block from the pool. Units already taken for the window are marked as unavailable in the picker.
• Quantity — for a capacity pool, how many of the pool to take out at once. They are blocked all together or not at all.
• Source — Cart, Maintenance, Staff hold, Partner allocation or Other, which sets the tag the block carries. Cart stands for a hold placed on a customer's behalf; because it is a customer-style hold, the product's advance window applies, so a Cart block cannot be set further ahead than that window allows.
• A reason (optional) — free text, shown later on the block's Source.

If the range is already taken, the form shows a conflict notice — “That window collides with an existing reservation — pick another slot or unit” — and offers the nearest free windows as buttons you can click to move to. Other notices catch an end before the start, a unit that is not in the pool or already taken, and a product that is not bookable in the current language. You cannot create the block until the notice clears.

Open a reservation and choose Cancel reservation. Confirm, and the slot opens up for other bookings straight away. A staff cancellation is not held to the customer cancellation window, so you can cancel even inside it.

To clear several at once, use the booking admin API's bulk cancel: each reservation is cancelled on its own, so one that cannot be cleared — an unknown reservation, or one already cancelled, expired or completed — does not stop the rest; check the outcome per reservation.

A reservation on a named-unit pool names one unit. When it has one, its detail panel shows a Reassign unit control next to the Reserved unit: choose it to move the reservation to another unit from the pool. The dropdown lists the pool's other units; if you pick one that is already taken for that window, the move is refused with a conflict notice, since assignment is validated against the pool for the reservation's language.

A reservation can also exist without a unit pinned to it — its panel then shows Unit — . Giving such a reservation its first unit is done through the booking admin API's assign-unit operation, which validates the unit against the pool the same way.

A staff block is a real reservation, so it removes that unit — or that much capacity — from what the storefront can sell for the blocked window, plus the product's policy buffers around it. Customers see the time as unavailable and cannot book it. Unlike a customer cart hold, a staff block has no expiry: it holds the slot until someone cancels it.

Reach the Reservations view from the main navigation. Reading a bookable product's details in the view — its pool and units — needs permission to read bookable products. Acting on bookings — creating blocks, cancelling reservations and assigning units — goes through the booking admin API, which requires booking-admin access on your token or role. Without it you can still open the view, but the actions are refused.