> ## 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. # Bookable services > A service is the thing a client books — its duration, price and payment mode drive every slot your booking page offers. A **service** is the thing a client books: a 45-minute consultation, a haircut, a Tuesday evening class. It is the single row that decides how long a booking runs, what it costs, whether the client pays, and which start times your booking page offers at all. Everything in [Appointments](/appointments/overview) — the calendar, the reminders, the public page — reads its settings from a service. **Services are not configured in Appointments.** They live under [Offerings](/offerings/overview), in **Services**. Appointments shows you the bookings; Offerings is where you create and edit the services those bookings are made against. There is no Services page in the Appointments hub — if you are looking for one, that is why. If you have used DMLY's older **Meetings** screen, a "meeting type" and a service are the same record under two names. See [Meetings](/appointments/meetings). ## Three kinds of service A service is one of three types, and the type decides how it behaves: * **Appointment** — a one-to-one booking against a staff member's available time. This is the default and the most common. * **Class** — a fixed session with a seat pool that several clients book into. Classes work differently enough to have their own page: see [Classes](/appointments/classes). * **Add-on** — an extra you attach to an order. **Add-ons are never bookable.** They never appear on your booking page and no one can book a time against them. ## What a service sets Only two settings change what a booking *is*: * **Duration (min)** — how long the booking runs. This is the block of time taken out of a staff member's day. * **Slot interval (min)** — how far apart the offered start times sit. A 60-minute service on a 30-minute interval offers 9:00, 9:30, 10:00 and so on, so a gap left by an earlier booking can still be filled. The rest shape *when* a client is allowed to book. On the service form (Offerings → Services) these sit together under one row: * **Buffer before** and **Buffer after** — padding either side of the booking, so back-to-back bookings leave you room to clean up, write notes, or travel. * **Min notice (min)** — the least amount of notice before a booking can start. Stops someone booking the 9:00 slot at 8:55. * **Days ahead** — how far in advance clients can book. **Min notice (min)** is in **minutes**, not hours. Type `2` and you have given yourself two minutes' notice, not two hours. The hours-based field you may be thinking of is the workspace one below. Do not set **Days ahead** to 0 or leave it empty. At the service level a horizon of 0 does not mean *no limit* — it means the latest bookable start is right now, so the service offers **no times at all** and its booking page comes up empty. The field's minimum is 1 for that reason. ### The workspace has its own notice and horizon Notice and horizon exist at two levels. Alongside the service fields above, your workspace sets **Minimum notice (hours)** — *Least amount of notice required before a booking can start.* — and **Booking horizon (days)** — *How far in advance clients can book. Leave blank for no limit.* — under **Booking policy** at **Appointments → Settings**. Note the different units: the workspace fields are in hours and days, the service fields in minutes and days. The two levels are not overrides — DMLY takes the **stricter** of each pair. The workspace minimum notice acts as a floor (whichever is longer wins) and the workspace horizon as a ceiling (whichever is shorter wins). A service asking for 120 minutes' notice in a workspace that requires 24 hours gets 24 hours. Leave the workspace values blank and the service's own numbers apply exactly as written — *blank means no limit* is true of the workspace horizon, not the service's **Days ahead**. **Cancellation deadline (hours)** and **Reschedule deadline (hours)** live in that same **Booking policy** section, and only there — they are set once for the whole workspace and cannot be varied per service. They govern what the client can do themselves on the booking's own management page. They do not restrict you: you can always cancel or move a booking from the calendar. Each service can also carry its own location. Choosing the **Zoom (auto link)** location makes DMLY create a Zoom meeting and join link for every booking automatically — see [Zoom](/integrations/zoom). ## Price and payment mode A service's **Payment mode** decides whether money changes hands, and when: | Mode | What happens | | ----------------------------- | ---------------------------------------------------------------------------------- | | **No payment required** | The booking is confirmed. DMLY asks for nothing. | | **Pay after the appointment** | The booking is confirmed straight away, then DMLY sends the client a payment link. | | **Pay before booking** | The slot is held, not confirmed, until the payment clears. | **Payment mode does nothing on a free service.** Both paid modes additionally require a price above zero — set **Pay before booking** on a service priced at 0 and it is simply ignored, and the booking confirms for free. The form says as much: *Set a price above 0 to require payment.* **Pay before booking** is the strict one, and it is worth understanding before you switch it on. The booking is created as a **15-minute hold**. During that hold nothing else fires — no confirmation message, no reminders, no calendar event, no automation trigger. All of it waits for the payment. If the client pays, the booking confirms and everything catches up. If they never pay, the hold expires after 15 minutes and the slot goes back on sale. If the payment fails, the slot is released too. **Pay after the appointment** confirms first and asks second. Sending the payment link is best-effort: if your gateway is missing or errors, the booking stays confirmed regardless. You get the booking; you chase the money yourself. **Pay before booking** needs a connected payment gateway or the service cannot be booked at all. With no gateway, DMLY refuses the booking up front and tells the client *"Online payment isn't available right now. Please contact us to book this service."* No hold is created and you never hear about it. Connect a gateway first — see [Payments and gateways](/finance/payments-and-gateways) — or use a different payment mode. Payment behaviour is covered in full on [Appointment payments](/appointments/payments). ### Booking with credits A service can carry a **Credit cost** — *Number of credits this service consumes when a client books with a plan.* When the service has a credit cost and the client has the balance, booking draws down one lot of credits, once per booking. See [Plans and credits](/offerings/plans-and-credits). **Credits are not an alternative to paying.** They are drawn down *in addition to* whatever the payment mode does. Give a service both a price and a credit cost and a booking charges the client's card **and** burns their credits. To make a service credit-only, leave its price at 0 and its payment mode at **No payment required**. ## How services drive availability You do not set opening hours on a service. Hours belong to **staff**. A service decides which staff can deliver it, and the offered slots are then built from those people's working hours. To produce the times a client sees, DMLY starts from the assigned staff member's **Working hours** — read in that staff member's own timezone, so a remote colleague's 9-to-5 is their 9-to-5 — and then removes: Anything inside the minimum notice window, or past the booking horizon. Busy periods from the connected calendar, so a booking never lands on top of a personal appointment. See [Calendar sync](/appointments/calendar-sync). Existing bookings for that staff member, plus the service's buffers either side of each one. One-off blocks and time off for that staff member, and workspace-wide blocks such as a public holiday. Whatever survives is offered. If the service is set so clients do not pick a person — **Hide staff selection**, *Clients won't choose a staff member; one is assigned automatically* — the page offers the **union** of every eligible staff member's free slots, and DMLY assigns someone when the booking is made. A slot appears if *anyone* who can deliver that service is free. A service that shows no available times almost always has a staff problem, not a service problem. Check that at least one staff member is assigned to it, is active, has **Accepts bookings** on, and has **Working hours** set. See [Staff and availability](/appointments/staff-and-availability). A service can carry its own weekly availability, and DMLY falls back to it when the assigned staff member has no hours of their own. This is how the older **Meetings** screen worked before staff existed. It still functions, but it is the fallback, not the design — set hours on your staff and let the service stay a service. ## Getting a service onto your booking page A service appears in your public booking catalogue only when it is active, set to be publicly visible, and is an appointment or a class. Add-ons never appear. If your booking page shows nothing at all, it is because no service passes all three tests. Where you create and edit services, set prices, categories and payment modes. Working hours, time off and per-staff service assignments — the source of every slot. The public page your services appear on, and how to share it on WhatsApp. Holds, payment links, expiry and failed payments in full.