Recall, waitlist and hold: three different queues everyone calls one thing

In short

A patient recall list holds people due to be seen again by a date a clinician set. A waitlist holds people who want an appointment sooner than the one available. A hold is a slot parked for someone who has not confirmed. Each fires on a different event and exits on a different condition, so one message template cannot serve all three.

BuildspaceLabs28 July 20264 min read5 sections

Key takeaways

Recall is time-driven, waitlist is capacity-driven, hold is patient-driven. That is the whole distinction.
Recall needs a due date and a tolerance window; a waitlist entry needs availability windows and a response deadline.
A recall closes on attendance, never on booking, or a patient who books and misses drops off the list built to catch them.
A hold with no expiry is a slot permanently removed from the schedule by someone who wandered off mid-form.

A recall list holds patients due to be seen again by a date somebody clinical decided. A waitlist holds patients who want an appointment sooner than the one available. A hold is a slot parked against a patient who has not confirmed. 3 queues, 3 triggers, and the only thing they share is one receptionist working all of them.

Merging them is not a naming problem. A recall message says you are due; a waitlist message says a slot is free now. Send the first when you meant the second and the patient replies on Monday, by which point the slot went elsewhere. Send the second when you meant the first and someone due in 6 weeks is asked to attend at 14:20 tomorrow.

What fires each queue and what takes an entry off it

Queue	Fires on	Ordered by	Exits when
Recall	A clinical due date arriving, set at the last visit	Due date, then overdue days	The visit is attended, or a clinician cancels the recall
Waitlist	A cancellation or release freeing capacity	A stated priority rule, not arrival order	The patient accepts, declines, or their target date passes
Hold	A booking started but not confirmed	Expiry time, soonest first	Confirmation, or the release timer runs out

The three queues, by the event that creates an entry and the event that ends it

The ordering row is where designs go wrong. Recall volume next month is knowable today; waitlist volume is not, because its arrival process is other people's cancellations. Filling a freed slot is closer to dispatch than to scheduling — perishable capacity, a constrained candidate set, a response deadline — the shape in AI in logistics operations.

One template cannot say all three things

Recall outreach carries a reason and a window. What is due, roughly when, and how to book. It can go 4 to 6 weeks ahead and repeat on a slow cadence without irritating anyone.
Waitlist outreach carries a slot and an expiry. This date, this clinician, reply by a deadline — without which you have offered 1 slot to several people.
Hold outreach carries a countdown and nothing else. If it needs a second message, the hold was too long.
Only recall has the lead time to carry a pre-visit intake link, the practical argument in kiosk intake versus a pre-visit link. A fill offered at 90 minutes' notice completes intake in the waiting room.

A recall says you are due. A waitlist offer says this slot expires. Send either in the other's voice and patients ignore both.

The recalled patient with no slot is now two records

This is the interaction most builds miss. A patient is recalled, calls to book, and the next suitable appointment falls outside the clinical window. They take the distant slot and join the waitlist. If the recall closes at the moment of booking, the reason a clinician wanted them seen sooner is erased.

The fields that stop one queue behaving like another

Recall	Waitlist	Hold
Due date and tolerance window	Earliest and latest acceptable dates	Slot identifier
Reason, and the visit type it needs	Visit type, clinician and site limits	Expiry timestamp
Who set it, and when	Days and hours the patient can attend	Channel the booking started in
Contact attempts, with outcome	Offers made, accepted or declined	Visible to other channels or not
State: due, overdue, booked, attended	Response deadline per offer	Release action on expiry

Minimum record shape, side by side

2 rows get left out. Contact attempts with outcomes make a recall measurable: 3 unanswered calls is a different situation from never having tried, and only 1 of them justifies a letter. Offers made turns a waitlist into a record of who was asked twice and said no.

Recalls also age in a way waitlists do not. An entry created 6 months ago carries a coverage position captured 6 months ago, so re-verify before any message implies a visit can proceed — and expect the identity-match failures in when eligibility cannot find a covered patient. Where the recall is for imaging, the study still has to reach the modality, the handoff in feeding the scanner a worklist.

Which of the three an unattended system should work

Hold expiry. Arithmetic, no judgement, and a 10-minute timer that never fires is capacity nobody can book. Automate first.
Recall outreach. Predictable volume, weeks of lead time, wrong only if the due date behind it is wrong.
Waitlist offers. Automate the offer and the deadline, but agree the priority rule with clinicians first: it encodes who is seen sooner.
None of the 3 may set the visit type. That comes from the recall reason or the original booking; a queue that reclassifies a patient has made a clinical decision.

Cancellations arrive after hours, when offers are worth most and least likely to be made — the question weighed in an answering service versus a voice agent for the calls after six. Reminder cadence has its own evidence, elsewhere in the front desk and patient access topic. Building 3 queues as 3 objects is scope we take under AI agents and automation for clinics.

Frequently asked questions

Short answers to the follow-ups this page tends to raise.

Is a recall list the same as a waitlist?

No. A recall list is driven by clinical time — a patient is due for review by a date set at the last visit — while a waitlist is driven by capacity, holding patients who want an earlier appointment than the one available. A patient can be on both at once, and those entries should be linked rather than merged.

How long should an appointment hold last before it is released?

Long enough to finish the booking and no longer: a few minutes for an online session, the length of the call for an assisted booking. What matters is that every hold carries an explicit expiry and an automatic release, because a hold with no timer removes a slot from the schedule indefinitely.

Should a waitlist offer go to one patient at a time or to several?

Decide it explicitly and publish the rule, because both are defensible and only silence is not. Sequential offers with a short deadline are fairer and slower; simultaneous offers to a small group fill the slot faster and mean some patients hear it has gone. What fails is offering to several without saying so.

patient access
scheduling
recall
clinic operations

// shipped work

The work behind this page

Builds from our portfolio that this page draws on.

Patient Front Desk

AI receptionist for clinics — auto intake, smart scheduling, and insurance verification before the patient walks in.

Healthcare AI

ScanQueue

An AI radiology worklist that flags suspected critical findings on incoming CT, MR and X-ray studies and orders every read by acuity and SLA — so the sickest patient is read first, not FIFO.