A booking reserves a bookable resource (a desk, meeting room, podcast studio, and so on) for a specific window of time. Deskie supports four booking intervals, applies the right price based on whether the booker is a member or a guest, checks for scheduling conflicts before confirming, and records the booking against the resource so the time slot is no longer available to others. This article explains how that flow works for staff booking inside the admin app, for members, and for guests booking from your public website.
For an overview of resources and how they are set up, see Resources overview. For who is allowed to book a given resource, see Resource access rules.
Booking intervals
Every booking is tied to one of four intervals: hourly, daily, weekly, or monthly. Each resource controls which intervals it accepts. A resource stores its allowed intervals in a list (its enabled intervals), and Deskie rejects any booking that uses an interval the resource does not have enabled. If a resource has no intervals configured, it defaults to hourly only.
The interval determines how the start and end times of the booking are computed:
- Hourly: You pick a specific start time and end time on a single date. The booking covers exactly that window.
- Daily: The booking covers the resource's configured operating hours for that day of the week. If booking hours are not configured, it defaults to 9:00 AM to 5:00 PM.
- Weekly: The booking runs from the start time on Monday of that week through the end time on Sunday of that week, using the resource's configured hours for those days.
- Monthly: The booking runs from the start time on the first day of the month through the end time on the last day of the month.
All start and end times are calculated in your workspace's timezone, so the reserved window lands on the correct calendar dates and hours for your location.
Duration limits for hourly bookings
Duration limits apply only to hourly bookings. A resource can define a minimum and a maximum booking length in hours:
- If a minimum is set and the requested window is shorter than it, the booking is rejected with a message telling the booker the minimum duration.
- If a maximum is set and the requested window is longer than it, the booking is rejected with the maximum duration.
A resource can additionally turn on a per-day maximum (enforce maximum per day). When this is on, the maximum is treated as a cap on the total hours a single person can book on that resource within one calendar day. Deskie adds up the person's existing confirmed hourly bookings for that resource on that day, adds the new request, and rejects it if the total would exceed the maximum. The message tells the booker how many hours they have already booked and how many remain. Daily, weekly, and monthly bookings are not affected by these duration limits.
Member and guest pricing
Each resource stores two sets of rates: member rates and non-member (guest) rates, for each interval (hourly, daily, weekly, monthly). Deskie always picks the rate that matches the booker:
- Members are charged the resource's member rate for the chosen interval.
- Guests are charged the non-member rate for the chosen interval.
For hourly bookings, the rate is multiplied by the number of hours booked. For daily, weekly, and monthly bookings, the rate is a flat amount for the whole interval. A person's member-or-guest status is determined by their role in the workspace: anyone with the guest role (or with no workspace membership at all) is treated as a guest and gets non-member pricing.
On the public website, the rate shown to a signed-in member is recomputed on the server when the booking is submitted, so the price a member is charged always matches the member quote they saw and is never taken on trust from the browser. See Public sign-up and checkout for how member-aware checkout works.
Coupons
A coupon code can be applied to a resource booking. Deskie validates the code against the resource, applies the discount to the booking subtotal, and records the redemption once the booking succeeds. If the code is invalid the booking is rejected before anything is created. If a discount brings the total to zero, the booking is treated as a free booking (see below).
Payment options
When a booking carries a cost, Deskie offers different ways to pay depending on who is booking and where.
Inside the admin app (staff and members)
Bookings created in the app support three payment options:
- Pay immediately: The booking is marked as paid at the time of booking.
- Add to monthly invoice: The cost is added to the member's billing so it is collected on their regular cycle. See Billing cycles and auto-charge.
- Use credits: If the member has plan credits that match the resource and interval, the booking can be covered by credits instead of money. Deskie verifies the credit balance before creating the booking, and the credit type and interval must match (for example, hourly credits cover an hourly booking, and the balance must cover the booked hours). See Account credits.
Guests must pay at the time of booking. Because a guest has no billing relationship and no saved payment methods, Deskie blocks the monthly-invoice and credits options for anyone with the guest role and requires immediate payment. This is enforced on the server, not just hidden in the form.
On the public website
Public self-serve bookings are always paid by card at checkout. The booker enters card and billing details, and Deskie creates and confirms a Stripe payment for the booking. Public checkout always bills the person booking directly, so the charge is never routed to a team even for members whose team would normally pay. Applicable tax and card-fee surcharges configured for your workspace are added on top of the resource subtotal at this point. See Tax and card fees and Payments and ACH.
If the card payment fails, Deskie removes the booking it had tentatively created so the slot stays open. If payment succeeds, an invoice and a payment record are created and the booking is marked paid.
Free bookings
If a booking's total comes to zero (for example, a resource with no charge for that interval, or a coupon that covers the full amount), Deskie skips payment entirely. It still creates the booking and a zero-amount invoice so the reservation is recorded, and it sends a confirmation.
Conflict and availability checks
Before confirming a booking, Deskie checks that the requested time does not collide with an existing confirmed booking on the same resource. The overlap test treats two windows as conflicting when one starts before the other ends and ends after the other starts. This deliberately allows back-to-back bookings: a booking that ends exactly when another begins does not count as a conflict.
Cooldown
If your workspace has a resource cooldown enabled, Deskie also blocks bookings that fall within the cooldown window before or after an existing booking, even if they do not directly overlap. This is useful for cleaning or reset time between reservations. The booker sees a message explaining that the slot conflicts with the cooldown period around an existing booking.
Resources that allow overlapping bookings
A resource can be configured to allow overlapping bookings. When that setting is on, Deskie skips both the overlap check and the cooldown check, and the resource can be booked by multiple people for the same time. This suits shared resources where capacity is not limited to one reservation at a time. On the public availability calendar, every time slot stays selectable for such resources.
Availability on the public calendar
The public booking calendar shows time slots based on the resource's non-member booking hours. If those hours are enabled, days that are turned off show no slots, and enabled days show half-hour slots within the configured start and end times. If non-member booking hours are not enabled, the calendar falls back to a default window. Slots that conflict with an existing confirmed booking (or its cooldown) are filtered out so guests can only pick a time that is actually open.
Access rules and other gates
Even when a time slot is open, a booking can still be refused for reasons unrelated to scheduling:
- Resource access rules: If a whitelist or blacklist blocks the person the booking is for, Deskie refuses the booking. This applies to the target member even when an admin is booking on their behalf; an admin cannot silently override a blacklist. See Resource access rules.
- Paused members: A booking for a paused member is refused. See Pausing and disabling members.
- Team booking switch: If the member belongs to a team that has disabled resource bookings, the booking is blocked unless the booker is an admin or a manager of one of their teams. See Teams.
- Resource state: A resource that is not active or not marked bookable cannot be booked.
What happens after a booking is created
Once a booking is confirmed, Deskie records it against the resource and the booker, stores the calculated amount and payment status, and links any invoice that was generated. A confirmation email is sent to the booker. For public bookings, Deskie can also notify admins by email, SMS, and push (subject to your notification preferences), and when a new guest is created during checkout, that guest is added to your members list and captured as a lead in your CRM. See Guests and CRM pipeline.