Bid-based rostering: publish the work and let your crew ask for it
Instead of handing shifts out from the top, you publish the work for a period and staff request the named positions they want. You still decide who goes where, and a ranked standby pool is there to cover the gaps.
- 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.
No request window is open on this page; the chronometer is shown without a time.
Instruments drawn on an example night. This site carries no customer data.
Publish named work with a fixed capacity
A period is a window you set. For a venue that opens at weekends, that's the coming Friday, Saturday and Sunday. Inside it you open particular nights, choose which areas are running, and set the named positions in each one, each with its own capacity. Nobody requests a generic 'evening shift'. They ask for a specific position on a specific night.
- A 3-layer hierarchy, with labels set per venue rather than hardcoded
- Each named position has a fixed capacity, kept as master data
- Skills control which positions a person can see and request
- A night's demand is the sum of the capacities you open
No request window is open on this page; the chronometer is shown without a time.
One link, with no app or password
Each person gets a fresh signed link for the period by SMS and email. They open it, see the nights and positions on offer, and request what they want within the minimum and maximum you've set for each night. There's nothing to install or remember. The link is their login, and it changes each period, so an old one can't be reused.
- A unique token per contact per period, expiring when requests close
- Each click is logged with device, browser and a fingerprint check
- A new device on a known token is flagged for admin review
- Reminders go to anyone who hasn't responded while the window is open
Allocate by priority and reliability, with a standby pool
When requests close, one board shows the requests against each open position. You place requesters, sorted by priority tier and reliability score. The people you don't place can stay on a ranked standby list for the night instead of hearing nothing. When you confirm, everyone placed and everyone on standby is told where they stand.
- Requesters sorted by priority tier, then reliability score
- A ranked reserve for each night
- People on standby are told too, so they know where they sit
- Changes after allocation are audited, and the people affected are told
- 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.
Questions about bid-based rostering
Do staff need to install an app or create a login?
No. Each person gets a unique signed link by SMS and email for the current period. Opening the link is how they sign in, so there's no password to set or forget.
Do we still control who gets the shift?
Yes. Requests tell you who wants what, but they never place anyone by themselves. You see the requests on one board, sorted by priority tier and reliability score, and you place people yourself.
What happens to people who aren't placed?
You can keep them on that night's ranked standby list. The people at the top are told they're on standby, and the rest wait as a silent reserve. If someone who was placed drops out later, dropout recovery offers the seat to the standby list.
Can the screens use the words our venue uses?
Yes. The 3-layer hierarchy, its labels and the field names are set per venue. The engine underneath is the same for everyone; only the vocabulary changes.
Is there a minimum or maximum number of shifts someone can request?
Yes. You set a minimum and maximum number of positions a person can request each night, which keeps requests in proportion to the size of your roster.
See requests run for your next period
We'll walk you through requests and allocation using your own venue and crew as the example.