Calendar & Scheduling

Calendar & Scheduling overview

Overview The Conversa Labs Calendar is the native scheduling and calendar module. In one place you create calendars, log events and appointments, connect one or more Google Calendar accounts with two-way sync, and publish a public booking page (Calendly-style) where customers book time themselves while respecting your real availability. The Calendar is wired into the rest of the platform: a booking can open a conversation, create a task with a reminder, link to a CRM deal, generate a Google Meet link, and send a confirmation email with an .ics file. All of it shows up inside the contact's conversation and can be driven by Maestro (AI) and by automations. Prerequisites - An active Conversa Labs account with the Calendar module enabled. It is optional and ships off by default — an administrator must turn it on for the account. - Adequate access (typically an administrator role to set up calendars, integrations and the public page). - For Google sync, a Google account with access to Google Calendar. - For paid bookings (optional), the Payments module enabled on the account. Step by step 1. Ask an administrator to enable the Calendar module for the account. 2. Open the Calendar from the left sidebar. 3. Use Calendar for daily operations and Bookings to review reservations, payments, and linked conversations. 4. Administrators can find Event types, Calendars, Connections, Reports, and Settings under Manage. 5. Create a native calendar (name, color and time zone) or connect Google Calendar. 6. Set your availability and create one or more event types for the public page. 7. Share the public booking link and track appointments in the Calendar. Settings & options - Calendars: native or Google, with time zone, color and assignment to agents, teams or inboxes. - Google connections: several Google accounts per Conversa Labs account, each exposing multiple calendars to mirror. - Event types: public-page templates with duration, buffers, minimum notice, maximum advance and intake questions. - Availability: recurring weekly ranges plus date-specific exceptions. - Booking side-effects: open a conversation, create a task, link to a CRM deal, and send a confirmation with Meet and .ics — each can be turned on or off. - Workspace: use the mini calendar, search, status filters, and calendar list to focus the grid. On mobile, Day/List is prioritized and filters open in a panel. - Events: selecting an event first opens a summary with time, contact, location, attendees, and actions. The full form remains available through Edit event; less common creation fields live under More options. Use cases - Take customer bookings without back-and-forth messages, with always-current availability. - Keep Google Calendar and Conversa Labs in sync without entering the same event twice. - Turn a confirmed appointment into a conversation, a task and a CRM deal automatically. - Send meetings with a Google Meet link and a ready-made .ics invite. Tips, limits & best practices - Start with one calendar and one event type; expand once the team is comfortable. - Keep the time zone correct on every calendar to avoid mismatched times. - In the current version, external sync is with Google Calendar (other providers are planned for a later phase). The generated .ics file works in any calendar app. - The public page is unauthenticated: it shows only free slots, never the details of other bookings. Troubleshooting - I don't see the Calendar in the sidebar: the module may not be enabled for the account or for your role — talk to an administrator. - Times look wrong: check the calendar's time zone — that is what anchors availability. An event type has no time zone of its own; the customer always sees times in their own browser zone. - An event didn't appear in Google (or vice versa): confirm the Google connection is active; sync runs in near real time, with a periodic safety check. See also - Connect Google Calendar (OAuth) and sync - Event types, availability and buffers - Public booking page - Reschedule, cancel, Google Meet and the .ics file

Connect Google Calendar (OAuth) and sync

