> 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/resources-providers-and-rooms.md).

# Resources: Providers & Rooms

**Master Data → Resources.** A resource is anything that helps determine whether a slot can be booked, or that adds cost to a booking.

This menu has two levels:

* **Resource** — the group. Example: `Instructor`, `Therapist`, `Treatment Room`.
* **Resource Item** — its contents. Example: Elma, She-Nie, Sevia, Shafa inside the `Instructor` group.

```mermaid
flowchart TD
  G["Resource (group)<br/>Therapist"] --> I1["Item: Agnes"]
  G --> I2["Item: Efan"]
  G --> I3["Item: Kia"]
  G --> I4["Item: Melinda"]
```

## Two kinds of resource

**Provider kind** — can be booked, has its own availability schedule, and **occupies a slot**. The system checks for schedule conflicts on this resource kind. Therapists, instructors, rooms, chairs, massage tables.

**Add-on kind** — cannot be booked and does not occupy a slot. Its only function is to **add a price** to the booking total. Premium mask, extra drinking water, towels.

{% hint style="info" %}
If something has no schedule and can never be "full", it's an add-on — not a provider. Placing it wrong makes slots disappear for no obvious reason.
{% endhint %}

## Capacity mode — the part that's most often wrong

Every resource group has a **capacity mode**, and it determines where the capacity number comes from.

| Mode                 | Capacity comes from                                                                  | Fits                                                                            |
| -------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
| **Shared** (default) | The **capacity number on the schedule slot**. The number of items does not limit it. | One person serves the entire group at once — a class instructor, an event host. |
| **Per item**         | The **number of active items** in that group.                                        | One unit serves one customer — a therapist, a room, a chair, an appliance.      |

```mermaid
flowchart LR
  subgraph S["Shared mode"]
    S1["1 instructor"] --> S2["Capacity 20<br/>from the schedule slot"]
  end
  subgraph P["Per item mode"]
    P1["8 active therapists"] --> P2["Capacity 8<br/>from item count"]
  end
```

**Common mistake:** a yoga studio with 4 instructors and a class capacity of 20. If the mode is set to `per item`, the class ends up limited to 4 people — because the system calculates capacity from the number of instructors. The correct mode is `shared`, so capacity 20 is taken from the schedule.

**The reverse:** a clinic with 8 therapists, where one therapist serves one customer. If set to `shared`, the system allows more than 8 bookings into the same time slot. The correct mode is `per item`.

## One provider group per business

The storefront shows **one filter chip per bookable resource group name**. If you have two groups containing the same people — for example `Therapist` and `Practitioner` — customers see two chips with the exact same list of people.

Merge them into one group. If the old group is already used in past bookings, don't delete it — just deactivate it so it no longer shows up.

## Providers are assigned per slot

In **shared** mode, every schedule slot must list who is on duty. A provider who isn't teaching that slot is marked **inactive** for that slot.

{% hint style="warning" %}
If every provider is left active on every slot, the storefront shows the **entire list of instructors on every class** — customers get confused choosing, and the data is wrong. This is a real complaint that has actually happened. Make sure only the people on duty are active on each slot.
{% endhint %}

## Staff and providers are two separate records

The same person often needs to be registered twice, and that's intentional:

| Registered as     | For what                                                             | Where                                    |
| ----------------- | -------------------------------------------------------------------- | ---------------------------------------- |
| **Staff**         | Has an account to log into the portal.                               | Master Data → Staff & Roles              |
| **Resource Item** | Can be selected by customers when booking, and generates commission. | Master Data → Resources → Resource Items |

The two are not linked to each other. Deleting one does not delete the other. If a therapist leaves, deactivate **both**.

## Availability

Every provider-kind resource item has its own weekly schedule: which days are active, and from what time to what time.

This schedule **trims** the service schedule. A service may be open 10:00–20:00, but if a particular therapist is only available 14:00–20:00, they don't appear as an option on morning slots.

```mermaid
flowchart LR
  A["Service schedule<br/>10:00 - 20:00"] --> C{{"Slots shown"}}
  B["Therapist A available<br/>14:00 - 20:00"] --> C
  C --> D["Morning: Therapist A<br/>not shown"]
  C --> E["Afternoon: Therapist A<br/>selectable"]
```

If every provider assigned to a slot is unavailable, that slot doesn't appear at all.

## Per-provider pricing

A single service can have a different price depending on who performs it — a senior costs more than a junior. Set this in the per-provider price field on the time slot in the service schedule.

## Commission

Only **provider**-kind resources generate commission. Rooms, equipment, and add-ons don't. See Provider Commission.

## Real examples

See Worked Examples for two different models: a class studio and a therapist clinic.


---

# 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/resources-providers-and-rooms.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.