Skip to content
עברית

Booking rules, approvals, calendar invitations and reminders

Use booking rules to set limits and decide who can approve exceptions. Configure calendar invitations and chat reminders separately, with defaults for your business and overrides for each meeting type.

Booking rules decide which appointments can go ahead automatically and which need staff approval. Invitations add the customer to a calendar event. Reminders are separate messages sent before an appointment or a group-class session. Turning one on does not turn the others on.

Open Settings → Bot → Handbook → Our policies → Booking for booking limits and exception approvers. A calendar manager who cannot edit that Handbook control keeps the booking-rule controls on Settings → Integrations → Google Calendar → Technical setup instead; each control keeps its existing permission.

Open Meetings → Appointment messages for the business-wide invitation and reminder defaults, lead time, reminder wording and effective settings for each meeting type. Open Meetings → ⋮ → Booking health to check availability, or Meetings → ⋮ → Archived appointment types to restore an archived type. Calendar bindings are on Technical setup. If your role cannot open Meetings, that page also contains Appointment messages, Booking health and Archived appointment types.

Meeting-type overrides stay with the saved type’s details: Meetings viewers can read them without integration access, including paused types, while existing calendar permissions govern edits. Open Appointments in What [assistant name] does when… for Who is this for and its Required verification. Exception approvers remain under Booking; enablement and invocation guidance keep their existing owners.

  1. Connect Google Calendar and set up availability.
  2. Create your meeting types. For recurring sessions and places, see group classes.
  3. Open Booking in the Handbook, or the controls available to you on Technical setup as described above.
  4. Choose Show advanced options to see customer caps, exception guidance and approvers.
  5. Change the fields you need using the settings below.
  6. Check the save status at the top of the page before leaving. These settings save automatically.

Calendar invitations and chat reminders are configured in Appointment messages, or on Technical setup when Meetings is unavailable; the Handbook’s Booking editor changes booking rules, not those messages. Editing in the Handbook also requires Handbook editing permission.

You need permission to manage integrations to change booking rules and workspace communication defaults. Changing the approval group needs permission to edit bot settings. If a control is read-only, ask your workspace owner to check your permissions.

Booking horizon: automatic, approval and maximum

Section titled “Booking horizon: automatic, approval and maximum”

Booking horizon and approval boundary has two boundaries, measured in days ahead using the business’s local date:

  • Auto up to is the automatic booking horizon. The initial value follows the maximum: 30 days. It can be 0, but cannot exceed the maximum.
  • Maximum is initially 30 days and must be at least 1 day. Use Show advanced options to edit both boundaries together. The simple view edits only Auto up to.
  • Between the automatic boundary and the maximum, booking needs approval.
  • Beyond the maximum, the selected Who may approve exceptions group can approve a policy exception. The maximum is therefore not an absolute ban while exceptions are available.

For example, with Auto up to = 7 and Maximum = 30, a compliant appointment five days ahead can be booked automatically. One 14 days ahead needs approval. A requested time 40 days ahead is outside the normal range and needs an exception from the selected approvers. Every time must still pass the other booking checks.

0 removes the automatic future-day range; it does not turn off appointments or replace the other rules. Same-day appointments are at day zero and still have to satisfy notice and the other checks. With No one — exceptions off, a proposal needing an exception is refused rather than sent for approval.

Setting What it controls Initial value and allowed values
Minimum booking notice How long before the start a new appointment must be booked without an exception. For example, two hours’ notice prevents an ordinary booking for 30 minutes from now. 120 minutes / 2 hours. Zero or more minutes; the editor offers minutes or hours. 0 removes this notice requirement.
Notice required to change or cancel without approval How close to the existing appointment a cancellation or move needs approval. It is not a cancellation fee. 24 hours. Zero or more; the editor displays hours. 0 removes this late-change approval window.
Open appointments per customer How many upcoming appointments a customer may hold at once. This is different from the rolling limit below. 3. A whole number of at least 1; zero does not mean unlimited. Shown in advanced options.
Rolling booking limit → Appointments / Rolling days The maximum appointments in any rolling period of the chosen length, across all meeting types and calendars. It checks appointment start times, not the dates customers sent their booking requests. Group-class places also contribute to the shared customer caps. Unlimited initially. Set both to positive whole numbers, or leave both blank or both at 0 for unlimited. Shown in advanced options.

