Guides

How to schedule a golf course crew when the weather decides the week

Most scheduling advice assumes a business whose Tuesday looks like its Wednesday. A golf course is not that business. Here is what actually decides the week, and how to build a schedule that holds when it changes.

Updated September 2026 · LazShift

A golf course runs four crews that share almost nothing: a maintenance crew that starts before dawn and is sent home by frost, outside services whose day is shaped by the tee sheet, a pro shop on retail hours, and food and beverage that spikes for events nobody put on the schedule. They have different start times, different skills, different seasons and different reasons to be sent home early. A single spreadsheet with a row per person and a column per day cannot hold that, which is why so many courses still run on a printed sheet, a group text and a superintendent who checks the radar at 4:30am.

This guide is about the parts that generic scheduling advice skips: the crews, the weather, the season, and the overtime cliff that arrives every July.

Start by scheduling four crews, not one staff list

The commonest mistake is treating the course as one roster. It is at least four, and they need to be modelled separately because their constraints are genuinely different.

Model each as its own department with its own shift types and its own coverage requirement. The practical payoff is that "we are short" stops being a single number and becomes a specific one: short a second mower operator at 5am Thursday, not short two people this week.

The frost delay is a scheduling problem, not a weather problem

Frost is the clearest example of the thing that makes course scheduling hard: the weather does not change how many people you need, it changes when you need them — and it does so after they have already driven in.

A crew called for 5:00am on a morning with frost on the greens cannot get on the course. Mowers stay in the barn. The tee sheet slides an hour, sometimes two. Depending on how you handle it, you are paying a full crew to wait, or sending people home having paid them a reporting-time minimum, or pushing everyone an hour later and running maintenance into golfers.

You cannot schedule frost away. What you can do is stop being surprised by it:

• Put the forecast on the schedule, not in a separate app. The decision you are making is a staffing decision, so the forecast belongs where the staffing decision is made. A low of 34°F on Thursday should be visible while you are building Thursday, not remembered at 4:30am on the day.
• Publish a stated frost policy with the schedule. Who calls it, by when, how the crew is told, and what they are paid if they are sent home. Ambiguity here is what turns one cold morning into a payroll dispute.
• Build a delayed-start variant in advance for the shoulder months. A second start time on the same shift, ready to swap in, is a two-minute change on the morning. Rebuilding the day from scratch at dawn is not.
• Know your state's reporting-time rules before the season, not during it. Several states — California among them — require a minimum payment when someone reports for a scheduled shift and is sent home early. That rule, not the frost, is what makes the call expensive.

Rain is the opposite problem, and it costs more

Frost delays labour you still need. Rain removes the demand for it. A wet Saturday empties the tee sheet, and every hour of outside services, starter and cart staff scheduled against that sheet is paid against revenue that did not arrive. It is the single largest avoidable labour cost on a course, and it is avoidable only if the forecast is in front of you while the week is being built — three or four days ahead, when a shift can still be shortened by agreement rather than cancelled on the morning.

The useful habit is to look at the week you have just built and ask one question per day: if this day is washed out, who is standing in the rain on the clock? Those are the shifts worth a call ahead. Everything else can be left alone.

The seasonal roster is a year-round cost if you let it be

A course in a four-season climate might run 45 people in July and 12 in January. Almost every scheduling tool in this category charges per user per month, and almost none of them stop charging when someone stops working. The result is a bill sized for July that arrives in February.

Three things worth checking before you commit to any tool:

1. What happens to a seasonal employee in the off-season? Can they be deactivated — keeping their history, their availability and their record — without being billed? Or is the only option to delete them and re-enter them in April?
2. Does the bill follow the roster automatically, or does it need you to remember to downgrade a plan and then remember to upgrade it again?
3. Does last year's schedule survive? Rebuilding the same rotation from memory every spring is a week of work that a copy-a-week function makes into an afternoon.

Overtime: the cliff arrives in the second week of July

Peak season is where course labour budgets are won or lost, and it is not usually lost to a decision anyone made. It is lost to arithmetic nobody did: someone picks up a Saturday to cover a call-off, and that shift is their 41st hour.

Overtime is entirely predictable at the moment the shift is assigned and effectively invisible afterwards. So the check has to happen while the schedule is being built, against hours already scheduled in the same pay period — and the pay period, not the calendar week, is what matters. A course on a two-week period that starts on a Sunday cannot answer "is this overtime?" by looking at a Monday-to-Sunday grid.

The same is true of rest between shifts. A closing shift followed by a 5:00am mow is legal in most places and a bad idea everywhere; it is also invisible unless something is looking at the gap between two shifts on two different days for the same person.

Publishing: the part that causes the most arguments

Most scheduling disputes at a course are not about who got which shift. They are about who knew. A schedule printed and pinned in the maintenance barn is invisible to the pro shop; a schedule texted as a photo is out of date the moment one shift moves, and there is no way to tell who saw which version.

What "published" should mean, at minimum: every employee has the current version on their phone, changes after publication are pushed rather than posted, and there is a record of when each version went out. "I never saw the schedule" should be an answerable question, and the answer should not be a superintendent's memory of a group text.

A checklist for the week

1. Build against availability you did not have to ask for — standing availability and approved time off already in the system, not a text thread.
2. Fill the rotation from last week, then fix what changed. Most of a course week is the same week.
3. Check the forecast across the whole week before publishing, not the night before each day.
4. Look at hours-to-date in the pay period for anyone near the threshold, before assigning the last few shifts.
5. Check rest gaps for anyone working a close and an early.
6. Name the coverage gaps you are choosing to accept rather than discovering them on the day.
7. Publish to every crew at once, and let changes after that go out the same way.

Related reading

• Seasonal staff scheduling
• Homebase alternative
• When I Work alternative