Shared queue for branches or separate queue for each branch?

In multi-branch facilities a usual paradox appears: one branch with a long waiting list and another with out of capacity. The joint list solves this in theory, but it may create another problem if applied without restrictions – offering an appointment in a distant branch to a client who chose the one closest to his residence.

The operational situation addressed by the topic

A client registered on the North Branch waiting list and is waiting two weeks. In the southern branch, an appointment is available tomorrow with the same service. Is it offered? Should he be asked first? What if he accepts and then it turns out that his usual specialist is in the first branch?

The most difficult question is: who decides – the system automatically, the reception, or the client himself?

The requirements you write for the resource

• Register branch preference: A specific branch, any branch, or a list of acceptable branches — selected by the client upon request.
• Filter under preference: Not to be offered an appointment in a branch that the client has not accepted.
• Service availability by branch: Not all services are available in every branch, nor are all specialists.
• Continuity of follow-up: For an existing case, the priority is to stay with the same specialist, not just find the quickest appointment.
• Session calculation for executing branch: So that each branch’s reports remain accurate.
• Unserved Request Report by Branch: To make it clear where the real pressure is and where the broken capacity is.

A practical example of testing the procedure

• Register a request preferring one branch, then edit an appointment in another branch: was it offered? Expected: No.
• He registered an application for admission to two branches: Was he nominated for an appointment in which of the two branches was he released?
• Try an existing follow-up case: Did the nomination keep the same specialist?
• Conduct a session for a client from another branch: For which branch was it counted in the reports?
• Request an unserved demand report divided into branches.

There is a practical compromise: a separate list for each branch, with reception notifying that there is capacity in a nearby branch and offering it to whomever it deems appropriate. This combines the benefit of sharing while keeping the decision human — and works better for most groups than automated cross-branch filtering.

Controls and exceptions

• Desire before capacity: Filling a vacancy is an operational goal, but offering a remote branch to someone who doesn’t want it does more harm to the experience than good to the table.
• Therapeutic follow-up first: In ongoing cases, continuing the relationship with the specialist is more important than shortening the wait — and the decision is professional, not mechanical.
• Price difference: If prices differ between branches, the client must be informed before acceptance, not after.
• Start with independent lists: If you’re just starting out, stand-alone menus are simpler. Activate sharing after pressure patterns between your branches become clear.

Next step for system review

Check your numbers: Is there really a pressure differential between your branches? If not, the joint list is an unnecessary complication. And review Multi-branch establishments page.