How to Manage a Resort Buggy Service: Dispatch and Wait Times

Nobody gets promoted for how well the buggies run at 3 p.m. on a Tuesday. Buggy service is judged — by guests, by review sites, by your GM — on about ninety minutes of the day: the breakfast rush, the sunset scramble, and the morning a full villa wing checks out at once. Managing a resort buggy service well means managing those ninety minutes, and almost everything in this playbook comes back to that.

This is written for the ops director or resort manager who already runs a fleet and is tired of the same two symptoms: guests waiting too long at peak, and nobody being able to say exactly how long “too long” was. Here’s the playbook I’d hand that person — dispatch model, wait-time target, SOP, staffing, and the feedback loop — in that order.

The job is demand-shaping, not driving

Your demand curve has three or four spikes, and the flat parts between them will lie to you. Breakfast pulls every occupied villa toward one restaurant inside the same forty-five minutes. Sunset pulls everyone toward the beach bar and then back again in the dark. Departure days stack luggage runs on top of normal traffic. Average the whole day and a two-buggy fleet looks comfortably idle; look only at 7:30–9:00 a.m. and the same fleet is drowning.

That’s why “how many buggies do we need?” is the wrong first question. The right first question is: when a spike hits, how does a request find a free driver? A fleet that idles at 20% utilization all afternoon and still leaves guests standing at breakfast doesn’t have a capacity problem — it has a dispatch problem. Fix how requests move before you buy another vehicle, because a fourth buggy dispatched badly just gives you a fourth idle buggy at 3 p.m.

All of it — everything below — is really one discipline: shaping how demand meets your drivers during those spikes.

Pick your dispatch model deliberately

Most properties never chose their dispatch model; they inherited it. A radio behind the front desk, a driver group chat, a loop schedule someone wrote years ago — these accrete, they aren’t decided. Step one of managing the service is picking one of the three real models on purpose. The full taxonomy is in what a resort buggy service is; here’s the short form for choosing.

Radio relay is defensible at very small scale — a couple of pickup points, one driver, low season — but at peak the desk becomes the choke point, and nothing gets written down afterward. The full comparison is in the radio vs. app dispatch scorecard, and the money side in what radio dispatch really costs.

Scheduled loops earn their keep on a single dominant corridor with steady all-day flow. Most resorts are webs, not corridors — so at peak, full buggies drive past the villa that actually called.

On-demand auto-assignment — the guest requests from where they stand, and the system offers the ride to the nearest free driver — is the model buggy reservation software exists to run, and the only one of the three that gets better under load.

The deliberate choice looks like this: radio if you’re genuinely tiny, loops if you’re genuinely a corridor, on-demand for everything else. What’s not defensible is running radio relay at forty villas because that’s what was there when you arrived.

Set a wait-time target and measure against it

A buggy service without a numeric wait target isn’t managed — it’s endured. The bar I’d hold any property to is single-digit minutes at peak: a guest who requests a ride during the breakfast rush should have a buggy in front of them in under ten minutes, and well under five off-peak. If you want to derive your own number instead, a defensible back-of-envelope target is your longest cross-property drive time plus two minutes of assignment slack — on most resort layouts that lands in the same single-digit range.

The target only matters if you measure against it, and you need exactly three numbers:

• Average wait, split by hour. Not the daily average — the daily average is where your breakfast problem goes to hide. You need to see 8 a.m. and 3 p.m. as separate facts.
• Rides per hour, per driver. This is your utilization truth. It tells you whether a long-wait hour is a too-few-drivers problem or a slow-assignment problem — the fixes are completely different.
• The peak curve itself. Requests by hour across a week. One look at it and your roster arguments end, because the demand spike is no longer anyone’s opinion.

Where does the data come from? If every ride is logged by your dispatch system, this is a CSV export and twenty minutes in a spreadsheet — ride history with request time, assignment time, and pickup time makes the whole curve visible. If your dispatch is radio, the honest answer is that the data doesn’t exist, and your wait times are whatever the last angry review said they were. That asymmetry — measurable versus anecdotal — is, for me, the strongest single argument for moving off radio, ahead of even the wait times themselves.