A rolling limit of 2 appointments / 7 days is not “two per calendar week”. It checks any seven-day span containing the proposed appointment. Appointments on either side of that proposed date can matter. Cancelled appointments do not count toward this rolling limit.

Fill in both rolling-limit fields before leaving that pair of fields. A half-filled pair is not saved as a new limit.

In advanced options, When to ask the team for an exception controls how readily a policy exception is requested. It does not approve anything itself.

Option Meaning
Default (use your judgment) The starting choice. Uses the built-in Use your judgment guidance.
Never ask for an exception Follow the rules and offer compliant alternatives instead of requesting an exception.
Use your judgment Request an exception for a genuine need when no compliant option fits, not just a preference.
Ask readily Request an exception when a booking rule is the only thing blocking the time the customer asked for.

Custom exception-request guidance starts blank. Nonblank text replaces the selected preset’s guidance; it is not an extra instruction layered on top. The limit is 2,000 characters. Clear it to return to the preset. These instructions cannot make unavailable facts or technical failures approvable.

Who can approve, and what exceptions off means

Section titled “Who can approve, and what exceptions off means”

Who may approve exceptions starts at Entire organization. The picker can narrow approval to an available role, person, team group or people with a selected permission.

  • Entire organization: approval can be given through the team channel.
  • A narrower selection: an eligible person must confirm in the app. A message from just anyone in the team channel is not enough.
  • No one — exceptions off: confirm Turn off exceptions to make the booking rules hard limits. Exception guidance is then disabled. This also stops an exception that was already approved but has not yet completed, and disables staff overrides through the channel. A compliant alternative is needed.

Never ask for an exception and No one — exceptions off are different. The first controls requests; the second removes the authority to make an exception at all.

Advanced options also include Staff who never take a class place. This starts empty and accepts up to 100 email addresses. Use it for staff already on class events who have no workspace login, such as a freelance instructor. Workspace members and standing invitees already count as staff and do not need listing.

This list does not invite anyone. It prevents those attendees from consuming class places. Do not put an attending customer here: that could make an occupied place look free. An address outside the workspace requires confirmation; review the warning before choosing Add anyway. See class capacity and staff.

Appointments capability and identity verification

Section titled “Appointments capability and identity verification”

Appointments is enabled by default. Its switch controls appointment and class actions together; it is not the reminder switch. The actions have different prerequisites:

  • New individual bookings, individual availability checks and moves need an active individual meeting type offered on an active calendar.
  • To offer group classes, an active calendar must offer an active group meeting type. A business offering only group classes does not need an individual meeting type.
  • Reading or cancelling existing appointments can remain available without an active meeting type, provided the connection works and the appointment’s calendar is active.

All of these actions need a working Google Calendar connection.

Instructions replace the default conversational instructions when customized. The built-in instructions favor a few concrete options, let the customer suggest another time, and call for confirmation of the meeting type, exact time and calendar when there is a choice. Resetting returns to the built-in text. Instructions do not override approval rules or missing calendar access.

The advanced verification controls are:

Setting Options and default
Required verification Default (Identity verified) initially. Identity verified requires proof of the customer’s identity; Resource verified is the lower, resource-specific proof level, not general identity proof; proof tied only to an unrelated order does not establish appointment ownership; No verification removes this capability’s identity-proof requirement. It does not remove ownership checks or the verified-email rule for invitations.
Proof recency Default (Any time) initially. Any time accepts qualifying past proof. This conversation requires proof in the current conversation. Within a set time uses a positive number of minutes; once proof is too old, a fresh code can be needed, including for WhatsApp customers.
When verification applies Automatic (At the action) initially for appointments. At the action keeps the appointment briefing available before verification; the action checks proof. From the start hides that briefing until the requirement is met.
Who may approve The same appointment exception approval group described above, not a second independent group.

