Restaurant Shift Scheduling via Linear Optimization and Staff Constraints | Hacker News Reader

Restaurant Shift Scheduling via Linear Optimization and Staff Constraints

2 pointsemmahexa10 comments

I’m working on a scheduling tool for restaurant / hospitality business owners and want to get some real feedback before I go too deep.

The idea is: you pick what matters most that week (keeping labor cost down, making schedules fair, matching staffing to projected sales, etc.), and the software automatically builds a full schedule based on who’s available and how productive each person is. No more scheduling by hand.

It would: 1. Generate a weekly schedule for you 2. Respect everyone's availability/time-off 3. Keep an eye on labor cost % 4. Adjust staffing with projected sales 5. Let you compare different “optimized” versions (cheapest, most fair, best sales coverage)

If you’re the one making schedules now, what’s the most annoying part? What would make a tool like this worth using?

Appreciate any honest thoughts!

View on HN

I used to be drawn to this kind of (over)-optimization of operational efficiencies, I think it's kind of natural for programmers.

The reality though is that for most businesses, the hard part is customer acquisition, marketing, logistics - for a restaurant, site selection, decor, etc... if you get that right, you can probably solve your staffing problems pretty easily by just being 50% overstaffed, and using a whiteboard and post-it notes. If you _don't_ get that right, then no amount of efficient shift scheduling can save you.

From my experience:

Back of House: schedules are pretty much set. The only time things change is working around someone being out.

Front of House is famously a giant pot exceptions. Mix of professional waitstaff and folks who are just picking up some shifts to finance their passion/true focus(art, music, non-profits, teachers). So you'll need to work around some fun priorities.

How do you flag special events? This will require extra people on a Monday that is historically forecast-ed to be slow. Large parties is a specialist skill in a lot of restaurants. Pretty much any server can make a large party work, but normally a few of the staff really shine with that kind of work, and you'll want them staffed.

Respect everyone's availability/time-off: FOH usually has a good mix of full-time and part-time. And a lot of people are willing to pick up an extra shift with some head's up. And that's both part-times going full-time for a week, and full-timers working extra shifts. People have preferences around working/not working doubles and clopens. One of your full-timers requests a few shifts off next week because their band is playing the next town over. The human process is just to ask a few people who are working if they want to pick up those shifts. Often the person taking off will have found someone to cover for them before requesting the time off, so you'll need that input. Often the GM/AGM making the schedule has all of the human parts in their head and just works through it.

This is super helpful — thank you. Here's how I think they can be solved:

1. Flagging special events by pulling from the booking system so the schedule doesn’t assume a “normal” Monday.

2. Tagging staff by skillset (large parties, wine, expo, etc.) so the optimizer doesn’t just fill slots but matches people to the right shifts.

3. Flexible availability instead of binary availability — things like “prefer not,” “can pick up if needed,” “no doubles,” “no clopens,” or “I already have a cover lined up.”

4. Transparent fairness — showing why someone got (or didn’t get) a shift, how hours were distributed, and what trade-offs were made so it’s not a black box.

5. Built-in shift-swap handling, since FOH often sorts coverage themselves before the manager ever touches it.

How do you compare to When To work? Or Hot Schedules ?

Worth putting implementation to one side for a moment and thinking about who your typical ideal customers would be. OK, a restaurant: how many employees, how many locations? How much revenue do they do every year? If they have too few employees, not much value to add from optimisation, no matter how good it is, vs how much it would cost you to sell to them and support them. On the other hand, if they're big, there's a fair chance they're already using some competing solution that offers scheduling as but one of many features.

Sometimes podcasts like business breakdowns can have insights about what a successful company did early on to get traction. I remember listening to one about a company that was selling to restaurants, it may have been the episode about Toast [1], maybe worth a listen. IIRC there was at least one anecdote in there about something they needed to change early on to start getting a foot in the door and have fruitful conversations with restaurant owners / managers.

You might not have much luck reaching potential customers here - HN users are mostly folks who have day jobs messing with software.

See if you can get a warm introduction to restaurant owners/managers through your existing network - friends of friends or family, etc. Or try knocking on some doors!

[1] https://joincolossus.com/episode/schreiber-toast-the-restaur...

My experience scheduling workers was not in restaurants, but I assume my biggest pain point is still relevant: Gaps.

Scheduling is easy when all the availability lines up, but most of the time there are gaps where people's availability simply doesn't match the needed shifts. You need to make some people unhappy. Balancing the human side of spreading the unhappiness fairly is the biggest challenge.

Thanks — the gap issue was one of the first problems I wanted to solve with “smart” shift updates when someone cancels. Your comment made me realize I might be prioritizing the wrong MVP.

If I pivot the product on shift coverage management instead, would that be more useful? Would you pay monthly for a tool that reliably finds coverage when someone cancels?

This is a huge pain point—validating this problem is definitely not the hard part! I’ve been tackling the exact same "Spreadsheet Tetris" nightmare with TimeClout ( https://timeclout.com ).

We actually just open-sourced our solution because we realized that while the scheduling interface needs to be simple, the optimization logic (fairness, constraints, sales matching) is where the real complexity lives. Since you're building something similar, you might find our approach interesting—we use a constraint satisfaction AI solver to handle the heavy lifting.

We’re currently looking for beta testers to stress-test the scheduler in real-world hospitality scenarios. Since you're deep in this space, I'd love to hear your take on our approach vs. what you're building.

Best of luck with your tool—the market definitely needs more than just "digital spreadsheets."

It is a valid problem but hell it is a very attacked problem. There are thousands of staff scheduling solutions. I think "does the software work for your industry" > the algorithm used. E.g. if the vendor is proven to work for fire-fighters rosters then it is low risk for another station or brigade to adopt. It is other features like HR and payroll integration, access control, working time regulations and law, attendance recording etc. that will make a big difference.

You are spot on about the market saturation and the "moat" being integrations rather than just the algorithm. It is a brutal space.

I am actually building a new tool in this space (TimeClout.com) precisely because, despite those thousands of existing solutions, I saw friends running a medical unit still drowning in spreadsheets. The "proven" enterprise vendors were often too rigid or expensive for their specific needs, and the lighter tools couldn't handle complex constraints like "fairness" (e.g., ensuring everyone shares the burden of inconvenient shifts equally).

My wedge isn't just "another roster app," but focusing on the constraint solver itself—using AI to automate that complex Tetris game of qualifications, rest times, and fairness metrics that most managers do manually. I’m also betting on an open-core model (repo is at djinilabs/timeclout) because I think the logic should be transparent and hackable.

I’d be curious if you think a "better solver + open source" approach is enough to compete against the heavy HR/payroll integrators you mentioned?

Reply on news.ycombinator.com