Field notes
The Sunday night schedule is a tell
If your GMs still build next week in a spreadsheet after close, the scheduler you already pay for did not survive its first short week. What to fix, and why the GM still writes the schedule.
If next week still gets built in a spreadsheet on a Sunday night, that is not a software problem. It is a sign the last system you bought did not survive its first short week.
The part that gets missed at group level: you do not have one Sunday night. You have one per GM. Nine stores is nine people doing the same two hours, nine different ways, and none of them can see what the others worked out.
I have built those spreadsheets. Copy last week. Stare at the forecast. Move names because somebody asked off. Hope Tuesday is as quiet as the template says.
Why the template breaks
A schedule is not a grid of hours. It is a stack of bets: who can close, who cannot work a double, who will quietly start looking if you put them on another Saturday they did not ask for.
The spreadsheet holds the hours. The GM holds the bets. Every tool that ignores the second half gets abandoned the first week it is confidently wrong, and then you are paying for it and not using it, which is the worst of the three options.
That is also why I do not open this conversation with scheduling software. The cost of a bad draft is not a red cell. It is a closer who does not show, or one who does and should not have been asked.
The Arizona version of this
Two things move covers here that a national template does not know about.
Snowbird season turns some trade areas over completely from about October, and summer flips daypart patterns — nobody is standing on your patio at 2pm in July, and late evening picks up what lunch lost. If your stores sit in different parts of the valley, they are not even on the same curve as each other.
A template built in March is wrong in July in a way that looks like your GM guessing badly. It is not the GM.
What is actually useful
Last year's same week, in front of the person building this week, before Sunday.
Your POS will export it. Almost nobody looks at it, because looking means an export and a spreadsheet and an afternoon — the same afternoon that is already going into building the schedule by hand.
That history is the thing worth handing to a tool. Not "write my schedule." Something closer to: here is what this week looked like the last three times it happened, by daypart, by store. A starting point somebody can argue with at 4pm instead of a blank grid at 9pm.
If you already pay for a scheduler with forecasting in it, open that before you buy anything. In most groups the feature is switched on and unused, which is a much cheaper problem than the one you were about to solve.
Who still owns the call
The GM writes the schedule. That does not move.
What changes is what they start from: a draft built out of the same week last year instead of the same week last week. They still cut it, because they are the one who knows that the new closer is not ready for a Friday and that two of your best people cannot be on the same shift.
A draft is a suggestion with the arithmetic already done. It is not a decision, and anything that tries to make it one will be off in exactly the way that costs you a person.
One week, one store
Not a rollout. Pull last year's same week for your busiest store and put it in front of that GM before they build.
Then ask what the export got wrong. Write those answers down — the split shift that never works, the section that needs two on Thursdays, the delivery that lands mid-rush. Those exceptions are the real scheduling rules in your group, and right now they live in nine heads and nowhere else.
Getting them written down is worth more than the software, and it is the part you keep when you change systems.
Not sure labor is where your week is going? Take the free check. Eight questions, no email, and it names the two things worth fixing first in your building — sometimes it is the schedule, often it is not.