> For the complete documentation index, see [llms.txt](https://docs.diro.app/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.diro.app/en/operations/setting-up-service-schedules.md).

# Setting Up Service Schedules

The schedule determines what slots customers see. This is the part that most determines whether your storefront takes bookings or looks empty.

Go to **Master Data → Services → select a service → Schedule**. There are two tabs.

## Two tabs, two functions

```mermaid
flowchart TD
  A["Operational Schedule & Pricing<br/>(weekly tab)"] -->|"repeats every week"| C{{"Slots shown<br/>on a given date"}}
  B["Specific Date Schedule<br/>(specific date tab)"] -->|"overrides the weekly schedule<br/>on that date"| C
  R["Resource Availability<br/>(provider / room)"] -->|"trims slots"| C
```

**Operational Schedule & Pricing tab** — the weekly pattern. You set this per day (Monday through Sunday): open or closed, and which time slots are available that day. This pattern applies continuously, every week, with no end date.

**Specific Date Schedule tab** — the exception. Applies only to the dates you specify, and **overrides** the weekly schedule on that date. Used for holidays, special schedules, or one-off sessions.

{% hint style="info" %}
The rule is simple: **if there is a specific date schedule for a given date, the weekly schedule is ignored for that date.** It is not merged — it is replaced.
{% endhint %}

## What a day contains

Each day (or date) contains one or more **time slots**. Each slot has:

| Field                | Function                                                                                              |
| -------------------- | ----------------------------------------------------------------------------------------------------- |
| **Name**             | Optional label, e.g. "Morning Session", "Evening Class". Shown to customers.                          |
| **Start & end time** | The slot's time range.                                                                                |
| **Capacity**         | How many bookings fit into this slot. Enter `1` for a private session, `12` for a class of 12 people. |
| **Price**            | Optional. If filled in, it overrides the service's base price — for weekend or peak-hour pricing.     |
| **Provider / room**  | Which resource is assigned to this slot, including a special per-provider price if there is one.      |
| **Booking cutoff**   | Optional. Overrides the service's booking cutoff specifically for this slot.                          |

Besides slots, each day can also have **locked time** — a block of time in the middle of the day that cannot be booked, such as a lunch break. Give it a name, a start time, and an end time.

## Example 1 — A salon with daily operating hours

The business is open Tuesday through Sunday, 10:00–20:00, with a break from 13:00–14:00, closed every Monday.

On the **Operational Schedule & Pricing** tab:

* Monday — disable this day.
* Tuesday through Sunday — active, one slot `10:00–20:00`, capacity matching your number of chairs.
* Add a locked time of `13:00–14:00` named "Break" on every active day.

Customers will see slots following the service duration within that range, with the lunch break unavailable.

## Example 2 — A weekly yoga class

Vinyasa class every Tuesday and Thursday, 18:00–19:00, maximum 12 participants.

On the **Operational Schedule & Pricing** tab:

* Tuesday — active, one slot `18:00–19:00`, name "Vinyasa Flow", capacity `12`, provider: the instructor teaching it.
* Thursday — the same.
* Other days — inactive.

This class automatically repeats every week without you touching it again. Customers see it on the storefront's **Timetable** page.

## Example 3 — A recurring class that sometimes needs to change or be cancelled

The problem with Example 2: if the instructor is unavailable on the 12th, you cannot cancel just that one session — the weekly schedule applies to every week at once.

The solution is **Materialize**. This feature turns the weekly pattern into date-by-date entries for a time range you choose.

```mermaid
flowchart LR
  W["Weekly pattern<br/>Tuesday 18:00"] -->|"Materialize<br/>1–31 October"| D1["Tue, Oct 7 18:00"]
  W --> D2["Tue, Oct 14 18:00"]
  W --> D3["Tue, Oct 21 18:00"]
  W --> D4["Tue, Oct 28 18:00"]
  D2 -.->|"can be edited or<br/>cancelled on its own"| X["Closed:<br/>instructor on leave"]
```

How to use it:

1. Build the weekly pattern first on the Operational Schedule & Pricing tab.
2. Open **Materialize**, choose the date range — e.g. October 1 to December 31.
3. Run it. Each session is now its own row on the Specific Date Schedule tab.
4. Edit or disable specific sessions as needed.

{% hint style="warning" %}
Once materialized, those dates **no longer follow** the weekly schedule. If you change the class time on the weekly tab, dates that were already materialized still use the old time. Change both, or re-materialize for the next range.
{% endhint %}

## Example 4 — Monthly sessions or an irregular schedule

A workshop that runs once a month, or a session whose dates you set manually.

DIRO **does not have a monthly recurrence rule** ("every first Saturday") as a dedicated setting. What you need to do: enter the dates as a specific date schedule.

On the **Specific Date Schedule** tab, one entry can cover:

* **A single date** — October 5.
* **A date range** — October 5 to 9, the same schedule for every day in that range.
* **A list of dates** — October 5, November 2, December 7 together in one entry.

For a monthly workshop, use the **list of dates** form: enter all the dates for the coming quarter in one entry, with the same time slot and capacity. Add the next batch of dates as the period nears its end.

## Example 5 — Closing a specific date

National holidays, renovation, or a collective day off.

On the **Specific Date Schedule** tab, create an entry for that date (or date range) and **disable its status**. Because a specific date schedule overrides the weekly schedule, that date is closed even though the weekly schedule is open.

## Duration, buffer, and duration options

On the service form (not on the schedule tab):

* **Duration** — how long one booking lasts. This is what splits a slot range into time choices for the customer.
* **Buffer time** — cleanup or preparation time after a booking, before the next booking can start.
* **Minimum booking cutoff** — how far in advance of the scheduled time a customer can still book.
* **Maximum bookings per slot** — the base capacity, which can be overridden per time slot.

A single service can also have **several duration options** at different prices — for example, a 60-minute massage at Rp 150,000 and a 90-minute one at Rp 210,000. The customer chooses the duration when booking, and slots are calculated based on the duration chosen.

## Resource availability trims the schedule

The service schedule determines when a service **can** run. Provider and room availability determines who **is able** to run it.

If a slot is assigned three therapists and only one is available at that time according to their resource schedule, the customer only sees one option. If none are available, that slot does not appear at all.

Set this up in **Master Data → Resources → Resource Items → select an item → Schedule**. The format is weekly, per day. See Resources: Providers & Rooms.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.diro.app/en/operations/setting-up-service-schedules.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
