Queue Management System
Tickets, counters and a chatbot instead of a crowd at the door
- Role
- Full Stack Engineer
- Timeline
- 2025
- Stack
- ReactNode.jsMongoDBWebSocketsDialogflow
A queue is a realtime system wearing a waiting room. Give it tickets, state and displays, and the crowd at the counter becomes people arriving right on time.
Problem
Service counters ran on physical presence: arrive, guess the wait, stand in it. Staff had no view of demand across counters, customers had no way to plan around the wait, and peak hours produced exactly the crowding the service existed to process.
Solution
Ticket-based flow across every channel. Customers take a ticket on-site from a kiosk view or remotely — including by asking a Dialogflow chatbot, which issues tickets and answers "how long is the wait" in natural language. Counter displays and staff consoles update live over WebSockets; supervisors watch queue depth per service and rebalance counters before waits blow up rather than after.
Architecture
Channels
- Kiosk view
- Remote ticketing (web)
- Dialogflow assistant
Realtime core
- Node.js API
- WebSocket broadcast
- Queue engine
Operations
- Counter console
- Display screens
- Supervisor dashboard
Data
- MongoDB
- Ticket history
- Service metrics
Every ticket event — issued, called, serving, done, no-show — is broadcast to all connected views from one queue engine, so the display board, the staff console and the chatbot never disagree about whose turn it is.
Challenges
Displays that must never lie
A wrong number on the big screen destroys trust in the whole system. Displays are dumb subscribers: they render only server-pushed state, reconnect aggressively, and show a visible stale indicator rather than ever guessing.
Estimating waits honestly
Naive averages promised times the queue couldn't keep. Estimates based on recent per-service handling times, shown as ranges rather than exact minutes, kept expectations aligned with reality — especially in the chatbot, where a number reads like a promise.
A chatbot that knows when to stop
Conversational ticketing works until the request is unusual. The Dialogflow flows were scoped tightly — take ticket, check wait, cancel — with a clean handoff to a human channel for everything else, which kept the assistant useful instead of frustrating.
Technologies
- Realtime — Node.js with WebSocket broadcast to displays, consoles and dashboards.
- Conversational — Dialogflow intents integrated with the ticketing API for issue, status and cancel.
- Frontend — React for kiosk, counter and supervisor interfaces from a shared component set.
- Data — MongoDB for tickets and per-service metrics that feed wait estimates.
Screens
Lessons Learned
- Broadcast one truth; let every screen be a projection of it.
- Under-promise in the estimate, over-deliver at the counter.
- The best chatbots have small, honest scopes and an obvious exit.