A fever clinic token system has one job before it has any other
A fever clinic token system is not there to make the queue tidy. It is there to separate people before they sit down — suspected dengue, suspected influenza, and a person who came for a dressings change — because once three of them share a bench for forty minutes, the triage decision at the door has achieved nothing.
Everything else a token does (numbering, display, reporting) is secondary to that first split. The general mechanics of running a numbered queue are covered in our queue management system guide; what changes in a fever clinic is when the split happens and who is allowed to change it.
We run this as part of SWIQ, the booking and queue tooling built from Jodhpur for Indian clinics, and the sequence below is the one we configure first.
Where the split happens: tokens issued at the gate
If the split happens at the counter inside, you have already failed — everyone is in the same room while the decision gets made. Issue the token at the gate or outside the entrance, with two questions at most: what is your complaint, and have you had fever for more than two days.
That gives you two token series from one door: F- for fever or suspected infectious presentation, G- for general — a decision the fever clinic token system lives or dies on. One display carries both, and — this is the part that matters — two physical waiting areas, one of which may be nothing more than a shaded area twenty metres away with a number board.
Front-loaded triage costs the attendant maybe ten seconds a person, and it is the only intervention that reduces exposure rather than managing it after the fact.
Isolation-aware ordering that can change mid-queue
Ordering inside a fever queue is not strict first-come. Priority needs to be an explicit, auditable rule rather than a judgement call at the desk:
- Red flags first — breathlessness, bleeding, altered sensorium, an infant under six months with fever. These jump the queue regardless of token number.
- Time-sensitive second — very high fever, elderly patients, patients on chemotherapy.
- Everyone else in arrival order within their series.
The rule that keeps this defensible: a re-order writes an event with a timestamp and a reason, visible to whoever is on duty. And when a patient is upgraded mid-queue, their token keeps its number — the display shows an asterisk, not a new number, because a patient who watched their number change will assume they were pushed back.
What the display shows — and what it must never show
The display in a fever waiting area is crowd control, not just information: a fever clinic token system that only reports position manages nothing. Show the token now being served, the next two, and an estimated wait refreshed as observed consultation times change.
Do not show a bare position count. "You are 12th" means nothing at 8 am when the clinic is running fast, and everything at 11 am when it is not — an estimate in minutes with a range survives variance, a position number does not.
Also worth deciding deliberately: what the display says when the queue is stalled. A doctor stepping out for 15 minutes produces a silent board, and silence reads as a broken system. Show a short, honest message instead — it converts "this is broken" into "I can wait".
WhatsApp confirmations and the "when should I leave home" message
The most useful message a fever clinic token system sends is not a reminder, it is a departure instruction: your token is F-27, roughly 40 minutes away, leave now. That single message moves patients out of the waiting area and into a car or their home, which is the cheapest form of distancing available.
Sequence it in three sends: a confirmation with the token number at issue, a countdown when they get close, and a "you are next" ping. Message categories, quiet hours and template structure are covered in our WhatsApp queue management for India write-up; the fever-clinic addition is one question in the confirmation — "reply YES if anyone at home currently has fever" — so triage gets one more data point before arrival.
Surge handling: batch tokens, triage nurse, cut-off tokens
In dengue season we have seen a morning list double against the same consulting rooms, and no reminder policy fixes that. Three practices hold:
- Batch issuance. Open the next 30 tokens only when the current batch is being worked through. An unbounded token list tells patients nothing useful and tells the clinic everything wrong.
- A triage nurse at intake, not at the desk. Vitals taken at token issue are the reason the ordering rule can be applied at all; without them, priority becomes whoever looks worst in the chair.
- A published cut-off. "Last fever token today: 1:30 pm", stated on the booking page and at the gate. A cut-off that exists only in the receptionist's head becomes an argument at 4 pm.
None of these need new software. They need the token to carry a series, a triage result and a time — which is exactly what an issued token is for.
Where SWIQ fits
SWIQ is the queue tooling behind the fever clinic token system flow above — digital tokens with two series from one door, a live display, WhatsApp confirmations and countdown messages, a waitlist for released slots, an online booking page for appointment-only sessions, and basic analytics on wait times and walk-aways. It is built from Jodhpur for Indian clinics, with plans from ₹777 per month, the first 300 bookings free, setup in about 2 minutes with no card required, and a 14-day free trial. Details are at swiq.services and on the landing page; questions go to WhatsApp +91 79002 60076.
Top comments (0)