> ## Documentation Index
> Fetch the complete documentation index at: https://docs.soundchecklive.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Availability requests
> Ask specific crew members whether they're free for a date or time window, and collect their answers in one place.
Availability requests let schedulers ask specific members whether they're free for a date, a whole day, or a time window — instead of texting everyone and chasing replies by hand.
Crew availability and offers are enabled per organization. If you don't see the **People** workspace or availability requests, the feature isn't turned on for your team yet.
Answers arrive in each recipient's [**My Mailbox**](/features/engagements/overview) as **Availability checks**, right alongside invitations and crew offers. Admins track outstanding responses on the org-wide [Mailbox](/features/engagements/overview) view.
## Who can send requests
Owners, admins, and gig coordinators create and send requests from the **People** workspace (**Availability → People** on the web app). Members can only respond to requests sent to them.
## Request lifecycle
```mermaid theme={null}
stateDiagram-v2
[*] --> DRAFT: Create request
DRAFT --> OPEN: Send to recipients
OPEN --> RESPONDED: Member responds
RESPONDED --> [*]: Answer reconciled into the calendar
```
## Create a request
From the People workspace, open **Request availability**. A request can include:
* A **title**
* A **date**
* A **mode**: **Whole day** or a specific **time window**
* Optional **start and end time** (for a time window)
* Optional **position filter** — target only the roles you need (keys, FOH, stage manager, and so on)
* **Recipients**
* An optional **linked gig** and **expiration date**
If you pick recipients while creating the request, Soundcheck sends it in one step. Otherwise it stays a draft until you send it.
## Candidate selection
Choose recipients from your active organization members. The position filter narrows candidates when you need specific roles, so the request only reaches people who could actually fill the slot.
## Member responses
Members respond **Available** or **Unavailable**, and can add a note. There's no separate approval step — a member's answer is reconciled straight into their availability calendar, and the sender sees the update.
Only a recipient of a request can respond to it. Responses can also be given in one tap from the email notification, which deep-links to the right item in Mailbox.
## Best practices
* Send a request when you need an explicit yes/no rather than relying on standing availability.
* Use **time window** mode when call time matters; use **whole day** for general date holds.
* Link a gig when the request is tied to a specific event.
* Keep recipient lists focused with the position filter so members only get relevant asks.
## Related pages
How members manage their own availability calendar.
The organization-wide view of everyone's availability.
Practical patterns for sending requests and acting on responses.
Where availability checks, invitations, and offers land.