How to Build a Fair Restaurant Shift Schedule

A restaurant schedule fails in one of three ways: the rush is understaffed, the same three people work every weekend, or someone closes at 01:00 and opens at 08:00. Each failure has the same root cause — the rota is built from who is free, not from what the week actually demands.

This guide walks through the order that works: demand first, rules second, people last.

Start with demand, not with names

Before a single name goes on the grid, write down what each day needs. For a mid-size restaurant that usually means something like:

Day part	Typical need
Lunch (12:00–15:00)	1 chef, 1 line cook, 2 servers, 1 bar
Quiet afternoon (15:00–18:00)	1 cook, 1 server
Dinner rush (18:00–22:00)	1 chef, 2 line cooks, 4 servers, 1 bar, 1 runner
Close (22:00–00:30)	1 cook, 2 servers

Two details matter more than the numbers themselves.

First, a headcount you state is concurrent, not cumulative. "Four servers at dinner" means four people on the floor at the same time, which — with a 20:00 shift change — may mean six people scheduled. Rotas that confuse the two are chronically short exactly when the room is full.

Second, demand is not flat inside a day part. Friday dinner is not Tuesday dinner. Build the week from the day parts that actually differ and copy the rest.

A useful sanity check before you go further: add up the hours your demand table implies for a full week and compare it with the hours your team actually has under contract. If the demand needs 380 hours and your roster supplies 310, no scheduling technique will save the week — you are short two people, and every rota you build will quietly borrow the difference from someone's rest day. Finding that out on a spreadsheet on Monday is much cheaper than finding it out on the floor on Saturday.

Turn policy into rules the schedule cannot break

Once demand exists, write your policy as constraints rather than as intentions. The useful distinction is hard versus soft.

Hard rules are the ones a published schedule may never violate:

• Minimum rest between shifts. Eleven consecutive hours is the benchmark daily rest period in the EU Working Time Directive; even outside its jurisdiction it is a sensible floor, and it is what kills the close-then-open pairing.
• Maximum consecutive days, and maximum consecutive late/closing shifts.
• Required qualification on the shift: a shift with alcohol service needs a certified bartender; a kitchen needs at least one person with food-safety certification on every shift.
• Contracted hours floors and ceilings — a part-timer's cap is a rule, not a preference.

Soft rules are the ones you optimise toward and occasionally trade away:

• Even distribution of weekend and closing shifts.
• Preferred pairings (a new server on the floor with an experienced one).
• Stated preferences: someone who wants mornings gets mornings when the week allows.

Writing the distinction down is what makes a schedule reviewable. When you need to break something at 17:00 on a Friday, you want to know you broke a preference and not a rest period.

Make fairness a number

"Fair" collapses the moment two people disagree about it, so replace the adjective with a tally. Track per person, over a rolling eight weeks:

1. Weekend shifts (Friday and Saturday evenings).
2. Closing shifts.
3. Total scheduled hours against contracted hours.
4. Holiday and peak-date shifts.

Then schedule the scarce, unpopular slots from the bottom of the tally upward. Two things change immediately: the argument moves from "you always give her the good shifts" to "my count is wrong, here is why", which is a fixable conversation; and the people who quietly absorbed every bad shift stop quietly deciding to leave.

Publish the tally alongside the schedule. Fairness that nobody can see is indistinguishable from favouritism.

Collect availability once, in one place

Most scheduling pain is actually intake pain: availability arriving by WhatsApp message, verbal aside, and a note on the pass, then living only in the manager's head.

Fix the intake and the rota gets easier on its own:

• One channel, one deadline. Availability for the next period closes at a fixed hour on a fixed day. Anything after the deadline is a swap request, not availability.
• Separate the three things staff actually mean: cannot work (hard), prefer not to work (soft), want extra shifts (opportunity). A rota built from a single yes/no field cannot distinguish a doctor's appointment from a mild preference.
• Keep a standing weekly pattern per person and collect only the exceptions. Students and second-jobbers repeat the same shape most weeks.

Write the swap policy before you need it

Swaps are where a good schedule quietly turns into an illegal or understaffed one. A workable policy is short:

• A swap is between two people who are both qualified for the shift.
• A swap must not break a hard rule for either person — rest period, consecutive days, hours cap.
• A swap is not final until a manager approves it, and the approved swap updates the published schedule. An unrecorded swap means the person you call at 18:00 is the wrong person.
• Repeated late swaps by the same person are an availability conversation, not a discipline one.

Publish on a rhythm, and protect it

Pick the day and hour you publish and never move it. Predictive-scheduling laws in several cities require advance notice and pay a premium for late changes, but even where nothing obliges you, a predictable publish day is what turns your schedule into something staff plan their lives around. Late, moving schedules generate exactly the behaviour managers complain about: last-minute unavailability, no-shows, and turnover.

Check hours and break entitlements against your local rules before you publish, not after. Break and meal-period requirements in the United States are set largely at state level rather than federally, so the applicable rule is the one where the restaurant actually operates.

One last habit that costs nothing: after the week is over, spend ten minutes comparing what you published with what actually happened. Which shifts were swapped, which ran short, where did you call someone in? Those three answers are next week's demand table. A rota that never gets compared against reality drifts toward the manager's assumptions; one that does gets more accurate every week, and the accuracy is what eventually buys you the two-week notice period.

How WeekEye handles this

WeekEye is built around exactly this order — demand, then rules, then people.

• Describe the restaurant in plain text. The AI org builder reads a brief such as "restaurant, 14 staff, kitchen and floor, lunch and dinner, closed Monday" and creates the positions, shifts and weekly structure for you, instead of starting from an empty grid.
• Rules are first-class objects. Rest between shifts, maximum consecutive nights, required qualification on a shift and fairness of distribution are rules you state once; the scheduler respects them when it generates a week and flags it when a manual edit breaks one.
• Bring the rota you already have. If your schedule lives in a spreadsheet, Excel import reads it and turns people, shifts and assignments into real entities — no retyping a year of history.
• Employee availability comes in as structured input, not as chat messages, so the generator can tell "cannot" from "prefer not".
• Publishing is a deliberate step. You generate, review, adjust, and then publish — the staff-facing schedule is the version you approved.

Nothing above requires a consultant or a migration project; it requires the week's demand written down once.