Staffing a Buggy Fleet: How Many Drivers Do You Really Need?

The staffing question always arrives in the same shape. A GM or a director of golf looks at the schedule, looks at the fleet, and asks what feels like a simple arithmetic problem: how many drivers do I actually need to keep buggies moving without paying people to sit? It feels like arithmetic. It almost never is. The honest answer is that the number you’re looking for isn’t one number — it’s a curve — and the mistake most properties make is trying to flatten that curve into a single headcount.

This is written for two readers at once. If you run guest transportation at a resort, “the fleet” means the buggies that move guests from lobby to villa, room to the first tee. If you run a golf club, it means the shuttle from lodging to the clubhouse plus the on-course swaps and bag-drop runs. Different properties, same underlying problem: demand for rides is not flat across the day, and staffing decisions made as if it were flat will be wrong in both directions at once — short when it counts, idle when it doesn’t.

The trap of staffing to the average

Here’s the seductive logic. You completed, say, 90 rides last Saturday over a twelve-hour operating day. That’s 7.5 rides an hour. A driver can comfortably handle a ride every ten or twelve minutes including the return leg, so call it five or six rides an hour per driver. Divide it out and one or two drivers covers the day. Tidy. Defensible on a spreadsheet.

It’s also wrong, and it’s wrong in a specific, predictable way: the average is the one rate that never actually occurs. Ride demand at a resort or a club isn’t a smooth 7.5-per-hour drip. It’s lumpy: a morning rush to the first tee, a midday lull where the same one driver is genuinely idle, a check-in/check-out window where everyone needs a buggy and their luggage moved in the same ninety minutes, a dinner surge. If you staff to 7.5 rides an hour, you are overstaffed at 2 p.m. and badly underwater at 8:30 a.m. — and the 8:30 failure is the one your guests remember and your reviews mention.

So the first reframe is to stop asking “how many drivers do I need on average” and start asking two separate questions: what’s my coverage at peak, and what’s my utilization off-peak? Those are different problems with different answers, and a good staffing plan solves them independently rather than splitting the difference and getting both wrong.

Peak concentration is the number that actually sizes your fleet

The variable almost nobody measures — and the one that matters most — is how concentrated your demand is. Two properties can run the identical 90 rides a day and need wildly different staffing, because one spreads those rides evenly and the other crams 40 of them into two windows.

A useful back-of-envelope way to think about it: take your busiest single hour, not your daily total. If your worst hour sees, say, 18 ride requests and a driver can realistically turn around five or six given your distances, you need roughly three drivers on the ground in that hour to keep waits civil — regardless of how quiet the rest of the day is. Your peak hour sizes your fleet and your peak roster. Your daily total mostly tells you how long that peak roster needs to be on shift.

The distances on your specific property bend this hard, so resist anyone’s universal ride-per-driver figure, including mine. A four-minute run each way supports far more rides per driver-hour than a twelve-minute crawl to the far lodging. This is exactly why a generic “one driver per X rooms” rule of thumb is close to useless — it ignores both your map and your demand shape, the two things that actually determine the answer. Treat any rule of thumb, this article’s included, as a starting hypothesis you then correct with your own numbers.

The two failure modes, and why they’re both expensive

Understaffing and overstaffing fail differently, and it’s worth naming the cost of each honestly rather than pretending one is free.

Understaffing at peak is the loud failure. Guests wait, they call the front desk to ask where the buggy is — which generates more work for the staff who are already the bottleneck — and the perceived wait balloons because nobody can see anything happening. At a club it shows up as the first tee backing up and the starter improvising. It costs you on review sites and pace-of-play complaints, and it’s invisible on a payroll report, which is precisely why it persists. You don’t get a line item for the guest who decided the shuttle was unreliable and rented a car instead.

Overstaffing off-peak is the quiet failure. A driver parked in the shade for two hours mid-afternoon is real money, but it’s comfortable money — it never shows up as a complaint, so it rarely gets questioned. Most properties carry more idle driver-hours than they realize, because the roster was built once around the worst-case peak and then never trimmed at the edges. The off-peak hours are where your savings live, and they’re the hours a gut-feel schedule almost always gets wrong.

The goal isn’t to eliminate either failure — a little slack at peak is insurance, and a little idle off-peak is unavoidable. The goal is to see both clearly enough to make the trade on purpose instead of by accident.

Right-sizing with data instead of gut feel