A one-page SOP skeleton

If your buggy operation lives in one veteran supervisor’s head, you don’t have a service — you have a person. Write the SOP. One page is enough, and here’s the skeleton to copy into your own doc and fill in:

1. Response-time target. The number from the section above, stated plainly: “Guests wait no more than X minutes at peak, Y off-peak.” Everything else in the document exists to hit this line.
2. Coverage hours per pickup point. Which points are served when. The jetty at 6 a.m. for the seaplane, the restaurant through dinner service, the spa until close. Guests forgive a point that’s clearly marked as closed; they don’t forgive one that’s silently unserved.
3. Pre-booked ride handling. Departure runs to the jetty and dinner reservations are known hours or days ahead — decide now how they’re captured, who confirms them, and how far in advance they lock a driver. A pre-booked departure run that collides with the breakfast rush is a scheduling failure, not bad luck.
4. Escalation when all buggies are busy. The all-busy state will happen; the SOP decides whether it’s a shrug or a procedure. Who tells the guest, what wait they quote, when a supervisor or spare vehicle steps in, and at what queue depth the desk starts actively managing expectations.
5. Shift handover. What the outgoing driver passes on: open scheduled rides, vehicle charge state, anything unusual on the property. Five lines, every shift, no exceptions — most “lost” pre-booked rides die at handover.

That’s the whole document. The skeleton above is enough to stop the operation being oral tradition.

Staff to the curve, not the roster

Once the peak curve is visible, rostering stops being guesswork: put drivers where the requests are, not where the shift template says. Two drivers at breakfast and one all afternoon beats three drivers evenly spread, every single week, and your rides-per-hour numbers will prove it. The actual headcount math — coverage hours, split shifts, seasonal swings — deserves its own treatment, and I’ve written it up separately in staffing the fleet to the demand curve. The one-line version: never argue the roster from memory when you can argue it from the curve.

Use ratings as your QA loop

You cannot ride along on every trip, so let the guests tell you which trips went wrong. A one-tap rating at the end of each ride costs the guest two seconds and gives you the only QA signal that scales: per-driver averages over time. Read them as an early-warning instrument, not a surveillance one — a driver whose average slips this month is usually flagging a route problem, a vehicle problem, or a training gap, not a firing offense. The pattern that matters most is a cluster: several low ratings in the same hour of day points at an overload window your wait-time numbers should corroborate; low ratings on one route points at the route. Ratings are how service quality stops being a thing you assert in the morning meeting and starts being a number that moves.

Worked example: what this looks like with software

Everything above is tool-agnostic — you could run the SOP on a radio if you insisted. But it’s worth seeing how the pieces click together when the dispatch layer is built for it, using Resort Buggy as the worked example. (If you’re earlier in the journey and still weighing what a resort buggy service is in the first place, start there.)

The dispatch model is on-demand by default: a guest scans a QR code at the villa or pickup point — no app download — and the request goes automatically to the nearest free driver’s one-button app. The wait-time target gets teeth because the ETA shown to the guest is learned from your property’s own ride history, and every ride logs to analytics — average wait and rides per hour, exportable to CSV — so the peak curve from section three is a download, not a project. The SOP’s pre-booked clause maps to scheduled rides up to 30 days ahead, the escalation clause maps to a live ops board where the desk sees the whole queue and can book on a guest’s behalf, and the QA loop is the built-in one-tap rating with driver averages on that same board.

If you want to watch those pieces run across a real shift, I’ve walked through what this looks like in practice, role by role — and the setup itself is small enough that properties stand one up in an afternoon.

Or skip ahead: book a demo and we’ll put your own property’s map and pickup points on screen — bring your worst breakfast rush, and we’ll show you what the curve would look like managed.