How to Allocate Placements by Merit and Preference (Step by Step)

Almost every institution runs the same operational ritual at least once a year, even though they rarely call it by the same name. A medical school posts its new house officers to hospitals. A teacher-recruitment board posts new cadre to schools. A university assigns students to limited-seat programmes, to elective blocks, to thesis supervisors, or to internship vacancies. A postgraduate office rotates trainees through a sequence of departments.

Underneath the different vocabularies, it is one problem: take a ranked list of candidates, a finite set of vacancies with capacities, and each candidate’s ordered preferences — and produce a placement that is fair, defensible, and reproducible.

Done by hand in a spreadsheet, this swallows a weekend, and the result is hard to audit when someone challenges it. This guide walks through how the allocation actually works, the three procedures you can choose between, and how to handle the awkward cases — couples, quotas, rotations — without losing the thread. You can follow along in the free Merit & Preference Placement Allocation Engine, which implements every step described here in your browser.

Start with the three tables

Every allocation reduces to three logical tables, no matter the domain:

1. Candidates — each with a unique ID, a name, and a merit rank (lower = better) or a score the rank can be derived from. Optional columns carry category (for quotas), a couple/link key, or a lottery number for tie-breaking.
2. Vacancies — each with a unique ID, a name, and a capacity (how many it can take). Optional columns carry location, group/zone, a minimum fill, and a cut-off score for eligibility.
3. Preferences — each candidate’s vacancies in priority order. This can be long (CandidateID, PreferenceOrder, VacancyID, one row per choice) or wide (CandidateID, Pref1, Pref2, …).

Before allocating, validate: no duplicate IDs, no preferences pointing at vacancies that do not exist, and a sanity check on total capacity versus the number of candidates. An over-subscribed pool (more candidates than seats) is fine — it just means some candidates will be reported as unplaced with a reason.

Procedure 1: Serial dictatorship (the default)

This is the procedure most posting exercises actually use, even when nobody writes the name down.

sort candidates by merit rank (1 = best)
for each candidate in rank order:
    walk their preference list from top to bottom
    assign them to the first vacancy that still has capacity
        and that they are eligible for
    if none is available → mark UNPLACED and record why

The appeal is that it is deterministic and trivially explainable. When a candidate asks why they did not get their first choice, the answer is exact: “Rank 14 received preference #2 because preference #1 was already full when their turn came.” That single sentence is the difference between a placement that survives scrutiny and one that does not.

Serial dictatorship is also the procedure that the couples, quota, and priority rules layer cleanly onto, because everything happens in a single, ordered pass.

Procedure 2: Deferred acceptance (when vacancies also rank candidates)

Sometimes the vacancies have opinions too — employers rank interns, hospitals rank applicants. Here you want a stable matching: no candidate–vacancy pair who would both rather be matched to each other than to what they actually got. An unstable matching invites people to go around the process, and it usually unravels.

Candidate-proposing deferred acceptance (the Gale–Shapley algorithm) guarantees stability:

while a free candidate still has untried preferences:
    that candidate proposes to their next preferred vacancy
    the vacancy tentatively holds its best proposers up to capacity
        (by its own ranking) and rejects the rest
    rejected candidates become free again and propose onward

When the vacancy’s ranking of candidates is simply the global merit order, deferred acceptance degenerates toward serial dictatorship — which is a useful sanity check. Use it when the two-sided ranking is real.

Procedure 3: Optimal assignment (maximise total satisfaction)

The first two procedures respect strict rank priority. Optimal assignment asks a different question: what allocation makes the cohort as a whole happiest? It minimises the total preference cost, where the cost of placing a candidate at a vacancy is that vacancy’s position in their preference list.

The trade-off is important and must be a policy decision: optimal assignment can hand a lower-ranked candidate a better slot than a higher-ranked one, if doing so improves the overall total. Only use it where policy explicitly permits utilitarian outcomes over strict merit priority. (Computationally it is solved with the Hungarian algorithm; keep the problem under a few hundred agents to keep a browser responsive.)

Handling the awkward cases

Couples / spouse linking

Two linked candidates should end up at the same location. The convention used across most posting exercises: process the pair at the better of the two ranks, but allocate both from the lower-ranked partner’s preference list, to the same hospital or station.

Worked example: partners at ranks 14 and 130 are linked. The pair is considered at rank 14’s turn, but both are placed together from rank 130’s list. The audit records that combined-preference logic so the outcome is explainable later.

Category / quota reservation

Reserve a number or percentage of seats for a category before open merit. Decide the order (reserved seats filled first, or open seats first) and whether unfilled reserved seats roll over to the open pool at the end. Rollover matters: without it, reserved seats that no eligible candidate claimed stay empty while open candidates go unplaced.

Priority / bonded groups

Bonded or priority candidates get a rank advantage — either jumping to the front of the order, or receiving a fixed rank offset. Apply this before the main pass.

Sequential rotations (multi-period)

For postgraduate rotations, run the chosen procedure once per period and carry forward constraints between periods — most commonly no-repeat (a trainee should not land the same department twice) and must-rotate across locations. The output is a per-candidate timetable across all periods.

Manual locks and hold-outs

Pin specific candidate-to-vacancy assignments before anything else runs, and route everyone else around them. Exclude deferred candidates or vacancies that are not part of this round.

Rule order matters. Locks before everything; quotas before open merit; couples resolved before the ordinary serial pass. A good tool makes the order explicit and reorderable.

Make it reproducible

The single most valuable property of a placement process is that two people running the same inputs get — and can prove they got — the same result. That means: a fixed random seed for any tie-breaking, and a run signature (mechanism + seed + rule set + timestamp) stamped on screen and on every export. When tie-breaks are involved, “random” must mean “seeded and repeatable”, never “different every time”.

Run it end to end

To see all of this working on real sample data:

1. Open the free Placement Allocation Engine and load one of the built-in scenarios (medical internship with couples, postgraduate rotations, teacher posting with district quotas, or university seat allocation with cut-offs).
2. Import your own three tables by paste, CSV, or Excel — columns auto-map by header name.
3. Choose a mechanism, add the rules your policy requires, and click Run Allocation.
4. Review the posting list, the per-candidate audit trail, the unplaced list with reasons, and the per-vacancy fill — then export to PDF, Excel, or CSV.

A process that allocates real postings deserves to be both fast and defensible. Getting the three tables right, choosing the procedure deliberately, and keeping a run signature on every export is how you get there.