# Reservations & Privatisations
When a user lands on the **`/index`** page, they have two available booking flows:
* A **standard reservation**
* A **privatisation request** (booking a private space)
Each path follows a similar logic, with a few key differences explained below.
***
## Standard Reservation Flow
To make a standard reservation, the customer must:
1. Select a **date**
2. Choose a **time**
3. Indicate the **number of people**
Once these are selected, the system displays the **personal information form**, where the user must enter:
* First name / last name
* Email
* Phone number
* A comment (optional)
***
## Default Scheduling Rules
By default:
* **Sundays** are blocked and not available for booking.
If you want to allow reservations on Sundays, simply remove the following conditional from the date picker:
**As a reminder, bubble associates the days of the week with the following numbers:**
* Monday: 1
* Tuesday: 2
* Wednesday: 3
* Thursday: 4
* Friday: 5
* Saturday: 6
* Sunday: 0
***
## Blocking Specific Dates
You can block specific dates using the `BlockedDate` system. This allows you to prevent:
* Reservations
* Privatisation requests
* Or both
Just create a `BlockedDate` record and define the type of restriction.
***
## After Submission
Once a request is submitted:
* The customer receives an **automated confirmation email**.
* A reservation record is created in your database.
***
## Client Record Logic
A new client is created **only if both**:
* The email **is not found**
* AND the phone number **is not found**
If a match is found, the system uses the **existing client record**.
***
## Privatisation Flow
The privatisation flow is almost identical to the standard reservation flow, with one key difference:\
The user must select a **private space** (called a *room* or *salon*), which you define and manage in the backoffice.
To appear in the form:
* A room must be **published** (`isPublished = yes`)
***
## 💳 Privatisation Fee & Payment
Once the user fills in their personal information, they are prompted to **pay the privatisation fee** defined for the selected room.
This amount is:
* Configurable per room
* Paid via Stripe directly in the form
After a successful payment:
* The customer receives a **payment confirmation email**
* The transaction appears in your connected Stripe account
***
## 🗂️ Backoffice Visibility
Once submitted:
* The request appears in your **admin backoffice** (`/backoffice`)
* You also receive an **internal notification email** for each new submission
***
## 📝 Draft Status
If a user **does not complete** the form or leaves before final submission:
* The reservation is saved with the status: `Draft`
* Drafts do **not appear in the backoffice**, but remain visible in the database
This allows you to debug or follow up manually if needed.
***
## 💡 Tips
* You can customize the email templates for confirmations directly inside the related workflows.
* Use the `BlockedDate` system to easily manage holidays, special events, or closures.
* The payment logic for privatisations can be extended to cover deposits, minimum spend, or multi-step approval if needed.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://bookit-2.gitbook.io/bookit-template-bubble/basics/markdown/reservations-and-privatisations.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.