How to Build a Queue and Waitlist Management System in 2026

Walk into any busy clinic, DMV office, or restaurant on a Saturday night. The experience is almost always the same: a paper sign-in sheet, a bored receptionist calling names, and a room full of people who have no idea how long they will actually wait. It is a terrible experience, and it is also entirely solvable with software.

A queue management system replaces guesswork with structure. Customers join virtually, see their position in real time, get notified when their turn approaches, and can wait from their car or a coffee shop instead of a crowded lobby. Staff see a live dashboard showing who is next, average wait times, and which service categories are backed up. Managers get analytics on peak hours, staff efficiency, and bottlenecks.

But building this well is harder than it looks. Real-time state synchronization across dozens or hundreds of concurrent users. Priority queues that let VIP customers or urgent cases jump ahead without breaking fairness rules. Wait time predictions that account for service variability, staff availability, and time of day. SMS and push notification pipelines that fire reliably at exactly the right moment.

The market is growing fast. Businesses that adopted virtual queuing during 2020 and 2021 never went back. Now customers expect it. If you are building for healthcare, government, restaurants, salons, auto repair, or any walk-in service, this guide covers the architecture, data models, and implementation details you need to ship a production-ready queue management system.

Your data model is the foundation. Get this wrong and every feature you build on top will feel brittle. The core entities are queues, queue entries, service categories, and locations.

Queues and Service Categories

A queue belongs to a location and a service category. A dental office might have separate queues for cleanings, consultations, and emergency walk-ins. A restaurant might have queues for parties of two, parties of four, and large groups. Each queue has its own settings: maximum capacity, operating hours, priority rules, and estimated service duration.

Each queue entry needs a unique ID, a customer reference (or a guest record with name and phone for walk-ins), the queue it belongs to, a priority level, a status (waiting, called, serving, completed, no-show, cancelled), a join timestamp, an estimated wait time at join, and metadata fields for notes or special requests.

Priority Queues

Not all queue entries are equal. A hospital triage system needs critical patients served before routine check-ups regardless of arrival time. Implement priority as a numeric field on each entry. Sort by priority descending, then by join timestamp ascending. This gives you a stable ordering where higher-priority entries go first, with ties broken by arrival order.

Redis sorted sets are ideal here. Use a composite score encoding both priority and timestamp: score = (MAX_PRIORITY - priority) * 1e13 + timestamp_ms. This single numeric score gives you correct ordering with a single ZRANGEBYSCORE call.

Customer Metadata

Store customer information flexibly. For registered users, link to a profile with visit history and contact info. For walk-in guests, collect the minimum: name, phone number, party size, and service type. Let staff attach notes like "needs wheelchair access" or "returning for follow-up." Support arbitrary metadata from the start so these details are easy to add later.

Estimated Wait Times

Every queue entry should store two values: the estimated wait time calculated at join time, and the actual wait time recorded when service begins. Storing both lets you measure prediction accuracy and improve your algorithms over time.

A queue system without real-time updates is just a digital sign-in sheet. The entire value proposition depends on customers seeing their position update live and staff seeing changes instantly.

WebSocket for Bidirectional Communication

WebSocket is the right choice because updates flow in both directions. Customers receive position updates. Staff send actions (call next, mark complete, skip). Use Socket.IO on top of raw WebSocket to get automatic reconnection, room-based broadcasting, and fallback to long-polling for flaky connections. Each queue gets its own room. When a customer joins, subscribe them to that room. When staff update the queue, broadcast the change to all room members instantly.

If you have explored real-time feature architecture before, you know the tradeoffs. WebSocket gives you the lowest latency but requires persistent server connections. For a single location with 50 to 100 concurrent users, this is trivial. For a multi-location SaaS, plan your connection management and horizontal scaling carefully.

Redis Sorted Sets for Queue State

Store active queue state in Redis, not just your primary database. Redis sorted sets give you O(log N) insertion and removal, atomic operations that prevent race conditions when two staff members try to call the next person simultaneously, and sub-millisecond reads. PostgreSQL is the source of truth for historical data. Redis is the source of truth for current queue state.

When a customer joins, add them to the sorted set with the composite priority/timestamp score. When staff call the next person, use ZPOPMIN to atomically remove and return the highest-priority, longest-waiting entry. Write the state change to PostgreSQL asynchronously for durability.

Server-Sent Events as an Alternative

If your system is primarily one-directional (server pushes updates to customers, staff actions go through REST endpoints), Server-Sent Events (SSE) is simpler than WebSocket. SSE uses standard HTTP, works through proxies without special configuration, and reconnects automatically. The tradeoff is server-to-client only, so staff actions go through separate API calls. For many queue systems, this is perfectly fine.

The customer experience is what separates a useful queue system from one that collects dust. If joining the queue is awkward or tracking your position requires refreshing, people will not use it.

Virtual Check-In via QR Code and Web

