Write a parking management system RFP nobody can answer yes to

Most parking management system tenders are copied out of a barrier manufacturer's brochure. Every software vendor answers yes to every line, the scores land within four points of each other, and the operator learns nothing they did not already know.

This post is the other kind of question. Operational, tied to a specific moment in a working day, and awkward enough that at least one vendor has to say no. Our own answers are at the bottom, including the six rows where ours is no.

Why every vendor answers yes

A requirement written as a capability is an automatic yes. Write "the solution shall support multi-site management" and there is no vendor on earth who ticks anything else.

These documents inherited their format from equipment tenders: barriers, terminals, pay stations, ticket printers. That format describes hardware, so it produces rows like "the solution shall provide reporting", which every piece of software written since 2004 satisfies. The vendor is not being dishonest when they tick it. The question simply has no wrong answer.

Four rules for a question that separates vendors

A useful question names a moment, admits a negative answer, asks for a demonstration, and asks about the failure rather than the happy path. Any row that fails those four tests can be deleted without losing information.

• It names a moment. Not "shift management". Instead: Tuesday 04:00, one driver, two sites, overlapping intervals.
• It has a possible no. If you cannot picture a credible vendor answering no, the row is decoration.
• It asks to see it. In the vendor's own demo tenant, and with the vendor's hands off the keyboard for the last five minutes.
• It asks about the failure. Every system works when the reseller sends a well formed email. Ask what happens on the morning they change their template.

The rostering questions

Rostering is where a two-site operator finds out whether the product understands that a person is one person. Ask these three and watch which vendor asks to come back to you. You find out at go-live otherwise, and by then it costs your duty manager forty minutes a morning.

• Can the same operator be scheduled on two overlapping intervals at two different sites? Does the system refuse it, warn about it, or accept it silently? Ask which of the three, not whether conflicts are handled.
• Can a driver sign in without an email address? Drivers on short contracts often have no company inbox, and creating one for each of them is a real line in somebody's budget.
• When you copy last week's roster onto next week, what happens to the manual changes already made to next week? Overwritten or preserved. There is a right answer and it is preserved.

The money questions

Ask who is allowed to void a cash line, and whether the voided line is still visible afterwards. If the answer is that the line gets edited, it is not a ledger and your cash variance will never be explainable.

• Who can void a line, and does the record keep the voided line with a reason and the name of the person who voided it?
• Does a blind count exist, meaning the person counting the drawer does not see the expected figure before they type theirs? A count that shows you the target first is not a count.
• Is "card" a capture or a declaration? Ask it out loud. In most operations software, card means an operator ticked a box after the customer paid on the car park's own terminal. That is a perfectly sensible design. It is not payment processing, and the difference shows up the first time you reconcile.

The channel questions

Ask what happens to a booking email the parser cannot read, then time how long it takes the vendor to reach the screen where that email is sitting. If there is no such screen, bookings are being dropped and nobody in the room knows how many.

• Where does an unparseable booking go? Discarded, written to a log only support can read, or queued somewhere the duty manager can see it with the raw message attached?
• When a reseller changes its email template on a Tuesday, whose job is it to fix the parser, and what is the turnaround? Get a number, in hours.
• Does the commission rate live on the channel or on the booking? If it only lives on the channel, your historic revenue reports rewrite themselves every time you renegotiate a rate.

That last row decides whether you can ever compare this March against last March. More on it in what a parking booking system has to do when you do not own the sales channel.

The shuttle and valet questions

Ask where the list of waiting passengers comes from. It is either a person's declaration or a claim about detecting arrivals, and you need to know which one you are buying.

• Who or what puts a customer into the waiting queue? A dispatcher typing, a flight feed, a customer app, or an assumption based on the booked time?
• What happens to a leg when the driver arrives and cannot find the customer? Is it an event with a count against it, or does the row just stay open until somebody tidies up?
• Is the key handling mode confirmed by a person, or inferred once from the booking and never looked at again? Keys held, customer keeps keys and valet are three different liabilities.

The exit questions

Ask for the export before you sign, not on the day you leave. The right answer is a named button or a named endpoint, plus a column list, plus a sample file with demo data in it.

• What comes out as a file, in what format, and who is allowed to run it? A vendor who says "we can provide an extract on request" is quoting you a future consultancy day.
• Do photos and signed condition reports come out with it, or only rows? A damage record without its photos is not evidence.
• Is historic booking import self-service, or run by the vendor's team? Both are fine. The second has a lead time and it belongs in writing.