Overview The Conversa Labs Calendar syncs two ways with Google Calendar: events created on the platform appear in Google, and events created in Google appear on the platform — without duplicating and without looping. The connection is made once through Google authorization (OAuth) and stays permanent — it refreshes itself until you disconnect manually. You can connect several Google accounts to the same Conversa Labs account, and each Google account can expose multiple calendars to mirror. Authorization is shared (you don't need to create your own Google app). Prerequisites - The Calendar module enabled on the account (optional, off by default — ask an administrator). - A role allowed to set up integrations (typically administrator). - A Google account with access to Google Calendar. - When authorizing, grant the requested calendar permissions — sync won't work without them. Step by step 1. Open the Calendar and go to the Google connections / integrations area. 2. Click to connect Google Calendar. You'll be taken to Google's authorization screen. 3. Choose the Google account and authorize access to your calendar. 4. Back on the platform, select which calendars from that account you want to mirror. 5. (Optional) Repeat to connect other Google accounts. 6. Wait for the first sync: existing events start to appear in the Calendar. Settings & options - Multiple connections: each connected Google account appears separately, with its calendars. - Calendar selection: turn on only the calendars you want to mirror. - Assignment: link each calendar (native or Google) to agents, teams or inboxes as needed. - Google Meet, attendees, reminders and recurrence: when created on the platform, they're pushed to Google; when created in Google, they come back to the platform. - Disconnect: the connection stays active and self-refreshing until you disconnect manually, which revokes access at Google and removes the connection. Use cases - Centralize a personal/team Google calendar inside your support operation. - Let public-page bookings respect busy times from Google. - Connect the calendar of more than one person or department to the same Conversa Labs account. Tips, limits & best practices - Sync is near real time (updates arrive quickly), with a periodic safety check so nothing is missed. - Events created by the platform are tagged internally to avoid back-and-forth loops. - In the current version, the supported external provider is Google Calendar. Other providers are planned for a later phase. - Your Google credentials are stored securely on the server and are never shown in the dashboard. Troubleshooting - Authorization failed: run the flow again and confirm you granted the calendar permissions. - Connected, but no events show: confirm you selected at least one calendar to mirror and wait for the first sync. - An event vanished or duplicated: check that the connection is still active; the periodic check reconciles differences automatically. As a last resort, reconnect the account. - Updates stopped arriving: the connection may have been revoked at Google — reconnect it. See also - Calendar & Scheduling overview - Event types, availability and buffers - Public booking page - Reschedule, cancel, Google Meet and the .ics file

Google Calendar sync: import, status and reconnect

Overview After you connect Google Calendar, the Calendar keeps everything in sync both ways. This article covers the monitoring side of that sync: how to import events that already existed in Google, what each sync status means, how to force an update with Sync now, and what to do when the Google access expires and you need to reconnect. The sync is near real-time, with a periodic check that reconciles differences. You don't need to sync manually day to day — the options below are for inspection and one-off cases. Prerequisites - The Calendar module enabled and a Google connection already created (see the connection/OAuth article). - A profile allowed to manage integrations. - At least one Google calendar selected to mirror. Step by step Import existing events: 1. Open the Calendar and go to the Google connection. 2. Select the calendars you want to mirror. 3. Wait for the first sync: events that already existed in Google start showing in the Calendar. Check the status and force an update: 1. On the Google connection, check the sync status (see the table below). 2. To update right away, use Sync now. Reconnect when access expires: 1. If the status shows access expired/revoked, click Reconnect. 2. Redo the Google authorization and grant the calendar permissions. 3. The sync resumes and the periodic check reconciles anything pending. Settings & options - Import existing events: the first sync brings into the Calendar the events already in Google. - Sync status: | Status | What it means | |---|---| | Connected / Synced | Up to date; updates flow both ways. | | Syncing | A sync is in progress (first load or an update). | | Access expired / revoked | Google revoked access — you need to reconnect. | | Error | A temporary failure; the periodic check retries. | - Sync now: forces an immediate update, without waiting for the periodic check. It also unsticks a connection wedged on "Syncing". - Reconnect: redoes the Google authorization when access expires or is revoked. - Last error / recent errors: the panel shows the latest failure Google returned even while the status is still "Syncing", so you never wait on a process that already failed. What happens when you change something directly in Google A change made in Google counts exactly like one made in the platform. When you drag, edit or cancel an appointment in Google Calendar: - The customer is told. A reschedule or a cancellation sends the same notice (WhatsApp/email and the .ics file) as one made from the dashboard — honouring the same notification switches you already configured. If you turned reschedule notices off, they stay off. - Your automations run. Rules and flows triggered by an appointment being created, rescheduled or cancelled now fire for changes coming from Google too. - The screen updates on its own. The agenda grid reflects the change without a page reload. - Reminders for the new time work again. Dragging an appointment to another date in Google reschedules its reminders to the new time. - The reservation follows. Cancelling in Google also closes the matching booking, so the customer's public page stops offering "reschedule" for an appointment that no longer exists. The first import is silent. When you mirror a calendar that already held hundreds of appointments, that initial load does not fire notices, automations or notifications — it only brings across what was already there. Only changes from then on are announced. Importing an appointment is never a booking confirmation. The platform never sends "your appointment is confirmed" to someone just because the appointment showed up in Google. Google integration per event type Each event type decides independently how it talks to Google. The setting lives in the event-type editor, under Google integration: - Block times already busy on these calendars: tick as many calendars as you like. No time already taken on any of them is offered on the public page. This is how you avoid being booked over a personal appointment that lives on a different calendar. - Create events on: pick one Google calendar to receive confirmed bookings. That is where the invite and the Meet link are created. If you configure nothing, behaviour is exactly what it was before: the type uses its own calendar and only talks to Google when that calendar is mirrored. Use cases - Bring the calendar that already existed in Google into the Calendar, without retyping events. - Quickly check the connection is up to date before a busy day. - Force Sync now after changing several events in Google. - Restore the sync with Reconnect after the Google password/permission changed. Tips, limits & best practices - Day to day you don't need to sync manually — the sync is automatic and near real-time. - Use Sync now only for inspection or after big changes in Google. - If the status stays on access expired, reconnect as soon as possible so you don't miss updates. - Select only the calendars you actually want to mirror — less noise in the Calendar. - Events created by the platform are internally marked to avoid loops back and forth. - Editing an appointment in the platform no longer changes what you configured only in Google: events marked "Free", the visibility (private/confidential) and the guest permissions are preserved. Troubleshooting - I connected, but the old events didn't come in: confirm you selected at least one calendar to mirror and wait for the first sync; use Sync now to force it. - I stopped getting updates: access may have expired/been revoked in Google — use Reconnect. - An event disappeared or duplicated: the periodic check reconciles differences; if it persists, use Sync now and, as a last resort, reconnect the account. - The status stays on "Syncing" for a long time: the first load of a large calendar takes a few minutes, but no longer than that. If it stays on "Syncing", don't just wait — open the connection panel and read the last error and the recent error count, which are now shown even while the status is still "Syncing". Use Sync now: it unsticks a wedged state and restarts the load. If the error persists, reconnect the account. - The status stays on "Error": the panel shows the message Google returned. An access error (expired/revoked) can only be cleared by Reconnect. - It stops syncing on its own after a few days: if the Google OAuth app is still in Testing mode (unverified), Google revokes access every 7 days — the connection will break weekly until the app is verified in Google Cloud. You get an e-mail when it happens; the permanent fix is to publish/verify the app. - Events marked "Free" in Google: they show up in the agenda but do not block slots on your booking page — the same behaviour as Google itself. - Recurring events: each occurrence is imported individually, so the series shows on every date, not just the first one. See also - Connect Google Calendar (OAuth) and sync - Delete or cancel an event: which to use - Reschedule, cancel, Google Meet and the .ics file - Calendar & Scheduling overview

Event types, availability and buffers

Overview An event type is the template that appears on your public booking page — for example "30-min meeting" or "1-hour demo". Each event type defines the duration, the rules for when it can be booked, and what happens when someone books. Availability defines the time ranges in which you accept appointments, and buffers guarantee breathing room between one booking and the next. The times offered to a customer are always the intersection of three things: your availability, your already-busy times (native and Google), and the configured buffers. That way the public page never offers a slot that conflicts with something already booked. Prerequisites - The Calendar module enabled and at least one calendar created or connected. - A role allowed to configure event types and availability. - (Optional, for distributing across several agents) the agents who will receive the bookings. Step by step 1. In the Calendar, open the event types area and create a new one. 2. Set the name, duration and location (in person, a link, or automatic Google Meet). 3. (Optional) Right below location, tick Let the customer choose the location and select two or more options (Google Meet, phone, in person or custom). 4. Adjust the time rules: minimum notice, maximum advance, and the buffers before and after. 5. Set your availability: the weekly time ranges in which you accept appointments. 6. Add exceptions for specific dates (holidays, days off or extra hours). 7. (Optional) Add intake questions the customer answers when booking. 8. (Optional) Set the assigned agents and how bookings are distributed among them. 9. Save and use the generated link on the public booking page. Settings & options - Scheduling limits (buffers, notices and horizon): each one can be left empty, in which case it follows the account default (the hint inside the field shows which number that is), or carry a number — including 0 — which then applies to this type only. Use Use the account default, right under the field, to inherit again. Details in Account scheduling defaults and inheritance. - Minimum cancellation notice: how much warning the customer needs to still cancel — the same window applies to rescheduling. - Reschedule limit: how many times one booking may be moved. Empty = no limit. - Auto no-show after: minutes past the start at which an unattended appointment is marked as a no-show. Empty = never automatically. - Duration: how long each appointment of this type lasts. - What one booking takes off the calendar: only the chosen time (default) or the whole shift — for businesses that sell a shift rather than a slot. See Shift occupancy. - Buffers: an automatic gap before and after each booking. - Minimum notice: how much lead time is required before the slot. - Maximum advance: how many days into the future a slot can be booked. - Location / Google Meet: in person, a manual link, or automatic Meet link generation. - Let the customer choose the location: sits right below the Location field in the event type editor. Tick two or more options (Google Meet, phone, in person or custom) so the public page shows the picker to whoever is booking. With none or only one option ticked nothing changes: the fixed Location set above applies. When the customer picks Google Meet, the video-call link is generated automatically — that requires an active Google connection. - Distribution across agents, when there is more than one host: - Round-robin: each booking goes to the host who has been free the longest. This is the default. - Collective: every selected host attends the same appointment and gets the invite. - Fixed: always the first host on the list. Use it when the event type belongs to one person. - Intake questions: custom fields answered at booking time. - Per-type side-effects: turn on or off, per event type, the creation of a conversation, a task, a CRM-deal link, and the sending of the confirmation. Use cases - Offer "30-min meeting" and "1-hour demo" with different rules. - Block last-minute bookings with a minimum notice (for example, 2 hours). - Guarantee 10 minutes of breathing room between meetings using buffers. - Open extra hours on a specific date without touching weekly availability. Tips, limits & best practices - Use minimum notice so you aren't caught off guard by instant bookings. - Use buffers for travel, notes or a break between sessions. - Keep availability lean and use exceptions for one-off cases. - When you let the customer choose the location, only tick the options you can genuinely honour — all of them show up on the public page. If you offer Google Meet, keep the Google connection active so the link gets generated. - Always check the time zone — it directly affects the slots offered to the customer. - For agent distribution, make sure each host has their own availability and calendar so round-robin works well. Troubleshooting - No free slots appear: check availability, the notice rules, and whether many times are already busy — buffers also reduce the options. - Slots I didn't want appear: review the availability ranges and the date exceptions. - The Meet link wasn't generated: confirm the event type has automatic Google Meet and that there's an active Google connection. - The customer can't choose the location: the picker only appears with two or more options ticked under Let the customer choose the location — with none or one, the fixed location applies. - Times are off: check the calendar's time zone — an event type has no time-zone field of its own; it uses the one on the calendar it belongs to. See also - Calendar & Scheduling overview - Connect Google Calendar (OAuth) and sync - Public booking page - Reschedule, cancel, Google Meet and the .ics file

Prevent overlapping appointments

Overview Prevent overlapping appointments makes the platform refuse to create or reschedule an appointment when it overlaps another one on the same calendar. Until this setting existed, the module's only conflict check lived in the public booking page — which has always offered free slots only. The direct path (the dashboard, the API and the bot's calendar tools) had no check at all: nothing stopped two appointments at 08:00 and 08:30 on the same calendar. It is optional and ships off. For a good reason: in many operations several attendants share one calendar and book at the same time on purpose. Turning it on by default would break those accounts. Turn it on only where overlapping really is a mistake. Prerequisites - The Calendar module enabled on the account. - Administrator permission to change the Calendar settings and the calendars themselves. - At least one calendar created. Step by step Set the account default 1. Open Calendar and go to Settings. 2. Under Scheduling defaults, turn on Prevent overlapping appointments. 3. Save. From then on, every calendar that has no decision of its own follows that default. Set a per-calendar exception 1. Open the Calendar's calendar list and edit the calendar you want. 2. In the Overlapping appointments field, pick one of three options: - Use the Agenda default — inherits the account setting (this is how every calendar starts); - Block overlaps — always prevents them, even with the account default off; - Allow overlaps — always permits them, even with the account default on. 3. Save. Settings & options How the decision is resolved The rule is read top-down, and the first explicit decision wins: calendar setting → Calendar default (account) → off A calendar on Use the Agenda default simply follows the account — and goes back to following it if you change the default later. Exactly what gets blocked | Path | Behavior with the setting on | |---|---| | Creating an appointment from the dashboard, the API or a bot tool | fails if there is an overlap on the same calendar | | Rescheduling (changing the date/time) | fails if the new time overlaps another appointment | | Editing an appointment without touching the time | not checked — the check only runs when the date/time changes | | Booking from the public page | unchanged: that page has always had its own conflict check and only offers free slots | The comparison is always within the same calendar. Two different calendars never conflict with each other, even if they belong to the same attendant. What counts as busy Not every appointment blocks a slot. These are left out of the check: - cancelled appointments — a cancellation gives the slot back; - appointments marked Free (transparent, in Google Calendar's vocabulary) — they show up in the grid but do not occupy the host. It is the same definition of "busy" the public booking page already used, on purpose: both sides of the module agree on what a taken slot is. An appointment marked Free is also not blocked when rescheduled — it never occupied anything. What the user sees When the setting is on and there is a clash, the operation fails with a message that names the conflicting appointment: This time overlaps the appointment "Client meeting" on the same calendar. Choose another time. Nothing is half-saved: the appointment is simply not created (or not rescheduled). Use cases - A single-person calendar (a clinic, a lawyer, a consultant): turning it on in the account default prevents the classic double booking. - A team with one calendar per attendant: turning it on in the account default protects everyone, since each calendar belongs to one person. - A deliberately shared calendar (a room, a class, an on-call shift with several attendants): leave that calendar on Allow overlaps, even with the account default on. - A calendar operated by the bot: with the setting on, the bot cannot book over a taken slot — the tool fails and it has to offer another time. - Migrating a calendar: leave it off while importing old appointments; turn it on once the data is tidy. Tips, limits & best practices - Turning it on does not fix what already exists. The setting applies to what is created or rescheduled from now on. Overlaps already saved stay there — review them by hand. - It is per calendar, not per attendant. If the same person works out of two calendars, one appointment on each is not treated as a conflict. - Appointments coming from Google arrive through the sync and start counting as busy (if they are active and not marked Free) — but the sync itself is not refused; the setting acts on the direct path. - The public page never depended on this setting. It avoided conflicts before and still does after — including with the setting off. - Mark as Free whatever genuinely does not occupy the host (a personal reminder, an informational block). That keeps the check useful instead of noisy. - If the team complains that they "can't save", the first place to look is the calendar's setting, not the account's: an exception on Block overlaps beats an account default that is off. Troubleshooting - "I can't save an appointment": there is an overlap on the same calendar. The message names the conflicting appointment — open it, confirm whether it is still valid and choose another time, or cancel the old one. - "I turned it off in Calendar settings and it still blocks": that calendar has its own exception on Block overlaps. Switch it to Use the Agenda default or Allow overlaps. - "I turned it on and it still lets me double-book": either that calendar is on Allow overlaps, or the existing appointment is cancelled or marked Free — neither occupies a slot. Also check that both appointments really are on the same calendar. - "I edited the title and got an overlap error": the check only runs when the date/time changes. If you got the error, the time was changed too — check the start and end fields. - "The bot said it couldn't book": with the setting on, that is the expected behavior on a taken slot. Ask the contact for another time, or free the slot on the calendar. - "Two attendants need the same slot": use one calendar per attendant, or leave that calendar on Allow overlaps. See also - Event types, availability and buffers - Cascading availability - Public booking page - Reschedule, cancel, Meet and .ics - Calendar overview

