Designing token series for a multi-doctor OPD

Once an OPD has more than one consultant, the token system stops being a ticket dispenser and becomes a design decision.

Get the structure right and patients understand their position instantly. Get it wrong and the display creates more questions than the register did.

Separate series per doctor, not one queue

The most important choice, and the one most often got wrong for the sake of neatness.

A patient is not waiting for a doctor; they are waiting for their doctor. One shared queue means a patient sees a number moving that has nothing to do with them, and consultants work at genuinely different speeds — so a fast consultant's patients get held behind a slower list they were never part of.

Separate series with clear prefixes — D1 for one doctor, K1 for another — mean each patient watches only the queue that applies to them. It also makes consultations per hour per doctor measurable, which a shared queue cannot.

The prefix should mean something to patients

Prefixes derived from the doctor's name are easier for patients than a system code. Someone told they are K-14 for Dr Kumar can find their queue on a display without instruction.

Sequential codes with no relationship to anything work for the software and not for the person holding the slip.

Walk-ins and appointments in one sequence

Most Indian OPDs run both. The question is how they interleave.

Two common approaches: appointments hold reserved positions in the same series, or walk-ins and appointments run as separate series against the same doctor.

The first is simpler for patients. The second is easier when appointment volume is unpredictable. Either works — what fails is having no rule, because the desk then decides case by case and patients notice.

Rules that have to exist before go-live

What happens to a missed token

A patient who steps out and misses their call needs a defined outcome: recalled after a set number of tokens, moved to the end, or requiring re-registration. Without a rule, it is negotiated at the desk each time, which is exactly the interaction the system was meant to remove.

Priority cases

Elderly patients, emergencies, staff. Priority is legitimate and should be a recorded action rather than an informal insertion — partly for fairness, and partly because unexplained queue-jumping is what makes waiting patients angry.

Follow-ups and report collection

These often need only a short interaction. Putting them in the main consultation queue makes everyone wait longer. A separate short series is usually worth it.

Doctor delays

The most common real-world event. If a consultant is late, the queue has to hold rather than advance, and patients should be able to see that it is holding. A display that keeps calling numbers into an empty room destroys trust in the whole system.

What the display should show

• Current token per doctor, large enough to read from the far end of the room
• The doctor's name alongside, not just the prefix
• Consulting status, so a delay is visible rather than inferred
• Optionally the next one or two tokens, which helps people prepare

What it should not show is estimated waiting time unless you are confident in it. A wrong estimate is worse than none, because patients plan around it.

Start with the doctors

Before configuring anything, sit with the consultants. Session times, expected patients per session, follow-up handling and how they want interruptions managed differ per doctor and are not negotiable by software.

Systems configured without that conversation get bypassed by the people they were meant to help.

If you want to see per-doctor series and displays working, see Digital Token or book a demo.