Restaurant Staff Scheduling Software

Restaurant scheduling has constraints that general employee scheduling tools handle badly: two service periods a day with a gap in the middle, front and back of house that cannot cover for each other, a labour cost target expressed as a percentage of sales, and a workforce where somebody calls in sick on the busiest night of the week.

We sell source code you clone and run yourself, so there is nothing here to log into. For a single restaurant, a dedicated product or a well-run spreadsheet will serve better than anything you build, and the useful part of this page is what separates the products.

Labour percentage is the number the rota exists to hit

General scheduling tools ask how many people you want on Friday. Restaurant tools ask what you expect to take on Friday and show the rota as a percentage of it.

That difference drives the features worth paying for. A forecast, ideally from your till history rather than a guess. A running cost as the rota is built, so overspending is visible while it is still editable. And a comparison of scheduled against actual once the week is done, because the gap between them is where the money went.

If a product cannot show cost as a percentage of forecast sales while you are dragging shifts, it is a calendar with a restaurant theme.

The constraints that break general tools

Communication is half the product

The rota is published and then it changes. Somebody is sick, a delivery is late, the function booking grew. What staff actually judge the software on is whether they find out.

This is why the successful products in this space are as much messaging tools as scheduling tools, and why so many restaurants run a group chat alongside whatever they bought. When evaluating, check whether a shift change notifies the affected person specifically rather than broadcasting to everyone, because a channel that alerts constantly gets muted and then the alerts stop working.

Predictive scheduling rules where they apply

Some jurisdictions require advance notice of schedules and pay a premium when they change late. Where those rules apply they change the software requirement from convenience to compliance, because you need a record of when the schedule was published and what changed afterwards.

Whether they apply to you depends on where you operate, and the rules differ. It is worth checking before choosing a product, because retrofitting an audit trail is not something you can do to somebody else's software.

When restaurant groups build

Not a single site. The build case is a group or franchise where head office needs consolidated labour cost across sites without each site being able to see the others, or a restaurant tech business selling scheduling as part of a wider platform.

Both are multi-tenant problems where the scheduling is one component.

What you would start from here

There is no scheduling product in this stack. No shifts, no rota, no labour costing, no swaps, no certifications, no till integration, and no staff messaging.

What the Open Calendar template provides is the surrounding application: organizations so each site is isolated, roles and invitations so a site manager sees their own team, and a calendar with five views, drag to reschedule, and working hours built on a CalendarEvent with a start, an end, an organiser, and attendees. Underneath is a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing if you charge sites. The notifications pack covers in-app and email delivery, which is the mechanism a shift change alert would use.

Two gaps to plan around. There is no recurrence rule, and a rota is a recurring shape, so shift patterns are the first thing you would add. And attendeeIds records who was invited rather than who accepted, which is not the same as a shift assignment with a state, so the assignment model is yours to write.

You would write the shift and assignment models, the labour cost calculation against a sales forecast, the swap request with its approval rules, and the certification checks. For a single restaurant, buy something. The packs below are for the multi-site case.