The question has three answers, and mixing them up is why nobody agrees
Ask five operators how many cars an attendant handles per hour and you will get five numbers between four and forty. They are not contradicting each other. They are answering three different questions without saying which one.
- Movements per hour. One movement is one car parked, or one car retrieved. It is a single trip out and a single trip back. This is the unit the work is actually made of.
- Complete cars per hour. One guest arrives, hands over a key, and later gets the car back. That is two movements. This is the unit your demand is made of, because covers and guest counts are counted in people, not in trips.
- Vehicles under management. The familiar ratios, one attendant per 15 vehicles at peak or one per 30 in steady state, describe how many cars sit under one person's care at a given moment. That is a stock, not a rate. It answers "how big is the crew", not "how fast does the crew go".
The third one is the one people quote when they mean the first one, and it is the reason a crew can be correctly sized on paper and still have thirty people standing at the podium. We covered the staffing ratios themselves as part of how to build a valet quote. This page is about the rate.
What we could and could not verify. There is no US industry rate or productivity survey for valet that we could find. The National Parking Association offers a Valet Operations Certificate and a Certified Valet Attendant credential, but we found no published throughput benchmark from any parking association. Every figure below traces to a named operator writing about their own operation, to a public engineering standard, or to arithmetic we show our working for. Where a variable is real but unmeasured in public, we say so rather than filling the gap with a plausible number.
The one published cycle time methodology we found
The most useful public source on this question is not a benchmark at all. It is a worked staffing example in Richard Raskin's write up on managing a valet operation, which gives three inputs and then does the arithmetic in front of you:
| Input | Value |
|---|---|
| Time to park a vehicle and return to the porte cochere | 5.5 minutes |
| Time to retrieve a vehicle and deliver it to the guest | 4.25 minutes |
| Productive time per attendant | 50 minutes of each 60 minute hour |
His example is a hotel morning with 15 arrivals and 50 departures in the same hour. That is 82.5 minutes of parking plus 212.5 minutes of retrieving, just under 300 minutes of work, which at 50 productive minutes each requires six attendants on the floor.
Two things about that are worth more than the numbers themselves. First, it is a method, so you can substitute your own measured times and it still works. Second, the 50 minute assumption is doing real work: it says that one sixth of the shift is not a cycle at all. It is greeting, waiting for the porte cochere to clear, taking payment, hunting for a key, handing off to a manager, and being human. Any model that assumes 60 productive minutes is wrong by 20 percent before it starts.
What that method produces
Run those inputs out and you get the three answers to the question at the top of the page:
| Measure | Arithmetic | Per attendant per hour |
|---|---|---|
| Parking only, arrival rush | 50 ÷ 5.5 | 9.1 cars |
| Retrieving only, departure rush | 50 ÷ 4.25 | 11.8 cars |
| Balanced mix of both | 50 ÷ 4.875 | 10.3 movements |
| Complete guest visits, park and retrieve | 50 ÷ 9.75 | 5.1 cars |
Complete guest visits per attendant per hour, at a venue where the lot is a short walk from the door. Nine to twelve if you count individual car movements instead.
Notice that retrieving is faster than parking in these figures, by more than a minute. That is not a mistake. On the way out the attendant walks to the car and drives back; on the way in they drive out and walk back, but they also greet the guest, write or scan the ticket, adjust the seat, and deal with whatever the guest left in the driver's door. Retrieval front-loads none of that. It just feels slower because the guest is standing there watching a clock, which is a service problem rather than a throughput problem.
Distance to the lot is the number, and everything else is a rounding error
Raskin does not say how far his lot was. You can back it out, and the exercise is the most useful thing on this page.
The return leg of a park cycle is walked, and walking is slow. US traffic engineering practice sizes the pedestrian clearance interval at a signal on a walking speed of 3.5 feet per second, about 210 feet a minute. That is a deliberately conservative design figure meant to cover slow walkers, and a fit attendant on clear pavement will beat it, but it is a published number rather than a guess, and it is close enough for planning. Driving inside a lot at a sane 5 mph is 440 feet a minute.
So a one way distance of d feet costs about d/440 minutes driving out plus d/210 minutes walking back, roughly 0.007 minutes per foot for the pair. If you assume 3 minutes of fixed handling per park (greet, ticket, get in, manoeuvre into the stall, lock up), Raskin's 5.5 minute cycle implies a lot about 350 feet from the door. Change the fixed handling assumption to 2 minutes and the implied distance jumps to about 500 feet; change it to 3.5 and it drops to about 285. That sensitivity is the point: two operators can both be honest and land two hundred feet apart.
Hold fixed handling at 3 minutes and vary only the distance, and the throughput curve looks like this:
| One way distance to the lot | Cycle time | Movements per hour | Complete cars per hour |
|---|---|---|---|
| 150 ft, adjacent lot | 4.1 min | 12.3 | 6.2 |
| 350 ft, across the parking area | 5.5 min | 9.2 | 4.6 |
| 600 ft, around the block | 7.2 min | 6.9 | 3.5 |
| 1,000 ft, one fifth of a mile | 10.0 min | 5.0 | 2.5 |
| 1,500 ft | 13.6 min | 3.7 | 1.8 |
| 2,640 ft, half a mile | 21.6 min | 2.3 | 1.2 |
A lot 1,000 feet away costs you 60 percent of your throughput compared with one at 150 feet, with the same people and the same effort. That is why two operators quoting the same headcount for the same guest count can produce completely different nights, and it is why "how far is the parking" belongs on your intake form above almost every other question.
The published operator experience matches the shape of that curve. One account of resort valet describes retrieval dropping from 8 minutes to under 3 after adding satellite stations closer to where the cars actually were. That is a distance fix, not a staffing fix, and it roughly doubles what each person can do.
The threshold where you stop hiring and start driving. Look at the bottom rows. Past roughly a quarter mile, an attendant spends more of the cycle walking than doing anything a customer values, and adding people multiplies a bad cycle instead of fixing it. That is the point where a runner shuttle pays for itself: one driver ferrying attendants back to the stand removes the walk from every cycle in the operation. Published examples exist, including golf cart shuttles bridging a five block gap between overflow lots and the gate at a Tampa arena. We found no published data on the exact distance at which a shuttle beats headcount, because it depends on your labour cost and the cart, but the arithmetic above lets you work out your own crossover in about ten minutes.
Burst rate is not sustained rate, and this is where the wild claims come from
If you have heard thirty or forty cars an hour per attendant, that figure is real and it is also not repeatable. A published account of amphitheater valet states that a well coordinated team of eight can process 40 to 50 vehicles in the first ten minutes after a show ends. Divide it out: 5 to 6.25 cars per person in ten minutes, an hourly rate of roughly 30 to 37 movements.
Three things make that possible, and all three expire:
- The cars were pre-staged. Crews start pulling vehicles forward before the encore ends. Those movements happened earlier, on the clock, and are being counted twice if you call the ten minute burst a productivity figure.
- Everybody is on the floor. No breaks, no podium coverage, no key board, no payment. The 50 productive minutes assumption goes to 60 for a few minutes because managers absorb everything else.
- The queue is doing the work. Guests are already lined up in departure order. The matching problem that normally eats time has been solved by the crowd itself.
Burst numbers are genuinely useful for one thing: sizing a departure surge. If you know the show ends at 22:30 and you have 400 cars, the burst rate tells you how many people you need for those ten minutes. It tells you nothing about how to staff a Tuesday.
ParkingPro's shift report shows how many vehicles each attendant actually handled on a real shift, which is the only version of this number that is genuinely yours. US$19/month, 14 days free, no sales call.
Start the free trial →What else moves the number, and how confident you can be about each
Running versus walking
A jog at 8 feet per second instead of a 3.5 foot per second walk cuts the return leg by more than half. At a 600 foot lot that takes the cycle from 7.2 minutes to about 5.6, roughly a 28 percent throughput gain, and the gain grows with distance. It is the single largest controllable variable after distance itself.
It is also the one nobody will put in writing. We could not find a published policy from any major US operator, or any association guidance, either requiring or prohibiting running in the lot. What is published is generic and cautious: safety guidance for valet operations tends to cover seat belts, observing posted speed limits and avoiding sudden stops and starts, and says nothing about the attendant on foot. Draw your own conclusions from the silence, but understand the two real constraints. A sprained ankle on wet pavement is a workers' compensation claim, and no human sustains a jog for the fifth hour of a shift. Whatever you decide, decide it explicitly and put it in the handbook, because an unwritten rule here becomes an argument after an injury.
Vertical movement
A multi level garage behaves differently from a flat lot of the same distance, and worse. A ramp is walked at less than 3.5 feet per second going up. An elevator is not a distance at all, it is a queue, and its wait time gets longer exactly when you need it shortest. If your parking is three levels below grade, measure your cycle rather than estimating it from a floor plan, because the floor plan will lie to you.
Tandem stacking
Stacking is what makes valet worth having: parking tighter than self park allows is commonly cited as fitting 40 to 60 percent more vehicles into the same space. It buys capacity and it sells throughput. A blocked-in car does not cost one movement, it costs three: move the blocker, get the target out, put the blocker back. If one retrieval in five is blocked, your effective retrieve cycle goes up by roughly 40 percent of a single move, and your departure rush is the moment it hits.
The mitigation is not more people, it is better ordering. Parking by expected departure time, keeping short dwell vehicles out of the deep stacks, and running first in first out within a stack all attack the same cost. So does knowing which car is where without walking the lot to find out.
Vehicle difficulty
No public data exists on this that we could find, and it is not for lack of looking. What every operator will tell you anecdotally is that the distribution has a long tail:
- A manual transmission is not a slow cycle, it is a hard stop for an attendant who cannot drive one. Know who on your crew can.
- Oversized pickups and three row SUVs in a lot striped for sedans turn a ten second manoeuvre into a ninety second one, repeatedly.
- Unfamiliar push button starts, electric vehicle shifters and drive modes cost time on the first encounter with each model.
- Damage inspection photos at drop off add fixed time to every single car. That is a deliberate trade of throughput for liability protection, and it is usually the right trade, but price it into your cycle rather than pretending it is free.
Weather
Also unquantified in public. The operationally nasty part is that it moves both sides at once: rain slows every cycle and simultaneously converts people who would have walked into people who arrive by car. Your worst throughput and your highest volume show up in the same thirty minutes.
The arrival curve
Not a throughput variable at all, strictly speaking, but the one that decides whether your throughput is enough. Event guidance describes a peak arrival window of 20 to 40 minutes for most events, and one operator account cites holiday resort weekends seeing 200 or more vehicles arriving inside a 4 hour window. Those are two completely different problems. A hundred cars over four hours needs 25 movements an hour, which is three people. A hundred cars in twenty minutes needs 300 movements an hour, which is thirty people you do not have, so the real answer is to stack at the curb, take keys faster than you park them, and clear the backlog during the meal. Curb stacking is a legitimate technique, not a failure. It buys throughput with curb space, and the only thing that makes it dangerous is running out of curb.
Measuring your own number, which takes about twenty minutes
Every number above is a starting point. The one that matters is yours, and getting it is genuinely quick.
- Pick your worst thirty minutes, not a representative half hour. A Tuesday cycle time is useless for sizing a Saturday. Measure the condition you are trying to survive.
- Define the cycle as door to availability. Start the stopwatch when the attendant takes the key, stop it when they are back at the stand and free to take the next one. Not "time to park the car". The walk back is half the cycle and it is the half people forget to count.
- Time ten parks and ten retrieves separately. They are different numbers and they peak at different times of the night.
- Use the median, not the average. One manual transmission, one blocked stack, one guest who cannot find their phone, and a mean of ten samples is garbage. The median tells you what a normal car costs.
- Measure your productive minutes instead of assuming them. Shadow one attendant for a full hour and total the time they are not on a cycle. Raskin assumes 50 of 60. If your attendants also take payment at the curb, work the key board, or hold the podium, yours will be lower, and that gap is where the missing capacity went.
- Do the arithmetic. Movements per hour equals your productive minutes divided by your median cycle. Complete cars per hour equals your productive minutes divided by the sum of your median park and median retrieve.
- Check it against reality. Take a real shift's vehicle count, divide by attendant hours worked, and see whether it lands near your calculated figure. If the real number is well below the calculated one, the difference is not cycle time, it is idle time, waiting, or a bottleneck at the podium. That is a different and usually cheaper problem to fix.
The most common way this measurement goes wrong. Managers time the fast attendant because they are the one who looks impressive with a stopwatch pointed at them. Your crew capacity is set by the median attendant on the median car, and on a busy night it is set by the slowest link in the chain, which is often not an attendant at all but the porte cochere itself. If cars cannot be handed off because there is nowhere to put them, hiring a seventh person changes nothing.
Turning the number into a crew size
Once you have your own cycle times, the crew calculation is one line, and it is Raskin's:
Attendants needed = (expected arrivals × your park cycle + expected departures × your retrieve cycle) ÷ your productive minutes per hour.
Do it for the worst hour, not the average hour, and round up rather than down. Then sanity check the result against the ratios in the valet pricing guide, which is where this number turns into money: crew size times shift hours times your loaded labour cost is the floor your quote has to clear. If your cycle-based crew size and your ratio-based crew size disagree by more than one person, the cycle number is the one to trust, because it is measured and the ratio is borrowed.
It is also worth putting in a proposal. When you are bidding against operators who quote a headcount with no reasoning attached, showing the venue that your crew size came from a measured cycle time at their distance to their lot is a real differentiator, and it costs you nothing to include. There is more on that in the piece on bidding a restaurant valet contract.
Where the software fits, and where it does not
ParkingPro does not calculate staffing. There is no crew size calculator, no cycle time timer, and no scheduling module, and we are not going to imply otherwise.
What it does have is the raw material for step 7 above. The shift report shows how many vehicles each attendant handled during a real shift, with the times attached. Divide that by the hours they worked and you have your actual throughput, from your actual lot, with your actual crew, instead of an average borrowed from somebody else's hotel. Run it for a slow night and a busy night and the gap between the two tells you more about your operation than any published ratio will.
Timestamps on tickets are the other half. Because entries and exits are logged, you can see when the arrival curve actually peaked rather than when you remember it peaking, which is usually a different time and is the input your crew schedule should be built on.
Straight about the limits. The report gives you vehicles per attendant per shift, not a broken-out park cycle and retrieve cycle. For those you still need the stopwatch, at least once. There is no automatic staffing recommendation, no labour scheduling, no payroll, and no licence plate recognition. Tax authority integration exists today only in the Dominican Republic and Mexico; in the US you get standard receipts.
Every cycle time and staffing figure on this page is attributed to a named public source consulted on 17 August 2026, or is arithmetic derived from one with the working shown. There is no industry productivity survey for US valet operations that we could locate, and the operator figures in circulation describe individual operations rather than a benchmark. Walking speed figures are US traffic engineering design values for signal timing, used here as a planning proxy and not as a measurement of any specific person. Treat everything here as a starting point for your own measurement. This article is general operational guidance and not legal, safety or employment advice. ParkingPro Cloud is a product of Abalon LLC.