Technical buying guide
Parking Guidance RFQ: Information a Supplier Needs
A useful parking guidance system RFQ tells suppliers what information drivers need, where that information comes from and how the proposed system will be accepted. A bay count and a request for sensors leave too much open. Two suppliers can quote similar quantities while assuming different zones, sign logic, installation work and software responsibilities.
Prepare a short, consistent enquiry pack before requesting prices. The Parking Guidance Systems category provides the equipment-family starting point. This checklist helps project teams define the required scope without assuming that every detection method, interface or software option is included in a standard package.
Establish the parking inventory and the decision boundaries
Issue a current plan with levels, zones, ramps, entrances, exits and numbered bays. Identify spaces that have different operating rules, such as reserved, accessible, visitor or temporarily unavailable spaces. Include the project team’s rule for each type. A physically empty bay is not always a bay available to every arriving driver.
Define the information needed at each scale. Does the owner need a count for the entire car park, individual levels, zones or each bay? Is the information intended for drivers, operators or both? These requirements affect the architecture and the evidence a bidder must provide. Do not let a quotation silently decide the required level of detail.
State which counts or observations already exist and who controls them. Where existing information will be reused, identify its meaning, update conditions and known limitations. Treat a total vehicle count, an occupied-bay observation and an available-space figure as different data items until the project defines how they relate.
The parking guidance components and site survey guide explains the earlier equipment and survey questions. Attach the resulting site information to the RFQ so bidders are working from the same baseline.
Describe the proposed detection scope without choosing by label
Provide ceiling and mounting information, obstructions, lighting, power and communication routes, and representative photographs. Mark unusual bay geometry, motorcycles, loading areas and any spaces excluded from the scope. These details help bidders identify where their proposed method needs a demonstration or an alternative arrangement.
If the owner has not selected a technology, invite a clearly identified base proposal and alternatives against the same requirements. Require the supplier to explain coverage, exclusions, installation dependencies and the method of validating results. A technology name alone does not establish reliable performance at the site.
For camera-based proposals, include the owner’s information-handling and network requirements. Have the responsible parties define access, retention and any local data obligations. For other detection arrangements, confirm what each device observes and how those observations reach the controller. The RFQ should request the offered implementation, not prescribe an unverified feature.
Give every driver-facing display a purpose
List sign locations on the plan and identify the decision each sign supports. Record destination names, the intended audience and the states that need to be displayed. An entrance display, a ramp sign and an aisle indicator serve different decisions. They should not all be priced as an undefined display quantity.
The FHWA discussion of active parking management describes a cycle from parking information to driver decisions and highlights the need to keep changing parking information updated. It supports treating information flow as part of the system brief. It is not a specification or a performance certificate for a particular supplier.
For a Commercial Parking project, document reserved tenant areas, public zones and any closures that change the driver’s route. Include language and naming requirements where relevant. Request confirmation of the actual sign formats, control method and available message states in the offer.
Use a scope table that exposes assumptions
| RFQ item | What the buyer supplies | What the bidder should return |
|---|---|---|
| Inventory | Current bay, level and zone plan | Included areas, quantities and exclusions |
| Detection | Site conditions and required information detail | Proposed method, coverage and validation approach |
| Guidance | Sign references and driver decisions | Display types, messages and data dependencies |
| Communications | Available routes, network rules and responsibility | Architecture, interfaces and required site provision |
| Software | Operator tasks, permissions and required records | Included functions, licenses and documented limitations |
| Installation | Working hours, access and civil-work boundaries | Installation scope, dependencies and commissioning work |
| Acceptance | Required scenarios and evidence | Test method, agreed criteria and defect-resolution process |
| Handover | Operator and service responsibilities | Drawings, configuration records, instructions and support scope |
Ask bidders to mark each response as included, optional, excluded or requiring clarification. Separate an equipment allowance from a confirmed quantity. Identify who owns changes if the issued plan differs from the final installation.
Specify how information fails and recovers
Define the required behaviour when a detector, communication link or controller is unavailable. Should a related sign stop displaying a numerical availability claim, show an agreed message or follow another approved rule? Request a documented response for the proposed configuration. Continuing to show an old number is not automatically an acceptable fallback.
Clarify who can correct a count or change the status of a zone, and what record is retained. Reconnection should include an agreed way to confirm that displayed information and the actual parking state are aligned. Do not assume that a platform resynchronizes automatically without asking how that behaviour is demonstrated.
Maintenance access belongs in the commercial scope too. Identify equipment that will need work above parked vehicles or in live traffic areas. Agree working restrictions, isolation arrangements and the party responsible for safe access. These conditions may affect implementation even when the equipment list is unchanged.
Agree the acceptance method before comparing price
Select representative zones and conditions with the project team. Define how the reference parking state will be observed, when readings will be compared and how closed or reserved spaces are treated. Set project-specific acceptance criteria with the proposed supplier. Do not invent a universal occupancy accuracy figure or accept a percentage without its measurement method.
Include ordinary parking changes, agreed edge cases and controlled fault scenarios. Follow the information from observation through the controller to each relevant sign and operator view. Record the configuration, time, expected result and observed result so a discrepancy can be traced to a location and process.
Use the Parking Access System RFQ Checklist for broader procurement boundaries. The guidance-specific pack adds the bay rules, information architecture and display obligations that a general entrance enquiry cannot fully describe.
The enquiry is ready when another project team can understand the required outcome from the documents without a private explanation. Send the current plan, parking inventory, sign schedule, site conditions and responsibility table together. We can use that common brief to discuss the available equipment families and return the questions that must be settled before a comparable proposal is issued.