What is shift bidding, and when does it actually work?

Shift bidding lets team members signal their preferences for upcoming shifts, and managers assign accordingly. Instead of building the schedule top-down and asking people to fit, the manager surfaces preferences first and assigns based on what people actually want.

It is most common where shifts have meaningfully different desirability (peak weekends pay more, night shifts are harder, some clients are easier than others, some venues are closer to home) and the workforce is variable enough that preferences shift week to week. The mechanic comes in two main forms. The traditional cycle, run monthly or fortnightly, is common in hospitality, healthcare, retail, and at the largest scale in aviation, where pilots and cabin crew bid systems have been operating for decades. The on-demand version posts individual jobs to a pool as they arrive and lets available people signal interest one job at a time. That second pattern fits events, catering, festival crews, surge staffing, and any team where work arrives as irregular bookings rather than predictable weekly patterns.

For workers, shift bidding usually serves one of two motivations. Casual or zero-hour workers bid widely to maximise income: they signal availability for as many shifts as possible and want to be picked for whatever they can get. Salaried or contracted workers bid for fairness: they want a distribution of the good and bad shifts that reflects their preferences rather than the manager’s intuition.

This guide covers when each form earns its overhead, the criteria you need to set, the failure modes that show up, and how to choose between them.

When shift bidding earns its overhead

A bidding cycle adds real overhead: the announcement, the bid window, the resolution, the override conversations, the appeals. It only pays back if the situation genuinely warrants it. Three conditions need to be true:

More people than shifts to fill. Bidding only makes sense when there is competition. If you have 12 shifts and 10 people who can take them, you do not have a bidding problem, you have a coverage problem, and the answer is recruiting more people or paying more for the harder slots, not a bid cycle.

Preferences are genuinely dynamic. If everyone’s availability is stable from week to week (Maria always wants Monday morning, John always wants Thursday evenings) a fixed schedule with occasional adjustments works just as well as bidding, and avoids the overhead. Bidding pays back when preferences shift week to week because of changing childcare, study schedules, second jobs, or personal life. In that situation, the bid window becomes a recurring availability submission, and the information is genuinely useful to the manager.

The team is big enough to justify the formality. Under about eight people, the manager can have a five-minute conversation with each person and skip the cycle entirely. Above that, those conversations become the manager’s whole week, and a structured bid saves time.

Some things look like bidding problems but are not:

“Everyone wants day shifts and nobody wants evenings.” This is not a bidding problem, it is a compensation or rotation problem. Pay more for evenings until demand for them rises, or rotate the unpopular shifts explicitly. Bidding will not fix uneven shift desirability when there is no real competition for the bad shifts.

“We need everyone to bid so the manager can build the schedule.” If the manager is using bids primarily as an availability check rather than a competition between preferences, you are not really running shift bidding. You are running an availability collection process, which is simpler and probably better suited to the on-demand pattern described later in this guide.

The criteria you need to set

The mechanic of bidding is simple. What makes it work or break is the criteria, decided before the first cycle and shared with the team in writing. The simple rules first: open the bid window two weeks ahead and close it a week before the schedule starts; default to manager assignment for anyone who does not bid, with no preference rights (make this explicit, or the bidders feel like they are doing extra work for no advantage). The harder rules below need more thought.

Priority weighting. When two people bid for the same shift, who wins? Common options: seniority, performance, availability percentage (people available for more shifts get priority on their preferred slots), rotation, or a hierarchy that uses one as the primary and another as a tie-breaker.

The trap is that a single weighting consistently disadvantages the same people. A junior performer who keeps losing bids will end up with the leftovers no one else wanted, fewer hours overall, and progressively less engagement with the bid system. The fix is either an explicit floor (every team member gets a minimum number of preferred shifts per cycle, regardless of weighting) or rotation as a hard requirement that overrides pure performance or seniority. Without one of those, the bid system becomes a slow path out of the team for the people who keep losing.

Bid caps. How many shifts can one person bid for? This depends on whether you have over-supply or under-supply, and it can go in either direction.

In an over-supplied team (more people than shifts available), cap the bids near the target count. Without a cap, people bid for everything to maximise chances and then back out of assignments they did not actually want. The cap forces commitment: if you bid for it, you can take it.

In an under-supplied team (more shifts than easily fillable), you may need to require over-bidding, say 150 percent of target. The manager then has flexibility to build a coverage-complete schedule without leaving uncovered shifts. The trade-off is more “I did not really want that one” conversations after assignment.

There is no universally right number. The principle: align the bid count with what the manager actually needs to build a workable schedule.

Manager override rules. Sometimes the bid result genuinely will not work: no one bid for Sunday morning, the only experienced person is missing from the Friday night bid, a client requires a specific team member. Document when override is allowed and how it is communicated. “Manager may override for operational coverage, with notification and reasoning to the affected team members” is workable. “Manager has final say” without explanation is not, because it is indistinguishable from arbitrary decision-making from the team’s side.

How a bidding cycle runs

The mechanics are standard: open the bid window with the resolution criteria attached, collect preferences within the cap, resolve and assign by the criteria (with the manager filling in for uncovered shifts), publish for confirmation within a set window (often 48 hours), then open the swap window for post-publication changes.

For a 20-person team running a fortnightly cycle, the whole process should take the manager about an hour. If it is taking a day, either the criteria are too loose (too many ambiguous cases need judgement) or the bid pattern is too contested (too many people fighting over scarce shifts, which is its own signal that something needs adjusting).

