Wooble
Back to Hazel's profile
Verified on Wooble

Clinicque - Live Queue Manager for Neighbourhood Clinics

Reduced patient wait uncertainty from 2–3 hours of guessing to a live token count & receptionist adds a patient in under 10 seconds.

Hazel SequeiraClinicque - Live Queue Manager for Neighbourhood Clinics

<10s

<10s receptionist adds patient + assign

0 refreshes

patient view updates live via Firebase

3 roles

receptionist · doctor · patient

Overview

76% of India's 1.5 million clinics run on paper token slips and verbal announcements. Patients wait 2–3 hours with no idea where they are in the queue. Receptionists manage the entire flow from memory where there is no dashboard, no history, no way to communicate delays. The moment a patient steps outside or loses track of the number being called, they miss their turn. The problem isn't that clinics lack technology. It's that the only tool that exists , the paper slip breaks the moment the patient walks away from the front desk. Process I started from the brief's three questions and worked backwards. Instead of designing screens first, I mapped the state machine first because in a queue system, every UI decision follows from what states a token can be in and what transitions are legal. That gave me a clear contract before I wrote a single component. I chose Firebase Realtime Database over a polling approach deliberately: polling introduces a lag window where one screen is ahead of another, which breaks the clinic owner's core trust in the system. The architecture had to be push-first from day one, not retrofitted later. Results The receptionist flow was timed at roughly 12 seconds on a real device with name entry, token auto-assigned, patient added to the live queue. A first-time user picked up the receptionist view without any walkthrough, which was the more useful signal: the interface communicates its own affordances. The patient screen and display board updated the moment "call next" was clicked, with no action needed on the patient's end. Reflection Start with Firebase security rules, not add them at the end The current DB is open for demo purposes. A production deployment needs per-role write rules — receptionists can write to the queue, patients are read-only, display is read-only. Designing those rules early would have shaped the data model, not forced a retrofit. Test the wait estimate algorithm with a longer session The rolling average works well once 4–5 tokens have completed. In the first two tokens of a session it leans heavily on the configured default. I'd add a confidence indicator — something that tells the patient "estimat

Links & files

Artifacts

5

Gallery

4