> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dmly.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Appointments overview

> How the Appointments module fits together: services live under Offerings, staff carry the availability, and clients book on your public page.

Appointments is where you take bookings. It covers one-to-one appointments — a haircut, a consultation, a viewing — and classes, where several people share a seat pool in the same session. Clients book themselves on your public booking page, or you add a booking by hand from the calendar. Either way you end up with the same kind of booking record and the same reminders on WhatsApp. Payment is a booking-page thing only — a booking you add by hand takes no payment and sends no pay link, whatever the service's payment mode.

<Note>
  **Services are set up under Offerings, not under Appointments.** This trips up almost everyone. The Appointments hub manages bookings, staff, availability and the booking page. The service itself — its duration, buffers, price, payment mode and reminder times — is edited at **Offerings → Services**. See [Services](/appointments/services) for what each setting does and [Offerings](/offerings/overview) for the wider catalogue.
</Note>

## The pieces

<Columns cols={2}>
  <Card title="Services" icon="list-check" href="/appointments/services">
    What you sell time for. A service carries the duration, buffers, notice rules, price and payment mode. Edited under Offerings.
  </Card>

  <Card title="Staff and availability" icon="user-clock" href="/appointments/staff-and-availability">
    Who can be booked, their working hours in their own timezone, and one-off time off or blocks.
  </Card>

  <Card title="Booking page" icon="calendar-check" href="/appointments/booking-page">
    Your public page. Clients pick a service, a staff member and a time without logging in.
  </Card>

  <Card title="Classes" icon="users" href="/appointments/classes">
    Fixed sessions with a capacity and an optional waitlist. Each seat is still a booking.
  </Card>

  <Card title="Payments" icon="credit-card" href="/appointments/payments">
    Charge nothing, charge after the appointment, or hold the slot until the client pays.
  </Card>

  <Card title="Calendar and Zoom sync" icon="calendar-days" href="/appointments/calendar-sync">
    Push bookings to Google Calendar, pull external events back as busy time, and mint Zoom links.
  </Card>

  <Card title="Custom domain" icon="globe" href="/appointments/custom-domain">
    Serve the booking page on your own domain. Plan-gated — see below.
  </Card>

  <Card title="Meetings" icon="clock-rotate-left" href="/appointments/meetings">
    The older scheduler. Same bookings underneath.
  </Card>
</Columns>

The Appointments hub itself has three working views — **Bookings** (an upcoming and past list), **Calendar** (*View and manage all bookings, classes and blocked time in one place*) and **Staff** (*Manage staff members, their hours and the services they offer*) — plus its settings, where the booking page branding, the booking form and the custom domain live.

## How a booking comes together

A service says how long it takes and how far ahead you will accept it. A staff member says which hours they work and which services they offer. DMLY combines the two and shows only the times that survive every check:

* The service's minimum notice and booking horizon. Your workspace settings can tighten both — minimum notice is a floor, the booking horizon a ceiling — but never loosen them.
* Busy time on the connected calendar.
* The staff member's existing bookings, plus the service's buffers either side.
* Any block or time off, whether it belongs to one staff member or to the whole workspace.

If a service is offered by more than one person and the client doesn't choose, DMLY offers the union of everyone's free times and picks an available staff member for them.

Two people can hit **Book** on the same slot at the same time. Only one wins; the other sees *Sorry, that time was just taken — please choose another.* The slot is locked while the booking is written, so a double booking can't slip through.

<Note>
  Working hours are wall-clock times in the **staff member's own timezone**, not yours. If someone works 9:00–17:00 in Lagos and your workspace is in London, set 9:00–17:00 on their record and let DMLY do the conversion.
</Note>

## What happens after the booking

Once a booking is confirmed, DMLY does the rest on its own:

* **Confirmation and reminders.** Reminders are seeded from the service's reminder times (for example, a day before and an hour before) and go out on the client's channel. A reminder is skipped — not retried — if the booking is no longer confirmed, or the contact has opted out or has the bot paused. The meeting time is fixed, so a missed window can't be caught up later.
* **Your team is told too.** The assigned staff member gets their own message, and the rest of the active team gets a heads-up. Reminders never notify the team.
* **The calendar event.** The event is pushed after the booking is saved, so a Google or Zoom failure can never lose you the slot. If nothing is connected, the booking simply lives in DMLY.
* **Automations fire.** Appointment booked, cancelled, rescheduled, completed and no-show all work as triggers. Classes fire their own class events instead. See [Triggers](/automation/triggers).

