What the work must achieve
A request for proposal for proximity technology sits between standard IT procurement and physical infrastructure work. Most generic RFP templates assume you are buying software licences or fixed-price hardware, but a beacon, NFC or indoor navigation deployment depends on the physical environment, signal behaviour and ongoing maintenance in ways that a software-only document does not capture.
The core purpose of this RFP is to give suppliers enough information about your site, your operational constraints and your intended outcomes that they can propose a realistic solution rather than a generic pitch. Equally, the document must ask the right questions so you can compare responses on a like-for-like basis.
Three factors distinguish a proximity RFP from a standard IT procurement. First, the supplier needs to understand your physical space: building materials, ceiling heights, footfall density and sources of radio interference. Second, the proposal must address what happens after installation: calibration, battery replacement, firmware updates and inventory management. Third, because the technology involves detecting people's location, the RFP needs to set clear expectations around consent, data minimisation and compliance with UK privacy requirements.
A well-structured RFP does not need to specify every technical parameter. Instead, it should describe your environment and objectives precisely enough that a competent integrator can propose appropriate hardware, placement and configuration, and explain the trade-offs involved.
Pilot the design under representative conditions
Describing the physical environment
The most useful section of a proximity RFP is often the site description. Suppliers cannot estimate beacon quantities, placement density or calibration effort without understanding the space. Include floor plans with approximate scale, identify construction materials (particularly metal framing, glass partitions and reinforced concrete), note ceiling types and heights, and flag areas with high footfall density such as entrances, lifts and narrow corridors.
For museums and galleries, list the number of exhibits or zones that need triggering. For retail, map the customer journey from entrance to till and identify where notifications or navigation prompts should occur. For events, specify whether the infrastructure is temporary, semi-permanent or needs to be reconfigured between shows.
Defining the technology mix
State which technologies you are considering and, crucially, where each might apply. You might specify Bluetooth beacons for zone-based notifications in a retail floor, NFC tags at individual exhibits in a museum, and dynamic QR codes as a fallback where visitors do not have Bluetooth enabled. If you are unsure, ask suppliers to recommend a mix and justify their choices against your use cases.
Be explicit about whether you require an app, a web-based experience or both. This affects the entire architecture: native apps can scan for beacons in the background, whereas web-based approaches rely on more limited browser capabilities. Asking suppliers to explain the trade-offs in their response helps you evaluate whether they understand the constraints.
Pilot and calibration requirements
Include a clear pilot phase in the RFP. Specify the area or zones the pilot should cover, the duration, the number of users you expect to test with, and what constitutes a successful outcome. Ask suppliers to describe their calibration process: how they measure received signal strength indicator (RSSI) values in your environment, how they account for interference, and what accuracy they can realistically achieve given your building's characteristics.
Request that pilot results are documented with measured data, not assumed figures. A supplier who promises a specific accuracy without referencing your site conditions is not providing a useful baseline.
Maintenance, monitoring and documentation
The RFP should require suppliers to explain their approach to ongoing operations. Ask specifically about battery monitoring and replacement schedules, firmware update procedures, how they handle beacon failures, and what documentation they will hand over. Require an asset register that maps each beacon's identifier to its physical location, installation date and battery status. Without this, maintenance becomes guesswork once the installation team has left site.
Privacy and consent
State your privacy requirements in the RFP rather than treating them as an afterthought. Specify that the proposed solution must support opt-in consent, that location data should be minimised to what is necessary for the stated purpose, and that you expect clear documentation on data retention periods and deletion procedures. Ask suppliers to explain how their platform handles consent withdrawal and what happens to data when a user opts out.
What to maintain after launch
Asking for guaranteed accuracy figures
One of the most common mistakes is asking suppliers to guarantee a specific accuracy, such as "within one metre," without reference to your environment. Bluetooth beacon accuracy depends on RSSI, which is affected by walls, people, metal fixtures and even the user's phone model. A responsible supplier will explain the accuracy range they expect in your specific site and describe how they will measure it during calibration. If a supplier guarantees a precise figure upfront, treat it as a warning sign.
Leaving maintenance vague
Many RFPs focus heavily on the installation and say little about years two, three and four. Battery replacement is the most visible ongoing cost, but firmware updates, beacon relocation when floor layouts change, and asset register maintenance all require resourcing. Ask suppliers to describe what their support contract covers, what it excludes, and what responsibilities remain with your team.
Not specifying response format
If you do not tell suppliers how to structure their response, you will receive documents that are impossible to compare directly. Require a standard structure: executive summary, proposed technology and rationale, site-specific deployment plan, pilot approach, maintenance and support, privacy and compliance, pricing breakdown and timeline. Ask suppliers to answer specific questions in numbered sections so you can build a comparison matrix.
Key questions to include in the RFP
- How will you assess radio interference in our specific environment before finalising placement?
- What calibration process will you use, and what measured data will you provide?
- How does your platform handle consent, and what options exist for users who decline location tracking?
- What documentation will you provide at handover, including asset register, floor plans with beacon positions and configuration records?
- How do you monitor battery status, and what is the process for replacement?
- What happens if a beacon fails or is removed? How quickly will the system detect this?
- Can the proposed solution accommodate changes to floor layout or zone definitions without a full reinstallation?
- How do you handle firmware updates, and what is the rollback procedure if an update causes problems?
Limitations of the RFP process
An RFP can only do so much. It cannot substitute for a site survey, and no document will fully protect you from a supplier who overpromises. The most reliable approach is to use the RFP to shortlist two or three credible integrators, then require each to conduct a limited site assessment before submitting a final proposal. This costs more upfront but significantly reduces the risk of a deployment that fails to perform in your actual environment.
Finally, remember that the RFP is a starting point for a working relationship, not a contract that covers every eventuality. Build in review points during the pilot and installation phases so you can adjust the scope if the measured results differ from the proposal.
