> 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/managing-reservations.md). # Managing Reservations Day-to-Day Every reservation in Oddle Reserve moves through a series of statuses — from the moment it's booked to when the guest leaves (or doesn't show up). Understanding how statuses work helps your team manage the floor efficiently and know exactly where each booking stands. *** ## Reservation Statuses Here's the typical flow a reservation goes through: **Booked → Confirmed → Seated → Bill Requested → Completed** Not every reservation will hit every status — some are optional, and others happen automatically. ### Booked The starting status for all reservations, whether created by the guest online or by your team manually through the Host App. ### Confirmed A reservation can be confirmed in two ways: * **Guest self-confirms** — Oddle sends the guest a confirmation request via email (or automated voice telephony, if configured). The guest confirms directly from that message. * **Your team confirms manually** — If your workflow includes calling guests to verify their booking, your team can mark the reservation as "Confirmed" in the Host App after speaking with them. Confirmation is optional — many restaurants skip this step entirely and go straight from Booked to Seated. ### Seated Your team marks the guest as seated when they arrive and are shown to their table. This is a manual action in the Host App. ### Bill Requested An optional status your team can use to signal that a seated guest has requested the bill. Useful for coordinating between floor staff and cashiers. ### Completed (Departed) The guest has left and the reservation is done. Your team marks this by "departing" the guest in the Host App. You may see this referred to as either "Completed" or "Departed" — they mean the same thing. Departing a guest frees up the table in your inventory, making it available for the next booking or walk-in. ### Cancelled The reservation was cancelled — either by the guest (through the self-edit link in their confirmation email) or by your team (through the Host App). Cancellations can happen at any point before the guest is seated. ### No Show The guest didn't turn up. You can mark a reservation as No Show manually, or the system can do it for you automatically at the end of the day based on your **Status Management** preferences (see Automatic Status Changes below). If the reservation had a card guarantee, you can charge the no-show fee at this point. *** ## Late & Overstayed These are visual indicators that appear alongside a reservation's current status to help your team spot issues at a glance. **Late** — Appears when the reservation time has passed by more than 15 minutes and the guest still hasn't been marked as Seated. This is a heads-up that the guest hasn't arrived yet, so your team can decide whether to hold the table or open it up. **Overstayed** — Appears when the current time has passed the expected end time of the reservation (based on dining duration) and the guest is still seated. This helps your team identify tables that are running over, especially during busy service when the next booking needs that table. *** ## Automatic Status Changes To save your team from manually updating every reservation, Oddle Reserve can automatically transition statuses at the end of the day. You configure this in the Host App under **Settings > Status Management**. There are two modes: ### Mode A: Completed Driven (default) The system automatically marks reservations as **Completed** at the end of the day, unless they're marked as Late or No Show. This is the easiest option for most restaurants — your team just needs to mark no-shows and late guests during service, and the system takes care of the rest. ### Mode B: No Show Driven The system automatically marks reservations as **No Show** at the end of the day, unless they're marked as Seated, Overstayed, or Bill Requested. This mode is better for restaurants where the team actively manages statuses throughout service — if you're diligent about marking guests as Seated when they arrive, any reservation that was never seated gets correctly flagged as a no-show. {% hint style="warning" %} Only use Mode B if your team is diligent about marking guests as Seated during service. If they don't, most reservations will end up incorrectly flagged as no-shows at the end of the day. {% endhint %} *** ## Past Reservations For reservations in the past (yesterday and earlier), you can only move them to terminal statuses — **Completed**, **Cancelled**, or **No Show**. You can't move a past reservation back to Booked or Confirmed, since those statuses are only meaningful for upcoming bookings. *** ## Late Arrival Prompt If a guest has a reservation but the current time is well past the original booking time and they haven't been seated, the system will prompt your team asking if you'd like to move the reservation to the current time. This is useful when a guest calls ahead to say they're running late — instead of cancelling and rebooking, you can simply shift the reservation forward to now and seat them when they arrive. *** ## Viewing Reservation Records While the Host App is where your team manages reservations in real time, **Merchant Admin** provides a full view of all reservation records — past and present. You can review reservation details, guest information, status history, and any notes or special requests from the reservations section in Merchant Admin. This is useful for managers who want to review booking volumes, check on specific guest history, or handle enquiries without needing access to the Host App. --- # 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: ``` GET https://www.oddle.me/docs/new-guests/reserve/managing-reservations.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.