Where shift bidding goes wrong

Beyond the per-rule failure modes covered above, two patterns cut across the whole system:

Vague criteria, applied ad-hoc. If the team cannot predict who will win a contested bid, they will assume the manager is playing favourites, even when the manager is not. The fix is written criteria, applied consistently and visibly. Show your work when you assign.

Unequal information. Senior team members know which shifts pay better, which are easier, which client gives bigger tips. New members do not. Document the shifts (location, expected workload, client, expected hours, pay if it varies) so the bid is informed for everyone. Otherwise the criteria look fair but the outcomes are not.

On-demand bidding: jobs posted to the pool

The traditional cycle assumes a regular schedule with periodic planning windows: monthly or fortnightly, with bids on shifts mostly known weeks in advance. That fits a lot of hospitality, healthcare, and aviation work.

For on-demand teams, the cycle does not match how the work arrives. A wedding is booked for next Saturday on a six-week lead. A corporate event needs a 30-person crew with three weeks notice. A catering company gets a request for tomorrow’s lunch service. A staffing agency takes a call for a short-notice retail surge. Each of these is its own bid moment, not part of a predictable rhythm. Running them through a monthly cycle would not work: half the jobs would not exist when the cycle opens.

The on-demand version of the same logic:

A job is posted to the pool. The shift, the location, the role, the pay rate, the expected hours, the supervisor on site, anything else the responder needs to decide whether to take it.
Available team members signal interest. Through a mobile app, usually with a single tap. The bid is “yes, I want this,” not a ranked preference among many options.
The manager picks from the responders. Based on skills, fairness, recent assignment history, location, or whatever criteria fit the work.
The pool moves on. The unassigned people get the next post when it arrives, not a “you lost this round” notification.

This pattern removes most of the criteria-setting complexity of the monthly cycle. There is no priority weighting between five competing bids, because the manager picks one from the responders rather than running a tournament. There is no bid cap, because each post is independent. There is no override conversation, because the manager is doing the assignment directly.

What the on-demand pattern needs instead is care in three specific places.

The job post. The post is the bid invitation. If it is light on information, the bids you get back are uninformed, and the pool that responds is the people willing to bet on incomplete information rather than the people best suited to the work. Treat the post like the standard brief for any delegated task: outcome (what the worker will be doing), deadline (when the shift starts and ends), background reference if relevant (a setup document, a previous version of the same job), support channel for pre-bid questions.

The pick criteria. When a job is posted and three or four people respond, the manager needs a quick decision rule. The common criteria:

Skill or qualification fit. The wedding asks for two experienced servers and one barback; pick from responders who meet those qualifications.
Recent assignment history. If one responder has worked three shifts this week and another has worked one, weighting the lighter-loaded responder is fairer and keeps both people available for future jobs.
Location or convenience. The responder who lives 10 minutes from the venue is often a better pick than the one an hour away, especially for short shifts.
Performance history at similar jobs. The responder who has done this client well three times before is a safer pick than a first-timer for a high-stakes booking.

Document the pick rule the same way you would document monthly bid criteria. If the pool cannot predict who will get picked from a contested post, they will assume favouritism, which is the same failure mode that breaks monthly bidding.

Response time from the manager. The pool responds to a post within minutes. If the manager takes hours or days to pick, the responders cool off, fill the time with other work, or stop trusting that responses lead to assignments. Pick fast, or set an explicit expectation about when picks happen. A “we will pick by 2pm” note on the post is enough. Silence after responses is the thing that erodes the pool.

Three failure modes specific to the on-demand pattern:

Picking from the same favourites. The same trap as monthly bidding, but the consequence shows up faster. If the same five people get picked for every well-paid job, the other twenty stop responding. Within three or four months your active pool is twenty percent of your nominal pool, and the rest of the list is dead weight you cannot rely on for surge bookings.

Bad job posts. If posts lack the information responders need to decide, two things happen. The careful responders ignore posts because they want clarity before committing. The casual responders bid on everything because they will sort it out later. Your assignments tilt toward the second group, and the careful workers slowly leave the pool.

Simultaneous jobs handled badly. When two jobs are posted at the same time, the same responder might bid on both with the understanding that they can only be assigned one. If your process does not handle this cleanly (one of the bids gets dropped silently, or both jobs go to the same person and one has to be reassigned later) the responders learn the system is unreliable and bid more cautiously next time, which shrinks the pool of viable picks.

Most teams that run on-demand bidding also have some recurring work. A hotel’s housekeeping team might run a fortnightly bid for the regular schedule and use on-demand posts for the extra rooms when an event books at short notice. The two patterns coexist without competing, with the same workers participating in both.

Where this fits

Traditional shift bidding earns its place when the team is big enough to need formal allocation (roughly 10 to 100 people), the shifts are varied enough that people have real preferences, the schedule is regular enough to plan in cycles, and the manager can articulate the criteria clearly. Below those thresholds, simpler approaches serve better.

On-demand bidding fits operational reality for events, catering, on-demand staffing, festival crews, and any team where work arrives as irregular jobs rather than recurring weekly patterns.

Zelos handles on-demand bidding directly: open shifts get posted to your team’s pool, available members signal interest from a mobile app, and you assign from the responses. The platform also supports the surrounding coordination toolkit (team chat, role briefs against tasks, time-stamped completion data, swap mechanics for assigned shifts). The simple staffing software page explains how it works.