Booking pages are the configurable booking surfaces prospects and clients land on when they want to schedule a meeting with you. Each page defines its own duration, location, availability, branding, and policies. Most teams set up separate pages for distinct workflows — an introductory call, a product demo, an onboarding session, a support check-in.

A booking page can also require payment before a time is confirmed. See Paid Booking Pages for pricing a page, handing a quote or invoice payer a link once they pay, and what a refund or a dispute does to a link that has not been used yet.

The booking-page editor has a rail of six sections — Basics, Availability, Timing, Limits, Team, and Booking form. Each one holds a single Advanced disclosure that starts closed. A control sits outside that disclosure only if a first-time user has to decide it to share a working link, so Basics shows the title, duration and location, and Availability shows where the hours come from, the weekly grid, and date-specific hours. Everything else — description, who can book the page, time zone, page URL, start-time spacing, buffers, caps, hosts, intake questions, follow-up email settings — is one click away under Advanced.

Every time a booker loads your booking page or picks a date, the scheduler evaluates your availability against three sources of busy time for the host user, all in the booking page's timezone:

• Existing bookings on any of your booking pages (so two booking pages can't double-book the same slot).
• Synced calendar events imported from your connected Google or Microsoft calendar (so external events block your scheduler).
• CRM activities on your calendar — meetings, calls, and any activity with a start/end time.

A slot only appears if the entire duration plus any buffer is free across all three sources. The database also prevents two bookers from grabbing the same slot at the same instant — whichever request completes first wins, and the other sees a “just booked” message and is prompted to pick another time.

Each booking page can be set to active or inactive. Use Disable in the page list (or Pause in the calendar's Booking pages rail) to switch one off, and Enable / Resume to switch it back on. All configuration and booking history is kept.

A paused page is not silently broken for someone holding the link. Its URL still renders, and it says so plainly: “This page is not accepting bookings right now.” No times are offered and no booking can be made while it is paused. Copy and Preview are hidden for a paused page in the calendar rail, because there is nothing bookable to send anyone to.

Two related states have their own sentences rather than a wall, so a booker who arrives outside the window knows what to do: before a fixed range opens the page shows “Bookings open on” with the date, and after it ends, “Scheduling ended on” with the date. A URL that names no real page — or a page that is set to Private link and reached without its secret link — gets one neutral sentence instead, “This booking page is not available.”, with nothing echoed back.

Deleting a booking page removes it and its booking history permanently, and its booking link stops working. If the page still has confirmed upcoming bookings, the delete is refused rather than quietly cancelling them.

• From the calendar's Booking pages rail, the refusal becomes a second, explicit question that names the number: “Cancel upcoming bookings?”, with a Delete and cancel button. Only that second confirmation cancels them, so one click can never do it.
• From the Scheduler page list, the delete simply does not go through while those bookings exist. Cancel or reschedule them first, or delete the page from the calendar rail if you intend to cancel them.
• Deactivating instead of deleting keeps every booking and every record intact.

Booking pages start on Pro: 2 on Pro, 3 on Business, and unlimited on Ultra. Creating one past your cap is refused with a message naming the limit. Deactivating a page does not free a slot — delete one, or move up a plan. Nothing else in this article is gated by plan; who can be booked is decided by roles.

Every booking link has the shape /b/[workspace]/[page] — your workspace booking URL first, then this page's own URL. A page URL of demo in a workspace called acme gives you /b/acme/demo instead of /b/acme/30-minute-product-demo.

The page URL lives under Advanced in the Basics section, labelled Page URL. It is generated from the title until you edit it, and it is checked as you type — Available, Already used by another page in your workspace, This word is reserved, or At least 3 characters.

Settings > Company > Scheduler holds the Workspace booking URL: “The first part of the web address of every booking page in your workspace.” It is shared by every page, so changing it changes all of their links at once. Only an admin with full scheduler access can change it; everyone else sees it as read-only text. Opening the page at all needs permission to see booking pages — a seat without it is returned to your home page rather than shown the workspace's scheduler settings.

Because of that blast radius, the change asks for confirmation and tells you exactly what breaks. Like a page URL, there is no redirect:

• Every booking link you have already shared stops working, and the confirmation names how many pages are affected.
• “Emails you have already sent point at the old address and will land on a not found page.” Outreach mail that is mid-send can carry the old address too.
• “Manage links in past confirmation emails point at the old address as well, so they stop working.” That is the cancel-and-reschedule link in every confirmation email you have sent.
• The bookings themselves are untouched. The recovery for any one of them is Copy new manage link in the Bookings tab, which mints a fresh link you can send the booker.

Under Advanced in the Basics section, Who can book this page offers three tiers:

On the Private link tier you generate the secret links yourself with + Generate link. A new link stays on screen for the rest of your editing session, with the note “Copy this now. Once you close this editor, it cannot be shown again.” — once the editor closes, only a short masked prefix is stored, so there is no way to reveal it again. Tick Single use before generating and that link stops working after its first booking. You can hold up to 10 private links on one page; revoking one frees a slot, and a used single-use link still counts until you revoke it.

Beyond name, email, phone, and notes, you can add up to 30 custom questionsper booking page. Question types: text, textarea, email, phone, number, date, single-select, multi-select, and checkbox. Mark any question as Required and the booker can't confirm without answering it. Responses are stored on the booking, surfaced in the host email, and rendered inline on the Bookings drawer for quick context before the call.

Toggle Allow recurring bookings on a booking page and add one or more allowed recurrence rules (RFC 5545 RRULE subset: FREQ=DAILY|WEEKLY|MONTHLY,COUNT, INTERVAL). The booker can pick a base slot and one of the allowed rules; the system expands the rule to N occurrences and books them all in a single atomic transaction. If any one occurrence fails the slot check (e.g., a future Tuesday is blocked by another booking), every previously-inserted occurrence is rolled back so the series is all-or-nothing.

• Each series gets its own series management token so the booker can cancel the entire series in one click.
• Per-occurrence management tokens still work — cancelling one occurrence leaves the rest of the series intact.
• Recurring is supported only on Individual strategy in v1 (multi-host recurring is a v2 candidate).

Three workspace-wide settings decide what a booker sees before they ever read the meeting details. They live together under Settings → Company → Scheduler, in a Branding group with an Email preview row beneath them that shows how the top of a booking email will look once they are set. It makes the same decisions the real send makes — which logo survives, and what color the button label ends up — so it is a preview rather than an impression.

With Pre-meeting briefing enabled (default on), the host receives a notification 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. Toggle it off if you don't want the noise. Briefings are dispatched by a background cron that runs every 5 minutes; bookings created with less than 60 minutes' notice don't get a briefing because the cron can't catch them in time.

From the booking-page editor, attach one or more resourcesas Required (every booking locks the resource) or Preferred (best-effort). Required resources are intersected into the availability calculation, so the booking page hides any slot where the host is free but the room isn't. See the Resources article for the full lifecycle.

Every successful booking sends two confirmation emails from the CRM, both with an.ics calendar invite attached:

• To the booker — subject “Your meeting with {host} is confirmed”. Includes date/time in the booking page's timezone, duration, location, join link (if available), any notes they submitted, and the host's name. Reply-to is set to the host so replies go directly to them.
• To the host — subject “New booking: {booker} booked {booking page}”. Includes the booker's contact details, any notes, and a link back to the CRM activity for the meeting. Reply-to is set to the booker so replies go directly to them. Only sent if the host user has an email address on file.

The attached .ics follows the iCalendar standard (RFC 5545, METHOD=REQUEST) so Outlook and Apple Mail show Accept/Decline buttons. Both parties' invites share the same event identifier, which means a future cancellation will remove the event from both calendars cleanly.

Public booking pages are open to the internet, so the CRM enforces several caps to prevent abuse without getting in the way of legitimate bookers:

• 5 bookings per hour per IP address — blocks a single source from flooding your calendar.
• 60 bookings per hour per booking page — protects against distributed abuse targeting one host.
• Input caps — booker name 200 characters, email 254 characters, phone 50 characters, notes 1000 characters. Control characters are stripped defensively so names can't break the calendar invite or email headers.
• Database-level overlap prevention — even if two bookers hit the same slot at the exact same instant, only one succeeds. The other sees a 409 message and is prompted to pick another time.

If a booker exceeds a rate limit, they see a friendly “too many attempts” message with a cooldown window. No error is logged on your end — rate-limit hits are transparent to you.

• scheduler.view — required to see booking pages at all, and to open Settings > Company > Scheduler; a seat without it is sent back to your home page instead. A view-only seat reads every page as text: no inputs, no host list, no private links, and no Create button.
• scheduler.create — required to create a booking page.
• scheduler.edit — required to change any setting on a page, including hours, the booking window, hosts, resources, and the page URL.
• scheduler.delete — required to delete a booking page.
• scheduler.admin — required for the organization-wide settings: the workspace booking URL, sender line, calendar event titles, and resources.