A practical guide to separating queue count from waiting time, choosing the right measurement method, and deciding when an AI camera or edge AI box fits the store.
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.
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.
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.
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.
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.
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.
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.
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 |
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.
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.
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.
