Bookings and assignments are where several parts of Deskie meet: someone reserves time or space, money changes hands, and (if you have door access configured) the right doors open at the right time. This article traces what happens behind the scenes so you can predict the outcome of a reservation. For the building blocks themselves, see booking a resource, assignments, and door access overview.
Two paths to a booking
A resource booking can be created in two places, and the path it takes through billing differs.
- From inside Deskie (a member booking through their dashboard, or an admin booking on someone's behalf). On this path the member chooses how to pay.
- From your public website (a visitor with no account, or a signed-in member checking out publicly). This is the public checkout path, and it charges a card at the moment of booking.
Both paths write the same kind of booking record: a resource, a start time, an end time, a booking interval (hourly, daily, weekly, or monthly), a status, and a payment status. The differences are in how payment is collected and what invoice is produced.
How a booking is priced
Price is always resolved on the server, never trusted from the browser. The resource carries separate member and non-member rates for each interval. Deskie picks the rate based on who is booking:
- A member is charged the member rate for the interval.
- A guest or anonymous public booking is charged the non-member rate.
For hourly bookings the rate is multiplied by the booked duration. For daily, weekly, and monthly bookings the flat interval rate is used. On public checkout, a signed-in member's total is recomputed from scratch on the server: the member rate is used when the resource allows member bookings and that member rate is set, otherwise the non-member rate, so the amount charged matches the quote the member saw. If a coupon is supplied, it is validated against the resource and applied to bring the total down before anything is charged.
Conflict and limit checks before anything is saved
Before a booking is committed, Deskie protects the time slot:
- Overlap. Unless the resource explicitly allows overlapping bookings, a new booking that overlaps an existing confirmed booking on the same resource is rejected. Back-to-back bookings (one ending exactly when the next begins) are allowed.
- Cooldown. If a cooldown is enabled in your booking settings, a buffer of that many minutes is enforced around every existing booking, and a new booking that lands inside that buffer is rejected. This check is skipped when the resource allows overlapping bookings.
- Duration limits. Hourly bookings are checked against the resource's minimum and maximum booking hours. If the resource enforces a daily maximum, Deskie adds up the booker's existing confirmed hourly bookings on that resource for the same day and refuses anything that would push the total over the cap.
- Interval enabled. The requested interval must be one the resource has turned on.
What billing actually happens
The payment status stored on the booking tells you how the money was handled. The outcomes are:
- Paid immediately. Settled at the time of booking. This is the case for public checkout (a card is charged) and for free ($0) bookings of any kind.
- Added to invoice (Pending Billing). A member chose to add the charge to their next invoice. Nothing is charged now; the line waits to be rolled up.
- Waived. The booking was covered by plan credits, so no charge applies.
- Pending. An interim state while a payment is being processed.
Public checkout: pay now, invoice and receipt after
On the public website, every paid booking charges a card through your connected Stripe account. The sequence is:
- Deskie resolves the booker. A signed-in member books against their existing profile; an anonymous visitor gets a guest member profile created automatically, anchored to the resource's location, with a temporary password so they can log in later.
- Workspace surcharges are applied on top of the resource subtotal. If you have tax or a card fee enabled, those amounts are computed and frozen into the payment so the receipt matches exactly what was charged.
- A Stripe payment intent is created and confirmed for the surcharge-inclusive total. If it does not succeed, the booking record is removed and the customer sees the failure.
- On success, Deskie creates a paid invoice for the booking and a matching payment record, then links both back to the booking. The invoice stores the resource subtotal, with the tax and card-fee amounts captured alongside it.
- A confirmation receipt email goes to the booker. Your admins are also notified: an owner notification email (sent only to admins who have the resource-bookings email preference enabled), plus an SMS and a push alert. These admin notifications fire on both the public checkout and the in-Deskie booking paths.
Free public bookings skip Stripe entirely but still produce a paid $0 invoice and a confirmation email.
Member bookings inside Deskie: pay now, add to invoice, or use credits
When a member books from their dashboard (or an admin books for them), they choose how to pay:
- Add to monthly invoice. The booking is marked Pending Billing and waits. On the next billing run, Deskie sweeps up every booking still marked added-to-invoice that has not yet been invoiced and rolls it into that member's invoice. Guests cannot use this option; they must pay at the time of booking, and Deskie enforces this on the server even if the request is manipulated.
- Credits. If the member has plan credits matching the booking interval, the booking is covered and marked waived, and the credit usage is recorded against the booking. Deskie verifies the balance before saving and rolls the booking back if applying credits fails.
- Free. A $0 booking is recorded as paid immediately and, if the member chose the invoice option, gets a paid $0 invoice for their records.
Whoever pays is also resolved up front. If the member belongs to a team that pays by default, the booking and any invoice it generates are both tagged to that team so billing has a single source of truth. A team can also turn off resource bookings for its members; that restriction is enforced here (team managers and workspace admins can still book).
How an assignment produces recurring invoices
An assignment ties a member to an asset (such as a private office, dedicated desk, parking spot, mailbox, or plan) and bills on a repeating cycle rather than per use. When you create an assignment:
- The assignment inherits the asset's rate, billing interval (monthly, yearly, quarterly, weekly, or daily), and cycle anchor (calendar or rolling). Its first next billing date is calculated from those settings.
- If you ask for an invoice due today, Deskie generates a prorated (or custom-amount) invoice immediately. A coupon, if supplied, is applied against the amount actually being charged today.
- From then on, the billing crons read the assignment's rate and next billing date to issue the recurring invoice each cycle, at full rate, with no proration mid-cycle.
You can change the recurring rate on an active assignment at any time; the new rate applies to the next cycle and every cycle after, while invoices already issued are left untouched. The asset's own base rate is unaffected, since the assignment rate is a per-member override.
Ending an assignment
Removing an assignment marks it inactive immediately and stamps an end date, which stops future billing. You can instead schedule a termination for a future date: the assignment stays active (the space stays occupied and keeps billing each cycle) until a scheduled cron flips it inactive once that date passes. Scheduling a termination can optionally switch on the asset's waitlist so the space lists on your public website as Coming Soon with a join-the-waitlist prompt.
How a booking grants door access for the right window
If you have Kisi door access connected and door access is enabled on a resource, a booking can open the configured doors during the booking's own time window. This is automatic; there is no manual granting or revoking for the booking window.
The resource carries a door-access setting and a list of Kisi lock IDs. When a guest views their doors, Deskie looks for their currently active reservations: confirmed bookings on resources with door access enabled, where the current moment falls between the booking's start time and end time. For each one, the resource's configured locks are added to the set of doors that person can open right now, along with an access window labeled with the resource name and the booking's valid-from and valid-until times.
Because the check is bounded by the booking's start and end times, this booking-window access turns on when the booking begins and turns off when it ends. The same guest view also surfaces passes (valid for their day) and events (valid during the event), so a single guest can accumulate door access from a booking, a pass, and an event ticket at the same time, each with its own window. For the full picture of how passes and events grant access, see passes, events, and access.
What each viewer sees depends on their role. Guests (including the auto-created guest accounts from public bookings) see exactly the doors their active bookings, passes, and event tickets grant. Members see the doors they have been explicitly granted on an ongoing basis through their assignments and group memberships, across Kisi, Unifi, and Deskie Access. Admins and owners see every door across every configured integration in the workspace. If a door integration is briefly unreachable, the doors screen falls back to an empty state rather than blocking, so an offline controller never stops the rest of Deskie from loading.
Putting it together
A single reservation can touch billing and access at once. A member books a conference room for 2pm to 4pm next Tuesday and chooses to add it to their invoice: a confirmed booking is written at the member rate, marked Pending Billing, tagged to their team if that's who pays, and the charge is swept into their next invoice on the billing run. A visitor who books the same room from your public website pays by card at checkout, gets a paid invoice and receipt, and (if the room has Kisi door access enabled) can open the room's doors only between the booking's start and end times. An office assignment, by contrast, bills on a steady cycle and keeps the space until you end or schedule the end of the assignment.