The visitor or operational moment to support
Queue detection in retail sits at the intersection of footfall counting and operations management. Several technologies can estimate queue length and waiting time, each with distinct trade-offs that become apparent once you move beyond a supplier's pitch and into a live shop floor.
Camera-based systems use overhead or angled cameras paired with computer vision to detect people shapes and track movement through defined regions. They can produce reasonably granular data about queue formation and service speed, but introduce privacy considerations around biometric processing under UK GDPR. They also require clear sightlines, consistent lighting and ongoing calibration as store layouts shift.
Infrared beam counters and pressure mats detect physical presence at a point or small area. They are simple and relatively inexpensive, but tell you only that someone crossed a line or stood on a tile. They cannot easily distinguish between a queuing customer and a passer-by brushing the threshold, and they do not track dwell time without additional logic.
Wi-Fi probe request counting listens for signals from phones searching for networks. It requires no hardware on the customer's part, but many modern phones randomise or suppress MAC addresses, reducing detection rates. The signal also does not resolve well enough to separate a queue from an adjacent browsing area in most shop layouts.
Bluetooth beacon-based detection uses low-energy beacons placed at queue entry points, service counters and, where useful, mid-queue positions. It detects phones with Bluetooth active and, depending on the approach, can estimate how many devices are in a zone and how long they have been there. This method fits naturally into a broader beacon deployment but shares the fundamental limitation that it detects devices, not people, and only those with Bluetooth enabled.
Manual observation, whether periodic or continuous, remains the baseline. It costs staff time but produces contextual judgements that automated systems still struggle with, such as distinguishing a customer waiting to be served from someone waiting for a companion who is still shopping.
For most UK retailers evaluating proximity technology, the practical question is not which system is universally best, but which matches the store format, the existing infrastructure and the level of accuracy the operations team actually needs to act on.
Beacon-Based Queue Monitoring
A beacon-based queue monitoring setup typically places beacons at two or three positions: a virtual entry point where a queue begins, one or more mid-queue positions for longer queues, and a service point beacon near the till or counter. The system logs when a detected device enters each zone and when it leaves, producing a dwell-time estimate that approximates waiting time.
There are two broad approaches to detecting devices. The first relies on a retailer's own app installed on the customer's phone. The app listens for beacon identifiers and reports its position to a backend system. This gives clean, consented data but limits detection to app users, which in most UK retail contexts is a small fraction of total footfall. The second approach uses beacon gateways or scanners that listen for generic Bluetooth advertisements from any nearby phone. This captures a larger sample but introduces ambiguity around consent and data minimisation under UK GDPR, because the device identifier, even if hashed, may still constitute personal data in some interpretations.
Zone definition and beacon placement
Defining the queue zone requires care. A beacon's radio range does not map neatly to a painted floor line. If the beacon at the queue entry also covers part of a neighbouring display, the system will count browsers as queuers. Practical deployments often use a combination of reduced transmit power, physical shielding and RSSI threshold tuning to narrow the detection area, but this must be measured on site rather than assumed from a datasheet.
Placement height matters. Ceiling-mounted beacons give a more even coverage pattern but may pick up devices on the other side of a low fixture. Counter-level beacons are closer to the phones but more vulnerable to being obstructed by baskets, display units or the counter itself. A pilot should test at least two positions and compare the resulting zone shapes using a floor plan marked with actual RSSI readings.
From device counts to queue estimates
Because the system detects devices rather than people, a raw count must be adjusted. One person may carry two Bluetooth-enabled devices; a family group of three might produce four or five signals. Conversely, a customer with Bluetooth disabled will be invisible. Most systems apply a scaling factor based on observed ratios, but this factor drifts as device habits change and should be revisited periodically rather than set once and forgotten.
Queue Detection Accuracy and Limitations
No beacon-based queue system delivers a precise count without a measured environment. The RSSI values that underpin zone detection fluctuate with the number of people in the space, the orientation of the phone, the presence of metal fixtures such as refrigerated cabinets or shelving units, and even the humidity and temperature of the shop floor. A reading that reliably indicates a device is within a two-metre zone on a quiet Tuesday morning may shift by a metre or more on a busy Saturday afternoon when dozens of bodies are absorbing and reflecting the signal.
Accuracy is best understood in bands rather than single figures. A well-calibrated beacon system in a controlled environment might distinguish between "no queue," "a few people" and "a significant queue" with useful reliability. Expecting it to report "fourteen people" and be correct within one or two is unrealistic for most retail environments without extensive per-site calibration and regular revalidation.
Common sources of error
- Signal bleed: Beacons near open doorways or wide aisles will detect devices outside the intended queue zone. Reducing transmit power helps but also reduces detection range for genuine queue members.
- Staff devices: Till operators and floor staff carrying company phones or handheld terminals will be detected by service-point beacons. Their dwell time is not a queue metric and must be filtered, usually by MAC address exclusion lists that require ongoing maintenance.
- Bluetooth variance across handsets: Different phone models and operating systems transmit at different power levels and scan at different intervals. An Android device and an iPhone sitting side by side may report noticeably different RSSI values from the same beacon.
- Queue shape changes: If customers form an L-shaped or serpentine queue rather than a straight line, a single entry beacon may lose sight of devices that turn a corner, causing the system to undercount or truncate dwell-time estimates.
Privacy constraints on data use
Under current UK GDPR guidance, tracking individual devices through a queue to measure personal waiting time raises questions about lawful basis, transparency and data minimisation. Many retailers limit beacon-based queue systems to aggregated, anonymised counts rather than device-level journey tracking. If you intend to link a queue detection event to an individual customer record, seek specific legal advice rather than relying on a supplier's privacy statement, which may not reflect your role as data controller.
Integrating Queue Data with Staffing Systems
Queue data has operational value only when it reaches the people who can act on it, in a format they can use, quickly enough to matter. The integration path depends on what the staffing system can accept and how the retail operation is structured.
The simplest integration is a real-time dashboard displayed on a tablet or screen visible to floor managers. The dashboard shows current estimated queue length and average wait for each monitored till or service point, updated at intervals dictated by the beacon scanning cycle. This requires no direct system-to-system integration but relies on staff noticing and responding, which works in smaller formats but scales poorly across large stores.
A more robust approach pushes alerts or data points into an existing workforce management or task-management platform via an API or webhook. When the estimated queue at a till exceeds a defined threshold for a defined period, the system generates a task to open another till or call for backup. The logic for these thresholds should be agreed with store operations staff before configuration, because a threshold that triggers too often will be ignored and one that triggers too late will not prevent the problem it was meant to solve.
Practical integration considerations
- Latency: Beacon scanning intervals, backend processing and API delivery each add delay. If the total latency exceeds sixty to ninety seconds, the queue may have already cleared or escalated by the time the alert arrives. Ask the supplier for measured end-to-end latency in a comparable environment, not a theoretical figure.
- Data format: Confirm whether the queue system outputs a simple count, a dwell-time distribution, a trend indicator or a composite score. The staffing system may only accept one of these, and mapping between them introduces interpretation that should be documented.
- Fallback behaviour: Define what happens when beacons go offline, a gateway loses network connectivity or the backend stops receiving data. The staffing system should display an explicit "data unavailable" state rather than defaulting to zero, which could mask a growing queue.
- Historical reporting: Queue trend data over weeks and months is valuable for roster planning, but this belongs to analytics workflows rather than real-time staffing triggers. Ensure the integration separates alert streams from reporting data so that one does not degrade the other.
Before committing to an integration build, agree with the operations team what action each alert is meant to trigger, how long that action should take, and how you will measure whether the alert actually improved the outcome. A queue detection system that generates data but does not change staff deployment decisions is a monitoring exercise, not an operations tool.
