Rostering the night shift at an entertainment venue in New Zealand
A large casual crew, several areas, every weekend night of the season — allocated from the crew's own requests instead of by whoever answered the group chat first.
No request window is open on this page; the chronometer is shown without a time.
- Draft
- Requesting
- Allocating
- Scheduled
- Revise
- Live
- Completed
Allocating. Requests are in and seats are being filled. Every roster sits at exactly one station, and each station names the one thing left to do.
Instruments drawn on an example night. This site carries no customer data.
An entertainment venue's busiest nights are predictable and unforgiving at the same time. The venue knows months out which weekends it's open; what it doesn't know until close to each one is who from its casual crew is free, which named position in which area they'd rather work, and who to call when someone drops out on the night itself.
The problem before
The roster wasn't really a roster — it was a group chat. Each week someone on the operations team posted the weekend's work and asked who was in. People replied in whatever order they saw the message, the favourite positions went within minutes to whoever happened to be looking at their phone, and quieter members of the crew were often still unplaced by the time the thread had scrolled past them. Working out who was confirmed for a given position on a given night meant scrolling back through days of messages. And when someone pulled out an hour before opening — which, across a crew that size and several areas a night, happened most weekends — the only way to recover was the same group chat, hoping someone free saw the message in time.
There was no record of who had been reliable across the season, so each weekend's allocation started from scratch, weighted mostly by who was loudest in the chat.
What changed
The venue now publishes each weekend's work as named positions — a specific location inside a specific area, each with its own capacity — instead of a vague call for "who's in this weekend". Every crew member gets a private link by SMS and email, unique to them for that period, with no app to install and nothing to log into. They open the link, see which positions are on offer on which nights, and request the ones they want.
When the request window closes, the operations team allocates from one board: requesters sorted by priority and by a reliability score built from their own attendance, with the people who weren't placed held on a ranked standby list for that night rather than left in silence. When the team confirms the roster, everyone placed and everyone on standby is told where they stand before the weekend arrives.
On the night, a supervisor marks attendance from a phone, position by position. When someone withdraws through their link, or is marked unwell, unavailable or gone on the night, the vacated seat is offered to the standby list with a one-time claim link. The first valid claim takes the seat, and anyone who opens the link after that sees it has gone.
How the season runs now
Each weekend runs the same cycle: publish the positions, let the crew request by link, allocate against priority and reliability, confirm, and run the night with attendance and standby cover on a phone. When a weekend's roster is completed, the reliability history it adds feeds the next allocation — the people who turn up consistently rise to the top of the list without anyone having to remember it. What used to be a scramble through a group chat every Thursday is now a published roster the crew checks in its own time, and a standby list that is in place before the first dropout of the night.