The hardware question, asked properly

One question does the whole job: name the last three sites where you connected to an existing barrier or plate reader, and say who wrote the connector. Everything else about hardware is brochure copy.

A lot of software in this category has "ANPR integration" on the website. Sometimes that means an installed integration at a named site with a named supplier. Sometimes it means the product has a plate field and somebody would be delighted to discuss it. Ask for the supplier's name and ask whether their engineer will be on the call. Before you write the row, read what integrating with a car park actually means, and who does the wiring.

A worked example, and how to score it

Take a 400 space off airport car park. Two sites, 11 staff, two shuttles, roughly 60 per cent of bookings through three resellers. An example, not a customer.

Twelve questions, scored 2, 1 or 0. Two means the vendor showed you the screen. One means they described it credibly and offered to demonstrate it next week. Zero means yes with no screen behind it. Twenty-four points available.

The useful output is not the total. It is the list of rows where all three vendors scored zero, because that is the part of your operation nobody on your shortlist covers, and somebody in your office is going to keep doing it by hand next year. Price that hand work before you decide, not after.

Decide before the demos which four rows are pass or fail. Afterwards is too late. There is always a good reason to rescue the product you already liked.

Our answers, including the noes

Here is how ParkAgenda answers its own questionnaire. Yes first, then the noes, which are the part worth reading.

• Two overlapping intervals for one operator across two sites: rejected, and the conflict is named.
• Driver sign-in without an email inbox: yes. A manager sets a sign-in name and a password.
• Voided cash line: kept, superseded rather than edited, with a reason and the operator's name against it.
• Blind count: yes. The expected figure is not shown, and the variance is snapshotted at the moment of the count.
• Car leaving with a balance owed: warned, not blocked. We are not going to trap a customer's car over 12 EUR at 06:00.
• Unparseable booking email: quarantined with the raw message and the reason. A person promotes it, reprocesses it, whitelists the sender, or dismisses it. Nothing is dropped in silence.
• Waiting queue: built from a dispatcher's declaration, and a not-found attempt at the kerb is counted on the leg.
• Key handling mode: suggested by the system, confirmed by the operator, and a change away from the suggestion needs a reason.
• Export: bookings, analytics raw data and a cash recap, per parking, as files.

Now the noes.

• No ANPR, no cameras, no barriers, no kiosks. There is no hardware layer in the product and no plate recognition of any kind. We connect to the system you already run through our API, and our team writes that connector with your supplier. Installation is a local partner's job, on site.
• We do not take your customer's parking payment. There is no payment processor in ParkAgenda. Card on a booking is your operator's declaration that the customer paid on your own terminal.
• No rate engine. No tariff grid, no seasonal price list, no yield rules. Prices arrive on the booking from the source or are typed by an operator. The only figure we calculate is the overstay surcharge, and the operator confirms, edits or waives it.
• No GPS, no ETA, no automatic dispatch. A person declares who is waiting and a driver claims a leg.
• Historic booking import is run by our team, not by you, and it has a lead time.
• Email only. No SMS, no WhatsApp, no push notifications.

If one of those noes is a hard requirement for you, we would rather you found out on this page than in week three of an implementation. Our prices are published too, so the commercial row of your document is already answered on the pricing page.

For the wider vendor field and which car park each one is actually built for, see the parking software vendors, sorted by the car park they actually run.

Questions we get asked about this

How long should a parking management system RFP be?

Short enough that a vendor can answer every row honestly in one sitting. Twelve operational questions with named moments will separate a shortlist better than eighty capability rows, and they take a tenth of the time to score.

Should hardware requirements go in a software tender?

Only as integration questions. Name the barrier or plate reader you already run, ask who writes the connector, and ask for three sites where they have done it. Mixing equipment specifications into a software tender is how a booking system ends up being scored on gate arm speed.

What if a vendor will not answer in writing?

That is an answer. Write refused in the row and score it zero. You are buying a supplier relationship as well as a product, and this is the cheapest preview of one you will get.

What to do next

Cut the questions above to twelve rows and send the same twelve to three vendors. A short document gets answered honestly. A long one gets answered by whoever in the vendor's office is free on Thursday. If you want ours filled in against your own rows, in writing, with the noes intact, tell us what you run.