Shift occupancy: one booking reserves the whole morning or afternoon

Overview Some services are not sold by the hour, they are sold by the shift. An upholstery-cleaning crew that arrives at 10:30 is not free again at 11:30: they take the whole morning. The customer still needs to pick an arrival time, but the rest of that shift has to leave the calendar the moment they book. That is what the "The whole shift" option does. It lives on the event type, under What one booking takes off the calendar: - Only the chosen time (default): the appointment plus its buffers. This is how Agenda has always worked, and nothing changes for event types that already exist. - The whole shift: booking any time reserves the entire availability range it falls in. Book 10:30 inside 08:00–12:00 and the whole morning disappears from the public page — only the afternoon shift stays for sale. The shift IS the availability range. There is no separate "shift" field: Agenda uses the ranges you already configure under Availability. A day with two shifts is a day with two ranges separated by a gap. Prerequisites - Agenda module enabled and an event type created. - The day's availability split into separate ranges — that is what defines the shifts. - A role allowed to edit event types. Step by step 1. Open Availability (on the calendar or on the event type itself) and split each day into the shifts you work. The classic shape: - 08:00 – 12:00 (morning) - 14:00 – 18:00 (afternoon) Use Add time range to create the second one. Leave a gap between them. 2. Save the availability. 3. Open the event type and, under What one booking takes off the calendar, choose The whole shift. 4. Set the duration to the real length of the service (that is what the customer sees, and what reaches Google and the .ics file) and the slot interval to how often you want to offer arrivals: every 30 minutes, every hour… 5. Save and test on the public page: pick a morning time and confirm the whole morning is gone, with only the afternoon left. Settings & options - What one booking takes off the calendar: Only the chosen time or The whole shift. - Duration: the real length of the service. It does not have to match the shift — the customer sees this duration, and it is what lands on their calendar. - Slot interval (under Agenda settings → Scheduling defaults): how often arrivals are offered inside the shift. - Buffers: with shift occupancy they protect the edges of the shift — the buffer before pushes its start, the buffer after extends its end. - Availability: each day's ranges. They are what define the shifts. Use cases - Upholstery cleaning: arrival between 08:00 and 10:00, but the crew stays all morning. - Removals and freight: one job per shift, two a day. - On-site technical installation: the customer picks "morning" and the technician sets the route order. - Renting a space by period: morning, afternoon, or both. Tips, limits & best practices - Leave a gap between shifts. Two ranges that touch (12:00–14:00 right after 08:00–12:00) are merged into one 08:00–14:00 range, and then a booking takes both. The lunch break is not just a pause: it is what separates one shift from the next. - A shift that runs past midnight works. A range cannot cross midnight, so a 22:00–02:00 shift is written across two days: Monday 22:00–24:00 and Tuesday 00:00–02:00. Because they touch at midnight they count as one shift — a 23:00 booking takes the small hours with it, and a customer can pick a start whose appointment ends after midnight. - A day with a single range is one shift. If the day is only 08:00–18:00, one booking takes the whole day. That may be exactly what you want (one job a day) — it just has to be deliberate. - Any appointment inside the shift kills it, not only bookings from the public page: an event created directly in the agenda or imported from Google at 09:00 also takes the morning off sale. - Rescheduling inside the same shift is allowed — the shift is already the customer's, so moving from 10:30 to 11:00 works normally. - On the dashboard grid the booking shows at its real time, with the reserved shift drawn as a faded band behind it. It is not a second appointment: it is the same booking, rendered. - On Google: the technician gets the appointment at its real time (10:30–11:30), not the whole shift. The shift reservation lives in Conversa Labs Agenda — anyone booking straight into Google needs to check Agenda too. Troubleshooting - I booked one time and the whole day disappeared: the day probably has a single range, or two ranges that touch. Open Availability and separate the shifts with a gap. - The afternoon went away with the morning: the two ranges are back to back (e.g. 08:00–12:00 and 12:00–18:00) and were merged. Leave a real gap between them. - The page offers no times at all: the duration may be longer than the shift. A 4-hour service does not fit in a 3-hour range. - Only one time per shift shows up: raise the slot interval — it is what decides how many arrivals are offered inside the shift. - The customer says their appointment is wrong on their calendar: it is not. Their invite is the real time they picked; the whole-shift reservation is internal, which is why it is not in the invite. See also - Event types, availability and buffers - Account scheduling defaults and inheritance - Cascading availability: account, calendar and event type - Prevent overlapping appointments

Cascading availability: account, calendar and event type