The fastest path into a virtual queue is a QR code posted at the entrance. Scan it, land on a mobile-optimized web page, enter your name and phone number, select your service type, and you are in. No app download required. This is critical for adoption. Every extra step reduces the percentage of walk-ins who actually use the system.

Generate unique QR codes per location using qrcode (npm) that encode the join URL. For businesses allowing remote joining, also provide a direct URL so customers can join from the parking lot or from home.

SMS Notifications When Turn Approaches

This is the killer feature. When a customer is three positions away, send an SMS: "You are almost up. Please head to the front desk." When they are next: "It is your turn. Please check in at counter 3." Without these notifications, customers are glued to their phone refreshing a status page, which is barely better than sitting in a waiting room.

Position Tracking and Estimated Wait Display

Show three things on the status page: current position ("3rd in line"), estimated wait time ("approximately 12 minutes"), and a visual progress indicator. Update all three in real time via WebSocket or SSE. One design detail that matters: show a range instead of an exact number. "10 to 15 minutes" feels honest. "12 minutes" feels like a promise you might break.

Your staff dashboard is where operational efficiency lives or dies. It needs to be fast, obvious, and hard to mess up. Staff at a busy counter do not have time to learn a complex interface.

Call Next

The primary action is a single large button: "Call Next." Pressing it pops the highest-priority, longest-waiting entry, updates their status to "called," triggers an SMS notification, and displays the customer's name and service type. If the customer does not show up within a configurable window (typically 3 to 5 minutes), the entry moves to "no-show" status and the next person is called automatically.

Skip, Hold, and Transfer

Staff need to skip a customer who stepped out temporarily (move them back a few positions), put someone on hold while waiting for a specific resource, and transfer between queues (walked in for a haircut but also wants a color treatment). Each action updates the Redis sorted set and broadcasts changes to all connected clients. The transfer is the most complex: remove from one queue, add to another with appropriate priority, and notify the customer.

Service Time Tracking

Start the timer when status changes to "serving" and stop it at "completed." Store durations per service category. This data feeds wait time predictions and lets managers spot when service times are drifting up. A visual indicator that turns yellow after the expected duration and red after double is surprisingly effective at keeping times consistent.

Multi-Counter and Multi-Staff Support

Model each service point as a separate entity linked to a staff member and a queue. When "Call Next" is pressed at counter 2, the customer is assigned specifically to counter 2, and their notification tells them where to go. Display a board view showing all active counters, who is being served at each, and how long each service has been running.

Accurate wait time predictions are what separate a good queue system from a great one. Customers can tolerate a 30-minute wait if they know it is 30 minutes. They cannot tolerate a "10-minute" wait that turns into 30.

Simple Averages as the Baseline

Start with the simplest model: average service time per category, multiplied by positions ahead, divided by active service points. If haircuts average 25 minutes, there are 4 people ahead, and 2 stylists are working, the estimated wait is (4 * 25) / 2 = 50 minutes. This works surprisingly well for steady-state queues and requires zero ML infrastructure.

Refine the average by weighting recent data more heavily. An exponential moving average with a decay factor of 0.1 to 0.2 adapts to changing conditions within a few hours.

ML-Based Predictions for Higher Accuracy

Once you have a few months of historical data, train a regression model with features like hour of day, day of week, current queue length, active service points, and recent average service time. A gradient-boosted tree (XGBoost or LightGBM) will typically outperform simple averages by 20% to 40% in mean absolute error.

Train offline, export as a lightweight model file, and load it into your backend for inference. Retrain weekly or monthly. If your team prefers Python for ML, build a small FastAPI prediction microservice that your main application calls via REST.

Dynamic Adjustments Based on Current Volume

Static models break down during surges. When the queue grows by more than 30% in 15 minutes, increase estimated wait times by a correction factor. When current service times are running 20% above the daily average, apply that multiplier. Publish updated wait times every 60 seconds to all connected clients so customers see their estimate adjust in real time rather than discovering the original estimate was wrong.

Notifications are the bridge between your system and the customer's real-world experience. They need to be timely, reliable, and informative without being annoying.

SMS via Twilio

SMS is the most reliable channel because it works on every phone without an app install. Use Twilio's Programmable Messaging API. Send three message types: a confirmation at join ("You are #7 in line. Estimated wait: 20 min."), an approaching alert at 2 to 3 positions away ("Almost your turn! Please head to the lobby."), and a called notification ("It is your turn! Please go to counter 2.").

Budget for SMS costs. Twilio charges roughly $0.0079 per outbound SMS in the US. At 3 messages per visit and 200 customers per day, that is about $4.74 daily per location. Use Twilio's messaging service with sender pools for throughput, and implement delivery status callbacks to know if a message actually reached the customer.

Push Notifications

For apps or PWAs, push notifications are a free alternative to SMS. Use Firebase Cloud Messaging (FCM) for Android and APNs for iOS. For PWAs, the Web Push API works across Chrome, Firefox, and Edge. The catch: push requires your app to be installed or web push to be opted in. Default to SMS for walk-in customers.

Display Board Integration

