Selection criteria for a defensible decision
Selecting proximity technology by use case means starting from the specific interaction or measurement you need to enable, then working backwards to the signal type that supports it. This sounds obvious, but a large proportion of failed deployments begin with a preferred technology in mind rather than a clearly defined task. The result is a system that technically functions but does not solve the operational problem it was meant to address.
The practical distinction between use-case-led and technology-led selection comes down to a handful of questions that apply regardless of venue:
- Does the user need to take a deliberate action (tap, scan) or should the system detect them passively?
- Is this a one-time interaction at a fixed point or does the system need to track movement over time?
- What range is required? A few centimetres, a metre or two, or broad zone-level detection?
- Can you reasonably expect users to have an app installed, or must the experience work without one?
- Does the use case require the user's device to receive data, the infrastructure to detect the device, or both?
These questions narrow the field quickly. If the answer is "deliberate action, fixed point, centimetre range, no app required", NFC or QR becomes the obvious candidate and beacons drop out of contention. If the answer is "passive detection, zone-level, continuous presence", beacons move to the foreground and QR becomes irrelevant. The difficulty arises when requirements sit between these extremes, which is where pilots and measured testing become essential rather than optional.
Use-case selection also forces clarity on what you are not trying to do. A museum that only needs to deliver text and audio to a visitor standing at an exhibit has a fundamentally different requirement from one that wants to measure dwell time across galleries and feed that into operational reporting. Both are valid, but they demand different infrastructure, different calibration effort and different maintenance regimes.
Capability, friction and operational burden
Delivering information at a fixed point
This covers exhibit labels, product information points, shelf-edge detail and any situation where content is tied to a specific physical location the user approaches deliberately. The interaction is typically one-to-one: one tag or code, one piece of content.
NFC and QR are the primary candidates here. NFC requires a tap, which means the user must be close and must know to interact. QR requires a camera scan, which demands line of sight and adequate lighting. Neither requires an app if the tag or code links directly to a web page. Beacons can trigger content at a fixed point, but they require the user to have Bluetooth enabled and, in most implementations, an app that listens for the beacon's identifier. For a straightforward information-delivery use case, adding that dependency is rarely justified unless the venue already has an app in widespread use.
The practical choice between NFC and QR at a fixed point often comes down to the physical environment. NFC tags embedded in a display case or behind glass work reliably; QR codes printed on the same glass may suffer from reflections. Conversely, QR codes on a poster at eye level are immediately scannable, whereas fitting an NFC tag to a curved or irregular surface can be mechanically awkward.
Triggering notifications on zone entry
When the goal is to send a notification as someone enters a defined area — a retail promotion zone, an event seminar room, a museum gallery — the requirement shifts from fixed-point interaction to proximity detection. Beacons are the established option here because they broadcast continuously and a listening app can trigger a notification when the received signal strength crosses a defined threshold.
The limitation is that zone entry via beacons is not a precise gate. RSSI values fluctuate with device orientation, body absorption, and environmental interference, so the boundary of a "zone" is fuzzy rather than sharp. A user standing just outside the intended zone may still receive the notification, and one just inside may not. Calibration in the actual space, with the actual devices your visitors carry, is the only way to understand the true zone shape. Promising exact zone boundaries before that measurement is done is a common source of disappointment.
QR codes cannot passively detect zone entry. An NFC tag at a doorway could theoretically trigger a notification if tapped, but that converts a passive detection use case into a deliberate-action one, which changes the user experience entirely.
Indoor wayfinding and turn-by-turn navigation
Wayfinding requires the system to know where the user is relative to a map, update that position as they move, and calculate a route. This demands continuous or near-continuous position fixes, which pushes the requirement firmly towards beacon-based infrastructure or, in some larger venues, Wi-Fi positioning.
The number of beacons required for wayfinding is considerably higher than for simple zone triggers. A single beacon can define a rough zone, but reliable positioning across a floor typically needs multiple beacons in overlapping range so the receiving device can triangulate or use fingerprinting. That increases procurement cost, installation complexity and ongoing battery replacement workload. Wayfinding also demands an up-to-date indoor map, which introduces a separate data-maintenance burden whenever the physical layout changes.
NFC and QR have limited roles in wayfinding. QR codes placed at decision points — junctions, lift lobbies, stairwells — can let a user scan to see a map or get directions from that specific spot, but this is not continuous navigation. It is closer to a series of fixed-point information deliveries chained together. For some venues, particularly those with simple layouts or infrequent wayfinding needs, that may be sufficient. For complex buildings or accessibility-critical routes, it usually is not.
Presence detection and dwell-time measurement
When the use case is operational — understanding how long people spend in an area, which routes they take, where congestion builds — the system needs to detect devices without requiring any action from the user. Beacons configured to listen for nearby BLE transmissions, or dedicated BLE gateways, can log device sightings over time.
This use case sits squarely within privacy-sensitive territory. Detecting a device identifier to measure dwell time constitutes processing of personal data under UK GDPR if the identifier can be linked to an individual, and the Information Commissioner's Office expects clear justification, transparency and data minimisation. MAC address randomisation on modern smartphones further complicates matters, as the same device may present different identifiers over time, making longitudinal tracking unreliable without additional mechanisms that themselves raise privacy questions.
NFC and QR cannot serve this use case at all, as they require deliberate user action and provide no continuous signal.
Check-in, validation and access control
Ticket validation, staff check-in, controlled access to a restricted area — these use cases share a common requirement: a deliberate, verified interaction at a specific point, often with a need for speed and reliability.
NFC is well-suited here. A tap is fast, unambiguous and hard to trigger accidentally. QR codes can also work for validation, but they require the user to present their phone screen to a scanner, which can be slower and is affected by screen brightness and angle. Beacons are a poor fit because passive detection does not provide the deliberate confirmation that access control typically demands.
Queue and flow monitoring
Detecting how many people are waiting in a queue or how flow moves through a space is a measurement use case, not a content-delivery one. It generally requires infrastructure-side detection — BLE gateways or similar — rather than device-side beacons. The practical challenges are significant: distinguishing queueing from passing, handling varying densities, and maintaining accuracy as the physical queue shape changes. This is an area where pilot testing with real visitor patterns is essential before committing to a full deployment.
Pilot gates, limitations and ownership
The most frequent error in use-case-driven selection is conflating what a technology can do with what it does well in a specific environment. Beacons can, in principle, trigger content at a fixed point. But if that is the only use case, the overhead of app dependency, calibration and battery management is hard to justify when an NFC tag or QR code would achieve the same result with less infrastructure. Conversely, QR codes can, in principle, be placed at every junction to approximate wayfinding — but the resulting experience is fragmented and does not meet the expectations of users who have seen continuous navigation in other contexts.
A second common mistake is selecting for the best-case scenario rather than the typical one. A beacon deployment may work perfectly during a quiet afternoon test but behave differently when the space is crowded, because human bodies attenuate Bluetooth signals significantly. An NFC installation may function reliably with a test phone but fail with certain device models that have the NFC antenna in a different position. Use-case selection must account for the full range of real-world conditions, not just the controlled ones.
Before finalising any technology choice against a use case, the following checks are worth completing:
- Has the use case been written down as a specific, testable statement? "Visitors receive exhibit information" is too vague. "A visitor standing within one metre of exhibit label X receives a web page with text and audio within three seconds, without installing an app" is testable.
- Have you confirmed the user's likely device state? Bluetooth off, no app installed, poor mobile signal — any of these can invalidate a technology choice for a given use case.
- Have you tested in the actual physical environment, not a lab or office, with a representative sample of devices?
- Does the chosen technology introduce a maintenance burden (battery replacement, tag damage, code vandalism) that is proportionate to the value of the use case?
- Does the use case involve detecting or tracking individuals? If so, have you mapped the privacy implications against current UK guidance before committing to the technology?
- Is there a clear rollback plan if the technology does not perform as expected in live operation?
Finally, resist the temptation to future-proof by selecting a more complex technology for a simple use case on the basis that "we might need it later". That approach adds cost and maintenance from day one for a capability that may never be used. Select for the use case you have defined, pilot it, measure it, and expand the infrastructure only when a second, validated use case justifies it.
