How to Write a Parking Enforcement Software RFP

Most parking enforcement RFPs are recycled from the last one, which was recycled from a vendor's own template. The result is a hundred-row feature checklist that every bidder marks "yes" and a scoring sheet that rewards the best demo team rather than the best system. If you are buying for a university, a city, a hospital, or a parking authority, here is a leaner structure that surfaces the differences that will matter in year two.

What to actually require

Write requirements around outcomes your staff can verify, in five groups. Operational: officers issue evidence-backed citations from standard phones or handhelds, with plate scans checked against permits and paid sessions before a ticket is written. Payments: drivers pay online by ticket number, plate, or QR code without creating an account, and you can state precisely where the money settles and when. Data: every record you create (citations, appeals, payments, permits) exports in a standard format, on demand, without a services contract. Branding: the citation, the pay page, and the receipts carry your institution's name and domain, not the vendor's. Implementation: a dated plan from signature to first citation, with the roster import and payment setup on the critical path where they belong.

The questions that separate vendors

Three questions do more work than the whole checklist. First, where does citation money settle, and whose name is on the merchant account? Platforms differ between direct settlement to your account and funds that pass through the vendor's balance first, and the difference shows up in reconciliation, refunds, and what happens if you ever leave. Lotably's answer, for comparison, is Stripe Connect direct charges to your own Stripe account. Second, can we export everything, today, by ourselves? Ask for a sample export in the proposal, not a promise. Third, what does the driver pay beyond the fine? Convenience fees charged to drivers are a hidden cost with a real effect on payment rates and public complaints, and some "low cost" bids are funded there.

Score total cost at your real volume

Have each bidder price the same scenario: your actual lot count, your annual citation volume, your expected online payment share. Ask for the all-in annual figure including platform fees, percentage or per-citation fees, hardware, implementation, training, and any driver-paid fees stated separately. A low platform fee with a high percentage beats the reverse at small volume and loses badly at scale, so the honest comparison only exists at your numbers, never on the rate card. Our buyer's guide has a longer treatment of evaluation criteria that adapt well to formal scoring.

Leave room for platforms, not just incumbents

Procurement language often accidentally requires a legacy vendor: demanding proprietary handhelds, or an on-premise option nobody will use, filters out modern platforms before scoring starts. Specify the outcome (printed slips where you need them, uptime and audit logging) rather than the 2012 implementation of it. Several requirements that used to need enterprise procurement, like white-label branding and published pricing, are now table stakes on self-serve platforms. Lotably publishes its entry pricing and quotes institutional deployments as Enterprise with the documentation a procurement file needs, and the university and municipality pages show the deployment shapes those programs use.

A sane timeline

Four weeks for responses is enough when the RFP is specific. Shortlist two or three, and replace the demo beauty contest with a working session: give each finalist a sample roster and a test lot, and have your own officers issue and pay a citation end to end. An hour of hands-on use tells your evaluation committee more than any slide deck. If you want Lotably in that shortlist round, contact us and we will set up a test workspace against your scenario.