> ## 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.
# How shifts work
> The full reference for crew shifts — statuses, seats, per-day responses, what stays editable after you send, and what happens when someone declines.
Staffing on Soundcheck is built from four things. Once you can name them, the rest of this page — statuses, seats, per-day answers, what you can change after sending — follows from how they nest.
This is the deep reference. If you're staffing your first gig, start with [Building teams for gigs](/features/gigs/team-building) and come back here when you need the details.
## The four pieces
| | What it is | Where it lives |
| ------------ | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| **Position** | A role your organization staffs — Sound Engineer, Guitar Tech, Lead Vocals. Defined once, used everywhere. | [**Settings → Positions**](/organization/teams/positions) |
| **Shift** | One block of work for one position on one gig: its days, call times, pay, and how many people you need. | The gig's **Crew** or **Staffing** section |
| **Offer** | One person's invitation to a shift, with their own status and their own response. | Inside the shift |
| **Day** | One working day of a shift. On a multiday gig each day carries its own call time, rate, and answer. | Inside the shift and the offer |
Two consequences worth internalising:
* **A position can have several shifts on the same gig.** Load-in, show, and strike are three shifts for one position — including two on the same day, with some of the same people on both.
* **A shift holds many offers, and every person answers for themselves.** There is no group accept.
Give a shift its own name — "Load-in", "Show call" — rather than leaving it as the position name. On a gig with three shifts for one position, the name is the only thing telling them apart in emails and on the crew's phones.
## Two kinds of shift
You pick this when you create the shift, and it decides what "filled" means.
| | **Open shift** | **Job offer** |
| -------------- | ------------------------------------------ | -------------------------------------------------- |
| Who it goes to | Several eligible people | A specific shortlist |
| How it fills | First to accept, up to the number of slots | Everyone can accept; you set how many you **Need** |
| Use it for | "I need two hands, whoever's free" | "I want these four people" |
## Shift statuses
The shift exists only for you. Crew do not see it in their Mailbox or on the gig. Everything is editable, call times may be left blank, and there may be nobody on it yet. Nothing you do to a draft sends a notification.
People have been notified and are responding. You can still change seats, call times, and who is on it. **Pay is locked** — it is the deal they accepted, so repricing means cancelling the shift and re-issuing it.
An open shift is filled when every day is at capacity. A job offer is filled when you set **Need** and accepted crew meet it, with nobody left to answer. A filled shift reopens by itself if someone drops off.
Set an expiry when you create a shift and unanswered offers close themselves at that time. Nobody can respond after it.
Everyone still attached is notified, and unpaid payouts for the shift are voided.
## Where each person stands
Every offer carries its own status, shown on the shift and on the [Staffing](#the-staffing-grid) grid.
| Status | Meaning |
| ------------ | -------------------------------------------------------------------------------------------------------------- |
| **Pending** | Notified, hasn't answered |
| **Accepted** | On the shift; a positive fee becomes a payout |
| **Declined** | Out. Their seat goes back to the pool |
| **Standby** | Held as a backup — the next person in [call order](/organization/teams/call-lists) if someone above them drops |
Declines never fill a shift. Ten people declining does not make a shift "done" — only acceptances count toward **Need** or capacity.
## Seats: capacity and Need
**Need** is optional, and leaving it blank is a real choice rather than an incomplete form:
* **Need set** — the shift is a target. It fills when accepted crew reach that number, and the gig list and calendar show it as covered.
* **Need blank** — the roster is unbounded. Add as many people as you like; nothing claims the shift is filled, and no fill target is invented for you.
Clearing **Need**, or raising it above the crew who already accepted, opens a filled shift again. Setting it when accepts already meet it fills it.
## Multiday gigs answer day by day
On a gig spanning several days, a shift's days are the truth — not a single date range.
* Each day carries its **own call time** and, if you use a rate card, its **own rate**.
* Crew **accept and decline per day**. Someone can take Friday and Saturday and pass on Sunday.
* Capacity is counted **per day**, so Friday can be full while Sunday is still open.
* Their payout is the sum of the days they actually accepted.
Call times can run past midnight. When the out time is earlier than the call time, **Past midnight (next day)** turns on and the out time lands the next morning — you do not need a second day for a 6 PM–2 AM call.
## Adding or removing days on a live gig
A gig's dates used to freeze the moment anything went out. That rule exists to
stop agreed work from **moving** underneath the people who accepted it — but a
festival adding a load-in day, or cutting a third show, isn't that. Growing or
shrinking the range doesn't move the days anybody agreed to; it only changes
which days exist either side of them.
So what matters is the shape of the change, not the fact that it happened:
| Change | What happens |
| ----------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Add days** at either end | Saves straight through. Nothing is taken from anybody, and **no shift is extended onto the new day** — nobody gets signed up for a day they never accepted. Build shifts for the new days as usual. |
| **Remove days** nobody works | Saves straight through. |
| **Remove days crew are booked on** | You're shown exactly who comes off, on which shift, on which day — before anything happens. Confirm and they're cancelled for those days and told why. |
| **Move the gig** to different dates | Still refused. Both ends moving the same way is the case the rule was written for. Cancel the shifts first, or create a new gig. |
Removing a day is **not reversible**. The day's roster, its answers, and its
calendar invites are cancelled outright — putting the day back gives you an
empty day, not the crew who were on it.
A day that has **already passed** can't be removed at all, confirmation or not.
Someone may have shown up and been paid; that would be rewriting history rather
than changing a plan.
### What removing a day does to pay
It depends on how the shift is priced, and the notice each person gets says
which:
* **Flat rate** — a flat fee buys the shift, not the day, so **nothing changes**
for someone who still works the shift. Only when they lose *every* day does
the fee come off.
* **Rate card (per-day rates)** — their payout is recalculated from the days that
remain.
Removing work never increases what's owed for it. If a payment has already gone
out for a removed day, it is **left alone** and flagged for someone to settle by
hand rather than silently reversed.
## Pay is the deal, not a field
Once a shift goes out, its rate is what people **accepted**. Changing it would
rewrite terms someone already agreed to, so pay freezes at send — the flat rate,
the rate type, and the per-day rate card alike.
Repricing is a deliberate act: **cancel the shift and re-issue it**, which puts
the new number in front of every recipient instead of moving it underneath them.
This holds in **both directions**. A raise is still a change to agreed terms, and
one rule leaves no argument about what counts as favourable — nor any way for a
mistyped 450 to land as 45.
One exception, and it isn't really one: you can still set a rate for someone you
**add after** the shift went out. They have accepted nothing yet, so that's
agreeing terms for the first time rather than changing them. Once they accept,
their rate is fixed too.
## Editing a shift after you've sent it
This is where most of the questions come from, so here is the whole picture.
| What you want to change | On a sent shift | What happens |
| ------------------------------------------------- | --------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
| **Pay** (flat rate, per-day rates, the rate type) | Locked | Changing it rewrites terms people already accepted. Cancel and re-issue |
| **One person's rate** | Locked once they accept | Someone still deciding, or newly added, can still be given a rate |
| **Seats / Need** | Editable | May fill or reopen the shift |
| **Who is on it** | Add anytime | Only the people on that send are notified; people already waiting are not pinged again |
| **Shift name and notes** | Editable | Everyone still attached is notified of the change |
| **Call times** | Editable on a **flat-rate** shift | Everyone still attached is notified, and anyone who already accepted can decline the new time. See below |
| **Call times on an hourly shift** | Locked | On an hourly shift the hours *are* the pay, so moving them silently changes what people are owed. Cancel and re-issue |
| **Which days the shift covers** | Locked | Cancel and re-issue, or [reschedule the gig](/features/gigs/creating-gigs) to move the whole thing |
Removing someone from a live shift rebuilds it, which re-notifies the people who remain. If you only need to take one person off, expect the rest of the crew to see an update.
## Changing a call time after people have accepted
Load-in slipping an hour used to mean cancelling the shift and starting over — losing the roster and re-asking everyone from scratch. You can now move the call time in place.
Edit the shift — from **Edit shift** on the Staffing board, the day-sheet, or **Edit Crew** on the gig's Details page. On a multiday shift, change only the days that actually moved. Selecting several shifts and using **Change times** applies one window across all of them.
Before saving, Soundcheck tells you how many people have already accepted and that they'll be able to decline. Only the days you actually moved are counted.
People who accepted and people still deciding both hear about it, however they've chosen to be notified. The message names the day and the old and new windows. People who already declined, and people parked on standby, are left alone.
Anyone who already accepted sees the change in their Mailbox with two choices: **Keep my spot** or **Decline the new time**. Doing nothing keeps the spot — silence is not a drop.
The right to decline is scoped to the change. It opens for the people who answered *before* you moved the time, covers only the days that moved, and closes as soon as they respond. Someone who accepted after the change never sees a prompt — they already agreed to the new time.
### When someone declines the new time
They come off the shift for the days they declined, and everything that acceptance set up is undone:
* Their **seat is freed**, and a filled shift opens again so you can re-staff it.
* They come off the gig's **calendar** for those days, and the auto-block on their personal availability is removed, so they show as free again.
* Their **payout** is voided, or recalculated down to the days they kept.
* You're notified that they dropped, the same as any other decline.
A payout that has already been **paid**, or that has payments attached, is never voided automatically — the money genuinely moved. The person comes off the shift and the payout is left standing for you to settle by hand.
## Who gets notified, and when
| Moment | Who hears |
| ------------------------------- | --------------------------------------------------------------------- |
| You send a shift | Everyone on that send |
| You add someone to a live shift | Only the new person |
| You change the name or notes | Everyone still attached, except declined and standby |
| You change a call time | Everyone still attached, except declined and standby |
| You remove a day from the gig | Only the people who held that day — and only about the days they held |
| Someone responds | You |
| You send a reminder | People who still haven't answered |
| You cancel the shift | Everyone still attached |
| The deadline passes | People who never answered |
Saving a **draft** never notifies anyone. **Save & Send** is what opens a shift and tells people about it.
## One roster, however seats were filled
A gig's roster is the union of its accepted invitations and its accepted crew-offer recipients, de-duplicated by position and person. Whether someone was invited directly or accepted an open shift, they appear once, in one place, under one response model.
## Save the board as a team template
Once a gig is staffed the way you like, choose **Save as team** in the Staffing header. It opens the same team-template form the People → Teams tab uses, already filled in from the board:
* One seat per position, sized to the shift's **Need** (or the people on it, if that is more). Several shifts on the same position, such as one per day, fold into a single slot sized to the largest of them, so a person working every day is listed once.
* Accepted crew sit in the first seats, then pending, then standby. People who declined or were removed are not on the team, and a person who holds two positions is listed once.
* The name defaults to the gig's title plus "Team". Rename it, pick a category, trim the roster, and save.
The template lands in your organization's team library, so **Use a team** on any other gig drops the same crew shape back onto its board as draft shifts. Pay does not travel with a template; set fees on the new gig's shifts before you send.
## The staffing grid
The **Staffing** tab in the People workspace is a cross-gig matrix: your org positions as rows, upcoming gigs as columns.
* Each cell shows who's staffed for that position on that gig — accepted, pending, and declined, with backups tagged **BU**.
* Cells also surface **available** members who said they're free that date and hold that position, so you can fill a hole without leaving the grid.
* Each row shows a **"N working"** count.
This is the "who's covering what over the next few weeks" view — the place to catch an unstaffed position across every upcoming gig at once.
## Troubleshooting
Pay freezes when a shift is sent, in both directions — it's the deal people
accepted. Cancel and re-issue to reprice. You can still set the rate for
someone you add afterwards, until they accept.
Two reasons the field itself is locked, and it tells you which: it's an **hourly** shift (the hours are the pay — cancel and re-issue), or the shift is **cancelled or expired**. There's a third case the field can't show in advance — a day that has **already passed** is refused when you save, because the call either happened or it didn't.
It shouldn't — a shift reopens by itself when an accepted person comes off. If it hasn't, check whether **Need** was lowered to match the crew who remain.
Check whether they accepted only *some* days of a multiday shift. The roster reflects the days they actually took.
Notifications only go out when the *effective* window actually changes. Re-saving the same time is a no-op on purpose, so a routine save never pages your crew. Drafts never notify at all.
Check their email address, look in spam, and confirm they haven't unsubscribed. People who haven't claimed their account yet are held back until they do — the shift replays to them on signup.
## Next steps
The two ways to staff a gig, start to finish.
Your organization's position catalog.
Reusable lineups with backup call order.
How accepted fees become crew payouts.