> 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/operasional/resource.md).

# Resource: Provider & Ruangan

**Data Master → Resources.** Resource adalah apa pun yang ikut menentukan apakah sebuah slot bisa dibooking, atau yang menambah biaya pada booking.

Menu ini punya dua tingkat:

* **Resource** — kelompoknya. Contoh: `Instruktur`, `Terapis`, `Ruang Treatment`.
* **Item Resource** — isinya. Contoh: Elma, She-Nie, Sevia, Shafa di dalam kelompok `Instruktur`.

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

## Dua jenis resource

**Jenis provider** — bisa dibooking, punya jadwal ketersediaan sendiri, dan **menempati slot**. Sistem memeriksa bentrok jadwal untuk resource jenis ini. Terapis, instruktur, ruangan, kursi, meja pijat.

**Jenis add-on** — tidak bisa dibooking dan tidak menempati slot. Fungsinya hanya **menambah harga** ke total booking. Masker premium, air minum tambahan, handuk.

{% hint style="info" %}
Kalau sesuatu tidak punya jadwal dan tidak bisa "penuh", itu add-on — bukan provider. Salah menempatkannya membuat slot hilang tanpa alasan yang jelas.
{% endhint %}

## Mode kapasitas — bagian yang paling sering salah

Setiap kelompok resource punya **mode kapasitas**, dan ini menentukan dari mana angka kapasitas diambil.

| Mode                | Kapasitas diambil dari                                             | Cocok untuk                                                                   |
| ------------------- | ------------------------------------------------------------------ | ----------------------------------------------------------------------------- |
| **Shared** (bawaan) | Angka **kapasitas pada slot jadwal**. Jumlah item tidak membatasi. | Satu orang melayani seluruh peserta sekaligus — instruktur kelas, host event. |
| **Per item**        | **Jumlah item aktif** di kelompok itu.                             | Satu unit melayani satu pelanggan — terapis, ruangan, kursi, alat.            |

```mermaid
flowchart LR
  subgraph S["Mode Shared"]
    S1["1 instruktur"] --> S2["Kapasitas 20<br/>dari jadwal slot"]
  end
  subgraph P["Mode Per item"]
    P1["8 terapis aktif"] --> P2["Kapasitas 8<br/>dari jumlah item"]
  end
```

**Contoh salah kaprah:** studio yoga dengan 4 instruktur dan kelas berkapasitas 20. Kalau modenya dipasang `per item`, kelas jadi dibatasi 4 orang — karena sistem menghitung kapasitas dari jumlah instruktur. Yang benar `shared`, sehingga kapasitas 20 diambil dari jadwal.

**Kebalikannya:** klinik dengan 8 terapis, satu terapis melayani satu pelanggan. Kalau dipasang `shared`, sistem membiarkan lebih dari 8 booking masuk di jam yang sama. Yang benar `per item`.

## Satu kelompok provider per bisnis

Storefront menampilkan **satu chip filter per nama kelompok resource yang bisa dibooking**. Kalau Anda punya dua kelompok berisi orang yang sama — misalnya `Terapis` dan `Praktisi` — pelanggan melihat dua chip dengan daftar orang yang sama persis.

Gabungkan menjadi satu kelompok. Kalau kelompok lama sudah terpakai di booking lama, jangan dihapus — cukup nonaktifkan agar tidak lagi muncul.

## Provider ditugaskan per slot

Pada mode **shared**, setiap slot jadwal harus mencantumkan siapa yang bertugas. Provider yang tidak mengajar di slot itu ditandai **tidak aktif** pada slot tersebut.

{% hint style="warning" %}
Kalau seluruh provider dibiarkan aktif di semua slot, storefront menampilkan **seluruh daftar instruktur pada setiap kelas** — pelanggan bingung memilih, dan datanya salah. Ini keluhan yang benar-benar pernah terjadi. Pastikan hanya yang bertugas yang aktif di setiap slot.
{% endhint %}

## Staf dan provider adalah dua data terpisah

Orang yang sama sering perlu didaftarkan dua kali, dan itu memang disengaja:

| Didaftarkan sebagai | Untuk apa                                                     | Di mana                                 |
| ------------------- | ------------------------------------------------------------- | --------------------------------------- |
| **Staf**            | Punya akun untuk login ke portal.                             | Data Master → Staf & Peran              |
| **Item Resource**   | Bisa dipilih pelanggan saat booking, dan menghasilkan komisi. | Data Master → Resources → Item Resource |

Keduanya tidak saling terhubung. Menghapus salah satu tidak menghapus yang lain. Kalau seorang terapis berhenti, nonaktifkan **keduanya**.

## Ketersediaan

Setiap item resource jenis provider punya jadwal mingguannya sendiri: hari mana aktif, jam berapa sampai jam berapa.

Jadwal ini **memotong** jadwal layanan. Layanan boleh buka 10.00–20.00, tapi kalau seorang terapis hanya tersedia 14.00–20.00, dia tidak muncul sebagai pilihan pada slot pagi.

```mermaid
flowchart LR
  A["Jadwal layanan<br/>10:00 - 20:00"] --> C{{"Slot yang tampil"}}
  B["Terapis A tersedia<br/>14:00 - 20:00"] --> C
  C --> D["Pagi: terapis A<br/>tidak tampil"]
  C --> E["Sore: terapis A<br/>bisa dipilih"]
```

Kalau seluruh provider yang ditugaskan ke suatu slot sedang tidak tersedia, slot itu tidak muncul sama sekali.

## Harga per provider

Satu layanan bisa punya harga berbeda tergantung siapa yang mengerjakan — senior lebih mahal dari junior. Atur di kolom harga per provider pada slot waktu di jadwal layanan.

## Komisi

Hanya resource jenis **provider** yang menghasilkan komisi. Ruangan, peralatan, dan add-on tidak. Lihat [Komisi Provider](/pertumbuhan/komisi.md).

## Contoh nyata

Lihat [Contoh Penerapan](/mulai/contoh-penerapan.md) untuk dua model yang berbeda: studio kelas dan klinik terapis.


---

# 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/operasional/resource.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.