The Bookings page (under Tools in the main sidebar) shows every booking that touches your booking pages. Sales reps see their own bookings, sales managers see their team's, and admins see the whole organization. Each row shows the booking page, booker name and email, date and time in the booking page's timezone, location type, and duration. Click a row to expand the detail drawer with the full booking record and action buttons.

• Booking page title — what the booker chose.
• A status word, at most one per row — Cancelled, Rescheduled, Attended, No-show, Needs review, or Not marked. Upcoming bookings carry none. See Marking what happened.
• Booker name and email — the linked CRM person if matched, otherwise the raw values from the booking page.
• Date, time, and timezone — rendered in the booking page's configured timezone, not the host's browser zone, so the host always sees what the booker sees.
• Location and duration — e.g., “Meet · 30m” or “Phone · 60m”.

The list loads 50 bookings at a time with paging controls underneath. Changing a tab, a filter, or the search resets you to the first page. When the total is not known, the paging shows only Previous and Next rather than inventing a page count.

The search box reads Search booker name or email and runs on the server, so it covers every booking in the current tab and not just the page in front of you. It matches the booker's name and email address only. A full email address is matched exactly; anything else is treated as part of a name — so a bare domain fragment finds nothing, and you should search the name instead.

Alongside the search there is a filter bar: My open deals, a booking-page picker, a host picker, and From date / To date. Clear resets them. The host picker appears only if your role lets you see teammates' bookings and there is more than one host to pick from. A few of these cannot apply at the same time as Needs review; when that happens the page turns the conflicting one off and announces which, rather than silently narrowing your results.

The toolbar carries an export link — Export this view, or Export followed by the row count when the count is known. It exports the whole current view (tab, filters, and search), not just the 50 rows on screen, and it is absent when the view has no rows at all.

• It needs scheduler.view, and the file is clamped to your data scope on the server — an own scope exports only your own bookings, whatever the filters say.
• The cap is 5,000 rows. Above it the export is refused with a message asking you to narrow the filters.
• The file is named bookings_export_ followed by the date.

The drawer expands inline below the row and shows everything the booker submitted plus context the CRM has on file:

• Start and end times, in the booking page's timezone.
• Booker contact — name, email, phone if provided.
• Strategy — Individual, Round robin, Collective, or Group. For group bookings, the attendee count is shown next to the strategy.
• Notes the booker submitted.
• Cancellation reason (and whether the booker or host cancelled), if applicable.
• The meeting URL (Meet, Zoom, custom) as a clickable link — only rendered as a link when the URL parses as http:// or https://; anything else (a phone number, an address, or a defensively-blocked stale value) is shown as plain text.
• Custom-question responses, if the booking page collected any.

A past booking that nobody has marked yet shows Needs review for a fixed window, then quietly settles to Not marked. The window is deliberately narrow so the queue stays finite:

• A booking becomes reviewable 2 hours after it ends — long enough that a meeting running over is not counted as a miss.
• It stays reviewable for 14 days. After that it drops out of the queue unmarked and reads Not marked.
• Only confirmed bookings are counted. A cancelled or rescheduled one is never in the queue.

The Needs review chip in the toolbar filters the list to exactly that queue, with a count beside it. Turning it on switches you to the Past tab. The chip is hidden when the count is zero, unless it is already on. If more than 50 are waiting, the list says “Showing the 50 oldest. Mark these to see the rest.”; when there is nothing left it says “No meetings from the last 14 days are waiting to be marked.”

Roughly 24 hours before a confirmed booking, the booker gets a reminder email headed Your meeting is coming up, and the host gets one headed Upcoming meeting. Both repeat the meeting, the date and time, and the location. The host copy respects your own meeting-notification preferences, so you can turn it off for yourself; the booker copy always goes.

The expanded row shows Reminder sent to the booker with the date, and only once a reminder has genuinely been accepted for delivery. A booking with no such line has not had one sent yet — there is deliberately no “reminder scheduled” line, because a scheduled send is not a sent one.

When Pre-meeting briefing is enabled on the booking page (it is by default), a notification is sent to the host roughly 1 hour before each confirmed booking. The briefing includes recent activity with the linked person, their lifecycle stage, and any open opportunities tied to them — so you walk into the call with context, not a cold introduction.

Briefings are dispatched by a background cron that runs every 5 minutes. A booking that starts in less than 60 minutes when it's created (so the cron can't catch it before the meeting starts) doesn't get a briefing — the cron only fires for bookings whose briefing window hasn't already passed. The booking row records briefing_sent_atonce the notification ships so it's never duplicated.

• scheduler.view — required to see the page, and to export. Data scope (own / team / all) decides which bookings show up, and the export is clamped to the same scope on the server.
• scheduler.edit — required to reschedule, to copy a new manage link, and to mark a meeting attended or no-show.
• scheduler.delete — required to cancel a booking.
• The Reschedule and Cancel buttons are hidden if the booking is in the Past tab or your role doesn't have the matching permission. A view-only seat still sees the list and the empty states, without the actions.