A camera can show that six people are standing near a checkout. Measuring how long each person has waited also requires a visible entry condition, service condition, and continuous track between them. That distinction determines the camera view, tracking logic, validation method, and edge hardware required for a useful retail queue system.
Start with the store decision: open another lane, redirect staff, alert a supervisor, or study a recurring bottleneck. Once that action is clear, the analytics can be designed around evidence the scene can provide.
A Queue Count Is Not a Wait-Time Estimate
Queue count is a state measurement. It asks how many tracked people currently meet the rule for being in a queue. Wait time is a duration measurement. It asks how long a person, or a representative person in the group, remains between a defined queue entry and a service event.
| Metric | Required Observation | What It Can Support | Main Risk |
|---|
| People in a queue zone | Person detection inside a defined area | Congestion alert | Passersby may be counted as customers |
| Queue length | Detection plus spatial ordering or lane logic | Lane comparison and staffing thresholds | Loose or curved queues break simple geometry |
| Observed wait time | Persistent tracking from entry to service | Distribution of completed waits | Track loss creates incomplete journeys |
| Estimated current wait | Queue state plus a calibrated service model | Operational guidance before service completes | The estimate can drift when service rate changes |
Label zone occupancy as queue count. Report wait time when the system can observe both a start condition and an end condition; otherwise, use a metric such as current queue count or time spent in the queue area.
Define the Queue Zone, Service Point, and Store Action
A usable specification needs three scene definitions. First, the queue zone identifies where a person is considered a possible member of the line. Second, the service point marks a checkout, pickup counter, kiosk, or staffed desk. Third, an exit rule describes when a wait is complete, abandoned, or unobservable.
These rules must reflect how the store operates. A coffee counter may have one order line and a separate pickup crowd. A supermarket may have several lanes with shoppers switching between them. A service desk may use ticket numbers, making physical order less meaningful. The camera view should separate these states instead of forcing every person near the counter into one queue.
Write the action before the threshold
Turn “Alert when the queue is long” into a testable requirement by stating who receives the alert, what they can do, how soon the action matters, and when repeated alerts should be suppressed. The threshold can then be tuned against the cost of missed congestion and the cost of unnecessary interruptions.
Choose Detection, Tracking, and Timing Logic
Person detection supplies observations. Tracking connects those observations across frames. Zone logic decides whether a track belongs to the queue, while timing logic assigns entry, service, exit, and abandonment states. Validate each layer separately before calculating the final wait-time result.
- Detection: Can the camera see enough of each person during peak density?
- Tracking: Are identities maintained through occlusion, lane switching, and brief exits from view?
- Queue membership: Can the logic distinguish waiting customers from staff, pickup customers, and passersby?
- Service state: Is a service event visible, or must another system provide it?
- Timing: Are device clocks stable enough to compare events across cameras or systems?
When one camera covers only part of the journey, use a second view, define a handoff rule, or select a metric that the available view can observe reliably.
Choose a Wait-Time Estimation Method
There are two practical families of wait-time output. The first is observed wait time for completed journeys. It is calculated after a track reaches the service condition and supports historical distributions and validation. Guidance for a newly arriving customer requires the second family: an active-queue estimate.
The second is an estimate for the active queue. It can use recent completed waits, queue position, or a service-rate model. It should be presented as an estimate with a confidence or freshness indicator. A sudden staff change, complicated transaction, lane closure, or group order can make recent history a poor guide.
A well-designed system keeps raw observations, derived states, and operational estimates separate. That makes it possible to revise the estimation method without rewriting the evidence.
If you have a floor plan, sample video, service-point definition, and intended store action, ask CamThink to review the measurement path before selecting hardware.
Choose the Camera or Edge Box Path
CamThink NE503 is the primary starting point for a new, fixed retail queue deployment. Its 20 TOPS Hailo-15H platform, continuous PoE operation, containerized applications, Event Bus output, and external REST or WebSocket access provide room for persistent tracking, queue-state logic, and wait-time processing. An application team can adapt queue zones, timing rules, and alert thresholds to each store during deployment.
NE301 PoE suits a controlled single queue when the target is lightweight person detection, a queue-zone count, a threshold event, or a basic timing pilot. It supports continuous capture with stable wired power and networking, while its STM32N6 platform runs compact models locally. NE503 provides the stronger path for dense scenes or richer tracking.
The battery-oriented NE301 variants fit scheduled or triggered queue snapshots. Use a continuous camera path when the goal is to measure each journey from queue entry to service.
An edge AI box fits projects that reuse existing IP cameras, process several views, or coordinate analytics centrally at the site. CamThink NG4500 uses NVIDIA Jetson Orin Nano or NX modules and supports JetPack, TensorRT, and DeepStream workflows. Benchmark stream capacity with the selected module, model, resolution, frame rate, decoder load, and pipeline design.
| Deployment Condition | Likely Path | Proof Needed Before Rollout |
|---|
| A new fixed queue with continuous tracking, wait-time logic, or richer local rules | NE503 primary path | View coverage, tracking stability, and event contract |
| One controlled queue with a compact model and basic count or timing logic | NE301 PoE lightweight PoC | Continuous runtime, tracking stability, and event behavior |
| Several existing IP camera views at one store | NG4500 edge box path | RTSP compatibility and measured pipeline load |
| Entry and service states split across views | Multi-camera design | Handoff logic, clock alignment, failure behavior |
| Service completion exists only in POS | Video plus business-system integration | Timestamp mapping and transaction correlation |
Turn Thresholds into Store Actions
A useful threshold includes persistence and recovery. For example, a store may alert only when a queue condition remains above its threshold for a defined interval, then clear the alert after the condition stays below a lower recovery threshold. This reduces rapid on-and-off notifications around the threshold.
Record the reason for each event, including zone, observed count, threshold version, timestamp, and device identity. If an alert leads to a staffing action, that action can be logged separately. This preserves a traceable distinction between what the camera observed and what the store decided to do.
Validate Against Human Observation
Validation should cover quiet periods, normal traffic, peak density, lane changes, groups, children, staff movement, carts, reflective surfaces, and partial occlusion. Use a short clip during development, then test across the operating conditions of a complete store day.
- Define the annotation rules before reviewing video.
- Sample different times and operating conditions.
- Compare queue membership, track continuity, and service completion separately.
- Review false alerts with store staff, because geometry may not match operating practice.
- Retest after moving fixtures, changing lane layout, or updating a model.
Document a store-specific operating envelope that states what the system measures, where it is reliable, and which conditions call for manual review or a different sensor layout.