Clients manage their own booking from the link they were sent: they can cancel, and — for a one-to-one appointment — reschedule, each within the deadline set at **Appointments → Settings → Booking policy**. **Cancellation deadline (hours)** and **Reschedule deadline (hours)** are workspace-wide, not per-service — *Hours before the start time. Set to 0 to allow up until the appointment.* Both start at 0, so out of the box a client can cancel or reschedule right up to the start time. A class seat can be cancelled but not rescheduled to another time. Confirmed, upcoming bookings also get **Add to calendar** links.

<Warning>
  Outside WhatsApp's 24-hour window — which is where most reminders land — a message only goes out on an approved WhatsApp template. If the template isn't approved yet, the message is dropped rather than sent as plain text; inside an open 24-hour window it still goes out as plain text. Check [WhatsApp](/channels/whatsapp) before you rely on reminders.
</Warning>

## When you charge

Each service has a **Payment mode**: **No payment required**, **Pay after the appointment**, or **Pay before booking**. All of it hangs off the price — *Set a price above 0 to require payment.* A payment mode on a free service does nothing.

Pay-before is the one to understand: the slot is held for 15 minutes while the client pays, and nothing else happens until the money clears — no confirmation, no reminders, no calendar event, no booked automation. If they don't pay, the hold is released and the slot goes back on sale. Pay-after confirms the booking first and sends a pay link afterwards.

If no payment gateway is connected, a pay-before service can't be booked at all: the client is turned away with *Online payment isn't available right now. Please contact us to book this service.* The **Payment mode** field warns you about this — *No payment gateway is connected, so clients won't be able to pay. Connect one in settings.* Connect one first: see [Payments and gateways](/finance/payments-and-gateways).

## Appointments vs the Meetings hub

They are not two systems. Meetings came first; Appointments is the same thing grown up. A meeting type **is** a service now, and a booking made either way is the same record — so everything shows up in the Appointments calendar, in reports and in the client's profile regardless of where it started.

Use **Appointments** for new work. It is the one that has staff, per-staff hours, classes and waitlists, payment modes, the branded booking page and calendar sync.

The one thing worth knowing about the older setup: if a service has no staff member with working hours of their own, DMLY falls back to the weekly hours and timezone stored on the service itself — the single-host way. Existing meeting types keep taking bookings; you don't have to migrate anything to keep the lights on. Add staff when you need more than one bookable person or per-person hours.

See [Meetings](/appointments/meetings) for the older hub.

## Before you start

<Steps>
  <Step title="Connect a channel">
    Reminders and confirmations go out over a channel. Connect WhatsApp first — see [Connect WhatsApp](/channels/whatsapp).
  </Step>

  <Step title="Create your services">
    Go to **Offerings → Services** and add what you take bookings for, with the duration, price and reminder times. See [Services](/appointments/services).
  </Step>

  <Step title="Add staff and their hours">
    Add each bookable person, tick **Accepts bookings**, set their **Working hours**, and assign the services they offer. See [Staff and availability](/appointments/staff-and-availability).
  </Step>

  <Step title="Connect a gateway if you charge">
    Do this before switching any service to **Pay before booking**, or nobody can book it. See [Payments](/appointments/payments).
  </Step>

  <Step title="Share your booking page">
    Preview it, brand it, then send the link on WhatsApp. See [Booking page](/appointments/booking-page).
  </Step>
</Steps>

<Accordion title="Things people expect to find and don't">
  **A reports screen.** There is no appointments report view in the app. **Bookings** is a plain upcoming-and-past list, not a dashboard.

  **A custom domain on every plan.** Serving the booking page on your own domain is plan-gated: *Custom domains aren't included in your current plan. Upgrade to connect your own booking domain.* Until a domain is added, verified and its SSL certificate is live, every booking link you share — including links sent by automations — uses the standard DMLY booking address, so nothing breaks while you set it up. See [Custom domain](/appointments/custom-domain) and [Plans](/billing/plans).

  **A staff member who can log in.** A staff member is a bookable person, not a user. Linking them to a team account is optional — use **Link team member** if they should manage their own bookings.
</Accordion>