Referrals come in by fax, email and portal, and none of them get booked

Pick a month that closed at least 60 days ago and produce 2 numbers: referrals received, and appointments that resulted from them. If nobody can produce the pair without a week of manual work, stop the investigation there — you have found the problem. A practice that cannot join arrivals to bookings has no referral process, only a set of inboxes that people work through in the order they happen to open them. Every subsequent question about leakage is unanswerable until that join exists.

The reason this is so common is structural rather than behavioural. A fax arrives as an image, a secure email arrives as an attachment, a portal referral arrives as a notification, and a hospital system pushes an electronic message into an interface. None of these creates a record that the practice owns, with a state, a timestamp and somebody responsible for moving it along. A document sitting in a folder cannot be overdue, because nothing has said what it was due to do.

Reconcile one closed month, and treat the difficulty as data

1. List every inbound channel by name: fax line or lines, each shared mailbox, each portal, each electronic interface, and the referrals handed over on paper at reception. Most practices find 5 or 6 where they expected 3.
2. Count arrivals per channel for the chosen month. Where a channel has no count available, record it as unknown rather than zero — the unknowns are usually the leaky ones.
3. Pull every new-patient appointment booked in that month and the following 2, and mark which ones can be traced back to a specific referral document.
4. Subtract. The residue splits 3 ways: referrals booked but untraceable, referrals genuinely never booked, and appointments that arrived some other way.
5. For 20 of the never-booked, read the actual document and record why it stopped. This is the only step that produces a ranked cause list rather than a theory, and it takes an afternoon.
6. Record how long the whole exercise took. That number is the business case for the queue you are about to build.

A document has no age; a case does

The failure is easiest to see by contrast. Ask a practice how many patients are waiting for an appointment and it can answer instantly, because an appointment request is an object in a system. Ask how many referrals are sitting unactioned and older than 14 days and the question does not parse — there is no field holding that, and nothing has an age at all. Loss is invisible not because anybody hid it but because nothing was ever counted in the first place.

This is the same shape of problem as a missed call that nobody owns: work exists, arrives continuously, and disappears the moment attention moves elsewhere. The stages, owners and close conditions that fix it are laid out in the missed-call playbook, and the referral version differs mainly in that the patient is not the one who initiated contact — which means silence from them is not consent to close.

5 places a referral stops moving, most common first

• No common intake point. Each channel is worked by whoever owns that inbox, cover during leave is informal, and a fax line nobody has checked since a staff change holds 3 weeks of unbooked patients. The signature is loss clustered by channel and by week.
• No identifier, so no traceability. Duplicates from a referrer who faxed and emailed the same letter get worked twice; a document filed under the wrong patient is gone entirely. The signature is bookings that cannot be tied back to any referral at all.
• Waiting on clinical triage, unowned. The letter needs a clinician to decide urgency or suitability before a slot type can be chosen, and it sits in a physical or virtual pile with no clock. This is usually the single largest bucket, and the fix is a named owner and a target turnaround, not a change to the clinical judgement itself.
• The patient cannot be reached. A wrong number on the referral, a patient who works shifts, 2 unanswered calls and then nothing. Without a defined close condition this becomes an indefinite limbo that reads as inactivity.
• An authorisation dependency stalls silently. The visit needs approval before it can be scheduled, the request goes out, and nothing brings it back. The referral is not lost so much as parked behind a process with its own separate failure modes.

Two of those deserve a note. Contact details on inbound referrals are frequently stale, because the referrer copied them from their own record, which was itself taken at a registration months earlier — the same decay that undermines reminders and coverage checks. And referral packets routinely include a photocopied or photographed insurance card, at exactly the quality that defeats extraction, which is why the reshoot-and-confirm loop in reading an insurance card from a bad phone photo matters here too.

A referral in an inbox is a document. A referral with an identifier, a state and an owner is a case. Only one of the 2 can be overdue, and only one of them can be measured.

The smallest set of states that makes the leak visible

Blocked is the state most systems omit and the one that pays for itself. It forces the question of who is being waited on, which converts an invisible stall into an item with a name attached to it. Authorisation dependencies belong here rather than in the referral workflow proper — the request, its evidence and its follow-up have their own machinery inside revenue cycle, prior authorisation and denials, and duplicating that logic in the referral queue produces 2 sources of truth about the same request.

Chasing without an infinite loop: attempts, channels and a real ending

A chase workflow needs 3 decisions made in advance, all of them clinical and operational rather than technical: how many attempts, across which channels, before a referral may be closed as unreachable; whether the referrer is told, and at which point; and what happens to a clinically urgent referral whose patient cannot be reached, which must never follow the same path as a routine one. Write those down before any automation is built, because software will otherwise encode whatever the last person did.

Once the rules exist, most of the work is mechanical and worth automating: acknowledging arrival to the referrer, extracting patient and referrer details from the document, de-duplicating the fax against the email, prompting the triage owner when an item ages past its target, running the outreach attempts on schedule, and closing the loop back to the referrer with the outcome. That is the scope of an AI agents and automation build, and the human decisions stay where they are. Pre-filling the intake form from what the referral already contains is the natural next step, using the method in pre-filling intake from records the patient already gave someone else.

One deployment question is worth settling early. Referral documents are dense with identifiable clinical information, and sending them to an outside extraction service is an egress decision, not a procurement one — the same question a hospital asks before an imaging study leaves its network, covered in clearing a study before it leaves the hospital network. Where the answer is that the documents may not leave, the options and their real costs are set out in private LLM deployment.

What a queue will not decide for you

The state machine makes referrals visible and ageable. It does not decide whether a referral is appropriate, how urgent it is, or which visit type it needs — those are clinical judgements, and a queue that quietly encodes them in a routing rule has taken a decision it was not asked to take. Build the queue so triage is a step with an owner and a turnaround target, and leave the content of the judgement alone.

It also does not fix referral volume that exceeds capacity. A practice with 6 weeks of unbooked referrals and a full template has a capacity problem that a better queue will describe precisely and not solve. That is still worth having: an accurate backlog with an age distribution is what makes the conversation about sessions, providers or redirection possible at all. The rest of this territory sits in front desk, intake and patient access, within our healthcare operations work.

• referrals
• patient access
• front desk
• workflow