Overview Availability in the Calendar works as a cascade, across three levels, from the most general to the most specific: 1. Account — the default availability for the whole operation. Set it once here and it applies everywhere. 2. Calendar — can inherit the account default or define its own hours for that calendar/agent. 3. Event type — can inherit what comes from the calendar (or account) or have its own hours for that service only (for example, "Demo" only on Tuesday mornings). Each level inherits from the one above until you decide to override it. That way you don't repeat the same grid everywhere: you adjust the default once and only create exceptions where you truly need them. The times offered to the customer are always the intersection of the effective availability (after the cascade), the busy times, and the buffers. Prerequisites - The Calendar module enabled and at least one calendar created or connected. - A profile allowed to configure availability. - (Optional) An inbox with business hours defined, if you want to copy them. Step by step 1) Set the account default: 1. Open the Calendar settings and go to Availability. 2. Define the default weekly time ranges and the time zone. 3. (Optional) Add holidays and exception dates that apply to the whole account. 2) Refine per calendar: 1. Open the desired calendar. 2. Keep it on Inherit from account or choose Customize and adjust the ranges for that calendar only. 3) Refine per event type: 1. Open the event type. 2. Keep it on Inherit (from the calendar/account) or set its own hours for that service. Copy the inbox's business hours (shortcut): 1. On the availability screen, use Copy business hours from inbox. 2. The inbox's business-hours ranges are brought in as a starting point — adjust as needed. Copying replaces the whole grid. An inbox stores a single range per day, so a day that had two (a morning and an afternoon separated by lunch) comes back with one. If you have already split your shifts, build the ranges by hand instead of copying — or copy first and re-create the gaps after. Settings & options - Inheritance (cascade): each level inherits the one above (account → calendar → event type) until overridden. - Weekly ranges: the recurring intervals per weekday when you accept appointments. - Time zone: set per level; it directly affects the times offered to the customer. - Holidays / exceptions: specific dates that block (or open) times, without touching the weekly grid. - Copy business hours from inbox: imports an inbox's business-hours ranges as the availability baseline. Use cases - Set one hours default for the whole account and not repeat it in every calendar. - A specific agent's calendar with hours different from the default. - A "Demo" event type in reduced hours only, even if the calendar accepts more. - Block a holiday for the whole account at once. - Reuse the business hours already configured on the inbox as a starting point. Tips, limits & best practices - Configure the account default first and only customize where there is a real difference — fewer grids to maintain. - Keep levels on Inherit whenever possible: change the account default and it changes for everyone who inherits. - Check each calendar's time zone; a wrong zone shifts every time offered. (Event types have no time zone of their own — they use the calendar's.) - Use holidays/exceptions instead of deleting ranges from the weekly grid — it's reversible and clearer. - After copying the inbox's business hours, review them: support hours aren't always the same as booking hours. Troubleshooting - I changed the account default and one calendar didn't change: it is probably Customized (not inheriting). Switch it back to Inherit or adjust it directly. - No free times appear: the cascade may have narrowed the effective availability too much; review account, calendar and event type. Review buffers and lead times too: they have their own account default under Agenda settings → Scheduling defaults, and an event type only departs from it when you fill its field in. Leaving the event type's field empty is what makes it follow the account. See Account scheduling defaults and inheritance. - A holiday didn't block: confirm at which level you added it — account holidays apply everywhere; a calendar's, only to it. - The inbox hours didn't come in: the inbox needs defined business hours to be copied. See also - Event types, availability and buffers - Public booking page - Calendar & Scheduling overview - Google Calendar sync: import, status and reconnect

Account scheduling defaults and inheritance

Overview Almost every timing rule in Agenda lives in two places: an account default and, if you want one, a value of its own on each event type. The account default is what applies to everybody; the event type's field only comes into play when you fill it in. The rule is simple and holds for every field on this page: Empty field on the event type = it follows the account default. Filled-in field = that event type has its own rule — including 0. 0 is an answer, not an empty field. Buffer after = 0 means "this type needs no breathing room", and that beats the account default. An empty field means "use whatever the account says" — change the account default tomorrow and this type changes with it. Prerequisites - Agenda module enabled. - A role allowed to open Agenda settings. Step by step 1. In Agenda, open Settings. 2. Go to the Scheduling defaults block. 3. Adjust the fields below — they apply to the whole account. 4. Save. 5. To see inheritance in action, open an event type: each limit field shows, as a hint inside the field, the number it would inherit if left empty. Settings & options - Slot interval: how far apart the offered times are on the public page. It is independent of duration: a 60-minute consultation with a 30-minute interval shows up at 09:00, 09:30, 10:00… This is the field that decides how many options the customer sees. - First day of the week: whether the public calendar (and the availability grid) starts on Sunday, Monday or any other day. It only changes the framing, never the availability. - Buffer before / Buffer after: minutes automatically reserved before and after each appointment. - Minimum notice: how much warning is required for a time to still be bookable. - Maximum advance: how many days into the future the page offers times. - Minimum cancellation notice: how much warning the customer needs to still cancel — or reschedule, which follows the same window. - Prevent overlapping appointments: the overlap guard for appointments created directly in the agenda (not through the public page, which has always had its own check). The five limit fields (buffers, notices and horizon) also exist inside each event type, and that is where inheritance happens. Use cases - Move the slot interval from 15 to 30 minutes for every event type at once. - Give the whole account 10 minutes of breathing room between appointments without touching each type. - Keep a single "Urgent slot" type with minimum notice 0 while everything else follows the account's 2 hours. - Start the week on Monday for an operation that does not work Sundays. Tips, limits & best practices - Leave it empty by default. Typing the same number the account already uses looks harmless, but it freezes that event type: when the account changes, it is left behind. - If a type already carries a number and you want it back on the account default, clear the value or use Use the account default, right under the field. - The slot interval is the field the customer notices most: a short interval means more options on screen; a long one means a tidier day. - The minimum cancellation notice applies to reschedules too. Without that, rescheduling would be an easy way around the cancellation window. Troubleshooting - I changed the account default and one event type didn't change: its field is filled in. Open the type and clear the value (or click Use the account default) to inherit again. - I set 0 and it went back to the account value: it shouldn't — 0 is a valid value and beats the account. If the field came back empty after saving, it was saved empty; type 0 again. - The public page shows fewer times than I expected: raise the slot interval or lower the buffers — every buffer minute also eats options. - The public page shows too many days: lower the maximum advance. See also - Event types, availability and buffers - Cascading availability: account, calendar and event type - Public booking page - Prevent overlapping appointments

Booking through the AI in a conversation

Overview The AI agent can handle scheduling inside the conversation itself: read an event type's free times, send the link for the customer to choose, or book directly the time you agreed on. It uses exactly the same rules as the public page — availability, buffers, notices, the overlap guard and payment — so nothing the AI books escapes your configuration. You decide which of these actions the agent may use; none of them is on by default. Prerequisites - Agenda module enabled, with at least one published event type. - An AI agent configured on the account. - The agenda tools enabled on that agent (they appear in its tool list). Step by step 1. Open the AI agent's configuration and enable the agenda tools you want: list event types, read free times, send booking link, book appointment, reschedule, cancel and list the contact's appointments. 2. Choose the approval mode. Actions that touch the customer's calendar or send a message — book, reschedule, cancel, add a guest and send the link — ask for human approval before running while the agent is in hybrid mode. 3. In the conversation the agent asks for what it needs (day, time of day, customer details) and uses the tools. 4. You approve the action in the conversation; only then does it happen. Settings & options - Read free times: the agent reads an event type's times per date window. It should always ask for one day (or a few days) at a time — the answer is deliberately bounded, so the agent sees the right day instead of a huge, vague list. - Send booking link: posts the public link in the conversation so the customer picks for themselves. It is the safest option while the customer is still deciding. Because it sends a message the customer sees, it goes through approval. - Book appointment: reserves a slot on the customer's behalf, using one of the free times read in the previous step. If the event type is paid, the booking is created as pending payment and the charge starts — the customer still has to pay for it to confirm. - Reschedule / cancel: honour the event type's minimum cancellation notice and reschedule limit, exactly as the customer would on the public page. - List the contact's appointments: shows only the appointments of that conversation's contact. Use cases - The customer asks "anything Thursday afternoon?" and the agent answers with that day's real times. - The customer asks to move an appointment and the agent offers next week's options. - The agent sends the link and lets the customer choose, without occupying an agent. - Before booking, the agent checks whether the contact already has an appointment. Tips, limits & best practices - Ask the agent to confirm the day before reading times. A broad query returns a few times across many days; a one-day query returns that whole day. - Prefer sending the link while the customer has not decided, and booking once the time has been agreed in writing in the conversation. - Keep human approval on for book, reschedule and cancel while you build confidence in the agent: there is a real customer's calendar on the other side. - An archived event type accepts no new bookings, not even from the AI. Troubleshooting - The agent says there are no times: check the event type's availability, buffers and notices — the AI reads the very same times as the public page. - The agent only shows the next few times and never moves to another day: ask for the date explicitly ("September 12th"); the query is windowed, and with no date it only covers the next few days. - The booking did not confirm: if the type is paid, it stays pending payment until the charge is paid. - "Slot unavailable": somebody took the time between the read and the confirm. Read the times again and pick another one. - The action never happened: check whether it is waiting for approval in the conversation. See also - Event types, availability and buffers - Account scheduling defaults and inheritance - Public booking page - Reschedule, cancel, Google Meet and the .ics file

Public booking page

Overview The public booking page is the link you send so customers can book time themselves, with no back-and-forth. It shows only the free slots of the chosen event type — computed from your availability, your busy times (native and Google), and the buffers. The customer picks a slot, answers the intake questions, and confirms. On confirmation, Conversa Labs can automatically open a conversation, create a task with a reminder, link to a CRM deal, and send a confirmation email with a Google Meet link and an .ics file — each side-effect can be turned on or off per event type. Prerequisites - The Calendar module enabled, with at least one event type and availability configured. - For the automatic Meet link, an active Google connection. - For paid bookings (optional), the Payments module enabled — in that case the slot is held and is only confirmed after payment. Step by step 1. In the Calendar, open the event type you want to publish and copy the public link. 2. Share the link with the customer (message, email, website, social bio, etc.). 3. The customer opens the page and picks a date and time from the free options. 4. If the event type offers more than one option, they choose the location of the meeting — for example Google Meet, phone, in person, or a custom location. 5. They fill in their contact details — including the phone number (optional) — and answer the intake questions, if any. 6. (If the event type requires payment) the customer completes the payment to confirm. 7. The customer confirms and receives the email confirmation with the details and the invite. 8. You see the new booking in the Calendar and inside the contact's conversation. Settings & options - Link per event type: each event type has its own link, with its own rules. - Intake questions: custom fields the customer answers when booking. Each question has a type — short text, long text, dropdown, multiple choice, checkboxes, number, email, phone or date — and the public form renders exactly that control (lists and choices use the options you configure). In the editor you can rename, change the type, reorder and delete any question. - Location / Google Meet: in person, a manual link, or an automatically generated Meet link. - Address / location instructions: for in-person, phone or custom locations, fill in the address (or the link/instructions). It goes into the invite, the confirmation message, the .ics file and the Google event. Meet needs none — the link is generated on its own. - Customer picks the location: when the event type offers two or more location options, the page shows a picker to whoever is booking. If the customer picks Google Meet, the video-call link is generated automatically. With a single option, the event type's fixed location applies. - Phone / WhatsApp: a field on the public form. When filled in, the customer also gets the confirmation and reminders over WhatsApp; left blank, everything still arrives by email. You can tick "require phone" on the event type — the booking is then only accepted with a valid number, including for callers hitting the API directly. - The number is always kept: the WhatsApp number typed in is written to the contact even when that contact already exists. If the contact already has a different number, the old one stays as the identity and the new one is recorded on the profile — nothing the customer types is discarded. - Extra guests: enable it to let the customer add other people to the appointment. You set the guest limit; each guest becomes an attendee and receives the Google invite. - Booking side-effects: conversation, task, CRM deal and confirmation email — per event type. - Distribution across agents: round-robin or collective when there's more than one host. - Payment (optional): require payment to confirm, or just hold the slot until payment (depends on the Payments module). Use cases - Put the booking link in your Instagram bio or email signature. - Drop the link mid-conversation on WhatsApp so the customer can book a demo. - Take paid bookings (consultations, mentoring) confirmed only after payment. - Automatically distribute bookings across the agents of a team. Tips, limits & best practices - The page is unauthenticated and safe: it shows only free slots, never the details of other bookings. - Keep intake questions short to reduce drop-off. - The phone number is optional, but worth it: with it the customer gets the confirmation and reminders over WhatsApp, which cuts no-shows. Without it nothing is lost — the email is still sent. - Only offer a location choice with options you can genuinely honour: everything ticked on the event type shows up for the customer. - Check the time zone — the page shows times in the correct zone for the customer. - Every confirmed booking becomes a complete record: use the side-effects (conversation, task, deal) so you don't lose the follow-up. Troubleshooting - The page shows no slots: confirm availability, notice rules and buffers on the event type — there may be no free windows in the period. - The customer didn't get the confirmation: check the email entered and whether the confirmation email is on for that event type. - The booking didn't create a conversation/task/deal: check that those side-effects are enabled on the event type. - Payment didn't confirm the slot: confirm the Payments module is active and the payment was completed — the slot is held until confirmation. See also - Calendar & Scheduling overview - Event types, availability and buffers - Connect Google Calendar (OAuth) and sync - Reschedule, cancel, Google Meet and the .ics file

Booking page branding (logo, color and name)

Overview The Conversa Labs public booking page can carry your brand instead of a generic look. You define three elements the customer sees before picking a time: - Logo — the image that identifies your business at the top of the page. - Color — the brand color applied to the page's buttons and highlights. - Display name — the name the customer sees (of the business, the service or the host). The branding applies to both the booking portal (the page that lists your event types) and a single event type page (the direct link for one specific service). Prerequisites - The Calendar module enabled with at least one event type published. - A profile allowed to configure the Calendar and the public page. - A suitable logo file (a crisp image, preferably with a transparent background). Step by step 1. Open the Calendar settings and go to Branding / Appearance for the public page. 2. Upload your business logo. 3. Choose the brand color (applied to buttons and highlights). 4. Set the display name the customer will see. 5. (Optional) Adjust the branding on a single event type page too, if you want something different from the portal. 6. Save and open the public link to check how it looks to the customer. Settings & options - Logo: image shown at the top of the public page (portal and single type). - Brand color: sets buttons and highlights on the booking page. - Display name: the name shown to the customer (business, service or host). - Scope: booking portal (list of event types) and single event type (direct link for one service). Use cases - Send a booking link that looks like your company, not a generic one. - Use a logo and color consistent with your website and social profiles. - Give a specific service (e.g. "VIP Mentoring") its own display name on the direct link. - Build customer trust by showing a recognizable brand before they book. Tips, limits & best practices - Use a crisp logo, ideally with a transparent background to blend with the page. - Choose a color with good contrast so the buttons stay legible. - Keep the display name short and clear — it's the first thing the customer reads. - After saving, test the public link on a phone and a computer to see the real result. - Branding is appearance only: it does not change availability, rules or booking side-effects. Troubleshooting - The logo doesn't show: confirm the upload finished and the file is a valid image; try a smaller file or another format. - The color didn't change on the page: save again and reload the public link; clear the browser cache if needed. - The display name is wrong: check that you edited the right scope (portal or single event type). - The page still looks generic: confirm the branding was saved for the page you're opening (the portal and a single type are configured separately). See also - Public booking page - Event types, availability and buffers - Payment and deposit on booking - Calendar & Scheduling overview

Reschedule, cancel, Google Meet and the .ics file

Overview Once a booking is confirmed, it isn't locked: the customer can reschedule or cancel using the links in their confirmation, and you can manage the appointment from the Calendar. When the event type uses Google Meet, the video-call link is created automatically and included in the invite. The confirmation email also includes an .ics file, which adds the appointment to any calendar app. Reschedules and cancellations are reflected on the platform and in Google Calendar (when connected), keeping everything in sync. Prerequisites - A booking that's already confirmed (via the public page or created by an agent). - For the automatic Meet link, an active Google connection and the event type set up with Google Meet. - The confirmation email enabled on the event type (so the customer receives the links and the .ics). Step by step Reschedule (customer): 1. In the confirmation email, the customer opens the reschedule link. 2. They pick a new free slot within the event type's rules. 3. They confirm — the appointment is moved and a new confirmation is sent. Cancel (customer): 1. In the confirmation email, the customer opens the cancel link. 2. They confirm the cancellation — the slot is freed and the parties are notified. Manage (agent): 1. Open the appointment in the Calendar (or from the contact panel in the conversation). 2. Edit the time, reschedule or cancel as needed. It does not matter how you do it: dragging the appointment on the grid, editing the date in the event form, or using the Schedule tab inside the conversation — in every case the customer gets the standard reschedule (or cancellation) message, Google Calendar is updated, and calendar automations fire. Only edits that leave the time alone (for example, renaming the appointment) do not notify the customer. 3. To see every booking and copy each one's management link, open the Bookings list at the top of the Calendar. The same link also appears when you open the event, in the Manage link field. Settings & options - Management links: each confirmation includes secure links to reschedule and cancel. - Bookings list: at the top of the Calendar, see every booking filtered by status and period, and copy any booking's management link to resend to the customer. - Automatic Google Meet: enable it on the event type to generate the video-call link on every booking. - .ics file: attached to the confirmation; opening it adds the appointment to the customer's calendar. - Sync: time changes and cancellations are reflected in Google Calendar when a connection is active. - Linked side-effects: conversation, task and CRM deal follow the booking's lifecycle. Use cases - Let customers rebook themselves, without opening a ticket or exchanging messages. - Send meetings with the Meet link ready, without creating the room manually. - Make sure the appointment lands in the customer's calendar (Outlook, Apple, Google) via .ics. - Automatically free the slot when a customer cancels, making it available to others. Tips, limits & best practices - The .ics file is a universal format and works in nearly any calendar app. - Encourage customers to use the reschedule/cancel links instead of simply not showing up. - Rescheduling respects the same event-type rules (availability, buffers, notice). - If the event type doesn't have automatic Google Meet, set a location or a manual link so invites aren't sent without a meeting address. Troubleshooting - I didn't get the Meet link: confirm the event type uses automatic Google Meet and that there's an active Google connection. - The .ics didn't open the appointment: try opening the attachment in the device's calendar app; some email clients require saving the file first. - I rescheduled, but Google didn't update: check the Google connection is still active; the periodic check reconciles differences. - The cancel/reschedule link doesn't work: the booking may already be canceled or changed — check its status in the Calendar. See also - Calendar & Scheduling overview - Public booking page - Event types, availability and buffers - Connect Google Calendar (OAuth) and sync

Delete or cancel an event: which to use

Overview In the Conversa Labs Calendar an appointment can leave your list in two different ways, and the choice matters: cancel and delete are not the same thing. - Cancel keeps the appointment record on the platform and only changes its status to cancelled. The history stays in the Calendar, the time slot is freed, the parties are notified, and — when there is a Google connection — the event is removed from Google Calendar (the cancelled record stays on the platform for history). - Delete removes the appointment for good: it stops existing on the platform and is erased from Google Calendar. There is no history after deleting. Rule of thumb: use cancel when you want to keep a trace (reports, no-show, follow-up) and delete only when the event was created by mistake or must leave no record at all. Prerequisites - The Calendar module enabled on the account and an existing appointment. - A profile allowed to edit/remove appointments. - For the cancellation or deletion to reflect in Google, an active Google connection on the event's calendar. Step by step Cancel an appointment: 1. Open the appointment in the Calendar (or from the contact panel in the conversation). 2. In the event form, click Cancel. 3. Confirm. The status changes to cancelled, the time slot is freed, and — when a Google connection exists — the event is removed from Google Calendar (the cancelled record stays on the platform). Delete an appointment: 1. Open the appointment in the Calendar. 2. In the event form, click Delete. 3. Confirm the deletion. The event is removed from the platform and from Google Calendar, leaving no history. Reactivate a cancelled appointment: 1. Open the cancelled appointment (use the Cancelled filter to find it). 2. In the event form, click Reactivate. 3. The status goes back to confirmed and the appointment reappears in the default view. See what was cancelled: 1. In the Calendar's appointment list, use the Cancelled filter to review everything that was cancelled (without mixing it with active ones). Settings & options - Cancel: cancelled status, keeps the record on the platform, frees the slot, notifies the parties and removes the event from Google Calendar (the cancelled record stays on the platform). - Delete: permanently removes the native event and calls the deletion in Google Calendar (the event is erased on both sides). No history. - "Cancelled" filter: separates cancelled appointments from active ones in the Calendar list. - Buttons: Cancel and Delete live in the event form (when you open/edit the appointment). Use cases - Cancel: the customer called off, but you want to keep the record for reporting and follow-up. - Cancel: officially register a cancellation and free the slot for someone else. - Delete: an event was created by mistake (wrong time, duplicate) and should appear nowhere. - Delete: clean up a test you created yourself and don't want in the history or in Google. Tips, limits & best practices - Prefer cancel in most cases: keeping the history helps with reports, no-show and missed-appointment analysis. Delete is irreversible and leaves no trace. - When you delete, the event also disappears from Google Calendar — make sure that's what you want before erasing it on both sides. - If the appointment already had a confirmation sent to the customer, cancelling triggers the proper cancellation notice; deleting simply removes the event. - Use the Cancelled filter to audit cancellations without cluttering your view of active appointments. Troubleshooting - I cancelled, but Google still shows the event: cancelling removes the event from Google Calendar. If it still shows, confirm the Google connection is still active; the periodic check reconciles differences. - I deleted, but the event came back: check the Google connection and whether it was recreated by a new sync of an event still present in Google — delete it in Google too if needed. - I can't find a cancelled appointment: use the Cancelled filter in the Calendar list. - I don't see the Cancel/Delete buttons: your profile may not be allowed to remove appointments — talk to an administrator. See also - Reschedule, cancel, Google Meet and the .ics file - Google Calendar sync: import, status and reconnect - Calendar & Scheduling overview - Booking side-effects, reminders and notifications

Paid scheduling: pay-to-confirm, deposits and subscriptions

Overview Paid scheduling connects the Calendar module to the Payments module: when an event type requires payment, the chosen slot is not confirmed right away. It enters an awaiting payment state and only becomes confirmed after Conversa Labs receives the gateway's approval for the payment. That way you only block your agenda for people who actually paid. Each event type defines how payment works: a one-off charge to confirm, a deposit smaller than the full price, or a subscription — requiring the customer to already be a subscriber, or creating the subscription at the moment of booking. Prerequisites - The Calendar module enabled, with at least one event type and availability configured. - The Payments module enabled, with a gateway connection (Asaas or Mercado Pago). - For subscriptions, a payment plan created. - A role with permission to edit event types and charges. Step by step 1. In Calendar, open the event type you want to charge for. 2. Choose the payment mode (see the table below): none, one-off charge, require a subscription, or subscribe on booking. 3. Set the amount and currency. If the event type is linked to a Catalog product or a plan, the price can come from there. 4. (One-off, optional) set a deposit that is smaller than the full price — only the deposit is charged to confirm; you collect the balance manually or on site. 5. Choose the accepted billing types: PIX, boleto and/or card (hosted link). 6. Pick the gateway connection and, for a subscription, the plan. 7. Set the slot hold mode and the hold time (see "Hold and expiry"). 8. Save. From then on, any booking of this type requires payment. Payment modes | Mode | What it does | |---|---| | None (none) | No payment — the slot confirms immediately. | | One-off charge (one_off) | Creates a single charge; the slot confirms when it is paid. | | Require subscription (subscription_gate) | Anyone with an active subscription on the plan books for free; everyone else is routed to pay or subscribe. | | Subscribe on booking (recurring) | Creates a gateway subscription at booking time; the first charge confirms the slot. | Settings & options - Amount and currency: the price charged to confirm. Resolution order is: amount set on the event type → the linked Catalog product price → the plan amount. If nothing resolves, the booking is not created (see "Troubleshooting"). - Deposit: only valid for the one-off charge; it must be greater than zero and smaller than the full price. Only the deposit is charged to confirm — the balance is collected later. - Billing types: a subset of PIX, boleto and card. With nothing selected, it falls back to the account or connection defaults; finally, PIX. - Connection and plan: the gateway connection that processes the charge; the plan defines the subscription cycle. - Hold time: how many minutes the slot is held while awaiting payment (default 15). Hold and expiry The hold mode decides what happens to the slot while the payment has not arrived: - Reserve and hold (reserve_and_hold): the slot is held as soon as the customer starts the payment and stays unavailable to others until a deadline (hold_expires_at). An automatic sweep runs every minute: if the deadline passes without payment, it cancels the unpaid charge at the gateway, frees the slot and marks the booking as expired. - Pay first (pay_first): the slot is not held during payment. When the payment is approved, the slot is re-checked: if it is still free, the booking confirms; if someone took the slot in the meantime, the booking enters payment failed and the (already paid) charge must be refunded manually in Payments. Booking lifecycle | State | When it happens | What the customer and the agent see | |---|---|---| | Awaiting payment | Charge created; slot held (in "reserve and hold"). | The customer gets the link/PIX; the agent sees the booking pending, not yet confirmed. | | Confirmed | Payment approved. | Triggers the booking side effects (conversation, task, deal, email) and generates the Google Meet link. | | Payment failed | In "pay first", the slot was taken before approval. | The slot is not kept; you must refund and reschedule. | | Expired | The hold time passed without payment. | The unpaid charge is canceled and the slot is free again. | Use cases Where it works Pay-to-confirm applies everywhere a booking is created: - The public booking page. - An agent booking directly in the conversation. - Automation and macros. - FlowBuilder (including native WhatsApp Flows). - Maestro (the AI assistant). Examples: - Consultations and mentoring sessions that are only confirmed after payment. - Charging a deposit to reduce no-shows, collecting the balance during the appointment. - Recurring sessions sold as a subscription. - Bookings exclusive to subscribers (members book without paying again). Tips, limits & best practices - Use PIX to confirm faster; boleto can take days and blow past the hold time. - Tune the hold time to your scenario: too short expires slow payments; too long ties up idle slots. - Prefer reserve and hold when the slot is in demand; pay first when you do not want to block your agenda before getting paid. Cancellation and refund - Cancelling a paid booking frees the slot and removes the event from Google, but does not refund automatically. A refund is a manual action in the Payments module. - Refunding or cancelling the charge of an already confirmed booking does not cancel the appointment by itself — the agent decides. Only a booking still awaiting payment is released automatically when its charge fails, is canceled or refunded. Troubleshooting - The payment did not confirm the slot: make sure the gateway connection is active and receiving notifications (webhook). The slot only confirms when the gateway reports the charge as paid — the payment success page alone does not confirm it. - The slot expired before payment: the hold time ran out. The unpaid charge is canceled and the slot is free again — just book again. Increase the hold time if this happens often. - The amount could not be resolved (error 422): the event type has no computable price — no amount set, no Catalog product with a price, and no plan. Set an amount (or link a product or plan) so the booking can be created. - In "pay first", the customer paid but lost the slot: someone else booked the same slot before approval. Refund the charge in Payments and offer a new slot, or use reserve and hold to avoid the race. See also - Public booking page - Event types, availability and buffers - Connect a payment gateway - Subscriptions and plans - Refunds, webhooks and reports

Payment and deposit on booking

Overview In the Conversa Labs Calendar, an event type can require payment to confirm the time slot. You choose between two modes: - Full amount — the customer pays the whole service to confirm. - Deposit — the customer pays only a part now to secure the spot, and the remaining balance is arranged for later (for example, "deposit now, remainder on site"). While payment isn't completed, the slot stays reserved (not confirmed) and expires if payment doesn't arrive within the deadline — freeing the spot for someone else. The booking only triggers the side-effects (conversation, task, deal, confirmation) once the required payment is confirmed. Prerequisites - The Calendar module enabled and the Payments module active, with a gateway connected (Asaas or Mercado Pago). - An event type configured to require payment (full or deposit). - A profile allowed to configure the Calendar and Payments. Step by step Configure (you): 1. Open the event type and enable Require payment. 2. Choose full amount or deposit and enter the deposit amount when applicable. 3. (Optional) Set the reservation expiry deadline while payment isn't completed. 4. Save and publish the link. Book and pay (customer): 1. The customer picks a time on the public page and fills in their details. 2. At the payment step, they see the charge — PIX, boleto or link/card, per the gateway. 3. The slot stays reserved while payment isn't completed. 4. On payment confirmation, the booking becomes confirmed and triggers the side-effects. 5. For a deposit, the customer sees the remaining balance to pay later. Settings & options - Charge mode: full amount or deposit with a partial amount. - Remaining balance: in deposit mode, the difference between the total and the deposit is recorded (e.g. pay on site). - Payment methods: PIX, boleto or link/card, per the connected gateway. - Payment status: pending/reserved → paid/confirmed (or expired, if the deadline passes). - Reservation expiry: the deadline for payment to arrive; without payment, the slot is freed. Use cases - Charge a whole consultation or mentoring session before confirming the slot. - Charge only a deposit to reduce no-shows, leaving the remainder for the appointment day. - Hold the spot for a limited time while the customer completes the PIX. - Auto-confirm the booking as soon as the payment is approved, with no manual checking. Tips, limits & best practices - Make it clear in the event type's name/description whether it's full amount or deposit, so the customer isn't surprised. - A short expiry deadline frees spots faster; a longer one gives room for PIX/boleto to clear. - In deposit mode, communicate the remaining balance well and where/how it will be paid. - The booking only confirms and triggers side-effects after the required payment — a reserved slot isn't yet a guaranteed appointment. - Gateway, method and refund details live in the Payments module (see "See also"). Troubleshooting - Payment didn't confirm the slot: confirm the Payments module is active, the gateway connected, and the payment was completed — the slot stays reserved until confirmation. - The reservation expired: payment didn't arrive within the deadline; the customer needs to book again. - The customer didn't see a way to pay: check that the event type has Require payment on and a gateway connected. - The remaining balance didn't show: confirm the event type is in deposit mode, not full amount. See also - Paid scheduling - Public booking page - Booking page branding (logo, color and name) - Calendar & Scheduling overview

Booking side-effects, reminders and notifications

Overview When a booking is confirmed (from the public page or created by an agent), the Conversa Labs Calendar can trigger a set of automatic actions — the booking side-effects. Each one is independent and can be turned on or off per account or per event type: open a conversation with the contact, create a task with a reminder, link or create a CRM deal, send a confirmation email with an .ics file, and send a native WhatsApp event. On top of that, the Calendar sends reminders before the start time, can flag no-show automatically, and produces distinct notifications: the customer receives the confirmation with the .ics, and the agent receives an alert (email and in-app) for a new booking or a no-show, with a deep link to the deal or the contact. Prerequisites - The Calendar module enabled and a booking that reaches the confirmed state. - For the confirmation email (.ics) and the agent notifications, SMTP configured on the account. - For the conversation side-effect, at least one inbox (the Calendar uses the inbox assigned to the calendar, or the first available one). - For the CRM deal side-effect, the CRM module active and a default pipeline/stage set when you want deals created automatically. - For the WhatsApp event side-effect, the contact must have a WhatsApp Web conversation. - For the Google Meet link in the invite, an active Google connection and the event type with Meet. Step by step 1. Open the Calendar settings (module gear). 2. In the Booking side-effects section, turn each effect on or off: conversation, task, CRM deal, email with .ics, and WhatsApp event. 3. In the Reminders section, set the lead times (in minutes before the start) and the channels (email and in-app). Default: 60 and 1440 minutes (1 hour and 24 hours). 4. Still in Reminders, optionally set auto-no-show: minutes after the start to flag a no-show. It is off by default. 5. For per-service rules, repeat the configuration on the event type (scope) — it overrides the account default. 6. Create a test booking and confirm the expected effects and reminders happened. Settings & options Booking side-effects (each toggles on/off, independent): | Effect | What it does | Default | |---|---|---| | Conversation | Finds or opens a conversation for the contact on the calendar's inbox and links the booking to it. | On | | Task | Creates a task Appointment: <title> due at the start time plus an in-app reminder, linked to the contact and conversation. | Off | | CRM deal | Links an existing open deal for the contact; if none, creates one in the default pipeline/stage (only when "create if missing" is enabled). | Off | | Email + .ics | Sends the confirmation to the customer with the .ics attachment (adds it to the calendar) and the Meet link in the body. | On | | WhatsApp event | Sends a native WhatsApp event (WhatsApp Web only) to the contact's conversation, with the Meet link in the description. It is free — no template, no 24h window. It has its own switch here in Booking side-effects and is opt-in: it ships off, and Delivery does not enable it (they are independent controls). Turn it on when you want the appointment to land in the customer's phone calendar, on top of the confirmation text. | Off | | Google Meet | Generates the video-call link for the invite. | On | Reminders: - Lead times (lead_times): a list of minutes before the start — default 60 and 1440. You can define as many as you want. - Channels: email and in-app (both by default). - Idempotency: each reminder fires exactly once per booking — queue re-runs never re-send the same reminder. - Scope: per account or per event type (the event type overrides the account default). Auto-no-show: - Minutes after the start to flag a no-show automatically, if the booking is still confirmed. Off by default (set a value to enable it). - Flags the booking once and emits the no-show event (automations/webhooks + agent alert). Notifications: - Customer: a confirmation email with the .ics (method REQUEST on confirmation/reschedule, CANCEL on cancellation) and the Meet link. - Agent: a new booking and a no-show alert via email and in-app, with a deep link to the CRM deal (when present), otherwise the contact, otherwise the Calendar. Use cases - Turn every confirmed booking into a conversation + task + deal with no manual work. - Send the confirmation with the .ics so the appointment lands in the customer's calendar. - Notify the customer on WhatsApp with a native event already carrying date, time and Meet link. - Remind the customer 24 hours and 1 hour before to reduce no-shows. - Flag no-show automatically and open a follow-up when nobody attends. Tips, limits & best practices - Effects run when the booking becomes confirmed — a draft or payment-pending booking does not fire the effects yet. - Reminders and auto-no-show run on a periodic background sweep (near real time). Reminders are evaluated for events starting in the next ~48 hours; no-show, for events that started in the last ~24 hours. - If you set a reminder whose time has already passed at booking, it is not re-sent — reminders only look forward. - The CRM deal effect only creates a deal when "create if missing" is enabled and a default pipeline/stage exists; otherwise it only links an existing open deal. - Keep SMTP configured: without it, the .ics email and the agent notifications are not sent. Troubleshooting - An effect did not fire: confirm it is enabled in the right scope (account or event type) and that the contact exists. The conversation needs an inbox; the WhatsApp event needs a WhatsApp Web conversation. - The CRM deal was not created: it is only created with "create if missing" enabled and a default pipeline/stage set; otherwise only an existing open deal is linked. - The task did not appear: check that the task effect is on and that the booking has a valid start time. - Missing reminder: the booking must be confirmed and start within the sweep window; check SMTP and that the lead time had not already passed at booking. - Duplicate reminder: it should not happen — each reminder is idempotent (once per lead time). If you see repetition, check you do not have two identical lead times configured. - The agent did not get the notification: confirm SMTP and that the agent has a valid email; the link points to the deal, otherwise the contact, otherwise the Calendar. See also - Calendar and bookings overview - Reschedule, cancel, Google Meet and the .ics file - Public booking page - Event types, availability and buffers - Connect Google Calendar (OAuth) and sync

Reminders: timings and message (template with variables)

Overview Reminders notify the customer (and can notify the agent) before the appointment time. You control two things: - When the reminder goes out — the lead times (for example, 24 hours and 1 hour before the start). You can set as many as you want. - What the reminder says — the message (template), written with variables that Conversa Labs replaces with the appointment's real data at send time. The configuration is a cascade: you set a default on the account, can override it per event type, and, if needed, adjust it directly on a single event. Prerequisites - The Calendar module enabled and a booking that reaches the confirmed state. - For email delivery, SMTP configured on the account. For WhatsApp delivery, a WhatsApp inbox with a conversation for the contact (see the channel-aware delivery article). - A profile allowed to configure the Calendar. Step by step 1. Open the Calendar settings and go to Reminders. 2. In Lead times, enter the minutes before the start — for example 1440 (24 h) and 60 (1 h). Add or remove as many as you need. 3. In Message, write the reminder text using the available variables (see the table below). E.g.: Hi {{contact_name}}, your {{title}} is on {{date}} at {{time}}. Link: {{link}}. 4. (Optional) For different rules per service, open the event type and set the timings and message there — they override the account default. 5. (Optional) On a specific event, adjust the reminders just for that appointment. 6. Save and create a test booking to check the final text and the send time. Settings & options - Lead times: a list of minutes before the start. Reference default: 1440 and 60 (24 h and 1 h). Each timing fires exactly once per booking. - Message (template): the reminder body, with variables replaced at send time. - Per language (optional): the reminder, confirmation, reschedule and cancel bodies — and their matching approved WhatsApp templates — can be set per language. The old single-text configuration keeps working unchanged: only fill in per language if you serve audiences in different languages. - Scope (cascade): account (default) → event type (overrides) → event (one-off adjustment). - Available variables: | Variable | Replaced with | |---|---| | {{title}} | Appointment title / event type | | {{date}} | Appointment date (in the correct time zone) | | {{time}} | Start time | | {{link}} | Management/meeting link (e.g. Google Meet or reschedule/cancel) | | {{location}} | Appointment location (in person or link) | | {{contact_name}} | Contact/customer name | | {{host}} | Host/agent name | | {{datetime}} | Date and time together (e.g. 12/05/2026 10:00) | - {x} picker: every message field has a picker that inserts the variable at the caret — the list is the same one the send resolves, so there is no "hidden" variable. - "Default" badge and "Restore default": an empty field shows, above it, the shipped text that will actually be sent. Once you write your own, Restore default deletes your version for that language (not just on screen: the removal reaches the server). - Native "Manage booking" button: by default the manage link goes out as a button on WhatsApp instead of a bare URL in the text — inside and outside the 24h window. Turn it off per kind under Delivery → Native buttons. On WhatsApp Cloud, Meta delivers a single button. - Auxiliary labels: the button text and the line above it are editable too, per language. - Preview and test: the preview shows the message rendered per channel (the same renderer the send uses) and the approved template that leaves outside the 24h window. The test really sends it to a conversation you pick, honouring the window. Use cases - Send one reminder 24 hours before and another 1 hour before to reduce no-shows. - Personalize the text with the customer's name and the ready meeting link. - A "Consultation" event type with a message and timings different from "Demo". - On an important booking, add an extra reminder without changing the default. Tips, limits & best practices - Write only what's needed and always include {{date}}, {{time}} and {{link}} — that's what the customer needs most. - Type the variables exactly as in the table (with the double braces). A name outside the list stays as literal text. - Avoid duplicate timings (two 60-minute reminders) — each timing fires once. - A timing whose time has already passed at booking is not re-sent: reminders only look forward. - Prefer adjusting at the right level: change the account to apply everywhere, the event type for a service, the event for a one-off case. Troubleshooting - The reminder went out with {{contact_name}} in the text: the variable was mistyped (extra space, missing brace) or doesn't exist — compare it with the table. - I didn't get the reminder: the booking must be confirmed and the lead time can't have already passed at booking; also confirm the channel (SMTP for email). - I changed the message and it had no effect: check the scope — an event type or an event may have its own text overriding the account default. - The reminder time was off: check the calendar's time zone and the contact's own zone (stored with the booking). An event type has no time zone of its own. See also - Reminder delivery over WhatsApp and email (channel-aware) - Booking side-effects, reminders and notifications - Event types, availability and buffers - Calendar & Scheduling overview

Calendar reports and metrics

Overview Calendar reports are the analytics dashboard for the Conversa Labs scheduling module. On a single screen, an administrator follows booking volume, the no-show and cancellation rates, performance by event type and by agent, the lead time (how far ahead people book), the occupancy (booked hours), and the sync health with Google Calendar. These are aggregate numbers across an entire account (or one specific calendar) within a date range you choose. It is the managerial view of the Calendar — not an event-by-event list. Prerequisites - An account administrator profile. Reports are an administrative surface: agents without administrator privileges cannot open them. - The Calendar module enabled on the account (it is optional and off by default). - At least some bookings in the period so the numbers are not all zeros. Step by step 1. Open the Calendar from the left sidebar. 2. Go to the Calendar Reports section (visible to administrators only). 3. Choose the period (date range) you want to analyze. 4. Optionally, filter by a specific calendar. With no filter, the report covers the whole account. 5. Read each dashboard section to understand volume, rates, performance, and sync. Settings & options Reports include the sections below. Each one is computed over the selected period and calendar. | Section | What it shows | | --- | --- | | Overview | Total bookings and the split between confirmed, cancelled, no-show, and rescheduled, plus the cancellation rate and the no-show rate. | | By event type | Bookings per event type (e.g., "Demo", "Support"), with total, no-show, and cancelled for each type, sorted from most to least booked. | | By agent | Bookings per host (the responsible agent), with total and no-show for each — handy for comparing the team. Shows the top agents in the period. | | No-show rate | No-show count and its proportion over total bookings. | | Cancellation rate | Cancellation count and its proportion over the total. | | Average lead time | Average time between a booking's creation and the appointment's start — how far ahead people book. | | Occupancy | Booked hours and the number of events active in the period — a calendar utilization signal. | | Sync health | Sync events classified as ok, error, and conflict, plus the timestamp of the last sync with Google Calendar. | - Calendar filter: limits every section to a single calendar; without it, the report spans the whole account. - Period: sets the date window used in the counts and rates. - Payments funnel (optional): when the Payments module is active and the event type is paid, the report also shows settled revenue, the pending-to-paid conversion, and the expired, failed, and refunded cases. Use cases - Measure absenteeism: track the no-show rate and act (reminders, prior confirmation, prepayment). - Compare agents: see who receives the most bookings and who has the most no-shows, by host. - Track utilization: use booked hours and the number of events to assess the calendar load. - Monitor the integration: check sync health and the last sync with Google. Tips, limits & best practices - The numbers honor the scope you choose: the whole account or one calendar, within the date window. - Values are aggregate (counts, averages, and rates) — not a list of each booking. - The rates (no-show and cancellation) are proportions over the total bookings in the period. - Lead time considers only bookings whose start is later than their creation (the real lead). - Occupancy sums the duration of active events; cancelled/archived events are excluded. Troubleshooting - I cannot see Reports: the section is administrators only. If you are a regular agent, ask an account administrator for access. - The numbers are all zero: widen the period or remove the calendar filter — there may be no bookings in the selected window. - Conflicts appear under sync health: a conflict means a divergence between Conversa Labs and Google that the periodic check reconciles. Confirm the Google connection is still active and review the last sync; recurring errors may require reconnecting the Google account. See also - Calendar and scheduling overview - Connect Google Calendar (OAuth) and sync - Event types, availability, and buffers - Public booking page - Reschedule, cancel, Google Meet, and the .ics file

Reminder and confirmation delivery over WhatsApp and email

Overview Delivery of confirmations and reminders from the Calendar is channel-aware: Conversa Labs picks the best way to reach the customer based on where they are and each channel's rules. - Email: sent whenever the contact has an email and SMTP is configured — it carries the appointment details, the .ics file and the manage links (reschedule/cancel). - WhatsApp Web: the customer gets a native WhatsApp event (with the Meet link in the description). There is no 24-hour window on this channel, so no approved template is needed. - WhatsApp Cloud inside the 24h window: if the customer messaged you in the last 24 hours, the notice goes as a session message (free text, no template cost). - WhatsApp Cloud outside the 24h window: once the window has closed, the message can only go as an approved template (HSM) of the official API — which is why you pick the template to use. A single WhatsApp switch. In the dashboard, WhatsApp is enabled in Delivery → Send on WhatsApp — there is no second WhatsApp toggle in Side effects. That switch controls the text notification (a session message on Web/Cloud, an approved template outside the window) and is opt-in, because outside the 24h window it sends a paid template. The native WhatsApp Web event is a separate object: it is free, it has its own switch under Agenda › Settings › Booking side-effects, and it ships off. This Delivery section does not enable it — Delivery governs the confirmation text and the reminders. They are independent controls. Turning Delivery on keeps it on, but you do not have to enable anything to keep receiving the event — installs that used the Calendar before this release lose nothing. Prerequisites - Calendar module enabled and the booking confirmed. - For email: SMTP configured and an email on the contact. - For WhatsApp: a WhatsApp inbox (Web or Cloud) and a conversation with the contact. - For WhatsApp Cloud outside the window: an approved template for reminder/confirmation. Step by step 1. Open the Calendar settings and go to Delivery. 2. Turn on the channels you want: Send by email and Send on WhatsApp. 3. In WhatsApp inbox, pick the inbox (Web or Cloud) used for the notices. 4. (WhatsApp Cloud) Under WhatsApp Cloud templates, select the approved template for each notice (Reminder, Confirmation, Reschedule, Cancellation) and map its variables (contact name, title, date/time). 5. Save. For each notice Conversa Labs decides on its own: native event (Web), session (Cloud inside 24h) or template (Cloud outside the window) — and sends the email when applicable. 6. Make a test booking and check delivery on each channel. Per event type. Delivery can also be customized per type: on the event type, the Delivery section starts as Inherits the account default; turn on Customize to use a different inbox or different templates for that type only, and Reset to account default to undo it. Create a scheduling template (WhatsApp Cloud) If you don't have an approved template yet, use + Create template next to each notice (available on WhatsApp Cloud inboxes with the WhatsApp feature suite enabled). 1. Pick the language (pt_BR, English or Spanish) and confirm. 2. Conversa Labs creates a UTILITY template with the notice text plus a "Manage booking" button carrying the link — and submits it to Meta for approval. 3. Approval is asynchronous: it can take from a few minutes to a few hours. 4. Track the status in the inbox's Templates tab. While it is Pending it does not show up for selection. 5. Once it is Approved, click Sync from WhatsApp and select the template here. Why is the link in a button? Meta rejects templates whose body ends with a variable, and bare links in the body are more likely to be refused. So the manage link lives in a URL button, filled automatically with the booking's link at send time. Settings & options | Channel / situation | How it is delivered | |---|---| | Email | Whenever there is an email + SMTP. Includes the .ics and manage links. | | WhatsApp Web | Native WhatsApp event (Meet in the description). No window, no template. | | WhatsApp Cloud — inside 24h | Session message (free text), the window is open. | | WhatsApp Cloud — outside 24h | Approved template (HSM) with the mapped variables. | - Send on WhatsApp: enables WhatsApp notices. The native Web event has its own switch under Booking side-effects. - WhatsApp inbox: which inbox sends the calendar notices. - Templates (Cloud): one approved template per notice kind, with its variables mapped. - URL button: the manage link is filled automatically at send time. Use cases - Confirm on WhatsApp right after booking and reinforce by email with the .ics. - Remind 24h before via an approved template, even if the customer hasn't written in days (Cloud). - Send the native event on WhatsApp Web, which lands straight in the customer's calendar. - Use different templates on one specific event type without touching the account default. Tips, limits & best practices - Keep email on as a safety net: it always goes out and carries the .ics. - For WhatsApp Cloud, have an approved template ready — without one, sends outside the 24h window don't happen (email still covers the notice). - The 24h window counts from the customer's last message; inside it the text is free. - UTILITY templates are the right category for reminder/confirmation — avoid marketing categories. - Check the timezone so the date and time in the notice match what was agreed. Troubleshooting - The template shows "Submission failed": Meta refused the format. The most common causes are body text ending with a variable or a bare link in the body — use + Create template, which already builds the accepted format (text + URL button). - I created the template and it isn't in the list: it only appears after approval. Check the status in the Templates tab and click Sync from WhatsApp. - The reminder didn't arrive on WhatsApp Cloud: it was probably outside the 24h window with no approved template selected/mapped. - Only the email arrived: the WhatsApp inbox may not be set, or there is no conversation yet. - Template variables came out empty: review the mapping (contact name, title, date/time). See also - Reminders: timing and message (template with variables) - Booking side effects, reminders and notifications - Reschedule, cancel, Google Meet and the .ics file - Calendar & Scheduling overview

Scheduled messages: create, manage and configure

Overview Scheduled messages let you prepare now an outbound message that will be sent later in the same conversation. The module supports one message, sequences and recurrences in the selected timezone. It uses the same content contract and channel checks as immediate sending. This feature is different from: - Campaigns, which distribute content to an audience or multiple contacts. - Follow-up, which automates a follow-up cadence and its conditions. - Calendar, which manages appointments. A scheduled message does not create or change one. Prerequisites - The Scheduled messages feature enabled for the account. - An existing conversation and a channel capable of carrying the content. - Agents create and manage their own schedules. Managing someone else's schedules or changing account/inbox policy requires an administrator or the Manage scheduled messages permission. - An administrator must complete the account policy before the first publication. Step by step 1. Open a conversation and compose the message as usual. 2. Beside Send, in the conversation header, or in the right-side panel, open the calendar icon and choose Schedule once, Schedule a sequence, or Schedule recurring messages. The primary Send click still sends immediately. 3. Enter a name and date, then search for the timezone by city. For each message, write text, drag in media/files, or open the interactive and template composer available for the channel. For a sequence, order the items and set each interval. 4. For recurrence, choose the frequency and an ending: never, until a date or after a count. For a special pattern, open Advanced settings and start from one of the explained examples before editing the rule. 5. Review the preview. It shows blockers, effective policies, channel capability and the next five occurrences. 6. Confirm. The conversation draft is cleared only after creation succeeds. 7. Open Scheduled messages in the main navigation to manage everything. For the current conversation, use the Scheduled messages tray in the side panel. Suggested screenshot: split send button, preview dialog and global module with the detail open. Settings & options In Scheduled messages → Settings, select Account defaults or A specific inbox. On a new account, choose Apply recommended setup to fill a safe baseline, then review only the exceptions. Policies are grouped by goal and searchable by name. For each Inbox policy, choose Use account default or Customize for this inbox. Counters show customized, inherited, and pending policies before you save. Policies cover inbound replies, resolved conversations, misfires, failure retries, resume behavior, quiet hours, overlap, Inbox changes, sender, variables, daylight-saving time and materialization/recovery limits. The source of every value remains visible. If another operator saves first, reload the current version before applying your change again. From schedule detail you can pause, resume, cancel, archive, retry or reconcile an uncertain result. For an occurrence, you can reschedule, skip, send now or retry. Always confirm the scope: this occurrence, this and future ones, or all future ones. Media and interactive content Inside the scheduling dialog, choose Choose from library to reuse account media, Upload from device for a new file, or drag images, video, audio, and documents onto the message. Options follow the conversation: WhatsApp Cloud shows Cloud templates and interactives; WhatsApp Web shows WhatsApp Web interactive; a Coexistence conversation shows both composers, clearly separated. Other channels do not receive incompatible actions. Content templates also open their native composer when the channel supports them. After you apply content, preview keeps its type and body visible and offers Edit or Replace in the native composer without losing the name, date, timezone, recurrence, or policies. In a sequence, Duplicate message copies the complete content; technical details stay collapsed by default. Use cases - Confirm a follow-up promised to the customer for tomorrow. - Send a short instruction sequence in the same support conversation. - Repeat a weekly reminder without creating a campaign. - Schedule an approved template for a WhatsApp message outside the session window. Tips, limits & best practices - The target is always one existing conversation; audience, segment and multi-contact targets are rejected. - Up to 500 occurrences per schedule are materialized within a 30-day horizon. Later occurrences are created progressively. - Attachments remain linked to the schedule. Do not delete the source file while future sends exist. - The channel is checked during preview and again when due. Disconnects, opt-outs, closed windows, unapproved templates or removed sender access may block a later send. - Notifications are exception-only: failures or Needs attention. Normal occurrences do not create an alert each time. - An uncertain provider effect is never retried blindly. Use Reconcile after checking the provider. Troubleshooting - The schedule option is missing: check the account feature and your permission. - Preview reports an incomplete policy: an administrator must complete the account setting or the missing value at the indicated scope. - The channel is blocked: open the blocker details and correct connection, window, template, attachment, opt-out or sender access. - Saving or an action returns a conflict: another operator or job changed the record. Reload its detail and repeat the intention against the current version. - An occurrence Needs attention: verify the provider outcome, then choose Reconcile → Sent, Failed or Canceled. See also - Scheduled messages API and MCP - Delivering reminders through WhatsApp and email - API reference (Swagger/OpenAPI)