Build a dedicated web view connecting to the same WebSocket/SSE channel. Display called numbers, currently serving at each counter, and estimated wait times. For healthcare, use ticket numbers instead of patient names. A Raspberry Pi running Chromium in kiosk mode connected to a TV is a low-cost, reliable display board solution.

Queue data is a goldmine of operational intelligence. Every interaction generates timestamps, durations, and outcomes that reveal exactly where the business is efficient and where it is bleeding time.

Average Wait Times and Service Times

Track these per service category, per staff member, per time of day, and per day of week. If wait times for haircuts creep up every Tuesday afternoon, you need an additional stylist for that shift. Aggregate every 5 to 15 minutes so managers can act on current data, not yesterday's report.

Peak Hours and Demand Patterns

Build a heatmap showing queue volume by hour and day of week. Overlay actual staffing levels on top of demand to highlight mismatches. Export to CSV or integrate with scheduling tools so managers can adjust rosters directly from queue analytics.

Staff Efficiency Metrics

Track customers served per shift, average service time per category, no-show rate, and idle time between services. Present these as comparative metrics, not competitive leaderboards. If one barber finishes cuts in 20 minutes while others take 30, the question is whether they have found a shareable workflow improvement.

Customer Satisfaction Correlation

Send a simple thumbs up/down SMS after visits and correlate scores with wait times. You might find satisfaction drops sharply after 15 minutes but stays flat between 5 and 15. That tells you your target wait time ceiling and helps set operational SLAs.

A single-location queue system is a useful tool. A multi-location queue platform is a SaaS business. If you are building for scale, multi-location architecture needs to be baked in from the start.

Multi-Tenant Data Architecture

Use a tenant-based model where each business has one or more locations, each with its own queues, staff, and settings. Isolate data using tenant and location IDs on every table and every Redis key. A shared database with row-level isolation works well up to thousands of tenants. Only build per-tenant schemas or separate databases if you get enterprise clients with strict data residency requirements.

Cross-Location Queue Visibility

A dental chain with three offices in the same city can route patients to the location with the shortest current wait. Build an API endpoint that aggregates queue state across locations, sorted by estimated wait time, and display it on a location picker page.

Integration with Appointment Scheduling

Walk-in queues and appointment schedules are two entry points into the same service pipeline. When a scheduled appointment arrives, they check in via the queue system and get priority over walk-ins. When the queue is slow, offer walk-ins the option to book a future appointment instead. This is exactly the kind of integration we covered in our guide to building scheduling apps.

Merge both data streams into a unified staff timeline showing scheduled appointments and walk-in entries in one view. If a scheduled customer is running late, their slot can go to a walk-in temporarily. This dynamic rebalancing maximizes throughput and minimizes empty chairs.

Hardware and Kiosk Integration

For locations where not everyone has a smartphone (government offices, hospitals), mount a tablet at the entrance running your web app in kiosk mode. Select a service, enter a phone number, print a ticket with a QR code linking to the status page. Use escpos (Node.js) for thermal receipt printer support via USB or Bluetooth.

After working with teams building queue systems across healthcare, hospitality, and government, here is the stack I recommend for a production-ready system in 2026.

Backend: Node.js with TypeScript, running on a framework like Fastify or Express. Fastify is my preference for new projects because of its schema validation and superior throughput. Use Socket.IO for WebSocket communication with automatic fallback.

Database: PostgreSQL for persistent data (customers, historical queue entries, analytics). Redis for active queue state (sorted sets), session management, and pub/sub for broadcasting updates across multiple server instances.

Frontend: Next.js for the staff dashboard and customer-facing status pages. React Native or a PWA for the mobile experience. For the display board, a simple Next.js page in full-screen mode.

Notifications: Twilio for SMS. Firebase Cloud Messaging for push notifications. SendGrid or Resend for email confirmations and receipts.

Infrastructure: Deploy on Vercel for the frontend, Railway or Render for the backend, and managed Redis (Upstash or Redis Cloud) for queue state. This keeps operational overhead low while you find product-market fit.

ML Predictions: Start with simple averages. When you have 3+ months of data, train an XGBoost model in Python, deploy it as a lightweight FastAPI service, and call it from your main backend.

A lean MVP covering virtual check-in, real-time position tracking, SMS notifications, and a staff dashboard can be built in 10 to 14 weeks with a small team. Adding advanced analytics, ML-based predictions, and multi-location support typically adds another 6 to 8 weeks. The key is shipping the core experience first and validating that customers actually use virtual queuing before investing in the advanced features.

If you are building a queue management platform for a specific vertical like healthcare or food service, or you want to integrate queuing into an existing product, the architecture decisions matter early. Refactoring from a single-location model to a multi-tenant platform is expensive. Planning for it from day one is not. Similar patterns apply when building salon and service booking platforms where walk-in queues and appointments need to coexist.

We have helped teams ship queue and waitlist systems from scratch and add queuing features to existing platforms. If you want to talk through your specific use case, book a free strategy call and we will map out the architecture together.