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.

A page hosted by one person reads the same way once that person's account is deleted from the workspace: it stops offering times and taking bookings, and a booker sees the paused sentence. Round-robin and collective pages are not paused this way, because their hosts come from the page's team.

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 whose booking URL is your-business gives you /b/your-business/demo instead of /b/your-business/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.” Every booking page sits under it, so changing it changes the address of all of them at once. 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.

Changing it is admin only. You need a workspace owner or admin role on top of full scheduler access; anyone else, including a seat that holds full scheduler access without the role, sees the address as read-only text under the line “Only a workspace admin can change this.” The same rule is enforced on the save, so there is no way around the read-only view.

Because every page moves at once, the change asks for confirmation first. The confirm names the real number of booking pages affected, shows the address before and after, and repeats that shared links keep working. If the count cannot be read the confirm refuses to open and asks you to reload, rather than guessing a number.

Under the booking URL, admins see Previous links: the addresses this workspace used before, each with the date it was replaced and whether it is still working. Three controls sit on each row.

• Shape. Lowercase letters, numbers and hyphens only, with no leading or trailing hyphen, and between 3 and 60 characters. Availability is checked as you type, and a taken address is answered with up to three alternatives you can take with one tap. Nothing is ever renamed for you behind your back.
• Reserved words. A word we use ourselves is refused only when it is the whole address, because on its own it reads as though the page were ours. support alone is refused; your-business-support is fine.
• Our own name. An address that reads as Laureo is reserved for us, including lookalike spellings.
• 5 changes in 30 days. Once your booking URL is set, it can change at most five times in any rolling 30 days. Replacing the temporary link a new workspace starts with does not count, so choosing your first real address is always free.
• 25 past links. A workspace keeps at most 25 previous addresses. At the cap the booking URL cannot change again, and the message says so.

The bookings themselves are untouched by any of this. If one booker has lost their confirmation email, Copy new manage link in the Bookings tab mints a fresh link for that booking, which is a separate thing from the workspace address. The new link is shown under the booking and copied when your browser allows it, and the line above it says which happened; on a touch screen a share button sits beside it. See Bookings.

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).

The workspace-wide settings below decide what a booker sees before they ever read the meeting details. They live together under Settings → Company → Scheduler, in the Branding & defaults section, with two preview rows beneath them that follow your changes before you save: Booking page preview shows how your logo and name sit at the top of a booking page, and Email preview shows how the top of a booking email will look. The email preview makes the same decisions the real send makes, such as 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.

Times in the booker's time zone. The booking page shows every time in the time zone the booker's browser reports, and names it in the time zone control above the calendar, for example Mountain Time (Denver), GMT-6 in summer. If the browser reports no usable time zone, the page uses your booking page's time zone instead. To see another zone, the booker opens that control and searches by region name, abbreviation, city or offset from GMT, such as Mountain, MST, Denver or GMT-6. A zone they pick is remembered in that browser for their next visit, and so is their choice of the 12h or 24h clock. The page they open from the Reschedule or Cancel meeting button in their email shows times in the same zone, including the new times offered for a reschedule; it has no time zone control of its own. When the booker's zone differs from your booking page's, both pages also show a Host time line with the chosen time in your zone.

Changing or cancelling from the email. The Reschedule and Cancel meeting buttons in the booker's emails open the booking's own page, straight at the step the button names, and each button appears only when the booking page allows that change. If the page does not allow cancelling, or its cancellation cutoff has passed by the time the booker clicks, that page says “Cancelling is closed for this meeting” and shows how to reach the host instead of a cancellation form. Rescheduling follows the same rule with its own cutoff. A recurring series follows it too: cancelling the series cancels every upcoming session outside the cutoff and leaves the sessions inside it in place, and the series page states the cutoff for the ones it keeps. If the page does not allow cancelling, the series page says cancellations are closed instead of offering the button.

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

• To the booker: subject “Confirmed: {booking page}, {date and time} {zone}”. Includes the date and time in the time zone the booking page showed the booker (with the time in your zone beside it when the two differ), 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}, {date and time} {zone}”. 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: booking branding (the logo, whether your organization name shows next to it, and the brand color), the sender line, calendar event titles, and resources. Booking branding, the sender line and event titles need it at the All scope, which workspace admins have and an admin can give to another role. The workspace booking URL needs this and a workspace owner or admin role; full scheduler access on its own shows it read-only.