Valet parking software stands or falls on the key handover

Valet parking software is sold on the ticket and the app. The ticket is not where the risk lives. The risk is the ninety seconds when a key moves from one hand to another, and the record that still exists three weeks later when a customer says the offside rear door was straight when they handed the car over.

A valet product should be judged on the handover and on what it can prove afterwards. Everything else is a lookup screen. This post walks the chain of custody from kerb to space to return, sets out the four questions that get asked after a damage claim, and says plainly what software cannot do about any of it.

A ticket is a lookup, not a record

A ticket proves that a car and a number were once associated. That is genuinely useful for finding the car in a hurry, and it is worth nothing in an argument.

What a ticket does not carry: how many keys were received. Whether the customer kept a spare. What the car looked like on arrival. Who drove it to the space and at what time. Who fetched it. Whether anybody looked at it in between. By the time a claim arrives, that ticket is in a bin at an airport and the only surviving record is what somebody remembers.

The chain of custody has four handovers, not one

Most products record the first and the last, and leave the middle blank. The middle is where cars get scratched.

1. Kerb to intake. Customer to agent. Keys counted, condition recorded, signature taken.
2. Intake to space. Agent to driver, often a different person, sometimes an hour later, frequently on a different shift.
3. Space to preparation. Whoever fetches the car when the return flight is announced, moves it, washes it if that was sold, brings it forward.
4. Preparation to kerb. Back to the customer, who walks round it in the dark with a suitcase in one hand.

Ask any operator where the unexplained damage comes from and you will get the same answer: the middle two. They are also the two that no ticket, no app screen and no photo at the kerb covers.

The four questions asked after a claim

Three weeks later, a claim arrives. It will be resolved on four answers.

• Who took the car, and at what time?
• Who moved it, and at what time?
• Who returned it, and at what time?
• Was the damage noted before any of that, and can you show it marked on a picture of the car with a date attached?

If you can answer three of the four, the missing one is the one the argument is about. That is not bad luck, it is arithmetic. The customer's account fills whatever gap you leave.

A shift is what makes the answer stick

The car was moved at 18:42 is not an answer. Marek, driver on the 14:00 to 22:00 shift at the west site, moved it at 18:42, is an answer. The difference is whether a movement belongs to a named person on a named shift or to a site.

ParkAgenda holds the shift agenda per car park as a flat weekly grid. One car park, one interval, one function (driver, dispatcher, vehicle preparer, check-in agent), zero or one operator. A conflict across car parks is rejected rather than warned about. A week can be copied forward, and the copy only adds, so it never quietly overwrites a shift somebody already changed.

There is one detail underneath this that matters more than it sounds. Operators sign in with a name and a password chosen by their manager, and they do not need an email inbox. A driver who has no login shares somebody else's, and a shared login destroys the chain of custody more thoroughly than a lost ticket ever will. The cheapest way to stop that is to make a personal login free of admin.

How the same shift model plays out for the people meeting customers at the terminal is covered in meet and greet is a scheduling problem disguised as a service.

What recorded has to mean before it is worth anything

Recorded means it cannot be tidied up afterwards. If a record can be edited quietly, it is a note, and a note settles nothing.

ParkAgenda records the physical intake as a six step wizard: confirm the booking details, handling and keys, vehicle state, damage inspection on a car diagram, customer signature, then review and finalise.

• A damage marker carries a type, an optional severity, a comment and photos, placed on the diagram in normalised coordinates so it lands in the same spot on any screen size.
• A deleted marker becomes a tombstone rather than a hole. You can see that something was removed, and when.
• Once a check-in is finalised, it only changes through an amendment that carries who, when, why and the difference.
• A PDF report comes out of the finalised record, which is the thing you attach to an email to an insurer.
• Separately, an append-only activity history records the change with the actor, their role, and the values before and after. Managers see it. Operators do not.

That last pair is deliberate. The history is written for a manager who wants to know what happened, in language a person can read. It is not sold as a forensic audit trail, and reads are not recorded at all.

The key decision is a field, and a person has to confirm it

