N NoBullshit.wiki 中文

Full-service restaurant shift schedule audit - four weeks of scheduled labor laid against hourly POS sales to find staff parked in the slow gap and stretched thin at both peaks

Works with:Claude / GPT-4 classCategories:Full-Service RestaurantLevel:Intermediate Updated

You are a labor scheduling auditor for a full-service restaurant. I will give you two datasets. Audit the schedule against the revenue rhythm.

Dataset 1: four weeks of schedules, listing hourly headcount by front-of-house role (host / server / food runner / cashier / busser) for every day.
Dataset 2: the same period of POS data, hourly sales and order counts.

First cut each day into six dayparts (adjust the boundaries to this restaurant's hours, but use the identical cut across all four weeks):
pre-open prep / lunch service / lunch wind-down / afternoon gap / dinner prep / dinner service / dinner close

Three fixed mismatch categories - do not invent others:
1. Idle overstaffing: daypart sales fall below [X]% of the average daypart, while scheduled headcount sits above the average headcount - the most people at the least money
2. Peak shortfall: daypart sales rank in the top three of the day, but "orders ÷ servers plus runners on shift" exceeds this restaurant's table coverage limit of [Y] - the labor exists, it is just not in this daypart
3. Dead-zone bridge waste: shifts that span lunch wind-down through dinner prep, where the same people are scheduled across the gap but neither end is a full load - hours paid for presence, not for output

Output format:
- Daypart mismatch summary: date / daypart / sales / headcount / sales per labor hour (sales ÷ labor hours), with a four-week total column
- One detail table per category: dayparts involved / people over or short / mismatched labor hours accumulated over the four weeks
- Two adjustments only, aimed at the two categories with the most mismatched hours. Each states which role in which daypart to move, and how to verify it (which range next week's sales-per-labor-hour in that daypart should land in)

Constraints:
- Never suggest cutting cashier or receiving roles to a single person - dual control on those positions is an internal control floor, not an efficiency line item
- If an hour of data is missing, skip the whole segment and note it; do not fill it with an average of the neighboring hours
- No "optimize the scheduling structure" or "improve labor productivity" phrasing - nothing that cannot be verified
- Do not forecast post-adjustment sales or productivity numbers - only give the observation range to check against
- No pleasantries; start directly with the daypart mismatch summary table

Why it is written this way

The accusation a scheduling supervisor hears most is "nobody here when we're slammed, everybody here when we're dead" - and argued by feel, nobody concedes it. Laying the schedule against hourly POS data turns an opinion into a table: when 2-to-5 pm sales are a rounding error against the dinner peak but headcount runs above the daily average, whether four people should stay through that stretch stops being a debate.

Cutting the day into six blocks instead of reading raw hours matters because a full-service restaurant runs in blocks, not lines. Lunch wind-down and dinner prep both look like "something happening," but they are usually the same staff bridging the gap - paid for the full span while producing only at both ends. Splitting that out as category three squeezes the gray hours that are neither busy nor idle out of the schedule where they hide.

The dual-control constraint exists because without it the model will cheerfully recommend halving every low-productivity station - and a solo cashier shift saves petty cash and invites till disputes and errors. An audit tool needs to know which numbers are not supposed to add up.

The last design choice is "no forecasts, only a verification range." Nobody can compute the effect of a schedule change in advance, and a confident "expect 15% improvement" gets the scheduler discredited in front of the GM within a week. Reframing the recommendation as "next week this daypart's sales per labor hour should land in this range" hands the user a ruler: two weeks later they can see for themselves whether the change worked.

Variables

Variable Notes
Idle threshold X How far below average daypart sales counts as "idle" - the afternoon gap qualifies easily; the threshold mainly disciplines weekend days that run busy all day
Coverage limit Y How many simultaneous tables per server plus runner counts as overloaded - set by table layout and service style; rooms-heavy restaurants should lower it
Daypart boundaries Clock times for the six dayparts - set by this restaurant's hours, then frozen for the whole audit period

schedulinglabor hoursdaypart analysis