PulseQueue — Live Digital Queue Manager for Neighbourhood Clinics
Replaced paper token slips with a real-time two-screen system — receptionist adds a patient in 3 seconds, and the patient's phone updates instantly via WebSocke
3s
Token assignment time
<50ms
Real-time sync latency
0
Page refreshes needed
Overview
India's neighbourhood clinics run on paper tokens and shouting. Patients wait 2–3 hours with zero visibility. Receptionists manage queues from memory. Hospital management systems cost ₹50K–2L/year — overkill for a 1-doctor clinic. WhatsApp has no queue logic. Google Sheets need manual refresh. The gap: a free, real-time, two-screen system that works on any phone browser — no app install. Process Mapped 3 personas (receptionist, patient, doctor) to define constraints: <10s per action, works on any browser, no app install. Evaluated 4 real-time strategies. Chose Socket.IO for <50ms sync with auto-reconnection. Built receptionist-first: auto-focused input → Enter to submit → 3s token assignment. Then patient view — large type for wall-mounted readability, pulsing orb, sound chime on turn. What didn't work: started with HTTP polling at 2s intervals. Server load spiked with 15+ clients. Switched to event-driven Socket.IO — load dropped to near-zero. Results Token assignment time: 3 seconds (receptionist types name → presses Enter → done) Real-time sync latency: <50ms between receptionist action and patient screen update Page refreshes needed: 0 — Socket.IO pushes every mutation instantly Wait time accuracy: improves throughout the day as real consultation data accumulates (rolling average replaces 5-min default) Edge cases tested: skip/recall ordering, race conditions on concurrent "Call Next", sub-1-minute consultations, browser refresh recovery (localStorage + Socket.IO reconnect), empty queue handling, MongoDB failure graceful degradation. Reflection 1. Real clinic validation: I designed for a receptionist persona but never tested with one. A 30-min observation would've revealed friction I can't simulate — interruptions, multitasking, handwriting-to-typing flow. 2. SMS fallback: Not every patient has a smartphone. Twilio SMS ("Your turn in 5 min") would cover the 20% who don't. 3. Multi-doctor routing: Current system assumes 1 doctor. I'd add room-based queue separation for 2–3 doctor clinics. 4. Offline resilience: Service Worker so patient view degrades gracefully on network drops instead of showing stale data.