Define the Requirement Before Requesting Quotes
Procuring proximity technology—whether Bluetooth beacons, NFC tags, QR infrastructure, or a combination for indoor navigation—means buying a physical system that will sit in your venue for years, not a piece of software you can swap out overnight. The hardware, its placement, and the ongoing maintenance burden all persist long after the initial purchase order is signed. A procurement checklist forces you to pin down the operational realities before contracts are exchanged.
The purpose of this checklist is not to replace technical evaluation of individual beacon models or supplier capabilities, but to ensure that the procurement process itself covers the questions most often missed. These typically fall into four categories: scope alignment, hardware and installation practicalities, data and privacy obligations, and long-term operational costs. Skipping any of these categories tends to produce one of two outcomes: a system that technically works but nobody maintains, or a contract that looks manageable until battery replacements and firmware updates start arriving.
A useful way to approach the checklist is to treat it as a sequence of gate criteria. Each section represents a set of conditions that should be satisfied before you move to the next stage of procurement. If you cannot answer a question with documented evidence rather than a verbal assurance, that is a signal to pause rather than proceed.
| Area | Evidence to request |
|---|---|
| Performance | Pilot method, acceptance criteria and raw test results |
| Operations | Asset export, battery plan, update process and support response |
| Security | Update policy, access controls, incident process and assurance |
| Privacy | Data flow, roles, retention, subprocessors and deletion evidence |
| Exit | Data export, configuration ownership and hardware re-use options |
Evaluate Hardware, Software and Suppliers
Defining the Operational Scope
Before requesting quotes, document what the system must do in physical terms. For a retail environment, this might mean triggering a notification when a shopper enters a specific aisle zone, with a defined maximum acceptable latency. For a museum, it might mean delivering exhibit content when a visitor stands within a certain radius of a display case. For an event venue, it could involve wayfinding between stages and facilities across a temporary site.
The scope document should specify the number of distinct zones, the expected density of users in each zone at peak times, the physical characteristics of the space (ceiling height, wall materials, metal fixtures), and whether the system needs to function alongside existing Wi-Fi infrastructure or other wireless systems. Without this, suppliers will price against different assumptions and you will not be able to compare responses meaningfully.
Hardware Quantity, Spares and Compatibility
When specifying quantities, include a spares allowance. Beacons will be damaged, lost during maintenance, or fail outside warranty. The right spares figure depends on your environment—a busy retail floor with trolleys and cleaning equipment needs a higher buffer than a museum display case. Ask suppliers to quote spares separately so the true unit cost is visible.
Check that the proposed hardware supports the Bluetooth standard and profile your platform requires. Not all beacons implement iBeacon, Eddystone, or manufacturer-proprietary formats in the same way. If your software platform expects a particular advertising packet structure, confirm compatibility in writing rather than assuming it based on the product name. For NFC tags, verify the chip type and memory size against your content requirements, and confirm whether tags can be rewritten after initial encoding or are locked to a single URL.
Installation and Physical Fixings
Clarify who is responsible for physical installation. If the supplier is quoting installation, confirm what that includes: mounting hardware, cable management (if powered beacons are proposed), access equipment, and any disruption to your venue operations. If your own facilities team will install, request the supplier’s mounting specifications, recommended fixings for each surface type, and minimum clearance requirements around each unit.
For listed buildings or venues with heritage constraints, procurement must account for consent requirements before any fixing method is agreed. Adhesive-mounted beacons may be acceptable where drilling is not. Document these constraints in the specification so suppliers can propose appropriate mounting solutions rather than defaulting to standard options.
Power, Batteries and Environmental Ratings
For battery-powered beacons, the procurement specification should state the required battery chemistry, the minimum acceptable battery life at your chosen advertising interval and transmit power, and how battery status will be monitored. If the venue experiences extreme temperatures—cold storage areas, glass-roofed atria in summer, or outdoor event zones—confirm that the hardware and batteries are rated for those conditions. Battery performance degrades significantly in low temperatures, and a unit quoted for twelve months at room temperature may last far less in a refrigerated environment.
For mains-powered or PoE beacons, confirm power source availability at each planned location and who bears the cost of any electrical work required.
Data, Privacy and Compliance
controller and processor roles depend on who determines the purposes and means of processing. The venue may be a controller, but suppliers can have separate or joint roles for some processing; map and record the actual responsibilities instead of assigning them from the product category
Treat supplier compliance claims as evidence to examine, not a substitute for the purchasing organisation’s own assessment. Request data-flow, security, retention, subprocessor and assurance documentation, and complete a DPIA when the planned processing is likely to be high risk
Integration and Platform Requirements
If the proximity system needs to feed data into or receive triggers from other systems—such as a content management system, digital signage, or analytics platform—specify the integration method and data format in the procurement documents. Ask suppliers to confirm which integrations they support natively, which require custom work, and what ongoing maintenance those integrations will need when either system is updated.
Acceptance, Contracts and Whole-life Cost
Procuring Against a Marketing Brief Rather Than an Operational One
A frequent error is writing the procurement specification around a campaign concept—“push offers to shoppers near the shoe display”—without translating that into the technical and operational requirements that determine hardware choice, quantity, and placement. Suppliers responding to a vague brief will propose different solutions at different price points, and you will have no objective basis for comparison. Always ground the specification in physical zones, user densities, and measurable performance criteria.
Ignoring Total Cost of Ownership
The purchase price of beacons or NFC tags is typically a small fraction of the long-term cost. Battery replacements, failed unit swaps, firmware updates, recalibration after physical changes to the venue, and platform subscription fees all accumulate. When evaluating quotes, ask each supplier to provide a projected five-year cost breakdown that includes these elements. If a supplier cannot or will not do this, treat the gap as a risk rather than an assumption that costs will be negligible.
Overlooking Firmware and Configuration Management
Beacons ship with firmware that will need updating over time. Procurement should establish how firmware updates are delivered—over-the-air, via a physical gateway, or by manual connection to each unit—and who is responsible for executing them. If your inventory runs into hundreds of units, manual update processes become impractical. Also confirm what happens if a firmware update changes the advertising behaviour in a way that affects your calibrated zones.
Assuming Accuracy Claims Without Site-Specific Evidence
Supplier documentation often states accuracy ranges for their hardware. These figures are measured in controlled environments and will not necessarily reflect your venue. Do not write accuracy requirements into a contract based on a supplier’s general specification unless you have verified them through a measured pilot in your actual space. Instead, specify that accuracy must be demonstrated during acceptance testing under your site conditions, and define what constitutes an acceptable result.
Key Checks Before Signing
- Scope alignment: Does the quoted solution match your documented zone definitions, user densities, and physical constraints, or has the supplier interpreted the brief differently?
- Spare provision: Are spares quoted separately, and is the unit price consistent with the main order?
- Mounting method: Is the proposed fixing appropriate for your building type, and have any consent requirements been addressed?
- Battery monitoring: Is there a documented method for checking battery status across the full inventory, and what alerting is included?
- Data-protection roles: Does the contract reflect who determines each purpose and means of processing, including any controller, joint-controller or processor role, with suitable clauses for the actual arrangement?
- Integration evidence: Has the supplier demonstrated the specified integration working, or provided documented API specifications you have technically reviewed?
- Acceptance criteria: Are there measurable, site-specific acceptance tests defined in the contract, rather than vague delivery milestones?
- Exit provisions: If you need to change supplier or platform in future, can you reconfigure or replace the hardware without a complete reinstall, and is there a clear process for data export?
- Warranty scope: Does the warranty cover the operational conditions of your environment, or does it exclude the very factors—temperature, moisture, physical impact—that are present in your venue?
- Update responsibility: Is it documented who handles firmware updates, how often they are expected, and whether they are included in the support agreement or charged separately?
Working through these checks before procurement closes will not eliminate every operational problem, but it will prevent the most common and expensive ones: buying hardware that cannot be maintained, signing contracts with unclear data obligations, and discovering after installation that the system does not perform as assumed in your specific environment.
