Built to order

Clinic Queue Token Display System with Dashboard

This project brings order to the clinic waiting room: patients take a printed token from the dispenser, each counter calls the next token onto the LED display boards, and a dashboard tracks waiting counts, average wait time and per-counter throughput. It is a real queuing system — token lifecycle, multi-counter arbitration and service-time analytics — built at a scale a student can demonstrate end to end. Suitable for B.E./B.Tech final-year projects in Electronics & Telecommunication, Computer Science and IoT & Embedded Systems.

Electronics / E&TC ESP32Arduino IDE firmwareHTML/JS dashboardLED display boardsToken dispenserMulti-counter arbitrationFIFO queue logicWait-time analyticsHybrid
Clinic Queue Token Display System with Dashboard — project thumbnail preview
More project photos (3)

The problem

Clinic waiting rooms run on shouting: the doctor calls names across a crowded hall, patients hover near the door, and nobody knows how long the wait is. Token systems fix this, but commercial ones are sealed boxes. The engineering gap is a student-built queuing system that shows the whole lifecycle — token issue, queue state, counter calls, no-shows, completion — with the analytics that make it a project and not just a display: average wait, throughput per counter, peak load. This project builds that on an ESP32: a push-button dispenser issues printed tokens, LED display boards show the current token per counter, and the dashboard tracks the queue with live analytics.

SYSTEM FLOW

6 components 5 connections

Live flow
Drag to explore
100%
userPatient

Presses the dispenser button and takes a printed token ticket.

Follow the working sequence

How it works

  1. The patient presses the dispenser button; the controller issues the next token number and a printed ticket comes out.
  2. The token enters the waiting pool; the dashboard waiting count increments and the estimated wait updates.
  3. Counter staff press the counter's call button; the firmware assigns the oldest waiting token to that counter.
  4. The LED boards update to the new token, the chime sounds, and the call is timestamped for wait-time math.
  5. If the patient does not respond, the counter recalls once; a second no-show skips the token and logs it.
  6. Completed tokens close out; the dashboard accumulates served counts, average wait and per-counter throughput.

Tech stack:

  • ESP32 development board (Wi-Fi dashboard sync)
  • LED 7-segment/matrix display boards (per counter + main)
  • Push-button token dispenser (printed tickets)
  • Counter call buttons + buzzer/chime
  • Plywood kiosk demo rig
  • Single-page queue dashboard (HTML/JS)
  • Arduino IDE (C/C++ firmware)
Parameter Value
Controller ESP32, drives displays and dashboard sync
Displays LED token boards per counter + main display; current token per counter
Dispenser Push-button issue with printed sequential tickets
Counters Design target 3 counters, independently callable
Queue logic FIFO with recall-once then skip for no-shows
Analytics Waiting count, average wait, per-hour served, per-counter throughput
Alerts Chime + flashing token on each new call
Dashboard Live queue state, analytics, end-of-day summary

Project features

  • [Token dispenser] A push-button issues the next sequential token with a printed ticket — the queue entry point patients actually touch.
  • [Multi-counter displays] LED display boards show the currently-served token per counter, all driven from the one controller.
  • [Call/next/recall logic] Counter staff advance, recall or skip tokens; the firmware arbitrates the queue fairly across counters.
  • [No-show handling] Unanswered tokens are recalled once, then skipped and logged — the queue never stalls on one patient.
  • [Queue analytics dashboard] Waiting count, average wait time, tokens served per hour and per-counter throughput update live.
  • [Audible call alert] A buzzer/chime sounds on each new call with the token number flashing on the boards.
  • [End-of-day summary] Served, skipped and no-show totals with peak-wait timing are formatted for the report.

What is included

  • Working token-system prototype (dispenser, display boards, counter buttons, ESP32)
  • Kiosk demo rig with printed token tickets
  • Complete firmware source code (token lifecycle, multi-counter arbitration, analytics, dashboard sync)
  • Queue analytics dashboard with live state and summaries
  • Circuit and wiring documentation
  • Counter-staff operating procedure (the demo script for the viva)
  • Project report PDF (queuing basics, system design, analytics from the buyer's demo run)
  • PPT presentation for final review
  • Viva Q&A preparation document (queues, FIFO, wait-time math, display driving)

Limitations & prerequisites

  • A demonstration-scale system; a real clinic needs bigger displays, networking across rooms and integration with registration — listed as future scope.
  • Average-wait estimates assume steady service rates; a slow consultation skews the estimate, which the dashboard shows honestly.
  • Printed tickets are simple sequential slips, not a full kiosk printer with patient details.
  • The demo queue is generated by the buyer's test run; no real patient data is involved at any point.
  • Display brightness and size suit a demo room, not a large hall.

Frequently Asked Questions

How do the counters share one queue fairly?

Strict FIFO: each call takes the oldest waiting token regardless of counter, so no counter can cherry-pick and no patient is overtaken.

What happens on a no-show?

The counter recalls the token once; if still unanswered it is skipped and logged, and the queue moves on — one absent patient never stalls the line.

How is average wait computed?

From timestamps: token issue time to call time, averaged over completed tokens in a rolling window. The dashboard shows it live.

Can it handle a real clinic's load?

The logic scales, but the prototype's displays, single controller and demo ticketing suit demonstration scale — real deployment needs are listed as future scope.

Why a chime on every call?

In a noisy waiting room the display alone is missed; the audible call plus flashing token is the standard pattern real systems use.

Is this project suitable for a final-year project?

Yes — for Electronics & Telecommunication, Computer Science and IoT & Embedded programs. It is a complete multi-user queuing system with real state, arbitration and analytics. Suitable for B.E./B.Tech final-year projects in Electronics & Telecommunication, Computer Science and IoT & Embedded Systems.

Components & software requirements
  • ESP32 development board (Wi-Fi dashboard sync)
  • LED 7-segment/matrix display boards (per counter + main)
  • Push-button token dispenser (printed tickets)
  • Counter call buttons + buzzer/chime
  • Plywood kiosk demo rig
  • Single-page queue dashboard (HTML/JS)
  • Arduino IDE (C/C++ firmware)
Delivery information

Built-to-order project. Delivery timeline is shared after order confirmation based on current queue.

Support terms

Complete documentation, setup guide, and viva preparation included. Support for setup and explanation provided.

Download free synopsis (PDF)

Enter your name and WhatsApp number — the synopsis PDF downloads immediately. We may send occasional project updates on WhatsApp; no spam.

Get a quotation