With the defaults, browsing open times does not require an identity code first. Verification applies when booking or accessing the customer’s own appointments, including moves and cancellations. See User identification for the difference between proving contact details and matching an account in your business.

Goal-driven posture starts at Inherit — follows your Motivation setting. It controls pursuit of the objective in the bot’s Motivation, not approval authority: Reactive responds to explicit requests; Opportunistic uses natural openings; Proactive actively steers toward the objective; Persistent keeps pursuing it and may feel pushy. It has no effect without a Motivation and does not override a complaint or an explicit customer request.

Workspace invitation and reminder defaults

Section titled “Workspace invitation and reminder defaults”

Open Appointment messages in the location above and find Appointment communications.

Setting Meaning Initial value
Calendar invitations Permits customer calendar invitations for meeting types that inherit this setting. An invitation needs the customer’s verified email address. On.
Appointment reminders Enables one scheduled reminder before appointments and classes that inherit this setting. It is separate from a calendar invitation. On.
Reminder lead time (minutes) How far before the start a reminder becomes due. Must be a whole number greater than zero. 1,440 minutes: one local calendar day before.

An email typed into a chat or stored as an unverified profile detail is not enough for a customer invitation. Where verification is needed to book and no verified email exists, the appointment flow favors email verification so the same address can be used for the invitation. A verified phone does not become a verified email.

Override communications for a meeting type

Section titled “Override communications for a meeting type”
  1. Open the relevant saved meeting type from Meetings, or from Technical setup when Meetings is unavailable.
  2. If you use Technical setup, enable Show advanced options there.
  3. Review that type’s invitation and reminder controls.

The Meetings drawer shows the meeting type’s communication overrides with its details. Technical setup uses its own advanced-options control to reveal the invitation and reminder overrides below, as well as Reminder copy override. Opening those details does not change the workspace defaults.

  • Invite customers to this meeting type’s calendar events: choose Inherit (on) or Inherit (off), On, or Off.
  • Send reminders for this meeting type: the same three choices apply.
  • Reminder lead time (minutes): enter a positive whole number to override the workspace value. Clear it, or choose Inherit (… minutes), to use the workspace value again.

New meeting types inherit these values. An explicit On or Off stays an override when the workspace default changes. For example, turning workspace reminders off does not stop a type explicitly set to On. To stop every type, check the effective-policy table as well.

In Appointment messages, Default reminder copy sets business-wide text. In a meeting type, Reminder copy override replaces it for that type. English and Hebrew have separate editors; neither starts with a custom override.

The message uses the customer’s recorded language, then the business’s customer language, then English. For that language, text is chosen in this order:

  1. The meeting type’s custom text in that language.
  2. The workspace’s custom text in that language.
  3. The built-in reminder text.

Custom English text is not reused as a Hebrew override, or vice versa. If your business’s stored customer language is another supported language, its built-in text can appear as an additional read-only preview; it is not another custom-text editor.

Variable Replaced with
%{service} The meeting type’s name.
%{when} Appointment date and time in the business time zone, displayed as day/month and hours:minutes.

For example: Reminder: %{service} on %{when}. Use the variable buttons to insert them. These are the only supported variables. To display a literal percent sign, enter %%.

Use Reset to default rather than saving an empty reminder. Reset removes only that language’s override at the level you are editing. Resetting a meeting-type text restores its workspace text if present, otherwise the built-in text. Resetting workspace text does not erase meeting-type overrides. Check the save status after editing.

In Appointment messages, Effective policy by meeting type shows the final Invitations, Reminders and Lead for each type, and whether each is inherited or overridden. Copy source lists English and Hebrew separately: per-type, org default, or scaffold. “Scaffold” means the built-in text, not a missing reminder.

