II · Getting it running · Topic 3

Building the schedule

15 min

Most schedules are built from last week's schedule, which was built from the week before, back to a Tuesday in a year nobody remembers. This topic is the other way to do it: demand first, people second. It takes longer the first time and less time every week after.

📈 Start with the sales curve, not the staff list

Pull hourly sales from your POS for the last four to six weeks and look at it by day of week. You are looking for three things:

  • When the rush actually starts and ends. Not when you feel it does. Restaurants routinely staff for a 7pm peak that has been arriving at 6:30 for a year.
  • How different the days really are. If Saturday does triple Tuesday's covers, a schedule with similar staffing on both nights is a decision you would not defend out loud.
  • The dead hour. Almost every restaurant has one, and it is almost always fully staffed.

Then translate covers into hands. For each hour, ask what has to be true: how many people on the line, how many on the floor, who is on the pass, who is at the door, who is prepping for tomorrow. Write it once as a target per hour and you have a staffing template — the thing you have been rebuilding from memory every week.

🧱 The order that works

  1. Fixed points first. Opening, closing, deliveries, prep blocks, the shifts that exist regardless of how busy you are.
  2. Peak coverage second. Your best people on your biggest shifts. This is where the money is made and it is not the place for a favour.
  3. Availability and requests third. The system should refuse to schedule someone who cannot work, rather than you remembering.
  4. Fill the edges last. Staggered starts — not everyone in at 5pm — is the single biggest saving available in a schedule, and it costs nothing.
  5. Read it once as an employee. Is anyone closing and then opening? Is anyone on six days? Does one person have every Saturday? Fix it now, not after they mention it.

Staggering deserves its own line. Bringing three people in at 4:30, 5:00 and 5:30 instead of all at 5:00 saves an hour of wages a night and usually improves the setup, because the first person is not competing for the same space as everyone else.

🗓️ Publish early, and publish once

Two weeks ahead is a good standard, one week is the minimum, and in some cities advance notice is not a preference but a legal requirement — that is topic 5. Beyond any rule, the practical case is simple: people who know their schedule two weeks out arrange their lives around it and show up. People who find out on Friday start looking for a job with predictable hours.

  • Same day, same time, every week. A schedule that appears "sometime Sunday" produces a hundred small messages asking when.
  • Publish through the tool, not a photo. A photo cannot be updated, and the version problem starts again.
  • Announce changes, do not just make them. A silent edit to a published schedule is how someone misses a shift they never knew they had.
  • Keep the templates. Save a normal week, a holiday week and a summer week. Next time you are editing, not creating.

🧪 Test the schedule before the week does

Five minutes of checking beats a bad Saturday:

  • Does every hour meet the staffing target, especially the first and last hour of service?
  • Does every shift have someone who can handle a problem — a keyholder, a manager, someone who can run the floor?
  • Is anyone scheduled who has training, a holiday or an approved request on file?
  • If your busiest server called in sick on Saturday, do you know who you would call, before it happens?
  • Does the total look sane against last week's? A jump of ten hours has a reason; find it now rather than in payroll.
Answer in your own words, JP gives feedback and a progress score.