Three handling modes exist for a stay: keys handed over, customer retains the keys, valet. The system suggests one from the booking. The operator has to confirm it.

If the operator picks a different mode from the suggested one, they give a reason, and the stricter of the two policies applies. Customer retains keys forces zero received keys and a mandatory spot number, because a car you cannot move has to be findable by somebody who has never seen it.

A valet stay is flagged from the booking option itself, whenever the option name contains valet or voiturier. That flag drives the valet badge on the booking, the valet filter on the day's list, and the opt-in valet digest that goes out at 20:00 the evening before in the car park's own timezone. A driver arriving for a 4am shift already knows how many keys are coming.

A worked example

Take a valet operation handling 120 vehicle movements on a Sunday in August: 45 arrivals, 40 departures and the rest internal moves. Example figures, constructed for this post.

Forty-five intakes, each with a condition record. At two minutes each that is ninety minutes of intake work concentrated into an evening peak, spread across three agents. Two minutes is the number to hold on to, because any process that takes six will be skipped by the third agent on the third Sunday.

Nineteen days later a claim lands: a scratch on the offside rear door, 900 euros of bodywork, and a customer who is certain.

With a ticket, you have a car, a number and a memory. You pay.

With a finalised check-in you have either a marker on the offside rear door, which ends the conversation in one email, or no marker, which tells you the damage happened on your site. The second outcome is not a win. It is still worth having, because the four handovers are named and you know which shift to talk to on Monday.

Run that arithmetic across a season. Even two settled claims a year at 900 euros pays for a lot of intake discipline, and the discipline is worth more than the software.

What no software can do, including ours

This is about traceability, not about damage prevention. Say it out loud in the buying meeting, because a vendor who lets you believe otherwise is selling you a disappointment.

• No software stops a scratch. It changes what happens after one.
• Nothing detects damage automatically. A person walks round the car and looks at it. There is no camera arch, no scanner and no image comparison in ParkAgenda.
• ParkAgenda has no native app. The console is a web app, and the check-in wizard is designed for a tablet or the screen at the intake point, not for a phone today. That is a real limitation and you should hear it now rather than at the demo. What a phone-first valet screen has to get right is the subject of the valet app has to work with one thumb and cold hands.
• The check-in saves live, to the server. There is no offline mode and no queued work on the device. If your intake point has patchy signal, fix the signal before you buy any software that records anything at the kerb. That is true of every product in this category, and most of them will not tell you.
• There is no GPS and no vehicle tracking. A spot is a field an operator fills in.

Four things to ask for in a valet software demo

Do not ask for features. Ask for these, in this order, and watch what happens.

1. Show me a record finalised three weeks ago, and change something in it. Then show me what the change looks like to a manager.
2. Tell me who moved this specific car between 15:00 and 19:00, and on whose shift.
3. Delete a damage marker, then show me what is left behind.
4. Turn off the wifi on that tablet and carry on with the intake. Tell me exactly what I lose.

The fourth one ends more demos than the other three combined.

FAQ

Does ParkAgenda know where a car is parked?

It records the spot, typed or chosen by an operator, and shows it on the departure board along with the plate, the model and the colour. There is no GPS, no sensor and no automatic detection of where a car actually is.

Can the customer sign on their own phone?

No. The signature is captured on the operator's screen at intake, as part of the six step wizard, and it is stored with the finalised record.

What if the customer keeps their keys?

That is a separate handling mode. It forces zero received keys and makes the spot number mandatory, so a car nobody can move is still a car anybody can find.

Does the driver get told who is waiting?

Waiting is declared by a person, not detected. The shuttle board shows the queue a dispatcher has confirmed, and a driver claims a leg from it. There is no ETA and no automatic detection that a customer has landed, which is set out in shuttle management software is a promise about waiting time.

Where to start

Pick one Sunday and time your own intake. If a full condition record takes more than two minutes with a real customer standing there, no software will save it, and the first thing to change is the sequence your agents follow, not the tool.

When you are ready to compare, the features page shows the check-in, the handling modes and the departure board, and you can ask for a look at a finalised record rather than a slide deck.