Between Hana Group and Zareen's I have built a version of this forecast three times, once on a $36M P&L across 21 franchise units inside Walmart, Sam's Club, Whole Foods, and Target, and twice inside a $30M Michelin-recognized Bay Area restaurant group with heavy enterprise catering to Stanford, Google, Apple, Meta, LinkedIn, Salesforce, Cisco, Adobe, and Nvidia. Every version started from the same complaint from the field: the built-in forecast inside the scheduling tool is not right often enough to be worth trusting.
What follows is the model I would build on day one, in any group past three units, with the tools most operators already own.
Start with what "forecast" actually means
Half of operators I talk to say they forecast labor. What they mean is they open last year's calendar and adjust it up or down by a feel number. That is not a forecast. That is a memory exercise, and it drops accuracy the second something changes: menu, weather, a new office building down the block, an anchor tenant closing at the Walmart, a Warriors playoff run in the Bay Area.
A forecast is a number you can defend before the week starts. It has inputs, it has weights, and when it is wrong you can go back and figure out which input was off. If you cannot do the postmortem, you did not have a forecast. You had a guess.
The four inputs that actually move the number
I have tested a dozen inputs. Most of them are noise. Four of them are signal, and the ranking is roughly the same across every unit type I have run, from a food-court sushi counter to a full-service Pakistani restaurant with $2.4M in catering.
Fig. 1 · Four inputs, one weighted model, one output.
Input one: historical POS by day-part
Pull two years of sales out of Toast at fifteen-minute or hourly buckets, per revenue center. Two years is the floor because a single year does not cover the calendar shifts that break forecasts, like Easter moving four weeks or Ramadan sliding through summer. Store it in Power BI or a small Azure SQL instance. This is the base layer, and it should still explain about sixty percent of your day-to-day variance by itself.
Input two: weather
Historical weather from NOAA for training, seven-day forecast from any decent API for the coming week. Weather matters more than most operators think, especially in shoulder seasons and for patio-heavy concepts. Rain on a Tuesday lunch in downtown Palo Alto pulls fifteen percent out of the number. A ninety-five degree afternoon takes a chunk out of a hot food counter and adds it to the smoothie counter next door. In a food-court model the weather signal shows up as a mix shift, not a top-line shift.
Input three: local events
This is the input that separates a real forecast from a Toast export. Warriors playoff games. Stanford graduation. A big product launch at a nearby tech campus. A concert at the Fillmore. None of that is in the POS history and none of it is in the weather feed. You have to keep it somewhere.
The lightest tool that works is Airtable. One base per region, one table for the calendar, the general manager and the catering lead maintain it every Monday. A Zapier feed pushes the coming week's events into the model. It sounds fragile and it kind of is, but I have watched a five-minute weekly ritual add half a point of forecast accuracy for a year.
Input four: the forward book
This is the only forward-looking input in the whole model, and it is the one the general manager trusts the most. Reservations from Resy or OpenTable, translated to expected covers. Committed catering orders from the catering CRM, which is usually Salesforce or a Square catering pipeline. On a full-service unit the forward book explains why a specific Thursday will run twenty percent hot even though the year-over-year model says it will be flat.
Why the built-in 7shifts forecast falls short
7shifts has a forecast. Toast has a forecast. Both of them are good enough to schedule a normal Tuesday in a normal week. Neither of them is good enough for the weeks that actually cost you money.
The built-in models are mostly same-day-last-year, adjusted by a rolling trend and, in the newer versions, a light seasonality curve. They do not know about the concert down the street. They do not know that your reservation book is up thirty percent for Friday. They do not know that a new office tower opened three blocks away in April and lunch traffic has stepped up permanently. They will figure it out eight to twelve weeks after the change, which is exactly the wrong horizon for a labor forecast.
The other structural miss is that both tools forecast sales, then let you infer labor demand from sales. That is fine for a single-day-part concept and terrible for anything with catering, private events, or a heavy delivery mix, because the labor cost of a $1,000 catering order is very different from the labor cost of $1,000 of dine-in.
The built-in forecast is a same-day-last-year model dressed up in a chart. On a normal week it is fine. On any week that matters it is off by enough to blow your labor number.
The Power BI model shape
The model itself is not exotic. A weighted blend of the four inputs, with the weights fit on the trailing ninety days and refreshed monthly. On most of my units the final weight distribution lands somewhere close to fifty percent POS history, fifteen percent weather adjustment, twenty percent event calendar, and fifteen percent forward book, with the mix shifting hard toward the forward book on catering-heavy days.
The output is a per-day, per-day-part sales forecast, plus a labor demand curve translated through a standard productivity ratio for that concept. In Power BI it is a dozen measures and one dataflow. In production it refreshes at 3am, lands in a shared OneDrive at 5am, and pushes into 7shifts by API by 6am so it is waiting when the general manager writes the schedule.
Forecast versus actual, by day-part
The report I run every Monday is a simple grid. Forecast against actual, per unit, per day-part, for the trailing week. Colors do the work: gold when the miss is under five percent, red when it is over ten. This is the report that keeps the model honest, because once you can see where the model is off, you can figure out why.
Fig. 2 · A real weekly grid. Two red cells is a normal week.
In this sample week the Wednesday lunch miss came from a campus event we forgot to log. The Thursday catering miss came from a client canceling a $9,000 order at 4pm the day before, which the forward book had not been updated to reflect. Both misses point at process, not model. That is what you want from a good forecast report.
The Monday grid is also where I run reconciliation against QuickBooks Enterprise. The POS number and the accounting number should agree within a rounding error by Monday morning. If they do not, the forecast comparison is meaningless because you are grading the model against the wrong actual. Ten minutes on Monday to lock the actuals is the difference between a report you can act on and a report you argue about.
The labor gain, in real numbers
Across my last three deployments the labor-percent gain in the first ninety days has run between 1.4 and 2.1 points of sales. On the $30M Zareen's turnover, that math worked out to roughly $450,000 a year of recovered labor once the model was covering all three locations plus the catering commissary. On the Hana Group $36M P&L, spread across 21 franchise units, the gain was smaller per unit but larger in absolute terms because the base of overstaffed slow shifts was bigger.
None of that recovery came from cutting headcount. All of it came from putting fewer people on shifts the model saw as soft and adding one extra body to shifts the model saw as hard. The workforce did not shrink. The mix got right.
The gain also compounds in a way the labor number does not fully capture. When the general manager stops overstaffing slow shifts, the strong closers stop getting sent home at hour four. Retention on the closing crew went up eleven points in one of the Zareen's units the year after the model went live, and I do not think that is a coincidence. A schedule that reflects the actual demand curve treats people better, and people who get treated better stay longer.
The holiday warning
Every model I have shipped has been badly wrong on at least one holiday per year. First Mother's Day after a menu change. First Fourth of July in a new location. First Christmas Eve in a unit that added a catering line. The model does not have enough training data for any of those and it will guess low or high in a way that costs you a lot of money in one shift.
The rule I now write into the rollout is that any date on the holiday list gets overridden by the general manager. The model still runs, the number still shows, but the schedule is written from the general manager's number, not the model's. Every override gets logged, and after the shift the actual number goes back into the training set. Inside two years the model catches up. Until then, do not let it schedule the biggest days of the year on autopilot.
Where operators get it wrong on rollout
Two mistakes come up every time. The first is treating the model as a replacement for the general manager's judgment instead of a tool that sharpens it. The moment the field feels like the model is grading them, they stop editing the schedule and labor gets worse, not better. The framing has to be: here is a good starting point, you still own the shift.
The second mistake is skipping the event calendar because it sounds low-tech. Every time I have let a group cut that step, the model accuracy has drifted inside three months. The five minutes on Monday morning is the difference between a model that stays useful and a model that becomes another retired dashboard.
The point
A predictive labor forecast is not a machine learning project. It is four inputs, a weighted model, a nightly refresh, and a Monday review meeting. The tools are Toast, 7shifts, Airtable, Power BI, and a Zapier or Make pipe. The gain is 1.4 to 2.1 points of labor as a percent of sales in the first ninety days, and it holds if the operator keeps the event calendar current and lets the general manager override the model on holidays.
Everything else is decoration.