Click an editable meeting-type name to open its settings. Archived types are marked Archived. This table explains configuration; it is not a delivery receipt.

A requested time breaks a rule or is already occupied

Section titled “A requested time breaks a rule or is already occupied”

Policy exceptions can concern notice, the booking horizon, customer caps, opening hours, preparation gaps or a start outside the meeting type’s normal start intervals. A staff-authorized change to one appointment’s duration or preparation time is also different from editing the meeting type for everyone.

A time that is already occupied is not an ordinary rule exception. An occupied time can proceed only with explicit staff authorization naming that exact time and with exceptions still enabled. A customer’s statement that “the team said yes” is not that authorization. A full group class has no over-capacity exception.

Unreadable calendars, unavailable booking counts, missing required customer details and connection failures cannot be approved away. Fix the missing information or access, or choose another time. Approval is not a promise that a booking has completed; the current rules and availability are checked again when it is carried out.

A calendar invitation fails or does not appear

Section titled “A calendar invitation fails or does not appear”

An invitation failure does not cancel an otherwise successful booking. Enabling invitations does not guarantee that the event appears automatically in the customer’s calendar. Google explains that this depends on the recipient’s settings; the customer may need to reply Yes or Maybe in the invitation email.

Turning invitations off does not remove existing attendees or disable standing staff invitees. People already attached to a moved appointment can still receive Google’s update; that is a correction, not a new invitation.

Reminder minutes cross a local calendar day

Section titled “Reminder minutes cross a local calendar day”

Positive multiples of 1,440 mean local calendar days at the same local clock time. For a 10:00 appointment, 1,440 means 10:00 on the previous local day, even across a daylight-saving change. 2,880 means two local days before.

Any other value means exact elapsed minutes: 60 is one hour; 1,500 is 25 elapsed hours, not “the previous day at the same time”. The business time zone matters. Check calendar and time-zone setup if timing looks wrong.

If the scheduled reminder time has already passed when a new booking or class place is created, no initial reminder is scheduled. For example, booking tomorrow morning after today’s reminder time has passed does not generate an immediate one-day-before reminder. Changing the lead or rescheduling can change the timing of eligible future reminders.

Reminders use the appointment’s linked customer conversation, not a calendar email invitation. On WhatsApp, ordinary reminder text can be used inside the reply window. Outside it, an approved, compatible WhatsApp template for reminders must be assigned for the sending line. WhatsApp’s official policy defines the window as 24 hours from the customer’s latest message.

WhatsApp delivery shows Ready on … of … lines. Warnings distinguish a missing template, a template that is not approved, and incompatible variables. Follow WhatsApp templates to review the assignment. Outside-window reminders are skipped if the required template is not usable. Editing Default reminder copy does not edit the approved WhatsApp template’s wording. See WhatsApp templates and lines.

Other channels still have their own sending restrictions. There is no automatic fallback from a blocked chat reminder to email. A full messaging opt-out can block a proactive WhatsApp reminder; see messaging consent. A human takeover alone does not suppress an appointment reminder.

  • No times: check active meeting types and calendars, opening hours, busy calendars, duration and preparation time. Then check notice, the horizon and customer caps. Approval-required times are not automatically bookable. See availability troubleshooting.
  • No exception request: check both the request preset/custom guidance and the approver group. No one — exceptions off makes the guidance inactive.
  • No invitation: check the type’s effective invitation setting and whether the customer has verified an email. For an invitation already sent, ask the customer to check their invitation email, spam and calendar settings.
  • No reminder: check the type’s effective reminder switch and lead, whether the appointment is still in the future, and the linked conversation’s sending eligibility. Then check WhatsApp readiness and opt-out status. A booked appointment is not proof that a reminder was delivered.
  • An appointment entered directly in Google Calendar: do not assume it has an omotto chat reminder. One-to-one reminders are tied to bookings made through omotto; adding an ordinary event in Google alone does not enroll it.
  • Still failing: contact support with the meeting type, expected local date and time, and the channel. Do not send verification codes or connection secrets.