Staff, shifts and swaps

The people running your event need a completely different view from the people attending it, and giving them the wrong one is how organizers end up as a human switchboard for the entire weekend.

A portal for crew

Staff get their own area showing what they are assigned to and when. What they do not see is the rest of your operation: no revenue, no attendee exports, no other events, no payout information.

A door volunteer needs a shift time and a place to stand, not the finance page. This is not about trusting them — it is about the fact that access you granted for one weekend tends to survive it, and the smallest useful permission is the one that stays safe when you forget to remove it. It also makes the portal genuinely usable: a page showing three shifts is more helpful than a dashboard showing everything with three shifts somewhere in it.

Shifts

Assign people to shifts on an event and they see their own schedule.

Assignments can be accepted, which is a small feature that solves a specific and recurring problem: the difference between "I put them down" and "they know about it". Those are not the same thing, and the gap between them is only discovered at 07:00 on the day, when the person you were relying on is asleep and has never heard of the shift.

An acceptance state means you can look at a rota the week before and see which assignments are confirmed and which are wishful thinking. That is a list you can act on while there is still time.

Swaps

People get sick, trains are cancelled, and something always comes up. Rather than every change routing through you, staff can arrange a swap between themselves and have it recorded.

You keep the oversight — the rota reflects reality, so you know who is actually on the door at 20:00 — without being the switchboard. The alternative, which is what most events do, is that the change happens anyway via a group chat and your rota silently becomes fiction. A recorded swap is strictly better than an unrecorded one, and people will only use the recorded path if it is easier than texting a colleague.

Tasks

Tasks can be assigned with a status, so setup jobs have an owner rather than living in a group chat that scrolls.

This is deliberately simple. Event setup does not need a project management system; it needs a list where each item has a name next to it and a way to mark it done. The failure mode it prevents is the classic one — everybody assumed somebody else was bringing the extension leads.

Permissions work the same way as everywhere else

All of this uses the same permission system as the rest of the platform. Access is granted per event and per capability, and removing somebody removes their access.

That last point deserves emphasis, because the common alternative is a shared login or an unlisted link, and neither of those can be revoked. You are relying on a former volunteer forgetting a URL, which is not a security control. Here, when the event is over and you remove them, the access is gone.

Running a rota that works

• Build it a fortnight out, not the night before. The value of an acceptance state is the time it gives you to fix the gaps, and you only get that if you send it early.
• Over-staff the first hour. Arrivals are front-loaded at almost every event; a rota with even coverage is understaffed exactly when it is visible.
• Name a decision-maker per shift. Most door problems are judgement calls, and volunteers should not have to guess who is allowed to make them.
• Remove access afterwards. It takes a minute, and it is the difference between a permission system and a list of people who used to have keys.