Here’s where the conversation usually stalls, because the honest objection is: I don’t have this data. If you dispatch by radio or by the front desk relaying calls, you’re right — you don’t. A spoken ride request that gets handled and forgotten leaves no record of when demand actually peaked, how long anyone waited, or which driver was idle when. Every staffing decision is therefore made on memory, and memory over-weights the one chaotic Saturday and forgets the twenty quiet Tuesdays.

The moment ride requests flow through a system instead of a voice channel, the staffing question gets a real answer. When every ride is logged — request time, wait, route, driver — you can finally look at demand by hour rather than demand on average. You stop arguing about whether “mornings are busy” and start seeing that the genuine spike is 8:15 to 9:45 and the 11-to-1 block is a ghost town. That single distinction is the difference between adding a driver and simply shifting one.

This is the practical reason we put busiest-points and busiest-hours analytics in the product, with a CSV export so the numbers are yours to pivot however your ops or finance team likes. The export isn’t a vanity dashboard — it’s the raw material for a staffing plan. Lay your ride history against your roster and the over- and under-served hours light up immediately. A director of golf can show the pace committee the actual demand curve instead of anecdotes; a resort GM can re-shift a driver from the dead afternoon to the check-out crush and cover the peak without adding headcount.

How automatic dispatch raises utilization — so fewer drivers cover more

There’s a second lever, and it’s the one people miss. Staffing isn’t only about how many drivers you roster — it’s about how much useful work each driver gets done per hour on shift. Raise that, and the same peak gets covered by fewer people.

The old model quietly wastes driver-hours in ways nobody tracks. A request comes in over the radio, two drivers both head for it and one wastes the trip; or it goes to whoever happened to answer rather than whoever was closest, so a buggy crosses the whole property while a free one sat fifty yards from the guest. Every one of those is a driver-hour you paid for and didn’t get a ride out of. They don’t show up as idle time — the driver was moving — but the motion didn’t produce a completed trip.

Automatic dispatch to the nearest free driver attacks exactly that waste. One ride, one offer, to the closest available buggy; it accepts, the next request routes on. No double-dispatch, no cross-property dead-heading, no “I thought you had it.” The effect on staffing is direct: when each driver’s shift produces more completed rides per hour, your peak-hour coverage math improves, and the three drivers you thought you needed at 8:30 might genuinely be two. That’s not a promise of a specific number — your map decides the size of the gain — but the direction is reliable: tighter dispatch means higher utilization means fewer driver-hours buying the same guest experience. It also makes the on-course shuttle and swaps at a golf club more forgiving when one driver is mid-run and a second request lands.

A sane way to actually set the number

If I had to compress this into a sequence a property could run next week, it would be four steps. First, find your real peak hour — not your busy day, your busiest single hour — because that sizes your roster. Second, get an honest read on rides-per-driver-hour for your distances, not a borrowed figure. Third, staff the peak with a little insurance slack, then deliberately trim the off-peak tails where utilization craters — that’s where the budget hides. Fourth, run it for a few weeks, look at the logged data, and correct. Staffing a fleet is a loop, not a one-time calculation, because your demand shape shifts with seasons, events, and occupancy.

If you want a directional starting point before you’ve logged a single ride yourself, the savings calculator is built for exactly this first pass. You feed in your own ride volume and a few assumptions, and it estimates the staff dispatch hours an on-demand model could reclaim — the idle-and-wasted driver-time that better dispatch and a data-driven roster would give back. It’s deliberately a back-of-envelope tool, not a promise; treat its output as the hypothesis you then test against your own numbers once rides are flowing.

The thing I’d most want a GM or director of golf to take from all this is that “how many drivers do I need?” is the wrong question, and it’s wrong in a way that costs money in both directions. The right questions are “can I cover my peak?” and “am I paying for idle off-peak?” — and both are answerable, precisely, the moment your rides stop evaporating into the air and start writing themselves down. Right-sizing golf cart staffing isn’t about cutting drivers or adding them — it’s about putting the drivers you have where the demand actually is, and being able to prove it.

That’s the slice we built Resort Buggy around — automatic dispatch to the nearest free driver, busiest-hours and busiest-points analytics, and a CSV export of your own ride history so the staffing plan comes from data instead of gut feel. If you want to see what your demand curve actually looks like on your property’s map, the demo takes twenty minutes and starts with your worst hour, not a slide deck.