> For the complete documentation index, see [llms.txt](https://www.oddle.me/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://www.oddle.me/docs/new-guests/reserve/setting-up-reservations/tickets-and-schedules.md).

# Tickets & Schedules

Tickets and schedules are two of the most important concepts in Oddle Reserve. Together, they define **what** guests can book, **when** they can book it, and **what rules apply** — from dining duration to booking windows to cancellation policies.

***

## What Are Tickets?

A ticket is a **type of reservation** you offer. Think of it as a bookable experience — it can be anything you want.

The simplest example is a "Restaurant Reservation" ticket, which is just a regular table booking. But tickets are flexible. You can create tickets for:

* **Regular dining** — "Restaurant Reservation," "Lunch Booking," "Dinner Booking"
* **Different seating areas** — "Indoor Seating," "Outdoor Terrace," "Private Room"
* **Special experiences** — "Valentine's Day Special," "Chef's Table Dinner," "Sunday Brunch"
* **Seasonal or limited-time events** — "Christmas Eve Set Menu," "Wine Pairing Night"

Each ticket is a separate bookable option that appears on your booking page. Guests choose a ticket first, then select their preferred date and time.

### Ticket Settings

Each ticket has its own configuration, giving you granular control:

| Setting                 | What It Does                                                                                                                                                                          |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Ticket name**         | What guests see on the booking page (e.g., "Lunch Reservation")                                                                                                                       |
| **Ticket description**  | Optional details about the experience — shown to guests on the booking page                                                                                                           |
| **Cover image**         | A photo displayed on the booking page. Recommended size: 600×214 (roughly 12:5 aspect ratio)                                                                                          |
| **Ticket colour**       | Internal only — helps your team visually distinguish ticket types on the Host App                                                                                                     |
| **Featured ticket**     | When enabled, this ticket is highlighted prominently at the top of your booking page. You can feature multiple tickets, but be selective — featuring every ticket defeats the purpose |
| **Payment settings**    | Whether this ticket requires a deposit, prepayment, or card guarantee — and whether that requirement changes with party size                                                          |
| **Reserve with Google** | Whether this ticket's availability appears on Google Search and Maps. Paid tickets are supported, apart from non-refundable deposits                                                  |

> **Tip:** When you first set up Oddle Reserve, a default "Restaurant Reservation" ticket is automatically created for your brand. You can rename it, customise it, or create additional tickets as needed.

### Payment by Party Size

A ticket's payment requirement doesn't have to be the same for every booking. You can let small parties book free and ask larger parties for a deposit, prepayment, or card guarantee — all on one ticket. For how this works and how to set it up, see **Prepayment, Deposit & Cancellation Window**.

{% hint style="info" %}
Guests can edit their own reservations too, but that setting lives on the **schedule**, not the ticket — so lunch, dinner, and special events can each have their own edit deadline. See **Step 3: Booking & Edit Window** below.
{% endhint %}

***

## What Are Schedules?

Schedules define **when** reservations can be made. Every schedule must have an associated ticket — a schedule without a ticket won't appear on your booking page, and a ticket without a schedule won't show any available time slots.

You manage schedules in the Host App under **Settings > Online Schedule**. Schedules are set up per store — if you have multiple outlets, you'll need to create schedules for each one separately.

There are three types:

***

### Weekly Schedules

Weekly schedules are your recurring service hours — the backbone of your availability. For example, you might have a lunch service Monday–Friday from 11:00 AM to 3:00 PM, and a dinner service every day from 6:00 PM to 10:00 PM.

You create weekly schedules through a 5-step wizard:

**Step 1: Service Details** — Select the ticket this schedule is for, the days of the week it applies to, and the service timing (first bookable time to last bookable time).

**Step 2: Seating** — Configure who can book, how many, and for how long:

* **Areas** — Choose whether this schedule applies to all areas or specific areas only. For example, if you have an "Outdoor Terrace" ticket, you'd associate its schedule with just the outdoor area.
* **Reservation Pax Limits** — Set the minimum and maximum party size for online bookings. The default maximum is based on your largest table.
* **Dining Duration** — How long each reservation is allocated (e.g., 1h 30mins). This determines how long the table is blocked in your timeline.
* **Seating Limits** — Optionally set a maximum capacity per service (total covers) and/or a maximum number of reservations per service. Online availability automatically closes once either limit is reached.

**Step 3: Booking & Edit Window** — Control how far in advance guests can book, and whether they can change the booking afterwards. The booking window defines the range of time during which a guest can make a reservation — bounded by a maximum (how far ahead) and a minimum (how close to the reservation time).

![Booking window diagram showing the bookable range between maximum and minimum advance time](/files/tSJ2yD6FMMI8x8J27dHa)

* **Maximum Time in Advance** — The furthest out a guest can book (e.g., 1 month). You can optionally check "Before a specific time" to set a cutoff — for example, "1 month in advance, but only before 12:00 AM" means the slot opens exactly one month before that time.
* **Minimum Time in Advance** — The closest to the reservation time a guest can still book (e.g., 1 day, 36 hours). You can optionally check "After a specific time" to fine-tune this.

> **Example:** Say your dinner service runs 6:00 PM–10:00 PM with a maximum booking window of 1 month and a minimum of 1 day. A guest browsing on March 1 can book any dinner slot from March 2 through April 1. They won't see tonight's slots (within the 1-day minimum), and they can't book anything past April 1 (beyond the 1-month maximum).

**Reservation Settings** — Also in this step, you set the **Timeslot Intervals** — the time gap between available slots shown to guests on the booking page. For example, a 30-minute interval means guests see options like 7:00 PM, 7:30 PM, 8:00 PM. A 15-minute interval gives more granular options: 7:00 PM, 7:15 PM, 7:30 PM, and so on.

**Customer Edit Window** — Also in this step, choose whether guests can change or cancel their own reservation through a link in their confirmation email.

Turn it on and set how far before the reservation time guests can still make changes. For example, "until 3 days before" means a guest with a Saturday booking can edit until Wednesday. The window can be set in minutes, hours, days, weeks, months, or "any time" for no cutoff.

Because this setting lives on the schedule, your lunch service, dinner service, and special events can each have their own edit deadline — even when they all use the same ticket. This setting used to sit on the ticket; if you had it set there, it was copied to that ticket's schedules automatically, so there's nothing to redo.

If a guest books after the edit window has already passed — they book on Friday for Saturday, and the window is 3 days — they won't be able to edit that reservation themselves. They'll see that self-editing isn't available.

Edit terms are settled at the moment of booking. If you give a schedule a more generous edit window later, reservations already in the book keep the terms they were made under.

You can also set a **Contact Restaurant** message for when self-editing is off or the window has passed. Choose whether it appears on the **Edit Reservation Page**, the **Cancellation Page**, or both, so guests know to call or message you instead.

{% hint style="info" %}
A reservation your team creates in the Host App might not match any schedule — an off-hours booking, for example. With no schedule to read the rules from, self-editing is off for that reservation and your **Contact Restaurant** message is shown instead.
{% endhint %}

**Step 4: Restaurant Policy** — Choose whether to use your default house rules and reservation policy, or write a different policy specifically for this schedule. Guests see the full policy — including system rules like deposit and cancellation terms — followed by your custom rules. You can edit the default policy from here if needed.

**Step 5: Timeslot Preview** — Review the generated time slots to make sure everything looks right before saving.

***

### Special Schedules

Special schedules are one-off overrides for specific dates. Use these for holiday hours, special event timings, or any day where your regular schedule doesn't apply.

**A special schedule overrides any weekly schedule for the dates it covers.** This is important — if you have a weekly dinner service on Fridays and you create a special schedule for a specific Friday, the special schedule takes over completely for that day.

The setup wizard is the same 5 steps as a weekly schedule, with one difference: instead of picking days of the week, you pick specific dates from a calendar. You can select multiple dates at once.

***

### Blockout Schedules

Blockout schedules close off specific dates entirely — for private events, renovations, holidays, or any day you're not taking online reservations.

To create a blockout, select the dates from the calendar, then choose which services to block. You can block all services on those days, or selectively block individual services (e.g., block lunch but keep dinner open). You can also add a staff note explaining the reason for the blockout — your team will see this in the calendar.

***

## How Tickets and Schedules Work Together

The relationship is straightforward:

1. You create a **ticket** (the "what")
2. You create a **schedule** (the "when")
3. Every schedule is **linked to a ticket** — this is set in the first step of the schedule wizard

This gives you a lot of flexibility. For example:

* Your "Restaurant Reservation" ticket might have both a lunch and dinner weekly schedule
* Your "Valentine's Day Special" ticket might have a special schedule just for February 14
* Your "Outdoor Terrace" ticket might only have a dinner weekly schedule, associated with just the outdoor area

> **Note:** When a guest books outside of any existing schedule (e.g., your team manually creates a booking for an off-hours time), the system defaults to a 1.5-hour dining duration since it doesn't know which schedule to reference.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## 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, and the optional `goal` query parameter:

```
GET https://www.oddle.me/docs/new-guests/reserve/setting-up-reservations/tickets-and-schedules.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.
